Content Security Policy (CSP) is the last line of defense against the exploitation of a XSS vulnerability. When correctly implemented, it seems to be extremely effective in doing so (nowadays). Here we will deal with the possible ways to abuse flaws in its implementation. For a comprehensive reference on CSP check here.
Some basic samples are available for exercise before you check this post:
Some Cross-Site Scripting (XSS) vectors arise from strict but allowed possibilities, forming tricky combinations. It’s all about contexts and sometimes the interaction between different contexts with different filters lead to some interesting bypasses.
Although in the same document (or page), usually the source code of a HTTP response is formed by 3 different contexts: HTML, Javascript and CSS. They have their own syntax and different filters are applied to the output of user input to avoid XSS situations.
Testing for Cross-Site Scripting (XSS) might seem easy at first sight, with several hacking tools automating this process. But regardless of how tests to find a XSS are performed, automated or manually, here we will see a step-by-step procedure to try to find most of the XSS cases out there.
For that we will use the same approach employed by KNOXSS, our online XSS PoC tool. Although without details of its own implementation and intermediary steps needed to make its decisions (which will be done by ourselves if we follow the tests manually), this will cover pretty much what is done by this unique tool.
In some cases, an information passed in one of the HTTP headers of the application is not correctly sanitized and it’s outputted somewhere in the requested page or in another end, giving rise to a XSS situation.
But unfortunately, once an attacker can’t make a victim to edit his/her own HTTP headers in an actual XSS attack, those scenarios can only be exploited if the attacker payload remains stored somehow. Continue reading
Testing for XSS vulnerabilities requires knowing the data format of input. Usually the format is simply “string” without any restrictions but sometimes the manipulation of XSS entry point is limited.
In most of times it might lead to the assumption of a security filter, one designed/employed specifically to avoid the attack which is not true.
Simple JavaScript injections like ‘-alert(1)-’ or even \’-alert(1)// (see cases #6 and #7 here) are usually enough to pop an alert box in a vulnerable page when an input reflection happens inside a script block and no HTML injection is possible (case #5 of same post above).
But there are cases where the injection point lands in the middle of a more complex JS code: inside functions and conditionals (if or if+else), nested inside each other.
In multi reflection scenarios, like we already have seen here, it’s possible to use payloads in such a way that avoid filters and WAFs (Web Application Firewalls) due to the change in the order of its elements.
But in source-based JS injections (those which happen in script blocks) there’s another interesting consequence of having more than one reflection point.
The most common type of XSS (Cross-Site Scripting) is source-based. It means that injected JavaScript code comes from server side to execute in client side.
But there’s another main type, the DOM-based one, where injected malicious input does not come from server via reflected or stored means: XSS is generated in client side by native JavaScript code.
More than an year ago, in my private twitter account Brutal Secrets, I shared an interesting way to bypass Google’s Chrome anti-XSS filter called XSS Auditor. We will see now in details, from a blackbox perspective, a logical sequence of assumptions and conclusions that leads to our XSS vector responsible for the bypass.
When reading material on XSS subject we usually see the classical <script>alert(1)</script> as an demonstration of such vulnerability (PoC – Proof of Concept). While very true, it doesn’t go much beyond this, making the novice in this field to look for more in order to deal with real world scenarios.
Tweet This