WHATWG URL removes tab, new line, and carraige return characters before
processing URL strings. To narrow the differences between WHATWG URL and
url.parse(), and thus reduce opportunities for host spoofing etc. due to
differences between the two APIs, let's do the same with url.parse().
PR-URL: https://github.com/nodejs/node/pull/45116
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
If a port is not a number, throw rather than treating the `:` that
delineates the port as part of the path. This is consistent with WHATWG
URL and also mitigates hostname-spoofing.
Concerns about hostname-spoofing were raised and presented in excellent
detail by pyozzi-toss (pyozzi@toss.im/Security-Tech Team in Toss).
PR-URL: https://github.com/nodejs/node/pull/45012
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Make the url.parse() hostname parsing closer to that of WHATWG URL
parsing. This mitigates for cases where hostname spoofing becomes
possible if your code checks the hostname using one API but the library
you use to send the request uses the other API.
Concerns about hostname-spoofing were raised and presented in excellent
detail by pyozzi-toss (pyozzi@toss.im/Security-Tech Team in Toss).
PR-URL: https://github.com/nodejs/node/pull/45011
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Emulate the WHATWHG URL parse behavior of trimming leading and trailing
C0 control characters. This moves url.parse() slightly closer to
WHATWHG URL behavior. The current behavior is possibly insecure for some
uses. (The url.parse() API is marked as Legacy and the documentation
specifically says it has known bugs and insecure behaviors. Still this
change makes a lot of sense.)
This issue was reported by P0cas. https://github.com/P0cas
PR-URL: https://github.com/nodejs/node/pull/42196
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Mestery <mestery@protonmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Based on existing tests and code comments, url.parse() is expected to
treat any URL containing user@host as having a hostname. However, it
turns out this behavior relies on the URL having a hash which is
surprising, to put it mildly. Detect the host even without the hash.
PR-URL: https://github.com/nodejs/node/pull/41031
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
The legacy url.parse() function attempts to convert Unicode domains
(IDNs) into their ASCII/Punycode form through the use of the toASCII
function. However, toASCII can introduce or remove various characters
that at best invalidate the parsed URL, and at worst cause hostname
spoofing:
url.parse('http://bad.c℀.good.com/').href === 'http://bad.ca/c.good.com/'
(from [1])
url.parse('http://\u00AD/bad.com').href === 'http:///bad.com/'
While changes to the legacy URL parser are discouraged in general, the
security implications here outweigh the desire for strict compatibility.
This is since this commit only changes behavior when non-ASCII
characters appear in the hostname, an unusual situation for most use
cases. Additionally, despite the availability of the WHATWG URL API,
url.parse remain widely deployed in the Node.js ecosystem, as
exemplified by the recent un-deprecation of the legacy API.
This change is similar in spirit to CPython 3.8's change [2] fixing
bpo-36216 [3] aka CVE-2019-9636, which also occurred despite potential
compatibility concerns.
[1]: https://hackerone.com/reports/678487
[2]: https://github.com/python/cpython/commit/16e6f7dee7f02bb81aa6b385b982dcdda5b99286
[3]: https://bugs.python.org/issue36216
PR-URL: https://github.com/nodejs/node/pull/38631
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This function did not only validate the input but it returned a new
value in case the hostname was valid. This simplifies the function
by always returning the required value, no matter if it is valid or
invalid, so the callee site does not have to check that anymore. On
top the function is renamed to `getHostname` to make clear that the
function does not only validate the input but it also returns a new
value.
PR-URL: https://github.com/nodejs/node/pull/26809
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Before this commit, Node.js left it up to the system resolver or c-ares.
Leaving it to the system resolver introduces platform differences
because:
* some support IDNA 2008
* some only IDNA 2003 (glibc until 2.28), and
* some don't support IDNA at all (musl libc)
c-ares doesn't support IDNA either although curl does, by virtue of
linking against libidn2. Upgrading from libidn1 to libidn2 in order
to get proper IDNA 2008 support was the fix for curl's CVE-2016-8625.
libidn2 is not an option (incompatible license) but ICU has an IDNA API
and we already use that in one place. For non-ICU builds, we fall back
to the bundled punycode.js that also supports IDNA 2008.
Fixes: https://github.com/nodejs-private/security/issues/97
Fixes: https://github.com/nodejs/node/issues/25558
PR-URL: https://github.com/nodejs/node/pull/25679
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Gürgün Dayıoğlu