At 11:38 AM -0500 1/23/06, Frank W. Zammetti wrote:
Joe, I think Rick is correct, I too do not see how this will solve the
problem.
Recall that the way it works today, you can bypass validate() being fired
for *any* Action, not just those which are designed to handle a cancel
button. This is where the problem arises... depending on what is done in
validate() (whether we as architects find it appropriate or not) can cause
problems in execute() and beyond, potentially security problems.
Of course, perhaps Rick and I are *both* not seeing it :)
Or it could be me. But this solution puts burden of activating the
cancel semantics on the person who manages the struts-config file.
When the command was not in legacy mode, it would only check for the
cancel parameter for requests whose Struts action path looks up an
ActionMapping which has had an explicit value set.
So once this was done, you couldn't bypass validate(), except for
actions that should be designed to handle it.
Joe
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
On Mon, January 23, 2006 11:20 am, Joe Germuska said:
> I would propose that the simplest approach would be to change it to
consult the ActionMapping for an arbitrary string property with a key
like "CANCEL_PARAMETER". It would use this parameter name instead of
the Globals.CANCEL (perhaps also adding a check for the same
param_name + ".x" to catch the case of an image button, as does the
current hard-coded parameter check.
How would that solve the problem? Assuming someone figures out the
name of this parameter they'd be able to do the same thing - add this
param to a URL and bypass the validation of a form. It's not the name
of the param that is the problem but that, by passing this param to an
arbitrary Action, you can bypass the validate method tied to that
action mapping. The problem is that Struts decides to still execute
the Action or dispatch method when it sees the canceled param being
passed to it. If someone figures out this new canceled param name we'd
be in the same boat, would we not?
If the user figures out the name of the parameter, they would only be
able to simulate clicking on the button. Since my suggestion
involves specifying the cancel parameter on a per-action-mapping
basis, it seems that any case where the user "spoofed the cancel
button", they would only succeed in submitting the form as if they
had clicked cancel, which you would have designed for. In non-legacy
mode, the absence of any such parameter for a mapping (that is, the
default) would mean that ActionContext.setCancelled(...) would never
be called. If you wanted to use a different parameter for each
mapping where it was supported, you could be even more "secure",
except again, if you use the mapping at all, presumably you're
already developing with the expectation that the request may be in
the "cancelled" state.
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
