Find, fix and prevent vulnerabilities in your code.
medium severity
new
- Vulnerable module: idna
- Introduced through: requests@2.24.0
Detailed paths
-
Introduced through: deckbsd/glouton-satnogs-data-downloader@deckbsd/glouton-satnogs-data-downloader#9674081b669b0ca3c04513ede4127c6221962a73 › requests@2.24.0 › idna@2.10
Overview
Affected versions of this package are vulnerable to Resource Exhaustion via the idna.encode
function. An attacker can consume significant resources and potentially cause a denial-of-service by supplying specially crafted arguments to this function.
Note: This is triggered by arbitrarily large inputs that would not occur in normal usage but may be passed to the library assuming there is no preliminary input validation by the higher-level application.
Remediation
Upgrade idna
to version 3.7 or higher.
References
medium severity
- Vulnerable module: requests
- Introduced through: requests@2.24.0
Detailed paths
-
Introduced through: deckbsd/glouton-satnogs-data-downloader@deckbsd/glouton-satnogs-data-downloader#9674081b669b0ca3c04513ede4127c6221962a73 › requests@2.24.0Remediation: Upgrade to requests@2.31.0.
Overview
Affected versions of this package are vulnerable to Information Exposure by leaking Proxy-Authorization
headers to destination servers during redirects to an HTTPS origin. This is a result of how rebuild_proxies
is used to recompute and reattach the Proxy-Authorization
header to requests when redirected.
NOTE: This behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080
), and only when redirecting to HTTPS:
HTTP → HTTPS: leak
HTTPS → HTTP: no leak
HTTPS → HTTPS: leak
HTTP → HTTP: no leak
For HTTP connections sent through the proxy, the proxy will identify the header in the request and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization
header must be sent in the CONNECT
request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.
Workaround
This vulnerability can be avoided by setting allow_redirects
to False
on all calls through Requests top-level APIs, and then capturing the 3xx response codes to make a new request to the redirect destination.
Remediation
Upgrade requests
to version 2.31.0 or higher.