Vulnerabilities

4 via 6 paths

Dependencies

7

Source

GitHub

Commit

045e9a86

Find, fix and prevent vulnerabilities in your code.

Severity
  • 4
Status
  • 4
  • 0
  • 0

medium severity
new

Resource Exhaustion

  • Vulnerable module: idna
  • Introduced through: requests@2.25.1

Detailed paths

  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 requests@2.25.1 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

Information Exposure

  • Vulnerable module: requests
  • Introduced through: requests@2.25.1

Detailed paths

  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 requests@2.25.1
    Remediation: 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:

  1. HTTP → HTTPS: leak

  2. HTTPS → HTTP: no leak

  3. HTTPS → HTTPS: leak

  4. 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.

References

medium severity

Information Exposure Through Sent Data

  • Vulnerable module: urllib3
  • Introduced through: urllib3@1.26.5 and requests@2.25.1

Detailed paths

  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 urllib3@1.26.5
    Remediation: Upgrade to urllib3@1.26.17.
  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 requests@2.25.1 urllib3@1.26.5

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Information Exposure Through Sent Data when the Cookie HTTP header is used. An attacker can leak information via HTTP redirects to a different origin by exploiting the fact that the Cookie HTTP header isn't stripped on cross-origin redirects.

Note:

This is only exploitable if the user is using the Cookie header on requests, not disabling HTTP redirects, and either not using HTTPS or for the origin server to redirect to a malicious origin.

##Workaround:

This vulnerability can be mitigated by disabling HTTP redirects using redirects=False when sending requests and by not using the Cookie header.

Remediation

Upgrade urllib3 to version 1.26.17, 2.0.6 or higher.

References

medium severity

Information Exposure Through Sent Data

  • Vulnerable module: urllib3
  • Introduced through: urllib3@1.26.5 and requests@2.25.1

Detailed paths

  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 urllib3@1.26.5
    Remediation: Upgrade to urllib3@1.26.18.
  • Introduced through: righettod/robots-disallowed-dict-builder@righettod/robots-disallowed-dict-builder#045e9a865f8e07656ce14317f32d7d64d7d4e329 requests@2.25.1 urllib3@1.26.5

Overview

urllib3 is a HTTP library with thread-safe connection pooling, file post, and more.

Affected versions of this package are vulnerable to Information Exposure Through Sent Data when it processes HTTP redirects with a 303 status code, due to not stripping the request body when changing the request method from POST to GET. An attacker can potentially expose sensitive information by compromising the origin service and redirecting requests to a malicious peer.

Note:

This is only exploitable if sensitive information is being submitted in the HTTP request body and the origin service is compromised, starting to redirect using 303 to a malicious peer or the redirected-to service becomes compromised.

Workaround

This vulnerability can be mitigated by disabling redirects for services that are not expected to respond with redirects, or disabling automatic redirects and manually handling 303 redirects by stripping the HTTP request body.

Remediation

Upgrade urllib3 to version 1.26.18, 2.0.7 or higher.

References