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 -- http://mail.python.org/mailman/listinfo/python-list
