I believe DWR too has a similar concern, conceptually. They have some
configuration parameters to deal with it. I wonder though if my
suggestion about securing all methods maybe isn't all that wacky?
Step 1... let's say we have a silly XML file like so:
<methodSecurity>
<role name="user1" />
<role name="user2" />
<class name="com.company.app.MyActionClass">
<restrict method="method1">user1,user2</restrict>
<restrict method="method2">user2</restrict>
</class>
</methodSecurity>
So, by default, all methods of all classes are accessible. All hail
backwards-compatibility :)
Step 2... there is a "magic session attribute" named, creatively enough,
UserRole. It is the application developers' responsibility to ensure
this gets set, during some sort of logon procedure, or whenever they
feel it appropriate. It should obviously match one of the <role> entries.
Step 3... For each method the framework attempts to call on an Action of
backing bean, it does a lookup... is the class being used mapped in the
config file? If so, is there a restriction placed on the method being
called? If so, is the user a member of one of the named groups? If so,
the method can execute (think of that <restrict> tag as saying "restrict
this method of this class to the following groups). Any other user
would not be able to execute it. If a method is unmapped, it can be
executed by anyone.
Now, the smart way to develop this of course would be to have a
switchable implementation, because if container-managed security is in
play, you'd want to work with isUserInRole(), and then the developer
doesn't have to do anything except provide the mapping file.
And of course, for the annotation fans out there, it's just a matter of
having the equivalent of those <restruct> tags annotating each method.
I don't perceive any of this as being rocket science, nor do I think
this is an original suggestion really, but I think it would alleviate
the concerns quite nicely. What do you think?
Frank
Craig McClanahan wrote:
On 8/25/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
It's interesting that no one says DispatchAction in 1.x is a security
flaw... doesn't that give you exactly the same thing just with a
different call semantic? I guess we should quick drop Dispatch-type
Actions for everyones' safety!! ;) LOL
The security concern isn't actually around the action execution methods
themselves -- as has been pointed out, the whole *purpose* of these methods
is to be called by mapping from a URL. Instead, it's around other public
methods (perhaps on non-action classes) that happen to have the same
parameter signature as your action methods, which enables calls to methods
that were not intended to be actions. You can indeed shoot yourself in the
foot in this manner even with DispatchAction if you are not careful,
although the potential for mischief is somewhat smaller because you can't
necessarily point at any arbitrary bean ... only the ones your actions are
mapped to.
I'm quite interested in how this gets resolved, because Shale Remoting
has a
similar sort of vulnerabiilty (you can map to arbitrary methods for
invoking
it's notion of an action), and it gets dinged for this being a security
vulnerability as well. I'd like to resolve it in a manner that is
conceptually similar to what Struts does, if feasible.
Craig
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
