About Ricardo Zuasti

Anti cross-site scripting (XSS) filter for Java web apps

Here is a good and simple anti cross-site scripting (XSS) filter written for Java web applications. What it basically does is remove all suspicious strings from request parameters before returning them to the application. It’s an improvement over my previous post on the topic.

You should configure it as the first filter in your chain (web.xml) and it’s generally a good idea to let it catch every request made to your site.

The actual implementation consists of two classes, the actual filter is quite simple, it wraps the HTTP request object in a specialized HttpServletRequestWrapper that will perform our filtering.

The wrapper overrides the getParameterValues(), getParameter() and getHeader() methods to execute the filtering before returning the desired field to the caller. The actual XSS checking and striping is performed in the stripXSS() private method.

Awesome post, I see you mentioned that one should configure the filter
as the first in the chain. Why is that? I can think that the reason is
to also protect the other filters but I’m not sure if that’s the main reason.

I was thinking about creating a jar with a web-fragment.xml and use it
in my web applications, but then the filter wouldn’t be the first.

Venkat, (and everyone else) its going to. It is patently NOT possible to input-validate away XSS attacks. The sheer amount of different browsers and encoding schemes means that you are ALWAYS going to leave some stone unturned. The only way to prevent XSS is to ensure that you’re escaping output for the correct context(s), and doing basic input validation on the front end. At no point do you EVER consider user input “trusted.” Burp Intruder + FuzzDB will unravel virtually ANY XSS-filter scheme. There’s a reason that OWASP has refused to write an XSS-Filtering library. This cheat sheet will show… Read more »

Earlier we used the filter you provided in your previous post and we were able to get through scan, can you please let me know what is the difference between these two filters.

“It is patently NOT possible to input-validate away XSS attacks.” does this mean we cannot prevent XSS attacks completely by using this filter and it is better to do output escaping and basic input validations?

“does this mean we cannot prevent XSS attacks completely by using this filter and it is better to do output escaping and basic input validations?” Yes, that’s exactly what I mean, and the reason why goes back to CS theory. Input validation in every practical usage I’ve experienced utilizes regular expressions, however, HTML and Javascript are not regular languages. Because of this, its mathematically impossible to write an input filter that really lets you treat your data as “safe.” Even after being run through the filter, data should still be treated as dirty. its MUCH more important to do output-escaping… Read more »

How to getParameter of hidden field and validate it, I tried to get parameter of hidden filed using getPatarmeter(String s) but it is not taking value of hidden field and hence I am not able to solve xss vulnerability of hidden field.
Please help

No, it does not work great, and you all who think it does need to heed both my words and the words of Guillaume and myself. I am a developer on the ESAPI project and have worked as a security engineer for 7 years. Guillaume contributes to find-sec-bugs and at least one other OWASP project. This filter as written is false security.

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.