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 <webskate...@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.lindh...@gmail.com>
> wrote:
>> A slightly cleaner way would be like this:
>>
>> <s:text name="resource.key" ><s:param><s:property
>> value="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 <webskate...@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="resource.key">
>>> <s:param value="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="v" name="resource.key">
>>> <s:param value="param1"/>
>>> </s:text>
>>> <s:property value="v"/>
>>>
>>> This works, but it is a lot of work. It seems to me it would be better
>>> if Struts2 supported
>>>
>>> <s:text name="resource.key" escape="true">
>>> <s:param value="param1"/>
>>> </s:text>
>>>
>>> or, better yet, had escape="true" as its default.
>>>
>>> Is there another way round this problem which I am missing?
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: user-h...@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
