for users of DispatchAction, a security idea

[Dan Allen <da...@mojavelinux.com>]

For those of you who are using DispatchAction and are having difficulty 
with the validation framework, I have an idea to propose.  Up to this 
point the two practices seemed to conflict, namely because the validator 
cannot distinguish between

EditUser?method=save
EditUser?method=delete
EditUser?method=retrieve

After beating my head and pulling my hair I came up with a sweet 
solution.  Instead of setting up your action as

<action
	path="/RetrieveUser"
	name="userForm"
	type="org.webapp.presentation.users.actions.UserFormAction"
	parameter="method"
	validate="false"/>

<action
	path="/EditUser"
	name="userForm"
	type="org.webapp.presentation.users.actions.UserFormAction"
	parameter="method"
	validate="true"
	input="userForm.page"/>

By splitting up the retrieve from the create, update, delete I have 
allowed two different actions to use the same DispatchAction class. 
However, a problem arises...what problem you ask?  Well, what stops a 
user from requesting

/RetrieveUser?method=add

???  Exactly, there is no check because the configuration doesn't allow 
for this distinction.  If you want to believe it works, it looks good, 
but as soon as you wake up from your day dream you realize that the 
extra action only adds cosmetic protection against getting around the 
validator.

So, I came up with a solution. While my idea does not necessarily 
dictate a patch to the struts framework, it certainly could be used in 
an application's BaseAction class.

consider the following:

<action
	path="/RetrieveUser"
	name="userForm"
	type="org.webapp.presentation.users.actions.UserFormAction"
	parameter="method retrieve"
	validate="false"/>

<action
	path="/EditUser"
	name="userForm"
	type="org.webapp.presentation.users.actions.UserFormAction"
	parameter="method create,update,delete"
	validate="true"
	input="userForm.page"/>

Now, in my BaseAction, which extends DispatchAction, I parse the 
parameter and check to see if the value of the parameter (the string 
before the space) matches a value from my tokenized list of methods 
(which follow the space).  This way, you can limit the method values 
which can occur for an action which uses DispatchAction.  Aha!  Now, you 
can use DispatchAction to organize your classes, but have the same 
control as if you where using different classes for each action....the 
perfect solution.  If a user tries to access

/RetrieveUser?method=add

I send them to the error.page global forward with an appropriate 
ActionError message.

So one last question, what about unspecified?  What if, because the jsp 
designer is lazy, you want more than one unspecified method, one for 
each action mapping perhaps?  Easy, the first one becomes the default. 
This way you use the syntax regardless, so if the user leaves off the 
method in RetrieveUser such as

/RetrieveUser

it just goes to the retrieve method.  Now you can use DispatchAction for 
every action!  No reason not to!  Tying the method names into the action 
mapping makes a whole lot of sense to me, provides security, and can 
easily be specified and created using xdoclet!

Hope that helps clear things up for some people.  Happy Struttin'

Dan


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org