You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Mike Kienenberger <mk...@alaska.net> on 2004/09/18 01:13:46 UTC
Re: DispatchAction security
Rick Reumann <r...@reumann.net> wrote:
> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
> > Any time you allow an end user an opportunity to specify a parameter for
> > reflection, you're introducing security concerns.
> > However, a "secure" version could be created by only allowing a dispatch
to
> > a hardcoded list of methods.
>
> But your approach to encoding could do the same thing for a dispatch
> param so I'm not certain that using an Action vs DispatchAction is any
> more secure.
I must not be understanding you.
If you have url of "/page&method=X" and use reflection to resolve X, then
you have far less control than if you simply check to see if "X" is in your
list of approved methods.
On the other hand, a pure action with /page&SaveButtonName=ButtonValue is
always going to go to my save code if the "SaveButtonName" parameter exists,
and it'll go to my default code if not. There's no other option. That's
as secure as it gets.
On the other hand, if you're just saying that you can encode your reflection
dispatch name so that "/page&method=X" becomes "/a1b2c3d4e5.psc", you've
just made the security more obscure. If someone figures out your encoding,
they can still bypass it.
The first rule of computer security programming is never trust user data.
Let users specify indexes of items in lists, never the item values
themselves.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction security
Posted by Rick Reumann <r...@reumann.net>.
Mike Kienenberger wrote the following on 9/17/2004 7:13 PM:
> On the other hand, if you're just saying that you can encode your reflection
> dispatch name so that "/page&method=X" becomes "/a1b2c3d4e5.psc", you've
> just made the security more obscure. If someone figures out your encoding,
> they can still bypass it.
I still don't see how it becomes that much different. Take the two
approaches (and correct me if I'm wrong, which I'm sure you will:):
In approach one will assume going straight to a regular Action:
"/fooBar.do"
I'm assuming you'll have this encoded to look unintelligible to the user
and it will end up resolving to use the /someAction.do mapping in your
PageStateCacheServlet.
In a dispatch approach you could have a URL that looked like
"/fooBar?dispatch=update"
I don't believe the above would be 'that' much more work to encode and
decode?
I don't think dispatch actions should be done away with because of
security concerns. Those not using any kind of encoding stuff, like you
are Mike, still often claim the regular Action is more secure because
you don't have a dispatch parameter signifying what you are going. This
argument is weak though because using a regular Action you can tell what
you are doing just as easily.
Couldn't most security concerns be checked when the user gets to the
Action or by some filter? In other words, if someone mangles a URL to
try to get to an update page when they should only be going to a view
only page, you could always make sure to check the user has permission
to get to that resource and kick them out if they don't.
After reverting back to using regular Actions I decided to go back to
using regular DispatchActions. I think they help organize the code
better. Like I mentioned in another post, I don't see people breaking up
a FooBarDao into UpdateFooBarDao, CreateFooBarDao, classes.
I'm certainly not saying that using a Dispatch Action is that much
better than breaking out the code into separate Actions, I'm just not
seeing how the other side can claim the reverse though - That using
regular Actions are much better. Possibly if it makes encoding much
easier in some way, and that is an application requirement, than I could
see how using regular Actions would be preferable in that instance.
You could also always just code your DispatchActions with the
unspecified method and then have the flexiblity to add other methods
later if they logically fit within that class.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction security
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Paul Speed wrote:
>
>
> Michael McGrady wrote:
>
>> Mike Kienenberger wrote:
>>
>>> Rick Reumann <r...@reumann.net> wrote:
>>>
>>>
>>>> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
>>>>
>>>>
>>>>> Any time you allow an end user an opportunity to specify a
>>>>> parameter for
>>>>
>>>
>>>
>>>
>>>
>>>>> reflection, you're introducing security concerns.
>>>>> However, a "secure" version could be created by only allowing a
>>>>> dispatch
>>>>
>>>
>>> to
>>>
>>>>> a hardcoded list of methods.
>>>>>
>>>>
>>>>
>>>> But your approach to encoding could do the same thing for a
>>>> dispatch param so I'm not certain that using an Action vs
>>>> DispatchAction is any more secure.
>>>>
>>>
>>>
>>>
>>> I must not be understanding you.
>>>
>>> If you have url of "/page&method=X" and use reflection to resolve X,
>>> then you have far less control than if you simply check to see if
>>> "X" is in your list of approved methods.
>>>
>>> On the other hand, a pure action with
>>> /page&SaveButtonName=ButtonValue is always going to go to my save
>>> code if the "SaveButtonName" parameter exists, and it'll go to my
>>> default code if not. There's no other option. That's as secure as
>>> it gets.
>>>
>>>
>>> On the other hand, if you're just saying that you can encode your
>>> reflection dispatch name so that "/page&method=X" becomes
>>> "/a1b2c3d4e5.psc", you've just made the security more obscure. If
>>> someone figures out your encoding, they can still bypass it.
>>>
>>> The first rule of computer security programming is never trust user
>>> data. Let users specify indexes of items in lists, never the item
>>> values themselves.
>>>
>>>
>>
>> I am not sure what you are saying, Mike.
>
>
> To bud in and sum up the other Mike's point, I think he was saying this:
>
> When you map request parameters directly to method names using
> reflection then the user can mangle the request parameters to set any
> property they want to... perhaps even unintended ones. Suddenly, any
> public properties are exposed to the world (or private ones if you've
> turned that on in security settings for some reason).
>
> -Paul
I see WHAT you are say and has been said will happen. What I don't see
is HOW that is true or how the two cases differ to the detriment of the
dispatch approach. I am not saying it is not true. But, I don't see
it. From the point of view of people trying to see how what you say is
true, I would like an example of a case where the reflection or dispatch
action object (DAO) is shown to have less security than the plain action
object (PAO). In law they say "/res ipsa loquitor/" which means: the
thing speaks for itself. Good lawyers ask: "Yes, I suppose so, but,
what does it say?". Could the people making this point give us one
example of how things might happen such that the DAO is less secure than
the PAO? I understand the sentiment. It is "age old". But, I don't
see where the "rubber meets the road". That is why I laid out the code
and said I did not see the actual security problem in the applications.
I too would like to avoid security problems.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction security
Posted by Paul Speed <ps...@progeeks.com>.
Michael McGrady wrote:
> Mike Kienenberger wrote:
>
>> Rick Reumann <r...@reumann.net> wrote:
>>
>>
>>> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
>>>
>>>
>>>> Any time you allow an end user an opportunity to specify a parameter
>>>> for
>>
>>
>>
>>
>>>> reflection, you're introducing security concerns.
>>>> However, a "secure" version could be created by only allowing a
>>>> dispatch
>>
>> to
>>
>>>> a hardcoded list of methods.
>>>>
>>>
>>> But your approach to encoding could do the same thing for a dispatch
>>> param so I'm not certain that using an Action vs DispatchAction is
>>> any more secure.
>>>
>>
>>
>> I must not be understanding you.
>>
>> If you have url of "/page&method=X" and use reflection to resolve X,
>> then you have far less control than if you simply check to see if "X"
>> is in your list of approved methods.
>>
>> On the other hand, a pure action with /page&SaveButtonName=ButtonValue
>> is always going to go to my save code if the "SaveButtonName"
>> parameter exists, and it'll go to my default code if not. There's no
>> other option. That's as secure as it gets.
>>
>>
>> On the other hand, if you're just saying that you can encode your
>> reflection dispatch name so that "/page&method=X" becomes
>> "/a1b2c3d4e5.psc", you've just made the security more obscure. If
>> someone figures out your encoding, they can still bypass it.
>>
>> The first rule of computer security programming is never trust user
>> data. Let users specify indexes of items in lists, never the item
>> values themselves.
>>
>>
>
> I am not sure what you are saying, Mike.
To bud in and sum up the other Mike's point, I think he was saying this:
When you map request parameters directly to method names using
reflection then the user can mangle the request parameters to set any
property they want to... perhaps even unintended ones. Suddenly, any
public properties are exposed to the world (or private ones if you've
turned that on in security settings for some reason).
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: DispatchAction security
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Mike Kienenberger wrote:
>Rick Reumann <r...@reumann.net> wrote:
>
>
>>Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
>>
>>
>>>Any time you allow an end user an opportunity to specify a parameter for
>>>
>>>
>
>
>
>>>reflection, you're introducing security concerns.
>>>However, a "secure" version could be created by only allowing a dispatch
>>>
>>>
>to
>
>
>>>a hardcoded list of methods.
>>>
>>>
>>But your approach to encoding could do the same thing for a dispatch
>>param so I'm not certain that using an Action vs DispatchAction is any
>>more secure.
>>
>>
>
>I must not be understanding you.
>
>If you have url of "/page&method=X" and use reflection to resolve X, then
>you have far less control than if you simply check to see if "X" is in your
>list of approved methods.
>
>On the other hand, a pure action with /page&SaveButtonName=ButtonValue is
>always going to go to my save code if the "SaveButtonName" parameter exists,
>and it'll go to my default code if not. There's no other option. That's
>as secure as it gets.
>
>
>On the other hand, if you're just saying that you can encode your reflection
>dispatch name so that "/page&method=X" becomes "/a1b2c3d4e5.psc", you've
>just made the security more obscure. If someone figures out your encoding,
>they can still bypass it.
>
>The first rule of computer security programming is never trust user data.
>Let users specify indexes of items in lists, never the item values
>themselves.
>
>
I am not sure what you are saying, Mike. Suppose we have use the
following actions. One action has the following:
1. SOLUTION ONE
Action that Chooses What CRUD to Use from the Button
public ActionForward execute(...) {
String command = getCommandName();
if("save".equals(command)) {
save(request.getParameter("SaveButtonName"));
} else if ("delete").equals(command)) {
delete(request.getParameter("DeleteButtonName"));
}
}
return mapping.getInput();
}
2. SOLUTION TWO: Dispatchers
Action that Chooses what CRUD Method to Call Via Reflection
public ActionForward execute(...) {
// Dispatch util is a method to get the methodName and use one of
the following methods by reflection
forward = new
DispatchUtil().dispatch(this,mapping,form,request,response);
}
public ActionForward save( ...) {
String ButtonValue = request.getParameter("SaveButtonName");
// use ButtonValue
}
public ActionForward delete( ... ) {
String ButtonValue = request.getParameter("DeleteButtonName")'
// use ButtonValue
}
}
3. SOLUTION THREE:
Plain Old Action Objects
SaveButtonAction
public ActionForward execute (....) {
String ButtonValue = request.getParameter("SaveButtonName");
/// do whatever
}
DeleteButtonAction
public ActionForward execute (....) {
String ButtonValue = request.getParameter("DeleteButtonName");
/// do whatever
}
Isn't the third option in fact the least safe? And, isn't the dispatch
option at least tied for the most safe? The safety of the parameter and
its value is in all three models, but in the plain old action object,
that is the only "distance" between a hack and the application, whereas
in the other cases there are added levels of security due to the
complexity of the internal logic. Ultimately the level of complexity
and the bottom security the name/value pair from a request parameter for
what must be deleted, etc. is the same in ALL cases. What is different
is that the object for deleting is an obvious target whereas the
operations are hidden in an object represening, in essence, an actor
rather than an action.
Please do not take this question as disingenuous or otherwise as an
attack on you. I don't even know you. This is just an attempt to
exchange ideas. I don't mean to suggest you would react that way but I
have gotton gun shy on this list. Thanks. I am interested in your answers.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org