generating method names 'dynamically'

[Peter Hansen]

Daniel Nogradi wrote:
>>Ouch! This certainly seems like a possible security hole!
>>
>>As someone else said, use rewrite rules to get this passed
>>in as a parameter.
> 
> I don't get it, why is it more safe to accept GET variables than
> method names? Concretely, why is the URL
> http://something.com/script?q=parameter safer than
> http://something.com/script/parameter if in both cases exactly the
> same things are happening with 'parameter'? 

If *exactly* the same thing were happening, the security risk is the same.

> It has to be checked in
> both cases, characters like ', ", /, \, etc, has to be stripped and
> than it will be fed into the same SQL query. So either way, I have to
> implement some checking mechanism, what difference does it make if the
> result of the checking is fed into a function as an argument and the
> SQL query receives it that way, or a method of a class is called by
> the name 'parameter' and the SQL query receives it as a reference to
> the method name?

The difference is that the script?q=parameter approach would be calling 
a single, defined function which could check the "q" argument fully, 
while the script/parameter approach might not be checked before the 
choice of function to be called is made.

In other words, script?q=__init__ is more likely to do the correct thing 
(rejecting the input) than script/__init__ is...  but ultimately if you 
do adequate checking of the inputs, either approach can be made safe.  I 
think Magnus was just pointing out that the script/parameter approach is 
more typically (i.e. in the real world) subject to quick coding and high 
exposure solutions than the other... not that it's inherently worse.

-Peter