A security issue was reported by Mike Lissner wherein an attacker was able to use \r\n in the url path, the urlparse method didn't sanitize and allowed those characters be present in the request.
In [9]: from urllib.parse import urlsplit
In [10]: urlsplit("java\nscript:alert('bad')")
Out[10]: SplitResult(scheme='', netloc='', path="java\nscript:alert('bad')", query='', fragment='')
Firefox and other browsers ignore newlines in the scheme. From
the browser console:
Mozilla Developers informed about the controlling specification for URLs is in fact defined by the "URL Spec"
from WHATWG which updates RFC 3986 and specifies that tabs and newlines
should be stripped from the scheme.
That link defines an automaton for URL parsing. From that link, steps 2 and 3 of scheme parsing read:
If input contains any ASCII tab or newline, validation error.
3. Remove all ASCII tab or newline from input.
urlparse module behavior should be updated, and an ASCII tab or newline should be removed from the url (sanitized) before it is sent to the request, as WHATWG spec.
changed the title [-]urllib.parse should sanitize urls containing ASCII newline and tabs.[/-][+][security] urllib.parse should sanitize urls containing ASCII newline and tabs.[/+]on Apr 20, 2021
changed the title [-][security] urllib.parse should sanitize urls containing ASCII newline and tabs.[/-][+][security] CVE-2022-0391: urllib.parse should sanitize urls containing ASCII newline and tabs.[/+]on Feb 6, 2022
changed the title [-][security] urllib.parse should sanitize urls containing ASCII newline and tabs.[/-][+][security] CVE-2022-0391: urllib.parse should sanitize urls containing ASCII newline and tabs.[/+]on Feb 6, 2022
This kind of eclectic approach -- taking part of one spec, part of another, ignoring invalid values, turning invalid outputs into answers without a warning -- is just going to cause more vulnerabilities. A URL with newlines in it was never valid, for browsers or anything else. Now there's just another parser that will give answers that don't match other parsers (whether it's browsers, or curl, or anything else). Better to bite the bullet and say "hey, that's not parseable".
If you have a concrete proposal to do something different or have found other bugs, please open a new Issue. Comments added to an old merged PR are likely to be ignored and unseen.
Understood. I mostly wanted to correct the record on urlsplit's existing behavior, for people looking back at the git blame to figure out why urlsplit behaves the way it does.
(And of course I couldn't resist tacking on a warning about parser mismatch, which I don't think got enough air time in the discussion.)
Activity
orsenthil commented on Apr 18, 2021
A security issue was reported by Mike Lissner wherein an attacker was able to use \r\n in the url path, the urlparse method didn't sanitize and allowed those characters be present in the request.
Firefox and other browsers ignore newlines in the scheme. From
the browser console:
Mozilla Developers informed about the controlling specification for URLs is in fact defined by the "URL Spec"
from WHATWG which updates RFC 3986 and specifies that tabs and newlines
should be stripped from the scheme.
See: https://url.spec.whatwg.org/#concept-basic-url-parser
That link defines an automaton for URL parsing. From that link, steps 2 and 3 of scheme parsing read:
If input contains any ASCII tab or newline, validation error.
3. Remove all ASCII tab or newline from input.
urlparse module behavior should be updated, and an ASCII tab or newline should be removed from the url (sanitized) before it is sent to the request, as WHATWG spec.
tirkarthi commented on Apr 19, 2021
See also a related issue to sanitise newline on other helper functions https://bugs.python.org/issue30713
See also discussion and compatibility on disallowing control characters : https://bugs.python.org/issue30458
54 remaining items
ambv commented on Jun 28, 2021
New changeset 634da2d by Senthil Kumaran in branch '3.8':
[3.8] bpo-43882 - Mention urllib.parse changes in Whats new section. (bpo-26277)
634da2d
vstinner commented on Feb 6, 2022
CVE-2022-0391 has been assigned to this vulnerability.
mlissner commented on Feb 7, 2022
Looks like that CVE isn't public yet.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0391
Any chance I can get access (I originally reported this vuln.). My email is mike@free.law, if it's possible and my email is needed.
Thanks!
vstinner commented on Feb 8, 2022
Message from Gaurav Kamathe who requested the CVE:
"We've sent a request to MITRE to get this published and it'll be available on MITRE shortly."
timmc commented on Aug 25, 2022
@gpshead urlsplit already raises an exception for some malformed inputs: https://github.com/python/cpython/blob/v3.9.13/Lib/urllib/parse.py#L484 -- you can try it out with urlsplit('http://]/').
This kind of eclectic approach -- taking part of one spec, part of another, ignoring invalid values, turning invalid outputs into answers without a warning -- is just going to cause more vulnerabilities. A URL with newlines in it was never valid, for browsers or anything else. Now there's just another parser that will give answers that don't match other parsers (whether it's browsers, or curl, or anything else). Better to bite the bullet and say "hey, that's not parseable".
gpshead commented on Aug 25, 2022
If you have a concrete proposal to do something different or have found other bugs, please open a new Issue. Comments added to an old merged PR are likely to be ignored and unseen.
timmc commented on Aug 25, 2022
Understood. I mostly wanted to correct the record on urlsplit's existing behavior, for people looking back at the git blame to figure out why urlsplit behaves the way it does.
(And of course I couldn't resist tacking on a warning about parser mismatch, which I don't think got enough air time in the discussion.)
parth-gr commented on Sep 5, 2022
@orsenthil Why isn't this backported to python2?
Should I open a manual backport of this? As it will be helpful for python2 users also
gpshead commented on Sep 5, 2022
python2 is EOL and receives zero support here.
fix for santization URLs containing ASCII newline and tabs in urllib.…