You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Dale Newfield (JIRA)" <ji...@apache.org> on 2007/11/13 01:53:36 UTC
[jira] Created: (WW-2316) ?method:METHOD_NAME vulnerability
?method:METHOD_NAME vulnerability
---------------------------------
Key: WW-2316
URL: https://issues.apache.org/struts/browse/WW-2316
Project: Struts 2
Issue Type: Bug
Components: Dispatch Filter
Affects Versions: 2.0.11, 2.1.0
Reporter: Dale Newfield
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.
[jira] Resolved: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Don Brown resolved WW-2316.
---------------------------
Resolution: Duplicate
Fix Version/s: (was: 2.1.1)
See WW-2363
> Ability to prevent method:METHOD_NAME access
> --------------------------------------------
>
> Key: WW-2316
> URL: https://issues.apache.org/struts/browse/WW-2316
> Project: Struts 2
> Issue Type: Sub-task
> Components: Dispatch Filter
> Affects Versions: 2.0.11, 2.1.0
> Reporter: Dale Newfield
>
> 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.
[jira] Commented: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Dale Newfield (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ted Husted updated WW-2316:
---------------------------
Issue Type: Sub-task (was: Improvement)
Parent: WW-2363
> Ability to prevent method:METHOD_NAME access
> --------------------------------------------
>
> Key: WW-2316
> URL: https://issues.apache.org/struts/browse/WW-2316
> Project: Struts 2
> Issue Type: Sub-task
> 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.
[jira] Commented: (WW-2316) ?method:METHOD_NAME vulnerability
Posted by "Jeromy Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42633 ]
Jeromy Evans commented on WW-2316:
----------------------------------
Also (in both cases) I'd also prefer to see a per-action configuration rather than a global option.
This would at least allow the existing submit button design to be unchanged and a relatively small code impact on existing applications.
ie. require the developer to enable method calls explicitly in the action config where applicable that overrides the global setting.
> ?method:METHOD_NAME vulnerability
> ---------------------------------
>
> Key: WW-2316
> URL: https://issues.apache.org/struts/browse/WW-2316
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
> Affects Versions: 2.0.11, 2.1.0
> Reporter: Dale Newfield
>
> 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.
[jira] Commented: (WW-2316) ?method:METHOD_NAME vulnerability
Posted by "Jeromy Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42632 ]
Jeromy Evans commented on WW-2316:
----------------------------------
It may need to be a separate flag from allowDynamicMethodCalls.
Dynamic method calls allows the developer to call public no-param methods matching a certain name pattern (eg do{1}) and hopefully they use this whilst aware of the venerabilities.
?method:METHOD_NAME provides access to any public no-param method.
I believe there are valid use-cases for the former option enabled without the latter.
> ?method:METHOD_NAME vulnerability
> ---------------------------------
>
> Key: WW-2316
> URL: https://issues.apache.org/struts/browse/WW-2316
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
> Affects Versions: 2.0.11, 2.1.0
> Reporter: Dale Newfield
>
> 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.
[jira] Updated: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Don Brown updated WW-2316:
--------------------------
Fix Version/s: 2.1.1
Issue Type: Improvement (was: Bug)
Summary: Ability to prevent method:METHOD_NAME access (was: ?method:METHOD_NAME vulnerability)
I changed this ticket to better reflect the feature and the proposed improvement. The ability to call any public, no-arg method on an action has been a key feature since WebWork 1. That said, I agree it would be nice to allow developers that don't use this feature the ability to disable it.
> 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.
[jira] Commented: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Dale Newfield (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42637 ]
Dale Newfield commented on WW-2316:
-----------------------------------
Privilege checks in the method would protect you, but in an interceptor is easier. It's the interceptor solution that is thrown for a loop with this, though.
Let's say you're using acegi's FilterSecurityInterceptor:
/viewFoo.html*=ROLE_ANONYMOUS,admin,user
/saveFoo.html*=admin
If you have all the methods that deal with Foo's in a single action (including both view and save), and if you *don't* have the check in the save method, the following is a security hole (i.e.: executable by ROLE_ANONYMOUS, where it should only be available for admins):
/viewFoo.html?method:save
A whitelist solution with per-action settings of which methods are "safe" would be ideal, but I think we're trying to trade configuration for convention, not add more configuration...
> 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.
[jira] Commented: (WW-2316) Ability to prevent method:METHOD_NAME
access
Posted by "Dave Newton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42635 ]
Dave Newton commented on WW-2316:
---------------------------------
Was the general philosophy of WW that "a public action in an action is always available to an app user"?
If so, methods that don't want to be exposed can just be made private (protected?).
If you're using an action method from somewhere else in the app then perhaps it belongs somewhere else anyway.
Privilege checks would have to be done either in the method or through an interceptor, and they'd only be on public methods.
> 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.