Basically I'm doing this (in my jsp)
<%
String mode = request.getParameter("mode");
%>
Would , encoding every field/attribute in the form bean , be a viable option?
jeff mutonho
Craig McClanahan <[EMAIL PROTECTED]> wrote:
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=>>>
>>>
>>t>alert(document.cookie)
>>
>>
>>>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:
>>
>>
>>
>>instead of something like:
>>
>>
>>
>>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.
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]
---------------------------------
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
