Re: Dealing with XSS in struts

[Craig McClanahan]

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 "&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]