Problem
auth_endpoint.py manually follows 301 redirects during sign-in to preserve the POST body (avoiding the POST→GET conversion that requests does automatically). This means credentials are re-sent to whatever URL the Location header contains.
A MITM attacker who can intercept the initial HTTP request can return a 301 pointing to http://attacker.com and receive the credentials. More relevantly, if a user connects to an HTTPS server and a MITM strips TLS, the redirect could downgrade the second POST to HTTP.
A scheme downgrade (https → http) in a redirect is never legitimate.
Proposed fix
Before re-POSTing in auth_endpoint.py, check for a scheme downgrade and raise:
if server_response.status_code == 301:
location = server_response.headers["Location"]
original_scheme = urlparse(self.parent_srv.server_address).scheme
redirect_scheme = urlparse(location).scheme
if original_scheme == "https" and redirect_scheme == "http":
raise Exception("Refusing to follow redirect from HTTPS to HTTP during sign-in")
server_response = self.parent_srv.session.post(
location, data=signin_req, **self.parent_srv.http_options, allow_redirects=False
)This has no false positives — a downgrade redirect is never a legitimate server behaviour.
Problem
auth_endpoint.pymanually follows 301 redirects during sign-in to preserve the POST body (avoiding the POST→GET conversion thatrequestsdoes automatically). This means credentials are re-sent to whatever URL theLocationheader contains.A MITM attacker who can intercept the initial HTTP request can return a 301 pointing to
http://attacker.comand receive the credentials. More relevantly, if a user connects to an HTTPS server and a MITM strips TLS, the redirect could downgrade the second POST to HTTP.A scheme downgrade (
https→http) in a redirect is never legitimate.Proposed fix
Before re-POSTing in
auth_endpoint.py, check for a scheme downgrade and raise:This has no false positives — a downgrade redirect is never a legitimate server behaviour.