Posted by Christopher Cummings on April 25, 2016
Did you know that the web is the most common target for application-level attacks? That being said, if you have ever been tasked with securing a web application for one reason or another, then you know it’s not a simple feat to accomplish. When securing your applications, it’s critical to take a strategic approach. This web application security testing checklist guides you through the testing process, captures key testing elements, and prevents testing oversights.
Tailor your approach and ensure that your testing strategy is as effective, efficient, and timely as possible with these six steps.
Ask the appropriate questions in order to properly plan and test the application at hand.
This includes areas where users are able to add modify, and/or delete content. These locations require verification on input sanitization and output encodings.
For example: Applications that allow users to enter large amounts of data such as blog posts, especially when done through HTML editors, are at high risk of injection attacks if proper prevention mechanism aren’t enforced.
This includes areas that require manual testing specifically focused on bypassing, escalation , and sensitive data disclosure techniques. Business logic flow can be defined as the data flow specific, and unique , to the application. This type of functionality is often overlooked with automated analysis.
For example: Functionality may include an approval workflow or privileged account access. A tester must ensure:
This is required in case of lockouts and/or multiple team member access.
Document your testing strategy to ensure each assessor knows what they’re working on and how much time they have to complete testing-related tasks.
If the application performs authentication, the following checks are applicable (not exhaustive):
The application should be split amongst team members by functionality or vulnerability type, depending on expertise.
Assign an individual to configure and scan.
This is the point when you should write the report.
Internal status calls should take places twice a week and include the testers and the project/client manager. External status calls should take place once a week and include the internal team and the customer(s). If possible, the project manger should walk through team status and then pass to team members for details.
This should be done only when the client requests it.
If required within the terms of the contract. This aids in the execution phase and provides details on scope if any adjustments need to be made.
Conduct tests and discover vulnerabilities (in any exist).
Automation tools should be carefully selected (cover common OWASP Top 10 vulnerabilities at a minimum). This allows testers to focus their skills on the business logic and data flow requiring manual analysis. Automated testing differs slightly per organization depending on what tools are licensed and/or internally built.
Manual tests cover business logic and data overflow specific to the application that are typically overlooked by automation. A manual test may look like the following:
Most tools send several requests to the same page to determine if the responses are different. Many tools state that a vulnerability exists when HTTP 500 errors are returned. It is the tester’s responsibility to review the request and the error message to determine if a vulnerability actually occurs.
Clients may request an output of tests performed even if vulnerabilities aren’t identified.
Document results thoroughly and report to the client.
This should include descriptions, instances (affected URLs), roles, evidence, steps to reproduce, likelihood, impact, and remediation.
This ensures that consistency, aesthetics, and technical writing remains intact.
(If requested by client) Review the results and make any appropriate adjustments based on the conversation.
Address the vulnerabilities discovered during testing.
It is the application owner’s responsibility to task a developer with specific remediation task. It is important to apply fixes in all similar locations of the code. Black box test may not be exhaustive and similar issues could exist.
Confirm that the vulnerabilities found during testing are resolved and ensure the fixes can’t be evaded.
Look for specific previously identified issues.
Perform filter evasion techniques for XSS, attempt escalation attacks with different roles, and perform redirects to different URLs.
Get the latest Software Integrity news, thought leadership, and more.