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.
CMSes (Content Management Systems) are a perfect target for XSS attacks: with their module installation features and the possibility to know all the requests done by a legit administrator of the system previously, it’s pretty easy to mount a CSRF (Cross-Site Request Forgery) attack against him/her.
Browsers accept “javascript:” in their address bar as a way to execute javascript code, which makes it a pseudo-protocol instead of a real one like “http:”, for example. It can be used in the same way as an URL when calling an external resource. Example:
Some sites offer spell checking as a feature of their search functionality or translation application. While this might be a good idea from an user perspective, it can also be a bad idea for one who is trying to avoid XSS in his/her code.
Some weeks ago, a XSS challenge was launched: the goal was to pop an alert(1) box in latest Google Chrome at that time (version 53). Code was minified (made by just one continuous line) which always brings interesting possibilities to handle input injections. Also, there was a CSP (Content Security Policy) header that didn’t allow external calls.
After a tester or attacker is able to pop an alert box, the next step is to call an external script to do whatever he/she wants to do with the victim. In scenarios where XSS is not possible with “<script src=//HOST>” or similar, we need to build the request to load our remote code.
