Cross-site scripting can be one of the easiest vulnerabilities to discover, but to be successful with this type of attack, it is essential to learn how to get past filters. In the previous guide, we explored some ways to do this, such as abusing attributes and event handlers and tricking the application into accepting unusual characters. Now, let's take a look at more techniques used to defeat filters.
<script>var a = 'myteststring; ... </script>
If we can inject a payload, we can determine if this particular avenue of attack is vulnerable. By closing the single quote, terminating the statement with a semicolon, and inserting our desired code, we can do just that.
'; alert(1); //
Here we have ensured that the script will still function properly by commenting out the rest of the script with double slashes. We could also declare another variable and insert another opening quote, since we terminated the string earlier, and it should behave in much the same way.
One method is to use the escape character to escape the imposed escape character, like so:
<script>var a = '\\'; alert(1); //
This essentially un-escapes the blocked quote and allows the payload to execute. Another method is to utilize Unicode characters, which also allows the script code past certain filters.
eval('1 + 1')
If the application allows the use of this function, it can be used to deliver an XSS payload. Like before, we can use Unicode encoding within the string to sneak past the filter.
If the eval() function is blocked, which it often is, success can sometimes be found by encoding the actual characters of the function as well.
Another technique we can use is dynamic string construction within the eval() command.
<script>eval('al' + 'ert(1)')</script>
There is another function that can be used in lieu of eval() called fromCharCode(). This will construct a string from individual characters, which can be successful when more direct methods are being blocked.
<script>eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 49, 41))</script>
It's often useful to try a multitude of character sets when trying to beat filters. By encoding some or all of the desired payload, filters can sometimes be tricked into allowing input that would otherwise be blocked and discarded. Some encoded examples of the string "alert(1)" follow.
61 6C 65 72 74 28 31 29
141 154 145 162 164 050 061 051
01100001 01101100 01100101 01110010 01110100 00101000 00110001 00101001
Encoding can be utilized on particular characters, strings, and everything in between. In some instances, different character sets can even be combined to bypass defenses, so it pays off to experiment and explore all the possibilities pertaining to encoding when testing for XSS.
A web browser can automatically refresh the current page after a certain period with something called meta refresh. This is employed by setting a parameter in the meta HTML element. Meta refresh has been known to send the header without a referrer, so this can be an avenue of attack when referring URLs are not needed. We can utilize the pseudo-protocol technique that we covered earlier to inject our payload.
Sanitization is arguably the most common type of defensive filter encountered when performing XSS attacks. This process attempts to strip or encode some aspects of the payload in an attempt to render the code harmless or stop it from running correctly.
Sometimes an application will try to remove the first instance of a script tag. In these cases, this defense can often be overcome by using multiple tags.
The first tag gets stripped leaving the resulting code to execute as intended. In other situations, we can check if the filtering is done recursively.
Here, if the script tag is removed, the resulting code still works after being joined together. When it comes to beating sanitizing filters, diligence pays off. It is vital to discover precisely how the sanitization is being performed and what is being filtered to outsmart this defense method.
Another type of defense commonly encountered when probing for XSS flaws is input truncation. There's not much you can do when there is limited space to craft a payload, so depending on the situation, one has to devise clever ways of getting around this predicament.
One such situation arises when there are multiple elements of user input being returned on the same page. Let's suppose there is a page that contains the following elements:
<input type="hidden" name="id" value="54"> <input type="hidden" name="checksum" value="345123"> <input type="hidden" name="status" value="critical">
By spreading the payload across these three elements, we can effectively bypass the length restrictions in place for each element on their own.
<input type="hidden" name="id" value=""><script>/*"> <input type="hidden" name="checksum" value="*/alert(1)/*"> <input type="hidden" name="status" value="*/</script>">
The pieces of code between the comment marks (/* and */) get ignored, so the browser ultimately processes our payload as if it was injected in only one location, thus defeating the length limits imposed on each element.
XSS is one of the most common vulnerabilities on the web today, and as such there are no shortages of defense against this type of attack. Throughout this guide, we have learned a variety of methods that can be used to bypass filters and deliver a successful attack. Though we have covered a multitude of techniques, the best way to defeat defensive filters is often a combination these. All it takes is a little time, persistence, and ingenuity to be successful.