In this post, we will see how Attack Surface Detector (ASD) can be used to expand the attack surfaces of a web application. This is useful in improving test coverage of many Dynamic Application Security Testing (DAST) tools. As I have pointed out in this post, many DAST tools are not able to identify some attack surfaces during the spidering / crawling stage.
I will not go through how to install ASD.
First, clone this project and then run it. You will need to use Java 8. If you are using Java 11, then set JAVA_HOME and PATH to Java 8 (JDK).
Please follow this video first on how to install ASD extension in Burp Suite.
In the screenshot below, we can see that Target > Site map is showing the highlighted endpoints are generated from ASD. Select the highlighted endpoints and run an active scan.
We can see that Cross-site Scripting are detected in the imported assets from the source code.
To verify, we can load one of the attack payload to see the result.
Why ASD is useful?
There are times where the web application is so huge and no one have an accurate inventory of the endpoints. This means that there might be untested endpoints during DAST / Manual Testing. ASD helps to ensure at least the endpoints that are derived from the source code will be added to the testing.
Recently, I was doing a few labs on Command Injection. It was mentioned that in most situation, the tester will not be able to see the response of the injected command. Therefore, alternative ways will need to be explored to check if the Blind Command Injection exists in the web application.
One of the ways that we can validate the existence of the Blind Command injection is to inject a nslookup command. In this scenario, we can use Burp Collaborator to validate if the web application has performed a DNS lookup. Please refer to this lab for more details.
First, you will need to click “Copy to clipboard” in the Burp Collaborator client. Insert the copied URL into the vulnerable parameter. Send this request to the web server.
There are many available testing tools that help Security and Software engineers to automate their security testing. However, there are situations which requires some manual testing in order to discover vulnerabilities. Still, we don’t have to manual test the same test cases every time. After we discover the test workflow, we can write a test case in Postman and run it automatically in our CI/CD platform.
Capturing Traffic of the workflow
In this example, I will be using Burp suite (Community Edition) to demonstrate how we can capture the workflow and export it to Postman.
First, install the Postman Integration extension to Burp suite. This allows us to export the request to Postman.
Now, we will be using http://demo.testfire.net/login.jsp to capture a XSS payload request.
We can observe that the payload ‘<script>alert(‘1′)</script>’ appears in the response. Later on, we want to use this observation to write a test case that will fail the XSS test if ‘<script>alert(‘1′)</script>’ appears in the response.
Now we want to export this request to Postman. Simply right click on the request and click ‘Export as Postman Collection’.
There will be a pop-out that allows us to set the Collection Name and Folder Name. We can also name the Test case (in this case, I named it as ‘Test XSS in Search Bar’). After the values are set, we can export it and then import the file into Postman.
Open up Postman and click ‘Import’. Choose the exported file and import to Postman. The Collection will appear at the side menu and we will see a folder called XSS. The request will be found in the folder.
Run the test and we shall see that the payload is in the response.
Writing Test case in Postman to validate
Since we know that this web application does not use any JS Frameworks (like Angular / ReactJS), we can simply check if the response will return the exact payload to validate if it contains a reflected XSS vulnerability.
In Postman, click on the ‘Tests’ tab. We can write a test case to test for reflected XSS. So if the response does not include the payload ‘<script>alert(‘1′)</script>’, then it passes the reflected XSS. And we can include different payload as well to ensure that the web application defence against XSS is robust.
In this scenario, we can see that the test failed because reflected XSS is found.
1) First, intercept the GET request and then click on Action button. In the menu, select ‘Do intercept’ > ‘Response to this request’.
2) Click Forward to allow the GET request to be made. Then you will notice that you can now see the response from www.example.com
4) Finally, when you forward the edited response, the alert will appear and the body will show that it is tampered.