AOH :: HP Unsorted B :: BT-21525.HTM

Bypassing OWASP ESAPI XSS Protection inside Javascript



Bypassing OWASP ESAPI XSS Protection inside Javascript
Bypassing OWASP ESAPI XSS Protection inside Javascript



Bypassing OWASP ESAPI XSS Protection inside Javascript
------------------------------------------------------
By Inferno (inferno {at} securethoughts {dot} com)

Everyone knows the invaluable XSS cheat sheet maintained by "RSnake". It is
all about breaking things and features all the scenarios that can result in
XSS. To complement his efforts, there is an excellent XSS prevention cheat
sheet created by "Jeff Williams" (Founder and CEO, Aspect Security). As far
as I have seen, this wiki page provides the most comprehensive information
on protecting yourself from XSS on the internet. It advises using the OWASP
ESAPI api to mitigate any XSS arising from untrusted user input.

I was evaluating this ESAPI api and the recommendations given on the wiki to
see if there are any potential flaws. Any weakness impacts a very large
number of users since many developers are using it to strengthen their web
applications throughout the world. This is my way of contributing back to
the community, but can never match the immense efforts put by Jeff and other
OWASP team members in developing this library.

I want to give you a little bit of background before diving into the real
vulnerability. The XSS prevention cheat sheet classifies XSS protections by
dividing them into broadly four buckets - HTML Body injection, HTML
Attribute injection, Javascript injection and CSS injection. For each of
these four buckets, there is an ESAPI function reference you can use for
output escaping/encoding.

If you allow any untrusted user input into javascript functions
document.write() OR eval(), it can still execute the XSS even after you do
the scrubbing using the ESAPI encodeForJavaScript() function. The reason
being that hex escaped chars are converted back into normal chars at the
time of execution of these functions. 

Here is the proof of concept jsp code:

01.<%@page import="org.owasp.esapi.*"%> 
02. 
03.<%@page contentType="text/html" pageEncoding="UTF-8"%> 
04."http://www.w3.org/TR/html4/loose.dtd"> 
06. 
07.
08.    
09.        
10.        ESAPI XSS Protection Bypass
11.    
12.    
13.        

ESAPI XSS Protection Bypass

14.


15.

16. 35. 36. Much thanks to Jeremiah Grossman and Jeff Williams for taking the time to review my idea and providing their insights. Jeremiah told me that he has seen such injections from time to time at WhiteHat and these do exist in the wild. Jeff confirmed that some documentation changes will fix this. I agree that no esapi code change is required, because function themselves are not insecure. But, if you are currently using esapi functions inside your javascript code, it is important that you re-review your javascript code and the places where your make calls to esapi functions. If you use the esapi function encodeForJavaScript() inside document.write, it is advised that you change them with other appropriate esapi functions depending on the context where the data is ultimately landing. For example, if you have document.write(""), you know the data is landing in html body context, so it is appropriate to use encodeForHTML() wrapper. Using user input inside eval is less common, but more disastrous. The reason for this is you can still begin another command context using , and (space) char and it won't be encoded by function encodeForHTML(). So, it is better to avoid putting user input inside eval. Any more suggestions or discussion on fixes is highly welcome. Thanks and Regards, Inferno Security Researcher SecureThoughts.com

The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH
We do not send spam. If you have received spam bearing an artofhacking.com email address, please forward it with full headers to abuse@artofhacking.com.