XSS Recombination Attack

Many web applications will attempt sanitize user input to avoid cross-site scripting. A very common example of this is in message boards where users are allowed to use a subset of HTML, but the administrators would still like to prevent malicious <script> tags. In many cases, it is possible to use the application's own sanitation routines against itself to inject an attack.

A recombination attack is able to subvert such sanitation by breaking up the attack string with content we know will be stripped. For example, if an attacker wishes to inject the classic <script>alert('xss')</script> attack but all <script> tags are blocked, they could attempt the following:

<scr<script>ipt>alert(0)</scr<script>ipt>

In the example above, the sanitation routine would identify the full <script> tags and strip them from the content. Assuming the application does not perform a secondary run of the routine, the end result is the desired code being injected into the site.

There are several ways to mitigate such attacks.

1. Sanitize all input by converting all greater-than and less-than signs into their respective HTML entity codes. This won't work if you need to allow users to submit a subset of raw HTML, so...
2. Avoid letting users submit HTML. Use another type of markup such as BBCode to allow users indirectly produce HTML formated messages.
3. If you absolutely must allow HTML, perform multiple sanitation runs. If you only run it a set number of times (x), then an attacker only needs to perform x+1 recombination attacks, therefore keep sanitizing until the input comes out clean. Since this may lead to a potential DoS depending on how expensive the sanitation routine is, you may want to simply abort the message if it comes up dirty.