The complete web application security testing checklist

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.

Web Application Security Testing Checklist Step 1: Information Gathering

Ask the appropriate questions in order to properly plan and test the application at hand.

Determine highly problematic areas of the application.

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.

Construct business logic and data flow.

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:

• Integrity of the workflow
• Users can’t bypass or skip steps
• Users can’t perform privileged activities without authorization

Request an understanding of the permissions/role structure. Gather two credentials for each.

This is required in case of lockouts and/or multiple team member access.

Step 2: Planning

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.

Organize the types of vulnerabilities applicable for this type of application.

If the application performs authentication, the following checks are applicable (not exhaustive):

• Session management
• Brute forcing
• Privilege escalation
• Password complexity

Assign specific roles and credentials to each team member (if working as a team).

The application should be split amongst team members by functionality or vulnerability type, depending on expertise.

Determine the types of automated tests to be performed.

Assign an individual to configure and scan.

Establish the “stop testing” deadline at which point the team will document all vulnerabilities.

This is the point when you should write the report.

Set up status calls internally and externally.

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.

Document specific test cases.

This should be done only when the client requests it.

Perform automated and/or manual crawling.

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.

Step 3: Execution

Conduct tests and discover vulnerabilities (in any exist).

Perform automated test and triage the results.

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.

Perform manual tests.

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:

1. A tester identifies a URL accessed by an admin that is slightly different from what they see: https://www.example.com/users/edit?id=123456&admin=false
2. They modify the URL in an attempt to act as an admin https://www.example.com/users/edit?id=123456&admin=true
3. Depending on the result, a vulnerability should be documented and the tester should navigate to similar pages to see if this issue is persistent.

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.

Document and collect artifacts when vulnerabilities are discovered.

Clients may request an output of tests performed even if vulnerabilities aren’t identified.

Step 4: Reporting

Document results thoroughly and report to the client.

Formalize results.

This should include descriptions, instances (affected URLs), roles, evidence, steps to reproduce, likelihood, impact, and remediation.

Conduct technical review of final reports.

This ensures that consistency, aesthetics, and technical writing remains intact.

Perform a “report out” call.

(If requested by client) Review the results and make any appropriate adjustments based on the conversation.

Step 5: Remediation

Address the vulnerabilities discovered during testing.

Address and follow the remediation guidelines in the report.

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.