What I've learned from conducting 300 web application pentests

Nick Merritt is Halo Security's VP of Security and is the lead architect of the Halo Security solution. Throughout his career, he’s conducted over 300 web application penetration tests for companies of all sizes and across all industries.

Nick shared the top 10 lessons he’s learned from those experiences in an ebook to help security teams avoid the most common web application security mistakes.

In this post, we’re giving you a preview of 3 lessons Nick talks about in his ebook. To read the complete ebook, download it here!

Lesson 1: Almost every web application is vulnerable to Cross-Site-Scripting (XSS).

While the OWASP Top 10 no longer lists cross-site-scripting (XSS), and improvements have been made in modern web frameworks to eliminate the issue, it is still one of the most commonly found vulnerabilities in a web application penetration test.

Even when clients have done everything right, like using a mature input validation library or framework and setting proper HttpOnly cookie attributes, these bugs tend to sneak in anywhere that custom code exists.

XSS attacks seem to get categorized as low risk, but experience has proven that these can often be much more severe. Risks range from account takeover of a user (leading to the theft of personally identifiable information) to complete compromise of the underlying application or infrastructure in a role-based application where administrator-type users exist and sensitive functionality is exposed.

For example, with WordPress sites, an XSS attack is of critical severity when targeted at an administrator due to the user’s ability to load plugins and thus execute code on the server.

Lesson 2: Most automated web application scanners can only go so far.

Automated scanners are typically only able to find previously known vulnerabilities or unknown ones through fuzzing. The bugs that scanners can find through fuzzing can often be false positives. Even in cases where a particular bug may exist, they tend to fail because more complicated vulnerabilities require a handcrafted payload for successful validation and exploitation.

Web applications that rely heavily on JavaScript single-page applications or utilize technologies like Web Assembly/GraphQL/etc. are often missed or have poor results due to scanners not being up to date with modern web development.

Scanners should complement a manual penetration test, not replace one. While scanners can quickly find the low-hanging fruit, the only way to guarantee reliable results is to have an experienced auditor manually look at every endpoint and maximize coverage.

Lesson 3: The weakest link tends to be authentication.

Vulnerabilities are almost always found in the authentication process, whether logging in or resetting a password.

It’s often possible to enumerate accounts on the system by looking at the response between a valid account and another that the auditor knows does not exist.

Lack of rate limiting for failed login attempts makes the application a target for brute-forcing or credential stuffing attacks. An attacker can discover a valid login or database of credentials by attempting every possible combination.

Authentication schemes like OAuth are often exploited when a predefined or allow listed redirect URL is not specified. This weakness can allow attackers to leak access tokens and bypass the authentication process.

Liking the ebook so far?

If you enjoyed this preview, download the complete ebook 10 Lessons I’ve Learned from Conducting 300 Web Application Pentests to continue reading.

Editor's note (Nov 2022): This article was originally posted on the TrustedSite blog in Apr 2022. It has been updated for the Halo Security blog.