ghsa-cw9j-q3vf-hrrv
Vulnerability from github
Impact
When you send a request with the Authorization
header to one domain, and the response asks to redirect to a different domain, Scrapy’s built-in redirect middleware creates a follow-up redirect request that keeps the original Authorization
header, leaking its content to that second domain.
The right behavior would be to drop the Authorization
header instead, in this scenario.
Patches
Upgrade to Scrapy 2.11.1.
If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.11.1 is not an option, you may upgrade to Scrapy 1.8.4 instead.
Workarounds
If you cannot upgrade, make sure that you are not using the Authentication
header, either directly or through some third-party plugin.
If you need to use that header in some requests, add "dont_redirect": True
to the request.meta
dictionary of those requests to disable following redirects for them.
If you need to keep (same domain) redirect support on those requests, make sure you trust the target website not to redirect your requests to a different domain.
Acknowledgements
This security issue was reported by @ranjit-git through huntr.com.
{ "affected": [ { "package": { "ecosystem": "PyPI", "name": "scrapy" }, "ranges": [ { "events": [ { "introduced": "2" }, { "fixed": "2.11.1" } ], "type": "ECOSYSTEM" } ] }, { "package": { "ecosystem": "PyPI", "name": "scrapy" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "1.8.4" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2024-3574" ], "database_specific": { "cwe_ids": [ "CWE-200" ], "github_reviewed": true, "github_reviewed_at": "2024-02-15T15:32:15Z", "nvd_published_at": null, "severity": "HIGH" }, "details": "### Impact\n\nWhen you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Scrapy\u2019s built-in redirect middleware creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.\n\nThe [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario.\n\n### Patches\n\nUpgrade to Scrapy 2.11.1.\n\nIf you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.11.1 is not an option, you may upgrade to Scrapy 1.8.4 instead.\n\n### Workarounds\n\nIf you cannot upgrade, make sure that you are not using the `Authentication` header, either directly or through some third-party plugin.\n\nIf you need to use that header in some requests, add `\"dont_redirect\": True` to the `request.meta` dictionary of those requests to disable following redirects for them.\n\nIf you need to keep (same domain) redirect support on those requests, make sure you trust the target website not to redirect your requests to a different domain.\n\n### Acknowledgements\n\nThis security issue was reported by @ranjit-git [through huntr.com](https://huntr.com/bounties/49974321-2718-43e3-a152-62b16eed72a9/).", "id": "GHSA-cw9j-q3vf-hrrv", "modified": "2024-04-16T14:05:51Z", "published": "2024-02-15T15:32:15Z", "references": [ { "type": "WEB", "url": "https://github.com/scrapy/scrapy/security/advisories/GHSA-cw9j-q3vf-hrrv" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3574" }, { "type": "WEB", "url": "https://github.com/scrapy/scrapy/commit/ee7bd9d217fc126063575d5649f00bdeeca2faae" }, { "type": "PACKAGE", "url": "https://github.com/scrapy/scrapy" }, { "type": "WEB", "url": "https://huntr.com/bounties/49974321-2718-43e3-a152-62b16eed72a9" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N", "type": "CVSS_V3" } ], "summary": "Scrapy authorization header leakage on cross-domain redirect" }
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.