General Description Of DOM XSS
For more information including labs and description regarding common DOM XSS flaws, I strongly recommend the following:
Background Behind The Flaw
A few months ago, while looking into my favorite program with wide scope on Synack Red Team, it came to my interest certain endpoints with
html extension that have been reported as DOM-Based Cross site scripting. Therefore, I proceeded to check the endpoints with the purpose to replicate the vulnerability, with the possibility to exploit the flaw in several more subdomains belonging to the client. The flaw ended up being exploitable in 3 more subdomains that were sharing all together 12 vulnerable endpoints.
Note: Information regarding the client’s name and paths will not be fully disclosed in this write up due to vulnerability disclosure policy.
When identifying and replicating the vulnerable endpoint, it displayed a blank HTML page with the following source code.
- The function
GetAttach()is being executed every time the user loads the web page due to
<BODY onload='GetAttach()'>HTML tag containing the
- The variable
strSearchis controlled by the attacker which allows to inject code after a question mark
(?), due to
location.searchproperty, which in this case works as an attacker controlled source from the URL.
- Later, the value variable
strSearchwill be passed to
document.location.replacewhich will trigger the XSS flaw every time the web page loads the web page, as
strSearchvariable is being controlled by the attacker from the URL, and it’s being passed to
document.location.replacein the DOM.
To conclude, the variable
strSearch will be the attacker controlled source from the URL due to
location.search property and the sink will be
document.location.replace as its using the
Then, create a Proof of Concept (PoC), the attacker proceeds to inject the payload
(?) which triggers the DOM XSS flaw effectively as:
Multi Path Exploitation
Once the flaw has been discovered and successfully exploited, it’s time to see what other paths are affected by the same flaw.
Therefore, it’s recommendable to fuzz common english words being gathered from english-words repository in order vulnerable paths that may contain the same flaw. This can be achieved by using ffuf as the following:
ffuf -c -v -w english-words.txt -u http://sub.domain.ca/web/source/tutorial/FUZZ/play/flaw.html -mc 200
After fuzzing english words in the vulnerable URL path the following were found:
Multi Domain Exploitation
Once the vulnerable paths have been gathered, it’s time to see what other subdomains are being affected by the flaw. This can be achieved by having a list of alive subdomains and with the usage of httpx. Then, the following can be used in order to test which alive subdomains are being affected, remember to repeat this for every vulnearble path:
cat alive-subdomains.txt | httpx -path /tutorial/fraud/play/flaw.html -status-code -content-length -mc 200
After recognizing more vulnerable paths, 3 more subdomains were being affected with the same 4 vulnearble endpoints which ends up with a total of 12 vulnerable endpoints in total.
Then, after recognizing all 12 vulnerable endpoints, it was reliable to report the vulnerability which thankfully was accepted and awarded with a
6.1 CVSS score.
If you’re a Synack Red Teamer, the analytics section can be a good way to start understanding a target as Ozgur explained in his article “Using Vulnerability Analytics Feature Like a Boss by Ozgur Alp”. In case if you’re in other platforms, you can use CrowdStream or Hacktivity for public available programs.
Any feedback and future recommendations are always welcome :)
Thanks for making it to the end!
If you want to chat or just connect, feel free to shoot a direct message on Twitter.