Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: Sergey says: I wanted to add that the fact that browsers encode the field names in the page encoding does not change that they should escape the header according to RFC 2047.
I respond: True, but RFC 2047 is _so_ weird, that it seems that browsers have a better solution. RFC 2047 is needed for 7-bit mail servers, from which it seems to have been inherited by specs for HTTP (but I've never seen it used by a browser, have you?). It would be nicer if HTTP had a header that allowed definition of the charset used for subsequent headers. Right now, the code processing form data has to assume a particular encoding for headers & data, and somehow make sure that all the <form>s that use the same code have the same encoding. Sergey says: I imagine there could be a non-ASCII field name that, when encoded in some encoding, will produce something SQL-injection-like: '"; other="xx"'. That string would make the header parse into something completely different. With IE8 and FF 3.6 it looks like it would be very simple. The same applies to uploaded files names too, so it's not just a matter of choosing sane field names. That's all a browsers' problem though. I respond: Perhaps there is, although it depends on how the parser is written what injection techniques would work, and it also depends on having a followon parameter with dangerous semantics to incorrectly act on. It isn't just a problem for the browsers, but for every CGI script that parses such parameters. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11269> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
