views:

624

answers:

2

I'm looking into some XSS prevention in my Java application.

I currently have custom built routines that will escape any HTML stored in the database for safe display in my jsps. However I would rather use a built in/standard method to do this if possible.

I am not currently encoding data that gets sent to the database but would like to start doing that as well.

Are there any built in methods that can help me to achieve this?

+4  A: 

not built-in, but check out the owasp esapi filter, it should do what you're looking for and more. It is a great open source security library written by the smart guys&girls at Owasp ("Open Web Application Security Project").

futtta
+5  A: 

You normally escape XSS during display, not during store. In JSP you can use the JSTL (just drop jstl-1.2.jar in /WEB-INF/lib) <c:out> tag or fn:escapeXml function for this. E.g.

<input name="foo" value="<c:out value="${param.foo}" />">

or

<input name="foo" value="${fn:escapeXml(param.foo)}">

That's it. If you do it during processing the input and/or storing in DB as well, then it's all spread over the business code and/or in the database. You should not do that, it's only maintenance trouble and you will risk double-escapes or more when you do it at different places (e.g. & would become &amp;amp; instead of &amp; so that the enduser would literally see &amp; instead of & in view. The code and DB are not sensitive for XSS. Only the view is. You should then escape it only right there.

Update: you've posted 4 topics about the same subject:

I will only warn you: you do not need to escape it in servlet/filter/javacode/database/whatever. You're only unnecessarily overcomplicating things. Just escape it during display. That's all.

BalusC
Yes maybe I should stop posting questions now... In terms of just dealing with output that is a conclusion I'm drawn to but I notice some sites advise you do output at the very least and then encode it on store over and above that.
AJM
You have good sites and you have bad sites.
BalusC
Yup, but do you know of a fairly definite source that I could point someone who is in love with the idea of persisting encoded HTML to in order to change their minds!!
AJM
It's nothing more than logical. It makes data unportable. The data is tied to a specific view. The data is also unmaintainable. You don't know what was escaped and what was not. Taking social actions in social sites is also impossible. You can't tell from data whether the user has malicious intents or so. You should **never** change user input. Only escape it from maliciousness right at the moment the data is about to be processed. E.g. escape SQL injections at the moment the data is to be persisted (PreparedStatement) and escape XSS at the moment the data is to be shown in HTML (fn:escapeXml)
BalusC
Good argument......
AJM
-1, performing HTML entity encoding on tags is not sufficient to prevent XSS exploits. You should also use a white list of allowed characters.
Pool
See here for a list of vulnerabilities associated with specific characters: http://ha.ckers.org/charsets.html You're giving very poor advice and you're not even aware of it.
Pool