[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41904
]
jholmes edited comment on WW-2107 at 8/15/07 9:23 PM:
-----------------------------------------------------------
This change definitely breaks the application I am working on. I am using JSP
EL to dynamically specify an OGNL property. Here is an example:
<display:table id="row" name="groupSeekers" requestURI="${tableUrl}"
defaultsort="${defaultSortColumnIndex}" defaultorder="${defaultSortOrder}"
class="listing">
<s:iterator value="selectedColumns">
<s:if test="%{dateColumn}">
<display:column title="${title}" sortable="true"
headerClass="sortable">
<s:date name="#attr.row.${property}" format="MMM d, yyyy, hh:mm
a"/>
</display:column>
</s:if>
<s:else>
<display:column property="${property}" title="${title}"
sortable="true" headerClass="sortable" autolink="true"/>
</s:else>
</s:iterator>
</display:table>
Notice the <s:date> tag. Basically I have a configurable set of columns for my
table and each column is represented by a TableColumn object. One of the fields
on the TableColumn object is "property" which specifies the field name on the
object representing the row.
I'm not an OGNL expert, so I don't know if there is a way to represent
"#attr.row.${property}" using a pure OGNL expression instead of incorporating
JSP EL to dynamically specify the name of the property. I'm happy to use just
OGNL if I can find a solution.
was (Author: jholmes):
This change definitely breaks the application I am working on. I am using
JSP EL to dynamically specify an OGNL property. Here is an example:
<display:table id="row" name="groupSeekers" requestURI="${tableUrl}"
defaultsort="${defaultSortColumnIndex}" defaultorder="${defaultSortOrder}"
class="listing">
<s:iterator value="selectedColumns">
<s:if test="%{dateColumn}">
<display:column title="${title}" sortable="true"
headerClass="sortable">
<s:date name="#attr.row.${property}" format="MMM d, yyyy, hh:mm
a"/>
</display:column>
</s:if>
<s:else>
<display:column property="${property}" title="${title}"
sortable="true" headerClass="sortable" autolink="true"/>
</s:else>
</s:iterator>
</display:table>
Notice the <s:date> tag. Basically I have a configurable set of columns for my
table and each column is represented by a TableColumn object. One of the fields
on the TableColumn object is "property" which specifies the field name on the
object representing the row.
I'm not OGNL expert, so I don't know if there is a way to represent
"#attr.row.${property}" using per OGNL instead of incorporating JSP EL.
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> ----------------------------------------------------------------------
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
> Affects Versions: 2.0.9
> Reporter: Don Brown
> Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
> <s:text name="foo" value="${bar}" />
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
> <s:text name="foo" value="%{1+1}" />
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
> <input type="text" name="foo" value="2" />
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
