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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
