URLs encoded with Punycode/IDNA use NFKC normalization to decompose characters [1]. This can result in some characters introducing new segments into a URL.

For example, \uFF03 is not equal to '#' under direct comparison, but normalizes to '#' which changes the fragment part of the URL. Similarly \u2100 normalizes to 'a/c' which introduces a path segment.

Currently, urlsplit() does not normalize, which may result in it returning a different netloc from what a browser would

>>> u = "https://example.com\uFF03@bing.com"
>>> urlsplit(u).netloc.rpartition("@")[2]
bing.com

>>> # Simulate
>>> u = "https://example.com\uFF03@bing.com".encode("idna").decode("ascii")
>>> urlsplit(u).netloc.rpartition("@")[2]
example.com

(Note that .netloc includes user/pass and .rpartition("@") is often used to remove it.)

This may be used to steal cookies or authentication data from applications that use the netloc to cache or retrieve this information.

The preferred fix for the urllib module is to detect and raise ValueError if NFKC-normalization of the netloc introduce any of '/?#@:'. Applications that want to avoid this error should perform their own decomposition using unicodedata or transcode to ASCII via IDNA.

>>> # New behavior
>>> u = "https://example.com\uFF03@bing.com"
>>> urlsplit(u)
...
ValueError: netloc 'example.com#@bing.com' contains invalid characters under NFKC normalization

>>> # Workaround 1
>>> u2 = unicodedata.normalize("NFKC", u)
>>> urlsplit(u2)
SplitResult(scheme='https', netloc='example.com', path='', query='', fragment='@bing.com')

>>> # Workaround 2
>>> u3 = u.encode("idna").decode("ascii")
>>> urlsplit(u3)
SplitResult(scheme='https', netloc='example.com', path='', query='', fragment='@bing.com')

Note that we do not address other characters, such as those that convert into period. The error is only raised for changes that affect how urlsplit() locates the netloc and the very common next step of removing credentials from the netloc.

This vulnerability was reported by Jonathan Birch of Microsoft Corporation and Panayiotis Panayiotou (p.panayiotou2@gmail.com) via the Python Security Response Team. A CVE number has been requested.

[1]: https://unicode.org/reports/tr46/

FYI I added this vulnerability to:
https://python-security.readthedocs.io/vuln/urlsplit-nfkc-normalization.html

New changeset 16e6f7dee7f02bb81aa6b385b982dcdda5b99286 by Steve Dower in branch 'master':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/16e6f7dee7f02bb81aa6b385b982dcdda5b99286

New changeset daad2c482c91de32d8305abbccc76a5de8b3a8be by Steve Dower in branch '3.7':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/daad2c482c91de32d8305abbccc76a5de8b3a8be

New changeset e37ef41289b77e0f0bb9a6aedb0360664c55bdd5 by Steve Dower in branch '2.7':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/e37ef41289b77e0f0bb9a6aedb0360664c55bdd5

This issue is now assigned CVE-2019-9636

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9636

A missed print statement in the 2.7 patch is causing the tests to fail.

Line 647 of Lib/test/test_urlparse.py

New changeset 62d36547f97210a26cc6051da78714fd078e158c by larryhastings (Steve Dower) in branch '3.4':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (#12224)
https://github.com/python/cpython/commit/62d36547f97210a26cc6051da78714fd078e158c

New changeset c0d95113b070799679bcb9dc49d4960d82e8bb08 by larryhastings (Steve Dower) in branch '3.5':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (#12223)
https://github.com/python/cpython/commit/c0d95113b070799679bcb9dc49d4960d82e8bb08

> A missed print statement in the 2.7 patch is causing the tests to fail.

How does that cause tests to fail? Is it going to stderr? Or just causing an error.

>
> How does that cause tests to fail? Is it going to stderr? Or just causing
> an error.
>

It is causing an "unexpected output error".  When the test is re-run at the
end, it is run in verbose mode so the extra output is ignored and thus
passes at that point.

>

New changeset 23fc0416454c4ad5b9b23d520fbe6d89be3efc24 by Ned Deily (Steve Dower) in branch '3.6':
[3.6] bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (GH-12215)
https://github.com/python/cpython/commit/23fc0416454c4ad5b9b23d520fbe6d89be3efc24

Sample buildbot log of print statement in testcase causing rerun of test : https://buildbot.python.org/all/#/builders/101/builds/364/steps/4/logs/stdio

Thanks. Just posted a PR that puts the print behind a verbose flag (on Python 3 it uses subtest so that we see which character caused the failure).

If that doesn't work for whatever reason, I'll just leave it out and hope that we never have to debug it on Python 2 :)

Commit e37ef41289b77e0f0bb9a6aedb0360664c55bdd5 introduced a regression on AMD64 Windows8.1 Refleaks 2.7:

test_urlparse leaked [114, 114, 114] references, sum=342

https://buildbot.python.org/all/#/builders/33/builds/532

It is fixed by PR 12291.

You can test:

python -m test -R 3:3 test_urlparse

If it's fixed by not printing to the console, then it must be a refleak in print. Or perhaps in the test failure/repeat.

That PR is going to be merged as soon as AppVeyor finishes, so nothing to worry about here.

New changeset 507bd8cde60ced74d13a1ffa883bb9b0e73c38be by Steve Dower in branch '2.7':
[3.7] bpo-36216: Only print test messages when verbose (GH-12291)
https://github.com/python/cpython/commit/507bd8cde60ced74d13a1ffa883bb9b0e73c38be

Hah, I typo'd the commit message and marked it as 3.7 instead of 2.7. Oh well.

I am trying to investigate the impact of this bug on Python 2.6 (yes, it is for SLE), and I have hard to replicate the steps in the description even on 2.7:

~$ ipython2
Python 2.7.15 (default, May 21 2018, 17:53:03) [GCC]
Type "copyright", "credits" or "license" for more information.

IPython 5.8.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from urlparse import urlsplit

In [2]: u = "https://example.com\uFF03@bing.com".encode("idna").decode("ascii") 

In [3]: u
Out[3]: u'https://example.com\\uFF03@bing.com'

In [4]: urlsplit(u).netloc.rpartition('@')[2]
Out[4]: u'bing.com'

In [5]: u = "https://example.com\uFF03@bing.com"

In [6]: urlsplit(u).netloc.rpartition('@')[2]
Out[6]: 'bing.com'

In [7]: u = u.encode("idna").decode("ascii") 

In [8]: urlsplit(u).netloc.rpartition('@')[2]
Out[8]: u'bing.com'

In [9]: import unicodedata

In [10]: u2 = unicodedata.normalize('NFKC', u)

In [11]: u2
Out[11]: u'https://example.com\\uFF03@bing.com'

In [12]: urlsplit(u2)
Out[12]: SplitResult(scheme=u'https', netloc=u'example.com\\uFF03@bing.com', path=u'', query='', fragment='')

In [13]:

Yes, the results are weird, and most likely they would break any software relying on them, but I am not sure that it is a security issue.

vstinner ? steve.dower ? What do you think?

You need a "u" prefix on some of your strings or they're probably being immediately decomposed. The result of urlsplit should be unicode on Python 2 for a Unicode input, and yours are not.

You are right. Thank you.

Fix meta (not incl 2.7 which is no longer available to select).