ghsa-jgh8-vchw-q3g7
Vulnerability from github
Published
2023-01-27 01:04
Modified
2024-11-26 16:13
Summary
safeurl-python contains Server-Side Request Forgery
Details

Description

In SafeURL it is possible to specify a list of domains that should be matched before a request is sent out. The regex used to compare domains did not work as intended.

Impact

The regex used was:

re.match("(?i)^%s" % domain, value)

This has two problems, first that only the beginning and not the end of the string is anchored. Second, that a dot in the domain matches any character as part of regex syntax.

Therefore, an allowlist of ["victim.com"] could allow the domain "victimacomattacker.com" to be requested.

This has lower impact since the usual attacker aim in an SSRF is to request internal resources such as private IP addresses rather than an attacker's own domain. But, in a case where SafeURL had specifically been used to try to limit requests to a particular allowlist, say for example a PDF renderer, the finding would be more severe.

Patches

Fixed in https://github.com/IncludeSecurity/safeurl-python/pull/5

References

Server-side request forgery (SSRF)

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "safeurl-python"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-24622"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-27T01:04:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\nIn SafeURL it is possible to specify a list of domains that should be matched before a request is sent out. The regex used to compare domains did not work as intended.\n\n### Impact\nThe regex used was:\n\n`re.match(\"(?i)^%s\" % domain, value)`\n\nThis has two problems, first that only the beginning and not the end of the string is anchored. Second, that a dot in the domain matches any character as part of regex syntax.\n\nTherefore, an allowlist of [\"victim.com\"] could allow the domain \"victimacomattacker.com\" to be requested.\n\nThis has lower impact since the usual attacker aim in an SSRF is to request internal resources such as private IP addresses rather than an attacker\u0027s own domain. But, in a case where SafeURL had specifically been used to try to limit requests to a particular allowlist, say for example a PDF renderer, the finding would be more severe.\n\n### Patches\nFixed in https://github.com/IncludeSecurity/safeurl-python/pull/5\n\n### References\n[Server-side request forgery (SSRF)](https://portswigger.net/web-security/ssrf)",
  "id": "GHSA-jgh8-vchw-q3g7",
  "modified": "2024-11-26T16:13:13Z",
  "published": "2023-01-27T01:04:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/IncludeSecurity/safeurl-python/security/advisories/GHSA-jgh8-vchw-q3g7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IncludeSecurity/safeurl-python/pull/5/commits/42dd0c8e5fc84e17e1d3578d18aaea169eece474"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/IncludeSecurity/safeurl-python"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/safeurl-python/PYSEC-2023-298.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "safeurl-python contains Server-Side Request Forgery"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.