when you request a url that requests Basic authentication info
HTTPBasicAuthHandler adds the Authorization header to the request as a
normal (not unredirected) header, then if the server returns a 301 or
302 redirect HTTPRedirectHandler will send a request to the redirected
address keeping the normal headers including the Authorization header
HTTPBasicAuthHandler added, I'll attach the code I used to test this.

GET from libwww-perl seems to do this but most browsers don't seem to
by default and although I can't find much in the RFCs about how
redirecting is supposed to work wrt. auth headers (feel free to point
out sections if I'm blind) I think it breaks
ftp://ftp.isi.edu/in-notes/rfc2617.txt somewhat (section 1.1,
"""
The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, the
same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server.
""") since redirects can point to arbitrary urls off of the server.

as in bug bpo-1480067 just adding the header as an unredirected header
would stop the header being sent across redirects if that's indeed the
proper behaviour.

1. The section you refer to is 1.2 of RFC2617, which specifies the details on
   Access Authentication in General and not specific to url redirects. So, I don't
   think we should take it as a referece.

2. Under the section - 3.3 Digest Operation, the Authentication cases under
   redirection is provided like this. (search for keyword 'redirect')

"""
The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data...
"""

This basically states that Authorization header should be passed on the
redirects in Digest authentication case and (should we assume in Basic
Authentication case also?) If yes, then urllib2 is actually doing the same
thing. Do you have a practical scenario where this has resulted in failure/
security loophole?

This is working as designed and Requestor has not supplied any further
information on why he thinks it a bug.

I agree this is a bug.

Senthil -- re "1)", the paragraph you refer to (quoted by the OP) is
relevant. The fact that it doesn't specifically mention redirection is
not relevant.

Re "2)": I don't know how digest auth works, but the paragraph you quote
from appears to be there for explanation rather than for prescribing how
digest auth or HTTP work (i.e. it appears to be "non-normative"). This
bug doesn't say that redirected requests shouldn't contain the
Authorization header. It says that the Authorization header for an old
request shouldn't be sent with a new request (though it may turn out the
new one is equal to the old one in some cases).

I think the test is close enough to acceptable, will adapt it if nobody
does first :)

I believe this bug affects urllib2 when it talks to the corporate single-sign-on solution Siteminder. Siteminder usually is installed as a web server module. When a request is made to the server (origin server), Siteminder issues a 302 redirect to a central authentication server running SSL passing the original request URL of the origin server. The central server responds with a 401 basic authentication challenge. Urllib2 responds with the password from the HTTPPasswordMgr. The central server sets some cookies and responds with a 302 redirect to the origin server on the original URL. Urllib2 then sends the authentication and cookies to the origin server which is virtually always unprotected. Browsers do not send the authentication to the origin server -- only the cookies.

Ok, in order to fix this bug, urllib2 should only send the cookies and not send the auth info across the the redirects. Yup, let me take this up.

I attached a diff of a fix for this bug. This may not be the ideal fix, but hopefully it will give the developer who actually does resolve it a good start.

The Basic Auth Authorization headers are added to unredirected_headers
and thus we will be able to prevent this problem. ( Digest Authentication was already so, it gives additional confidence that is the right way).

Fixed and committed in revision 78422.

merged into other branches r78423, r78426, r78428

FYI, this change caused a regression in Mercurial - see http://mercurial.selenic.com/bts/issue2179.