You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Security] http.server can be abused to redirect to (almost) arbitrary URL #76265
bpo-43223: [security] http.server: Open Redirection if the URL path starts with //
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2021-05-21.23:10:46.228>created_at=<Date2017-11-20.13:49:15.952>labels= ['type-security', '3.7', 'library']
title='[Security] http.server can be abused to redirect to (almost) arbitrary URL'updated_at=<Date2021-05-21.23:10:46.227>user='https://github.com/vstinner'
The problem is in the SimpleHTTPRequestHandler.send_head() function:
self.path = '//www.python.org/%2f..'
translate_path() translates '//www.python.org//..' path to self.directory (the current directory by default).
isdir(self.directory) is True but self.path doesn't send with '/', so send_head() creates a HTTP redirection (HTTP 301)
The redirection URL is '//www.python.org/%2f../'. Extract of the raw HTTP: "Location: //www.python.org/%2f../"
The web browsers translates the URL '//www.python.org/%2f../' to "http://www.python.org/%2f../"... It surprised me, but ok, it's a fact.
I'm not sure what is the best way to fix this vulnerability without rejecting valid HTTP requests.
IMHO the root issue is the redirection URL starting with "//". I would expect something like "localhost//". The problem is that I'm not sure that the HTTP server knows its own "external" hostname. "localhost" is wrong is the server is accessed from the outside. Maybe the server must just fail on that case?
This vulnerabilility was reported to the Python Security Response Team (PSRT) at October 18, 2017 (one month ago). Since no obvious fix was found, it was decided to make the vulnerability public to get more eyes on it to find a quick fix.
Note: I'm not sure that this vulnerability is important, since the redirected URL ends with "/%2f../" which should be rejected by any correct HTTP Server (say, not the Python builtin "simple" HTTP server...).
Maybe a good fix would be to “escape” the double slash with “/.”:
ifos.path.isdir(path):
url=self.pathifurl.startswith('//'): # E.g. "//www.python.org/%2f.."url="/."+url# Becomes "/.//www.python.org/%2f.."parts=urllib.parse.urlsplit(url)
...
When this “escaped” URL is resolved with the base URL, it should give the right result:
>>> base ="http://localhost:8000//www.python.org/%2f.."
>>> redirect ="/.//www.python.org/%2f../"
>>> urljoin(base, redirect)
'http://localhost:8000//www.python.org/%2f../'
A simpler idea is to strip off all but one of the leading slashes, so you end up with "/www.python.org/%2f..". That would technically be a different URL, but would access the same file through the default SimpleHTTPRequestHandler behaviour, so most people wouldn’t notice.
In bpo-34276 I suggested a fix to “urlunsplit”. In this case it would send “Location: ////www.python.org/%2f../", with an extra pair of slashes denoting an empty host name. This should stop a browser from seeing “www.python.org” as a host name.
Activity
vstinner commentedon Nov 20, 2017
iDer reported a vulnerability in the HTTP server.
(1) Start a local HTTP server (listen to tcp/8000):
python3 -m http.server 8000
(2) Open a web browser and to go:
http://localhost:8000//www.python.org/%2f..
=> the browser is redirected to http://www.python.org/%2f../
(on this example, the python.org web server redirects to https://www.python.org/%2f../ )
Raw HTTP to see the HTTP redirection using netcat:
---
The problem is in the SimpleHTTPRequestHandler.send_head() function:
The web browsers translates the URL '//www.python.org/%2f../' to "http://www.python.org/%2f../"... It surprised me, but ok, it's a fact.
I'm not sure what is the best way to fix this vulnerability without rejecting valid HTTP requests.
IMHO the root issue is the redirection URL starting with "//". I would expect something like "localhost//". The problem is that I'm not sure that the HTTP server knows its own "external" hostname. "localhost" is wrong is the server is accessed from the outside. Maybe the server must just fail on that case?
This vulnerabilility was reported to the Python Security Response Team (PSRT) at October 18, 2017 (one month ago). Since no obvious fix was found, it was decided to make the vulnerability public to get more eyes on it to find a quick fix.
Note: I'm not sure that this vulnerability is important, since the redirected URL ends with "/%2f../" which should be rejected by any correct HTTP Server (say, not the Python builtin "simple" HTTP server...).
vstinner commentedon Nov 20, 2017
Extract of send_head():
urllib.parse.urlsplit('//www.python.org/%2f..') returns:
Is urlsplit() the correct function to call here? www.python.org is part of the path, not of the netloc.
vstinner commentedon Nov 20, 2017
I wrote this patch, but I'm not sure that it's ok to always reject redirection URLs starting with //:
vadmium commentedon Nov 26, 2017
Maybe a good fix would be to “escape” the double slash with “/.”:
When this “escaped” URL is resolved with the base URL, it should give the right result:
A simpler idea is to strip off all but one of the leading slashes, so you end up with "/www.python.org/%2f..". That would technically be a different URL, but would access the same file through the default SimpleHTTPRequestHandler behaviour, so most people wouldn’t notice.
vadmium commentedon Jul 30, 2018
In bpo-34276 I suggested a fix to “urlunsplit”. In this case it would send “Location: ////www.python.org/%2f../", with an extra pair of slashes denoting an empty host name. This should stop a browser from seeing “www.python.org” as a host name.
ned-deily commentedon May 21, 2021
This looks like a duplicate of bpo-43223 which has a PR in progress.