Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <634c0af71002190716s6c98b81bm376a27b9d1c9e20d@mail.gmail.com>
References: <634c0af71002181425l64d0c6fcl3b91af687b0a2136@mail.gmail.com>
	 <74a2042d1002190624v10263394q51170fdd8e897049@mail.gmail.com>
	 <634c0af71002190716s6c98b81bm376a27b9d1c9e20d@mail.gmail.com>
Date: Fri, 19 Feb 2010 21:06:04 -0500
Message-ID: <e34c19111002191806t7333a4bbi9bbd60afa77c419@mail.gmail.com>
Subject: Re: XSS vulnerability with <s:text>
From: Wes Wannemacher <wesw@wantii.com>
To: Struts Users Mailing List <user@struts.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Go ahead and file a jira. Better yet, file one with a patch and unit
test. I don't know if we would make escaping the default (it might
break backward compatibility). But it is definitely worth putting in
the next release.

-Wes

On 2/19/10, John Orr <webskate101@googlemail.com> wrote:
> Thanks for the cleaner code - that is an improvement, and I'll use that
> idiom.
>
> I agree that generally <s:text> is intended for displaying safe text.
> However the use case "Hello, {0}" has to be pretty common, when
> something like a user name is inserted. Also the ability to access
> OGNL inside resource bundles ("Hello, ${user.firstName}") guarantees
> that parameters that may well originate with user input can end up
> inside <s:text>. (Note, parameter escaping wouldn't help in this
> case.)
>
> The problem becomes most serious if different people have different
> responsibilities. If the person responsible for writing the JSP's is
> not involved with the resource bundles or the action layer, then they
> have no way of knowing whether the text they are inserting is safe or
> not. And I'd say they really need a clean way to take responsibility
> to ensure what goes on the page is safe. Perhaps an "escape" attribute
> on <s:text> which defaults to "false" would help.
>
> Thanks, again,
>
> John
>
> On Fri, Feb 19, 2010 at 8:24 AM, Greg Lindholm <greg.lindholm@gmail.com>
> wrote:
>> A slightly cleaner way would be like this:
>>
>> <s:text name=3D"resource.key" ><s:param><s:property
>> value=3D"param1"/></s:param></s:text>
>>
>> I think in most cases <s:text> is used for displaying "safe" text that
>> the app either supplies or generates.
>> Obviously if you do use it to echo user supplied data you need to be
>> careful.
>> It would be nice to have a flag like you suggest however it might be
>> difficult to get the behavior exactly right since the text may contain
>> formatting tags and what you really want is to just escape the
>> parameters.
>>
>>
>> On Thu, Feb 18, 2010 at 5:25 PM, John Orr <webskate101@googlemail.com>
>> wrote:
>>> This is my first posting to this list, so excuse me if this is an
>>> issue that's already been addressed.
>>>
>>> My concern is with the XSS vulnerability in the following use case:
>>>
>>> <s:text name=3D"resource.key">
>>> =A0<s:param value=3D"param1"/>
>>> </s:text>
>>>
>>> It seems (Struts 2.1.8.1) that there is no mechanism in s:text or
>>> s:param to do HTML escaping. If param1 contains user input then this
>>> opens the door to XSS attacks.
>>>
>>> The easiest solution I can see is to modify the code to
>>>
>>> <s:text var=3D"v" name=3D"resource.key">
>>> =A0<s:param value=3D"param1"/>
>>> </s:text>
>>> <s:property value=3D"v"/>
>>>
>>> This works, but it is a lot of work. It seems to me it would be better
>>> if Struts2 supported
>>>
>>> <s:text name=3D"resource.key" escape=3D"true">
>>> =A0<s:param value=3D"param1"/>
>>> </s:text>
>>>
>>> or, better yet, had escape=3D"true" as its default.
>>>
>>> Is there another way round this problem which I am missing?
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--=20
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org