Unusual cases of reflected XSS
Today, I would like to talk about some cases, connected with XSS attack, which I faced with during web-application security analysis (in private bug bounty).
First case - XSS in burp, but not in the browsers
Analyzing requests in Burp, I paid attention to one of them; the parameter appeared on the web page without filtering.
I was surprised, because I thought that many researchers had already analyzed this web-application. I look through old Bug Bounty programs or well-known applications with aiming to find interesting vulnerabilities or to work with unknown for me software (servers, programming languages, frameworks, etc.)
Because the GET parameter was vulnerable and there was no protection against CSRF, I copied the URL and tried to follow to this address in browser
I tried to remove this header in the old request and sent it again. Really, reflection disappeared. Hm-m, I tried to set Referrer to «https://subdomain.vulnerable.com» and nothing new happened. After that I recovered the old Referrer (https://subdomain.vulnerable.com/PublishTools/) and again saw the reflection that I was needed. After some attempts, one idea came to my mind that logic on the server may be something like that:
- Check the domain: «subdomain.vulnerable» must be include in it
- Check the URL path: it must exactly be «/PublishTools/»
If both points are true, the referrer will be valid and vulnerable parameter will be displayed on the page.
I checked this idea and I was absolutely right. Having added the A record
subdomain.vulnerable.mysite.com A 184.108.40.206 from my domain name registrar (220.127.116.11 – my server ip), I created the «PublishTools» folder and the «index.html» file on my web-server. The source code of the «index.html» file:
<a href="https://subdomain.vulnerable.com/ToolForPagePreview?preview_url=<svg/onload=alert(1)>" id ="a_id">Click</a> <script> document.getElementById("a_id").click(); </script>
And now, after opening the http://subdomain.vulnerable.mysite.com/PublishTools/ page, an automatic click on the https://subdomain.vulnerable.com/ToolForPagePreview?preview_url=<svg/onload=alert(1)> link will be performed and you will open this page with the following Referrer header:
Second case - XSS, but not for everyone
You can try to solve the same XSS challenge before reading the continuation of the blog. Important: try your XSS vector in different browsers for a full vector that will work for any user.
Analyzing requests on Burp, I found explicit XSS again. Application hasn’t custom headers, but it has one strange value of GET parameter similar with CSRF-token. After removing all Cookies, I sent request again through «Repeater» tab and saw the reflection.
OK, copied the URL and sent request in browser for checking reflection and making screenshot for the report. I saw the needed alert box and started to make a report about dull reflected XSS. I don’t know why, but during creating the report one idea came into my mind and I checked the reflection in Chrome browser. When I opened URL with a payload I didn’t see alert box, even reflection of «name» parameter disappeared.
So, I faced with something interesting and probably this suspicious behavior connected with
cdp parameter. At the beginning, I started to search the value of
cdp parameter in Burp history and found it on the one page. It was clear that its value depends on which User-Agent we are using when opening the page. I changed User-Agent to string «a» and tried to find the shown on the page hash in Google. This hash wasn’t found, this means that we cannot calculate it by themselves, because of the salted data.
For solving this problem, we need to change the victim’s User-Agent to the one whose hash we know, or somehow figure out the victim’s hash. First case is impossible, on my opinion, so I decided to create the attack scheme like that:
- Victim opens the previously created php script
- Script takes User-Agent header from victim’s request and send the new request with this User-Agent to the web page where the hash value written
- Grab the token from web page for next request
- And finally, redirect victim to the page with malicious payload and correct token which was generated for his User-Agent