> -----Original Message----- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 11:01 AM > To: Struts Users Mailing List > Subject: 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 > >>> > >>> > >>t>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. > >> > >> > >>> > >>> > >>> > >>> > >>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 "<" 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.
We live with the limitation that input data can't contain special characters like "<". In the rare cases where we absolutely need it, we use our own convention for escaping the input data and then unescaping it server-side. > 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. Thanks for the warning. I do remember seeing a problem a long time ago in the first iteration of my solution on 2.2. At present, all our Struts webapps that use it are running in a container that supports 2.3. So, that is no longer an issue for us. > >Maybe that says something about what they think of me? :-) > > > > > > :-) > > Craig Van --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
