In this day and age, you really can not come barging in with an alert(1) anymore when it comes to reporting a reflected XSS bug. It may seem hard but leveraging XSS is a process that can only increase the severity of our bug so we only have things to gain from it but exactly how do we leverage this issue type and what can we gain from it?
This article will be keeping bug bounties in the back of our minds where certain exploits might not be accepted as valid reports. You also have to know that XSS in an application where all information is supposed to be public is likely to not get accepted so you should probably not look for XSS on those types of programs.
Stealing cookies is so 2002
The first thing that often springs to mind when talking about XSS is stealing cookies but while this is a very effective and impactful method, it seems every developer and their grandmother knows about the httponly that can be set on a cookie these days. We usually want to steal a session cookie and if we are in luck, we might find the value of the session cookie reflected on the page somewhere but this does not happen often at all and it’s best to count on other techniques to raise the impact of your XSS attack.
So how exactly do you steal a cookie?
Reading data from the page
Usually, we have to be lucky that reflected XSS happens on a page where authentication is required. If this happens we might be able to steal some valuable data from the page itself. We can execute some simple JS such as “document.getElementById(‘adress’).innerHTML” and we can again send this data off to our own webserver.
This will leave a trace in our access logs with the address of the users.
Photo by Christina @ wocintechchat.com on UnsplashWhat else can we do?
Besides the attacks we previously talked about there is a lot more you can do with reflected XSS, for example you can try to:
Steal a CSRF token and change the email address for a full account takeover
Execute a damaging JS function such as deleteAccount()
Include a JS crypto miner which would tax the users’ computers to gain you profit. Of course, you should report this and not actually execute the attack.
Besides all the obvious stuff you could change the contents of the page which would open up a whole new world of pain and phising
What can stop an attack
Of course, developers did not sit still and there have been ways to thwart our attempts at XSS.
Content Security Policy ensures only content (images, scripts, …) from the defined sources can be included in the webpage. This is not really to prevent XSS but to lessen the impact of an XSS attack that might occur. CSP is a header or meta tag that the browser reads and has to implement, otherwise, CSP is not enforced. This means CSP is browser-based protection and might not even be implemented.
According to Mozilla “Content-Type is a representation header that is used to indicate the original media type of the resource (prior to any content encoding applied for sending)” an example of this could be:
Content-Type: text/html; charset=UTF-8
The browser still has to implement and enforce this which means that if the response is interpreted in an intended way.
Photo by Viktor Talashuk on UnsplashEncoding and filtering
As a developer, it is absolutely vital to properly filter and/or encode all data the user can enter. This can be in filenames, file content, shadow APIs, functionality that’s hidden deeper in the application, table headers, …
It really is not easy but it is vital to get this right as even with filtering, small amount of events might not get picked up and pass the filtering/encoding anyway.
Reflected XSS is a great issue and I love it but unfortunately the fun does end at <script>alert(document.domain)</script>