list at joreybump.com
Tue Jul 6 14:28:45 EDT 2004
Gregory (Grisha) Trubetskoy wrote: > > This behaviour is part of mod_python.util.FieldStorage class, which is a > little convenience tool. Protocol compliance is of little or no > relevance here, since you're free not to use it and process input data > using your own code or, for example using Python standard library > FieldStorage. > > Also, if I remember it correctly, most relevant RFC's tend to focus on > the behaviour of the browser (e.g. the user should be warned before a > POST if you hit reload, but not for GET), and there is nothing there > about how the form variables should appear to an application. > > As to why it processes GET and POST together and GET wins - that's a > matter of personal preference. I find it convenient to be able to > override variables in a form by appending them to the URL, and I think > most user-friendly applications should behave this way, because IMHO > ability to tinker with the URL is a good thing. > > Some people believe that this should not be allowed because it enables a > user to alter hidden POST variables, which would otherwise be difficult, > but this seems to me like a silly argument. There are much more certain > ways of ensuring that hidden variables have not been modified, e.g. an > MD5 or SHA signature passed along. It all seems harmless enough. If a programmer decides to use this method, it will be necessary to check if the result is a string or a list and act accordingly. If the need arises to distinguish between the query parts and the POST data, that's easy enough with cgi.parse_qs(req.args) or util.parse_qs(req.args). Is there a similar function that returns only POST data? For applications not designed this way, what is the worst that could happen? String operations would break when a list is returned, like name = name.upper() If there is an exploit, it's no different than any other user input validation issue, regardless of the method used (POST or GET).