5 Lessons Learned From Hundreds of Penetration Tests

Web applications are the top vectors attackers use to pull off breaches. According to Verizon’s “Data Breach Investigations Report” (PDF), Web applications were the way in for roughly 70% of all breaches studied.

After conducting more than 300 Web application penetration tests, I see why. Developers keep making the same security missteps that create vulnerabilities. They often don’t use secure frameworks and try to write security code and authentication processes themselves.

It’s important to note how much pressure developers are under to bring products to market quickly. They’re rewarded based on how many features they can introduce as quickly as possible, not necessarily as securely as possible. This leads to taking security shortcuts and, down the road, vulnerabilities in Web applications.

Five Lessons for More-Secure Apps

Pen testers play the role of devil’s advocate and reverse engineer what application developers create to show where and how attackers gain access. The results have highlighted common fundamental mistakes. Here are five lessons software development companies can learn to make their applications more secure.

1. Attackers are still leveraging cross-site scripting (XSS). XSS has long been a popular Web application vulnerability. In 2021, it came off the Open Web Application Security Project (OWASP) top 10 list due to improvements in application development frameworks, but it’s still evident in nearly every penetration test we perform.

   It’s often thought of as low risk, but the XSS risks can be severe, including account takeover, data theft, and the complete compromise of an application’s infrastructure. Many developers think that using a mature-input validation library and setting proper HttpOnly cookie attributes is enough, but XSS bugs still find a way in when custom code is used. Take WordPress sites, for example — an XSS attack that targets an administrator is critical because the credentials allow the user to load plug-ins, thus executing code-like malicious payloads on the server.

2. Automated scanners don’t go far enough. If you’re only scanning Web applications using automated tooling, there’s a good chance that vulnerabilities slip through the cracks. Those tools use fuzzing — a method that injects malformed data into systems — but that technique can create false positives.

   Scanners are typically not up to date with modern Web development and don’t offer the best results for JavaScript single-page applications, WebAssembly, or Graph. Complicated vulnerabilities need a handcrafted payload to validate them, making the automated tools less effective.

   There’s a human element required for the most accurate and detailed analysis of vulnerabilities and exploits, but these scanners can be a complementary resource to quickly find the low-hanging fruit.

3. When authentication is homegrown, it’s usually too weak. Authentication is everything to securing a Web application. When developers try to create their own forgotten password workflow, they typically don’t do it in the most secure way.

   Pen testers often get access to other users’ information or have excessive privileges that aren’t in line with their role. This creates horizontal and vertical access control issues that can allow attackers to lock users out of their accounts or compromise the application.

   It’s all about how these protocols are implemented. Security Assertion Markup Language (SAML) authentication, for instance, is a single sign-on protocol that’s becoming more popular as a means of increasing security, but if you implement it incorrectly, you’ve opened more doors than you’ve locked.

4. Attackers target flaws in business logic. Developers look at features to determine whether they accomplish a customer’s use case. They’re often not looking from the other side of the lens to identify how an attacker might use that feature maliciously.

   A great example is the shopping cart for an e-commerce website. It’s business-critical, but often not secure, which creates severe vulnerabilities such as zeroing out the total at checkout, adding items after checkout, or replacing products with other SKUs.

   It’s hard to blame developers for focusing on the primary use case and not recognizing other, typically nefarious, uses. Their performance is based on delivering the feature. Executives need to see the other side of the coin and understand that the business logic should correlate to security logic. The features with the highest business value, such as a shopping cart or authentication workflow, probably aren’t the job for a junior developer.

5. There’s no “out of scope” in a good penetration test. Web applications can quickly become complex based on how many resources and assets go into them. Back-end API servers that enable the functionality of the main application need to be considered.

   It’s important to share all those external assets, and how they connect to what the developers built, with security auditors that conduct penetration tests. The developer may consider those assets to be “out of scope” and that they therefore aren’t responsible for them, but an attacker wouldn’t respect that line in the sand. As penetration tests show, nothing is “out of scope.”

A Question of Balance

When software development companies understand some of these common risks up front, they can have better engagements with security auditors and make penetration tests less painful. No company wants to hold its developers back, but by balancing creativity with security frameworks, developers know where they have freedom and where they need to align with the guardrails that keep applications safe.