Paul Speed wrote:
Michael McGrady wrote:
Mike Kienenberger wrote:
Rick Reumann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
