Reputation: 1281
We had a penetration tester discover pages in our wicket 6 apps where a javascript injection attack could be successful. Basically put script tags with javascript in them into a form field, save it, and then it executes for the next person to view that record.
Now, my understanding is that Wicket is supposed to do it's own prevention of this, and will unless setEscapeModelStrings(false) is set. I noticed my guinea pig app had ALOT of fields with this set to false. Asking other devs why, no one knew. So I took the flag off...but was STILL able to enter those script tags and get them to execute.
On our non-Wicket apps, we have a javax.servlet.Filter set up to sanitize inputs by wrapping the request using HttpServletRequestWrapper as it begins the chain. Some of the Wrapper's methods are called when Wicket runs, but getParameter(), getParameterValues() nor getParameterMap() seem to be called to get the parameters that populate the model. It's like Wicket is using some other part of the API, but I have no idea what it is.
So here's my questions (I really just need one of these two methods to work):
Is there something else I need to do to get Wicket 6 to sanitize model strings and protect against XSS attacks beyond removing the setEscapeModelStrings(false) calls? Is there some Application class or something?
Can someone point me to where in the Wicket 6 code wicket pulls the parameters from the request to bind to the models and what part of the HttpServletRequest API it's using so that my wrapper can only provide sanitized versions of the inputs?
Upvotes: 1
Views: 569
Reputation: 17533
You should remove all setEscapeModelStrings(false)
calls if they are not really needed! These are the reason for the XSS problem you have.
Usually you don't need to sanitize the input. You need to sanitize the output! Before writing to the database you should sanitize your SQL, before writing the HTML back you need to sanitize it too, ...
Upvotes: 0