Dale Newfield wrote:
Jeromy Evans wrote:
I always use the following configuration to minimise the vulnerability::
<action name="/home_*" method="do{1}">
</action>
With that setting, only methods with the prefix "do" in their name
can be executed.
ie. ?method:update calls doUpdate()
Even if that does exactly what you expect it does (which I'm not
convinced about), all it does is change the names of the methods. It
does nothing to mitigate the vulnerability of allowing any user with
sufficient credentials to call a single method in your action
("doView", for example) the ability to call any method in that action.
If you're set up to allow anybody to execute "doView" but only admins
to execute "doUpdate", then "/viewFoo.do?method:update" could be a
security hole whether the actual method being called is "update()" or
"doUpdate()".
It's precisely analogous to the "/viewFoo!update.do" vulnerability,
which is closable by disabling "allowDynamicMethodCalls". I'm simply
proposing that the same flag be used to address both vulnerabilities.
Another solution would be to add an explicit allow list (per action
class) for what methodNames would be allowed in "?method:methodName",
but I don't see a good place to put that whitelist, and recognize it's
just more configuration at a time when the struts developers are
trying to replace configuration with convention.
-Dale
Right you are. I just built a test app and the "?method:MY_METHOD_NAME"
notation will execute any public method irrespective of the
wildcard/dynamic method call settings.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
