GHSA-cjvr-mfj7-j4j8
Vulnerability from github
Impact
If you manually define cookies on a Request object, and that Request object gets a redirect response, the new Request object scheduled to follow the redirect keeps those user-defined cookies, regardless of the target domain.
Patches
Upgrade to Scrapy 2.6.0, which resets cookies when creating Request objects to follow redirects¹, and drops the Cookie header if manually-defined if the redirect target URL domain name does not match the source URL domain name².
If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.6.0 is not an option, you may upgrade to Scrapy 1.8.2 instead.
¹ At that point the original, user-set cookies have been processed by the cookie middleware into the global or request-specific cookiejar, with their domain restricted to the domain of the original URL, so when the cookie middleware processes the new (redirect) request it will incorporate those cookies into the new request as long as the domain of the new request matches the domain of the original request.
² This prevents cookie leaks to unintended domains even if the cookies middleware is not used.
Workarounds
If you cannot upgrade, set your cookies using a list of dictionaries instead of a single dictionary, as described in the Request documentation, and set the right domain for each cookie.
Alternatively, you can disable cookies altogether, or limit target domains to domains that you trust with all your user-set cookies.
References
- Originally reported at huntr.dev
For more information
If you have any questions or comments about this advisory: * Open an issue * Email us
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "scrapy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.6.0"
},
"package": {
"ecosystem": "PyPI",
"name": "scrapy"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-0577"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-01T22:12:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nIf you manually define cookies on a [`Request`](https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request) object, and that `Request` object gets a redirect response, the new `Request` object scheduled to follow the redirect keeps those user-defined cookies, regardless of the target domain.\n\n### Patches\n\nUpgrade to Scrapy 2.6.0, which resets cookies when creating `Request` objects to follow redirects\u00b9, and drops the ``Cookie`` header if manually-defined if the redirect target URL domain name does not match the source URL domain name\u00b2.\n\nIf you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.6.0 is not an option, you may upgrade to Scrapy 1.8.2 instead.\n\n\u00b9 At that point the original, user-set cookies have been processed by the cookie middleware into the global or request-specific cookiejar, with their domain restricted to the domain of the original URL, so when the cookie middleware processes the new (redirect) request it will incorporate those cookies into the new request as long as the domain of the new request matches the domain of the original request.\n\n\u00b2 This prevents cookie leaks to unintended domains even if the cookies middleware is not used.\n\n### Workarounds\n\nIf you cannot upgrade, set your cookies using a list of dictionaries instead of a single dictionary, as described in the [`Request` documentation](https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request), and set the right domain for each cookie.\n\nAlternatively, you can [disable cookies altogether](https://docs.scrapy.org/en/latest/topics/downloader-middleware.html#std-setting-COOKIES_ENABLED), or [limit target domains](https://docs.scrapy.org/en/latest/topics/spiders.html#scrapy.spiders.Spider.allowed_domains) to domains that you trust with all your user-set cookies.\n\n### References\n* Originally reported at [huntr.dev](https://huntr.dev/bounties/3da527b1-2348-4f69-9e88-2e11a96ac585/)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* [Open an issue](https://github.com/scrapy/scrapy/issues)\n* [Email us](mailto:opensource@zyte.com)",
"id": "GHSA-cjvr-mfj7-j4j8",
"modified": "2024-10-22T16:37:18Z",
"published": "2022-03-01T22:12:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/scrapy/scrapy/security/advisories/GHSA-cjvr-mfj7-j4j8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0577"
},
{
"type": "WEB",
"url": "https://github.com/scrapy/scrapy/commit/8ce01b3b76d4634f55067d6cfdf632ec70ba304a"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/scrapy/PYSEC-2022-159.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/scrapy/scrapy"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/3da527b1-2348-4f69-9e88-2e11a96ac585"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/03/msg00021.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Incorrect Authorization and Exposure of Sensitive Information to an Unauthorized Actor in scrapy"
}
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.