> *>* 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
Okay, it's clear, certainly a well done code should check the 'parameter' before telling script to actually do the calling. Thanks a lot. -- http://mail.python.org/mailman/listinfo/python-list
