Web application security testing has a lot of moving parts, but even with its complexities, it doesn't have to be that difficult. The trick is to know what you want, what you need and then take a measured approach to focus your efforts on the most important applications.
So how do you go about fully vetting your application environment to make sure you have no big security flaws in your critical applications? It's doable for even the most complex environments.
The following information lays out the what, when, why and how of most web application security testing scenarios, including figuring out what systems you need to test, which tools are best suited for the task, the use of vulnerability scanners and scanner validation, and additional manual checks.
1. What needs to be tested?
The scope of your security assessment is extremely important. You may have your own internal requirements or you may have to follow the requirements of a business partner or customer. And you need to get all the right people on board.
It must be clear which applications, network systems and code you need to test; how you will test them; and what your specific expectations are for the deliverables. This includes requirements for testing any specific user roles. I always recommend testing as a typical user, as an untrusted outsider and as a user with all the possible privileges within the application.
2. What tools are best suited for the task?
At a minimum, web application security testing requires the use of a web vulnerability scanner, such as Netsparker or Acunetix Web Vulnerability Scanner. For authenticated testing, you'll want to use an HTTP proxy such as Burp Suite, which allows you to attempt to manipulate user logins, session management, application workflows and so on.
It must be clear which applications, network systems and code you need to test; how you will test them; and what your specific expectations are for the deliverables.
Other tools are available if Source code analysis is a requirement, but be careful; you get what you pay for with source code analysis tools and, unfortunately, most are pricey. I'm not convinced the value of source code analysis is worth the money and effort involved. It could be a requirement, nonetheless, so it may have to be done.
3. Vulnerability scanning
Rather than trying to create a checklist of every test you need to run for every vulnerability for web application security testing, it's easier to break it down into the important categories. When running vulnerability scans, make sure your scanners are testing for the big things, like SQL injection, cross-site scripting and file inclusion. Running the scanner with an OWASP Top 10 or similar policy is often a great start. You might find you need to create a custom policy based on your application platform and specific requirements.
The focus of vulnerability scanning is mostly on Layer 7, but source code, cloud configurations and network hosts may need to be addressed. At a minimum, your automated tests should look for misconfigurations with SSL/TLS, as well as for vulnerabilities at the web and application server level.
Dedicated web vulnerability scanners should find most flaws, but I have found that you often need traditional network vulnerability scanners such as Nessus or Qualys to uncover everything at this level. Additional cloud security misconfigurations can be uncovered in AWS environments, for example, by using a tool such as Nessus or a dedicated tool such as Cloud Conformity.
4. Scanner validation and additional manual checks
As with vulnerability scanners, I can't possibly list all the checks you need to perform because there are so many potential areas for exploitation. The first thing you need to do is validate all your web vulnerability scanner findings to see what's exploitable and what matters in the context of your application and your business.
the login mechanism and session manipulations involving passwords, cookies and tokens;
functionality and flaws that are user- or web-browser specific;
application logic weaknesses that allow for manual manipulation of the business workflow and specific input fields; and
password policy exploitation, including complexity enforcement and intruder lockout capabilities.
This is arguably the most difficult and time-consuming aspect of application security testing. The main goal should be to look at your application with a malicious mindset and see what an attacker can do to the application using a good old-fashioned web browser and, as I mentioned above, HTTP proxy.
5. Document your findings and disseminate them to the proper people
Unfortunately, a lot of application security testing stops with step four. One of the most undervalued aspects of a formal application testing program is codifying your findings into a formal security assessment report.
This not only creates a paper trail and demonstrates due care, it is also helpful for other stakeholders, such as the development teams, DevSecOps staff and executive management, to reference. One of the quickest ways to lose support for application security initiatives -- and to get breached -- is to keep everything to yourself and keep others in the dark.
Every environment is different, and every business has its own unique needs. That said, a reasonable approach to web application security testing will likely involve some, if not all, of the above items. I see a lot of security assessment misperceptions, assumptions and oversights in my work as a security consultant, and much of that involves application environments.
There's too much at stake and too much that attackers can exploit to simply run basic scans with no formal risk evaluation or reporting. It's just as bad to write application security off as someone else's problem. Whether you are developing, hosting and maintaining your software in-house or via third parties, application risks and specific exploits will come back and land in your lap as something that you should have been doing all along. Make sure you're being smart with your approach.
