Bug #61700 [PATCH]: FILTER_FLAG_IPV6, FILTER_FLAG_NO_PRIV_RANGE, FILTER_FLAG_NO_RES_RANGE failing

Edit report at https://bugs.php.net/bug.php?id=61700&edit=1 ID: 61700 Patch added by: cmb@php.net Reported by: nanocaiordo at gmail dot com Summary: FILTER_FLAG_IPV6, FILTER_FLAG_NO_PRIV_RANGE, FILTER_FLAG_NO_RES_RANGE failing Status: Verified Type: Bug Package: Filter related PHP Version: 7.2.11 Assigned To: cmb Block user comment: N Private report: N New Comment: The following pull request has been associated: Patch Name: Fix #61700: FILTER_FLAG_IPV6/FILTER_FLAG_NO_PRIV|RES_RANGE failing On GitHub: https://github.com/php/php-src/pull/7476 Patch: https://github.com/php/php-src/pull/7476.patch Previous Comments: ------------------------------------------------------------------------ [2021-08-05 15:58:16] cmb@php.net Related To: Bug #79906 ------------------------------------------------------------------------ [2018-10-11 20:51:52] requinix@php.net Given how many notations and short-hands there are, the only real way to validate IPv6 is to inet_pton it (which requires IPv6 support) and check the octets. PHP doesn't do that. It looks at the input string directly. The checks are self-explanatory. https://github.com/php/php-src/blob/PHP-7.2.11/ext/filter/logical_filters.c#L811 Note that the address must be mostly normalized beforehand (so no 0:0:0:0:0:0:0:1) yet some of the leading zeroes are required (2001:0010:: is excluded but 2001:10:: is not). https://3v4l.org/MHERV Regarding the original report, the first example should return false as the input was not a valid IPv4 address - the dotted notation has no technical significance and is only a convenience for humans to read. It's an IPv6 address that happens to map onto the IPv4 space. The second example is debatable, considering that the address is IPv6 and not in the IPv6 private range, but I think it's very reasonable to say it should fail because the address explicitly corresponds to an IPv4 address which *is* private. (Why should the first not be valid IPv4 but the second be treated as such? The IPV4/IPV6 flags test syntax and general usability, and a system that does not support IPv6 is not going to know to support a mapped address. I'm skeptical this format is used much in the wild anyways.) Third example, of course, should not pass. ------------------------------------------------------------------------ [2018-10-11 19:16:02] eric at ericstern dot com Any chance we can look into this further? It's been open and verified for over six years (I encountered it on 7.2.8), and has the potential to lead to security issues if code is relying on the accuracy of this filter to e.g. prevent malicious redirects to localhost. There are a _lot_ of ways to write an IPv6 address that equates to ::1, and this filter only appears to catch one of them. ------------------------------------------------------------------------ [2014-04-12 12:41:34] klunejko at gmail dot com FILTER_FLAG_NO_RES_RANGE also has some false positives, it sees 128.0.96.0/21 as a reserved, when it's not. This is happening in PHP 5.5 ------------------------------------------------------------------------ [2013-03-11 18:25:21] bugreport at zippymail dot info Hellon The problem is still present, even on newer version. Can you fix please ? Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61700 -- Edit this bug report at https://bugs.php.net/bug.php?id=61700&edit=1