Skip to content

Month: October 2020

OWASP Attack Surface Detector (ASD) – Demo

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.

What do Security Folks think about DAST?

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.

Interesting Tweets about DAST

Notes on Web Cache Poisoning

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.

Basic Example: Unkeyed Header

In the request, the attacker discovered that the X-Forwarded-Host value will be reflected in response. The application tries to load a tracking.js file from cache resources. When the attacker passes a specific host in X-Forwarded-Host parameter, the tracking.js file will be loaded from another path <malicious host>/resources/js/tracking.js. Consequently, this allows the attacker to control the content of tracking.js file and load malicious JavaScript (potentially leading to issues such as XSS).

Unkeyed header

Case of Unknown Header

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 our poison request, we have used X-Host and the victim’s User-Agent. Keep sending the request until you see the X-Cache is hit
In the Vary header, we see that User-Agent is used to decide the cache response decision.

DOM XSS from Web Cache Poisoning

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.

If we examine the JavaScript carefully, we can see that the country value is taken from the JSON file and then assigned to innerHTML. This is a classic DOM XSS attack surface to take note.

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.

UI showing the JSON value

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.