Overview
It is a common misconception that a web application penetration test and a bug bounty program are the same thing. Although a lot of the skills transfer over and the methodology is very similar, the biggest difference between the two is that a bug bounty program is not governed by time for the tester to find an issue with the application, while web application penetration testing is time-dependent and typically expected to be completed in as short a period of time as possible.
In an attempt to achieve an organization’s goals in these limited-time frames, web application penetration tests should include the option of allowing the tester access to or a copy of the application’s source code. Providing the source code to the tester also allows for the discovery of other vulnerabilities present in the code base that would not have been found without it.
Considerations
As web applications evolve, the initial content discovery can consume a great amount of time or may not be 100% complete without the source code of the application – leaving the allotted time to discover bugs in the application short. Providing the source code to the application allows for the entire code base to be reviewed for vulnerabilities and identify any sensitive areas of the application that should be avoided during dynamic analysis (such as a form that sends emails).
Consider internal penetration testing for a moment. You are trusting the tester behind your firewall and in your production network. Now back to web application penetration tests: if you trust the same team inside your network to discover vulnerabilities, would you not trust that team with the source code of the web application? That trusted team with access to the source code can assess the whole code base in a greater detail and potentially discover bugs not known without the source code, such as blind SQL injection vulnerability and deserialization vulnerability.
Example
Consider a page located on the application 10 directories deep /one/two/three/four/five/six/seven/eight/nine/ten/page.php with the following source code snippet:
<?php
echo $_POST[“name”];
?>
This page may be missed during the discovery of the application and the parameter to the page almost unknown. In this very simple example, we can clearly see that this page is vulnerable to cross-site scripting attacks and should be reported as part of the penetration test.
In another example lets look at the following code snippet:
String query = “SELECT account_balance FROM user_data WHERE user_name = “
+ request.getParameter(“customerName”);
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}
Upon initial inspection, there looks to be a SQL injection vulnerability present, but it is unclear where the results of the query are used; therefore unless the results are echoed back in the response or the tester can trigger some out-bound service with a server-side request forgery attack (or is very lucky with timed-based queries) the vulnerability could be missed during a penetration test without the source code.
Providing the tester with the source code to this application allows the tester to quickly see that user-supplied input is used in conjunction with a SQL statement, and then the tester can see if any sanitization is made to the parameter prior.
Contributed by Joe Thorpe, Senior Security Consultant at Foresite.
