Given that the documentation of parse_url()[1] states

| This function is not meant to validate the given URL, it only
| breaks it up into the above listed parts. Partial URLs are also
| accepted, parse_url() tries its best to parse them correctly.

I don't think this qualifies as security issue.  However, given
that filter_var($a, FILTER_VALIDATE_URL) returns the URL (instead
of false), I think there is a security issue in php_url_parse_ex().

A possible fix would be recognize the userinfo only if it is valid
according to RFC 3986[2], which could look like
<https://gist.github.com/cmb69/180b63eea1c5163cb29440421007ba4a>
(this has been developed against PHP-7.4).

Stas, what do you think about this?

[1] <https://www.php.net/parse-url>
[2] <https://tools.ietf.org/html/rfc3986#appendix-A>

I think if userinfo is invalid FILTER_VALIDATE_URL definitely should not accept it.

We'd probably need a fix for this from 7.1 up.

Oops, I meant 7.2 of course not 7.1

Ah, right!  Patch for PHP-7.2:
<https://gist.github.com/cmb69/449e29fa609cf2fd6b617cf5f41638e3>.

Hello,

Have we considered a case where the input has only "@" within the URL instead of "\@". A sample use case is below on latest version of PHP, where the hostname being returned is still incorrect (malicious).



$ php -v
PHP 7.4.14 (cli) (built: Jan  5 2021 10:45:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.14, Copyright (c), by Zend Technologies
$ 
$ rpm -qa | grep -i php-7
php-7.4.14-1.fc33.x86_64
$ 
$ cat test.php 
<?php
	#$a = "http://php.net\@aliyun.com/aaa.do";
	$a = "http://php.net@aliyun.com/aaa.do";
	var_dump($a);
	$b = parse_url($a);
	var_dump($b);
?>
$ 
$ php -f test.php 
string(32) "http://php.net@aliyun.com/aaa.do"
array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(10) "aliyun.com"     <<<<<<<<
  ["user"]=>
  string(7) "php.net"
  ["path"]=>
  string(7) "/aaa.do"
}
$

The hostname returned in this case is correct. Also, please don't comment on the issues' page about different issues, it makes it very hard to track things.

Was this intended to be merged into the 7.2 branch? I thought that was out of support now?

It looks like there is a regression regarding this fix.

https://3v4l.org/hGkQj

The fix is in: 7.3.26, 7.4.14 and 8.0.1 as wanted, but it's gone again in: 7.3.27, 7.4.15 and 8.0.2

The change to parse_url was intentionally reversed. The change in filter_url still there.

Thanks for the info.