RE: Dealing with XSS in struts
Jeff, The way that I solved this was to implement my own subclass of the TilesRequestProcessor (because we use Tiles) and then specify that request processor in the controller element of the struts config file. In this subclass, I override processValidate() and in my override I wrap the incoming request object with my own extension of HttpServletRequestWrapper (part of 2.3 Servlet API, but, you could just pull that class into your project to make this work with a servlet container that only supports the 2.2 version of the Servlet API). My extension of the request wrapper class has both a helper function to do validation of the request parameters for XSS *and* filtering on the parameter getter functions to prevent a round-trip back to the client of any nasty XSS stuff. This allows me to do the XSS check in one bottleneck and treat it as a form validation error when XSS request parameter data is detected. If the XSS validation check passes, then I call the super.processValidate() and let Struts take it form there. I suppose something similar could be done using a request filter, but, I like doing it inside the request processor where I have access to the associated Struts action mapping along with the request object. With the action mapping available to me, I can do logical forwarding using struts configuration settings in this context that I wouldn't be able to do with a separate request filter. I've used this technique successfully on several projects. In one project, the paradigm was to take the user back to the input page with an error message at the top and cleaned up data redisplayed in the form. In another project, they preferred to go to a separate error page specific to XSS errors. With this approach, I was able to implement the first way relying on the input setting of the associated action mapping. I was also able to implement the second approach using a global forward for the error page and doing a lookup (i.e., mapping.findForward()) to implement the error handling that way. Hope this helps, Van Mike Van Riper Silicon Valley Struts User Group http://www.baychi.org/bof/struts/ -Original Message- From: jeff mutonho [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 4:52 AM To: [EMAIL PROTECTED] Subject: Dealing with XSS in struts Hi What are the recommendations to deal with cross-site scripting in struts? I'm got an app that a use can access at a URL , let's call it http://localhost/myapplication , now doing something like http://localhost/myapplication/applicationInit.do?mode=script alert(document.cookie)/script reveals a pop-up box containing the currently set cookies. How can I block that from happening?Is there a way of encoding a form bean? Please help as this is critical to the app. jeff mutonho - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dealing with XSS in struts
jeff mutonho wrote: Hi What are the recommendations to deal with cross-site scripting in struts? I'm got an app that a use can access at a URL , let's call it http://localhost/myapplication , now doing something like http://localhost/myapplication/applicationInit.do?mode=scriptalert(document.cookie)/script reveals a pop-up box containing the currently set cookies. How can I block that from happening?Is there a way of encoding a form bean?Please help as this is critical to the app. One of the keys to avoiding the particular XSS attack you are talking about here is to be careful about how you render dynamic content that was originally entered by the user. For example, if your string above was read in to a bean property named mode and you wanted to render it as text in another page, you should use something like: bean:write name=mybean property=mode/ instead of something like: %= mybean.getMode() % Struts protects you because (unless you explicitly ask it not to), it will render as lt; so that the embedded script will not actually get executed. Using the runtime expression, or things like that, simply copy the bytes back out again with no filtering. jeff mutonho Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dealing with XSS in struts
-Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 9:47 AM To: Struts Users Mailing List Subject: Re: Dealing with XSS in struts jeff mutonho wrote: Hi What are the recommendations to deal with cross-site scripting in struts? I'm got an app that a use can access at a URL , let's call it http://localhost/myapplication , now doing something like http://localhost/myapplication/applicationInit.do?mode=scrip talert(document.cookie)/script reveals a pop-up box containing the currently set cookies. How can I block that from happening?Is there a way of encoding a form bean?Please help as this is critical to the app. One of the keys to avoiding the particular XSS attack you are talking about here is to be careful about how you render dynamic content that was originally entered by the user. For example, if your string above was read in to a bean property named mode and you wanted to render it as text in another page, you should use something like: bean:write name=mybean property=mode/ instead of something like: %= mybean.getMode() % Struts protects you because (unless you explicitly ask it not to), it will render as lt; so that the embedded script will not actually get executed. Using the runtime expression, or things like that, simply copy the bytes back out again with no filtering. However, this only protects you when you are diligent in all your JSP coding. My management was more comfortable with an approach (see my other recent posting on this same topic) that didn't rely on that being true. Maybe that says something about what they think of me? :-) jeff mutonho Craig Van - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dealing with XSS in struts
Van Riper, Mike wrote: -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 9:47 AM To: Struts Users Mailing List Subject: Re: Dealing with XSS in struts jeff mutonho wrote: Hi What are the recommendations to deal with cross-site scripting in struts? I'm got an app that a use can access at a URL , let's call it http://localhost/myapplication , now doing something like http://localhost/myapplication/applicationInit.do?mode=scrip talert(document.cookie)/script reveals a pop-up box containing the currently set cookies. How can I block that from happening?Is there a way of encoding a form bean?Please help as this is critical to the app. One of the keys to avoiding the particular XSS attack you are talking about here is to be careful about how you render dynamic content that was originally entered by the user. For example, if your string above was read in to a bean property named mode and you wanted to render it as text in another page, you should use something like: bean:write name=mybean property=mode/ instead of something like: %= mybean.getMode() % Struts protects you because (unless you explicitly ask it not to), it will render as lt; so that the embedded script will not actually get executed. Using the runtime expression, or things like that, simply copy the bytes back out again with no filtering. However, this only protects you when you are diligent in all your JSP coding. My management was more comfortable with an approach (see my other recent posting on this same topic) that didn't rely on that being true. Did you implement an escaping mechanism for cases where you legitimately needed a character in the input data? If so, you might still be at risk even with a filter, unless you are diligent as well. Side note -- using a servlet request wrapper on a 2.2 container, in the manner you did it, is playing with fire since the servlet spec (2.2) had explicit assumptions that the request and response objects passed around were the original ones on the request. That's why we had to play the strange games on file uploads in a 2.2 world, ensuring that we unwrapped the request before trying to use a request dispatcher. Maybe that says something about what they think of me? :-) :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
