generating method names 'dynamically'

Daniel Nogradi nogradi at
Fri Jan 27 18:35:42 EST 2006

> *>* I don't get it, why is it more safe to accept GET variables than
> *>* method names? Concretely, why is the URL
> *>* safer than
> *>* 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

Okay, it's clear, certainly a well done code should check the
'parameter' before telling script to actually do the calling.

Thanks a lot.

More information about the Python-list mailing list