Package Instance

urllib3's Proxy-Authorization request header isn't stripped during cross-origin redirects
When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected.

However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects.

Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident.

Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach.

## Affected usages

We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited:

* Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support.
* Not disabling HTTP redirects.
* Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin.

## Remediation

* Using the `Proxy-Authorization` header with urllib3's `ProxyManager`.
* Disabling HTTP redirects using `redirects=False` when sending requests.
* Not using the `Proxy-Authorization` header.

urllib3 redirects are not disabled when retries are disabled on PoolManager instantiation
urllib3 handles redirects and retries using the same mechanism, which is controlled by the `Retry` object. The most common way to disable redirects is at the request level, as follows:

```python
resp = urllib3.request("GET", "https://httpbin.org/redirect/1", redirect=False)
print(resp.status)
# 302
```

However, it is also possible to disable redirects, for all requests, by instantiating a `PoolManager` and specifying `retries` in a way that disable redirects:

```python
import urllib3

http = urllib3.PoolManager(retries=0)  # should raise MaxRetryError on redirect
http = urllib3.PoolManager(retries=urllib3.Retry(redirect=0))  # equivalent to the above
http = urllib3.PoolManager(retries=False)  # should return the first response

resp = http.request("GET", "https://httpbin.org/redirect/1")
```

However, the `retries` parameter is currently ignored, which means all the above examples don't disable redirects.

## Affected usages

Passing `retries` on `PoolManager` instantiation to disable redirects or restrict their number.

By default, requests and botocore users are not affected.

## Impact

Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable.

## Remediation

You can remediate this vulnerability with the following steps:

 * Upgrade to a patched version of urllib3. If your organization would benefit from the continued support of urllib3 1.x, please contact [sethmichaellarson@gmail.com](mailto:sethmichaellarson@gmail.com) to discuss sponsorship or contribution opportunities.
 * Disable redirects at the `request()` level instead of the `PoolManager()` level.