The Complete Web Application Security Testing Checklist
1 like2,121 views
The document outlines a comprehensive checklist for web application security testing, emphasizing the importance of effective penetration tests to prevent application-level attacks. It details the necessary steps including information gathering, planning, executing tests, and documenting vulnerabilities, while also stressing the significance of manual testing for business logic and data flow. Lastly, it provides guidance on remediation and verification to ensure identified vulnerabilities are effectively addressed.
The Complete Web Application Security Testing Checklist
- 1. Get on-demand access to hundreds of security experts and premium testing tools with Cigital’s Managed Services. Learn more at www.Cigital.com Web Application Security Web Application Security Testing Checklist Testing Checklist Web applications are ubiquitous and plentiful. In fact, the web is the de facto delivery mechanism for both consumer-grade and business-critical functionality these days. As a result, the web is also the most common target for application-level attacks. To prevent any web application security oversights, use this checklist to guide you through the necessary steps to ensure your penetration tests are effective, efficient, and timely. Web applications are ubiquitous and plentiful. In fact, the web is the de facto delivery mechanism for both consumer-grade and business-critical functionality these days. As a result, the web is also the most common target for application-level attacks. To prevent any web application security oversights, use this checklist to guide you through the necessary steps to ensure your penetration tests are effective, efficient, and timely. This is required in case of lockouts and/or multiple team member access. Request an understanding of the permissions/role structure. Gather two credentials for each. 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 skips steps • Users can’t perform privileged activities without authorization Construct business logic and data flow. This includes areas where users are able to add, modify, and/or delete content. These locations require verification of input sanitization and output encoding. 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 mechanisms aren’t enforced. Determine highly problematic areas of the application. Ask the appropriate questions in order to properly plan and test the application at hand. Step 1. Information GatheringStep 1. Information Gathering Step 2. PlanningStep 2. Planning This is the point when you should write the report. Establish the “stop testing” deadline at which point the team will document all vulnerabilities. Assign an individual to configure and scan. Determine the types of automated tests to be performed. The application should be split amongst team members by functionality or vulnerability type, depending on expertise. Assign specific roles and credentials to each team member (if working as a team). If the application performs authentication, the following checks are applicable (not exhaustive): Session management Brute forcing Privilege escalation Password complexity Organize the types of vulnerabilities applicable for this type of application. 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. Internal status calls should take place 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 manager should walk through team status and then pass to team members for details. Set up status calls internally and externally. This should be done only when the client requests it. Document specific test cases. 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. Perform automated and/or manual crawling. Clients may request an output of tests performed even if vulnerabilities aren’t identified. Document and collect artifacts when vulnerabilities are discovered. Manual tasks cover business logic and dataflow 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. Perform manual tests. 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 automated tests and triage the results. Conduct tests and discover vulnerabilities (if any exist). Step 3. ExecutionStep 3. Execution Step 4. ReportingStep 4. Reporting This ensures that consistency, aesthetics, and technical writing remains intact. Conduct technical review of final reports. (If requested by client.) Review the results and make any appropriate adjustments based on the conversation. Perform a “report out” call. This should include descriptions, instances (affected URLs), roles, evidence, steps to reproduce, likelihood, impact, and remediation. Formalize results. Document results thoroughly and report to the client. It is the application owner’s responsibility to task a developer with specific remediation tasks. 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. Address and follow the remediation guidelines in the report. Address the vulnerabilities discovered during testing. Step 5. RemediationStep 5. Remediation Step 6. VerificationStep 6. Verification Perform filter evasion techniques for XSS, attempt escalation attacks with different roles, and perform redirects to different URLs. Ensure the fixes prevent “transformed” attempts at the same vulnerability. Look for specific previously identified issues. Review the application again. Confirm that the vulnerabilities found during testing are resolved and ensure the fixes can’t be evaded. The CompleteThe Complete