On 8/25/06, Craig McClanahan <[EMAIL PROTECTED]> 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.
Looking at it from a slightly different perspective - even if you have
a method/action that you do want to expose theres always a requirement
to permit some users access and deny others. Virtually every part of
out app is protected in this way, asking the question "is the user
permitted to do this?". So rather than blaming the syntax that allows
people to configure/code in a way they prefer (wildcards, dispatch,
POJO methods etc) isn't the issue that security features need to keep
pace with other cool developments in the framework - e.g. along with
wildcard mapping, needs to come wildcard security.
Niall
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
