Encode brackets
%uff1cscript%uff1ealert(‘XSS’);%uff1c/script%uff1e
In this way, the angle bracket ＜ will be transformed by the DBMS to <
- Try also using UTF7 encoding
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
try also
or an updated one:
<~/XSS/*- */STYLE=xss:e/**/xpression(alert('XSS'))>
this last one works even if it lands in a already-opened double quote (example <<~/XSS/*- */STYLE=xss:e/**/xpression(alert('XSS'))> )
For sure working on
Microsoft Internet Explorer 6.0.2800.1106
Microsoft Internet Explorer 7.0.5730.13
Quite often, when injecting XSS payloads, the prior HTML tag has to be escaped by a double quotation mark followed by a left-angle bracket ('">') or similar. Otherwise, the injected scripting code is not executed by the client. ProCheckUp has found this last attack using the tilde ~ is a bit trickier to get working, as the injected payload must be returned within an existing angle bracket (in the image fname is the vulnerable paramenter)
Notes:
ProCheckUp found, after experimenting with different attack strings, that for style sheets IE would still execute code after a forward slash ("/"). Note: normally „
This works with IE, and yes you can evaluate scripts within style sheets! However, the aforementioned payload would not bypass ValidateRequest if patch MS07- 040 was applied.
[..]
The original expression( string was modified by splitting it up with comment strings (‟/**/‟) as reported by Roman Ivanov [6] . So the attack URL becomes: http://target.foo/test.aspx?varname=XSS STYLE=xss:e/**/xpression(alert('XSS'))> Which bypasses the 2nd filter (IE BUG #2). [..]
The original expression( string was modified by splitting it up with comment strings (‟/**/‟) as reported by Roman Ivanov [6] . So the attack URL becomes: http://target.foo/test.aspx?varname=XSS STYLE=xss:e/**/xpression(alert('XSS'))> Which bypasses the 2nd filter (IE BUG #2).
[..]
Procheckup found the comments ('/**/') can be used for more than breaking up the expression of the style attribute: they can be used to represent other characters such as spaces. For instance, putting the dash character ('-') within a comment, causes IE to (bizarrely) interpret /*-*/ as a space (IE BUG #3). So the attack URL then becomes: http://target.foo/test.aspx?varname=XSS/*- */STYLE=xss:e/**/xpression(alert('XSS'))>
[..]
This payload not longer bypasses the .NET filter, since Microsoft patch MS07-040 was released on July 10, 2007. Since that patch, the filter blocks requests including a forward slash character ('/') following a left angle bracket ('<'). i.e.:
By going through different payload permutations, ProCheckUp found that for style sheets, IE would still interpret HTML code after a left angle bracket, followed by a tilde, and forward slash („<~/„) (IE BUG #4) <~/XSS STYLE=xss:expression(alert('XSS'))> This code snippet is successfully executed by IE 6 and IE 7 fully patched, although the attack string has changed:
See also https://securityvulns.ru/files/bypassing-dot-NET-ValidateRequest.pdf
