On Fri, Jul 16, 2010 at 11:28 PM, Graham Dumpleton <span dir="ltr"><<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">> Nah, not nearly that hard:<br>
><br>
> path_info = urllib.parse.unquote_to_bytes(environ['wsgi.raw_path_info']).decode('UTF-8')<br>
><br>
> I don't see the problem? If you want to distinguish %2f from /, then you'll do it slightly differently, like:<br>
><br>
> path_parts = [<br>
> urllib.parse.unquote_to_bytes(p).decode('UTF-8')<br>
> for p in environ['wsgi.raw_path_info'].split('/')]<br>
><br>
> This second recipe is impossible to do currently with WSGI.<br>
> So... before jumping to conclusions, what's the hard part with using<br>
<br>
</div></div>Sorry, it is not that simple. The thing that everyone is ignoring is<br>
that SCRIPT_NAME and PATH_INFO are also normalized by the web server<br>
normally. That is, .. instances are removed. By passing the raw URL<br>
through to the application, you are now forcing every application to<br>
have to deal with that as well with the possibility of directory<br>
traversal attacks when people get it wrong and the URL is mapping<br>
somehow to file system resources. It is a huge can of worms which at<br>
the moment the web server deals with.<br></blockquote><div><br>Well... at least to me "raw" only means "not URL decoded", so it doesn't necessarily mean you can't clean up the request path. I guess an attacker could encode "." to make things harder.<br>
<br>Nevertheless, WSGI servers don't currently guarantee this cleaning. I added it to paste.httpserver, but I don't know one way or the other about any other servers. A quick test shows wsgiref does not clean paths. So apps shouldn't rely on a clean path.<br clear="all">
<br></div></div><br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>