[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42672 ]

Dale Newfield commented on WW-2316:
-----------------------------------

So the real danger here is in relying on url patterns to do the security checks, and not re-checking those restrictions within the action method.  I'd almost say that WW/Struts2 should officially discourage security by url patterns (FilterSecurityInterceptor) because there are so many ways (with different url patterns) to get the same action method to execute (!METHOD_NAME, ?method:METHOD_NAME, maybe more I don't know about).  And add in the documentation "If you insist on using that security mechanism, here are a few flags that can be turned off to help eliminate other paths to those methods: "allowDynamicMethodCalls", "allowAlternateMethodCalls", etc."


We briefly discussed this issue at a BOF at ApacheCon last night, where I suggested the simplest solution (from the struts webapp developer's perspective) would be to add to the action definition in struts.xml a per-action-definition whitelist, something like validAlternateMethods="cancel,view", but that is heading backwards towards more configuration rather than forwards towards convention.  I asked Don if there was a non-struts.xml way to do something like that, and he mentioned that there are annotations that enable you to add role restrictions for actions, and that those could be made to work for individual methods in the action...

> Ability to prevent method:METHOD_NAME access
> --------------------------------------------
>
>                 Key: WW-2316
>                 URL: https://issues.apache.org/struts/browse/WW-2316
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Dispatch Filter
>    Affects Versions: 2.0.11, 2.1.0
>            Reporter: Dale Newfield
>             Fix For: 2.1.1
>
>
> In order to allow multiple form submission buttons result in different behavior based on the button pressed, a specially named parameter is included in the form submission that instructs the ActionMapper to call a method indicated in the URL.  This special parameter can be used to implement a credential escalation attack, though:  If a user has suffiicient credentials to call a single method on an action, this provides a mechanism whereby they could call any method on that action.  The "action!method.do" capability introduces a similar vulnerability, and the "allowDynamicMethodCalls" option closes that hole.  Besides needing to provide a different mechanism to allow different form submission buttons to do different things, is there a large downside to using this same option ("allowDynamicMethodCalls") to close this hole as well?
> (Just to be explicit, that solution would wrap "if (allowDynamicMethodCalls) {" and "}" around lines 186-188 in org.apache.struts2.dispatcher.mapper.DefaultActionMapper.java .)
> http://www.nabble.com/forum/ViewPost.jtp?post=13710147&framed=y
> http://www.nabble.com/forum/ViewPost.jtp?post=13711925&framed=y

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.