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.
Note that this a collection of tweets about DAST (excluding any specific company pitch). In general, it seems like many companies are unable to utilize the potential of DAST yet because of limitations in most of DAST tools. This opens up opportunity for people to create new DAST tool to overcome current problems.
Many AppSec folks are struggling to get any real value out of commercial DAST tools. Many problems include tools being unable to record Authentication properly and test coverage issues.
OWASP ZAP and Burp Enterprise Scanner are popular tools used in DAST automation in DevSecOps pipeline.
Some AppSec folks are proxying their QA stage to ZAP or Burp in order to improve test coverage of DAST scan.
“DAST biggest issue in modern apps is not exactly ‘testing’ or even ‘detecting’ vulns, but crawling the same website to identify to the attack surface.” ~ Jeremiah Grossman
OWASP Attack Surface Mapper tries to use SAST to pre-seed attack surface for DAST scan.
An attacker can use Web Cache Poisoning technique to send malicious response to other users. The poisoning will happen when certain unkeyed inputs are not validated by the application and allowing the malicious response to be cached.
In most situations, you will need to guess the unkeyed header. If you are using Burp Suite, then Paraminer will be a useful plugin to use.
First, go to the Target tab and select the paths in scope. Then right click on all these selected paths and click Guess Header.
If you are using Burp Pro, then you can see the result appearing in Dashboard - Issue activity.
Some sites may use the Vary header in the response to decide when to use the cached response or to refresh the response from the server. In the lab example, we can see that User-Agent is used to decide when the cached is used. To target your victim, you will need to know their User-Agent and then use the User-Agent values in your poison payload.
In this example, we see how Web Cache Poisoning can cause DOM XSS in an application. In some cases, an application is taking some properties value from a JSON and then use the value dynamically in a DOM. The assumption is that these properties values can be trusted since they are controlled by the application. However if an application is susceptible to Web Cache Poisoning, then these properties value can be controlled by the attacker.
In the example, we first see that that there is a host injection issue. If you use X-Forwarded-Host, then the injected host value will be reflected in the response.
In the response, we can also see that the injected host name will be used for retrieving a JSON value. Using the given exploit server (in the lab), we can see the access log showing that a user is making a GET request to retrieve geolocate.json file.
After doing some tracing of the original JSON value, we can see that there is a property called ‘country’ which contains the value that will be passed to the innerHTML.
Since we found the attack surface, we can now create a JSON file in the exploit server. This will return a JSON which contains the DOM XSS payload. Access-Control-Allow-Origin need to be wildcard in order for the object to be shared with the application.
After this is completed, then we can see that the Web Cache Poisoning will be successful and the DOM-XSS payload will be executed.