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:

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