The Vulnerability of Web Applications – What You Should Target

Once you've narrowed down the program you're going to participate in – or maybe you've skipped that and are just plowing through random sites, looking for easy pickings – you can start evaluating individual applications for testing.

Doing so requires an understanding of each application's attack surface. As a quick refresher, Wikipedia sums it up succinctly:

We'll get into actual Attack Surface Analysis in the next chapter, preparing for an engagement, but it helps to have a simple idea of it while evaluating different options.

Using that definition of an attack surface and understanding that the larger the attack surface, the more opportunities there are to discover bugs, means we'll want to look for apps that have a lot of entry and exit points for information, ideally ones that are available to anonymous or otherwise not-logged-in users. Social media sites, or blogs and forums that allow anonymous commenters, are all input-rich environments, where the different types of posts, comments, reactions, and so on, provide many different vectors for possibly malicious information to enter the system.

Sites or applications with smaller attack surfaces obviously provide fewer opportunities to find vulnerabilities. A completely static site, where a web server is providing the HTML/CSS markup with no user data input, and no server-side language is interpreting or dynamically creating the site's content, is much more difficult to pentest with the aim of successfully discovering vulnerabilities – there are only so many ways the user can affect the site.

And as discussed briefly earlier in the chapter, web applications – regardless of type – that are protected by large security teams, exposed to large user bases, audited actively by other researchers, or all three, are the least likely to be fruitful hunting grounds. All of these factors combine to create a general portrait of a site's potential: a niche social network with a lot of opportunities for users to interact with the site and each other, created by a small startup, will be an easier target than a static site hosted on an Amazon S3 bucket, where there are no opportunities for user input and the security of the service is managed by a large, dedicated team.

With the concept of an application's attack surface in mind, some areas make for natural points of interest. OWASP categorizes the different types of attack points to help better model a site's risk:

• Admin interfaces
• Inquiries and search functions
• Data-entry (CRUD) forms
• Business workflows
• Transactional interfaces/APIs
• Operational command and monitoring interfaces/APIs
• Interfaces with other applications/systems

And of course many other actions that allow for user input. These are all opportunities to check for poor data-handling techniques and mishandled sanitization procedures.

As the web becomes more mature, applications become entangled in dependencies and subsidiary services. Those points of contact – APIs – are also great weakpoints to probe in any engagement. A slightly different set of techniques is required than testing through the UI of an application. For example, while testing an application's UI, you might look for an instance of frontend validation that isn't properly enforced by backend services, where you can circumvent the frontend checks or use different encodings to bypass security measures. That technique isn't as applicable to a public API that receives considerable traffic and is designed to be an exposed ingress layer – although it's still susceptible to vulnerabilities, they probably won't be as simple as encoding issues.