There are XSS scenarios where there’s a strong filter in place like WordPress’s KSES. That filter, like many others, uses a Whitelist approach allowing only HTML that’s harmless against the application. By default it allows only basic formatting tags like <b>, <i> etc, links <a href=URL>, images <img src=URL>, tables and several other HTML elements with attributes that can execute Javascript.

Needless to say, no script element or event handler is allowed. Neither the pseudo-protocol “javascript:” in any of the attributes that need an URL. XSS against those filters are only possible with a 0-day which will be probably fixed soon due to the level of exposure the applications that use those filters and libraries have.

Continue reading →

Property-based payloads are payloads based on some particular properties of the document object and the elements. From the document object we already know the location-based payloads and from the elements we have the properties  “innerHTML” and “outerHTML”.

Those 3 are very useful to evade a filter or WAF when we get to the point where the JavaScript code needs to be obfuscated. That scenario usually arises when we get past to the event handler in a HTMLi-based XSS vector but it can also be used in regular JavaScript injections (inside script blocks) or even in DOM-based XSS scenarios.

Continue reading →

When dealing with JavaScript injection scenarios sometimes we might get into a difficult situation: the target page is not meant to be accessed directly and some of its code is supposed to use some other code in the setup intended.

That leads to some broken script blocks and when the injection context is one of those sections, injection won’t work since the whole executing context is dismissed.

But due to a JavaScript feature named HOISTING it’s still possible to perform a successful XSS PoC (Proof-of-Concept) or attack by fixing the current syntax or by making use of remaining code in the next valid script blocks.

Continue reading →

XSS is all about practice. It requires a lot of time to print in the mind all vectors, payloads and tricks at our disposal. There are lots of XSS cases, each one requiring a different approach and construct to pop the alert box.

Thinking on that and following the previous XSS Test Page released with the blog post “The 7 Main XSS Cases Everyone Should Know“, a new set of XSS exercises was built to help with that practice both for beginners and advanced XSS testers, since the same XSS cases are useful to test and build new XSS vectors.

This new “workout” can be found in our XSS GYM.

Continue reading →

XSS polyglots are quite popular among beginners and lazy XSS testers since they only require a single copy and paste. Although doomed to be easily flagged by any decent filter or WAF, they can be useful to spot most of the XSS cases out there.

Here we will try to build a cost-effective XSS polyglot, with the least amount of characters possible and the maximum and best XSS cases we can come with. We will also add some key elements for validation and even some basic evasion tricks.

Continue reading →

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:

Learn & exercise your #XSS #CSP bypass skills!

Powered By the Tweet This Plugin

Tweet This

Continue reading →

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.

Continue reading →

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.

Continue reading →

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.

Continue reading →