Reproducing the vulnerabilities documented in a pentest report is a common engineering pain point. But aligning developer skills with the tooling used during the pentest can help confirm issues faster, and deploy fixes faster.
The Tools Of The Trade
BurpSuite (or “Burp”) is the industry standard framework for performing professional application penetration tests. For developers, there are a few key features that greatly improve on standard browser debuggers:
- Clearly view raw requests/response pairs.
- Replay (and modify) requests.
- Intercept (and modify) requests.
Installing BurpSuite
Burp has a free community edition that contains all the key features above. This can be downloaded here: https://portswigger.net/burp/releases
How it Works
Burp is “MITM proxy” and thus can inspect all HTTP and Websocket traffic. A browser must be configured to use the local proxy (127.0.0.1:8080) and trust Burps root Certificate Authority certificate. Fortunately, Burp includes a pre-configured Chrome binary:
Navigate to Proxy – Intercept – Open Browser to open the browser.
Once you open the browser, you can navigate and authenticate to your application. By default, “Intercept” is toggled on, and you will probably want toggle that off:
Trusting the Root Certificate
Burp needs to proxy TLS connections and must be able to inspect SSL. If you see certificate errors with the pre-configured browser, you should install Burp’s CA certificate at the system level.
When Burp is running, a web interface is available at http://burp from the configured browser.
On Windows you can follow the following steps to trust the certificate:
1 Click CA Certificate and download the cacert.der certificate. 2 Double-click the der file and click Install Certificate 3 Select Current User 4 Select Place all certificates in the following store 5 Select Trusted Root Certification Authorities
Reproducing Common Pentest Vulnerabilities
Now let’s look at some real world examples of vulnerabilities we can test for. These examples highlight workflows that can be used to confirm and test for a great deal of pentesting test cases.
Are Session Tokens Invalidated After Logoff?
When a user logs out of an application, the session token should be terminated. A common vulnerability exists when the token is only cleared from the browser, and not actually invalidated by the application. To test for this we can do the following:
- Login to the application and generate a request that proves we’re authenticated. Below a request retrieving chart data will work great.
- Send the request to ‘Repeater’
In Proxy – HTTP History we can right click on any request and send its contents to repeater:
- Click Logout to end the session
- Return to the repeater tab, and send the previously used request.
Now we can see the session token cannot be replayed and is now terminated on the server side. Had we seen that we can still use the request to access the API, the vulnerability would be considered still open.
Modify a Request “on the fly”
In many situations it will be difficult to simply replay a previous request. In cases of file uploads, single-use CSRF tokens, and other complex requests, it is easier to use a browser to make each new request.
By using Burp’s Intercept, we can tell Burp to hold all requests before sending them to the server. We can then modify, forward, or drop all requests as we please.
Reproducing Cross-site Scripting (XSS) Vulnerabilities
Scenario: Our super secure app uses JavaScript to prevent users from entering bad characters. But the pentest team told us they still found XSS in a form field.
When trying to reproduce this with a browser, our security controls worked! How could this be?
As it turns out, client-side security controls are fundamentally flawed; users ultimately have full control of client-side JavaScript. To bypass these controls, a pentester can use the form as it was intended, but enable Burp’s Intercept. When this feature is on, all requests are halted here so we can edit and forward or drop before they are sent on.
In the example below, we populated the form with safe characters, but injected the dangerous payload here:
Miscellaneous Raw Requests
By now you should have the tools and skills to reproduce any vulnerability which is reasonably documented on an application pentest report. Remember that as long as you have a raw request, you can cut and paste this into Repeater. Just remember to update the actual network hostname of the application:
Other Common Pentest Issues
| Vulnerability | Test Method |
|---|---|
| Session Cookies Not Marked Secure | Observe response headers after authentication |
| Insufficient Cache Controls | Observe headers on pages containing sensitive data. |
| Username Enumeration | Login valid use/invalid password – send response to comparer. Login invalid user – send response to comparer. |
Helping Teammates with Curl Commands
Your teammates may not adopt Burp, but you can still help them. Burp allows any request from your proxy history to be copied as a curl command. Just right click anywhere you see a request displayed and Copy as curl command.
You can see this in your clipboard:
curl -i -s -k -X $'POST' \
-H $'Host: staging.example.com' -H $'Connection: close' -H $'Content-Length: 36' -H $'Accept: */*' \
--data-binary $'username=<script>alert(1)</script>' \
$'https://staging.example.com/api/settings'
Conclusion
These methods should give you the ability to quickly generate any request you need and modify them just as a pentester would.