Add 'multipart_uri_whitelist' INI option to control which URL paths are allowed to submit multipart body

[chopins]

Currently, in PHP, users can upload files to the server under any circumstances, even if the PHP script does not include file upload handling.
This not only unnecessarily increases server bandwidth usage but also introduces the security risk of arbitrary file uploads to the server. like : hitcon-ctf-2018-one-line-php-challenge.
So add multipart_uri_whitelist PHP_INI_PERDIR ini option to Allow file uploads only from whitelisted paths.

[iluuu1994]

Seems more like a webserver responsibility, but I'll let Jakub be the judge of that.

[chopins]

Seems more like a webserver responsibility, but I'll let Jakub be the judge of that.

The issue that PHP automatically saves uploaded files to temporary files should still be addressed.
Additionally, since the server cannot determine whether the php script will handle the file upload, PHP needs to make that determination.

[arnaud-lb]

hitcon-ctf-2018-one-line-php-challenge relies on the existence of an arbitrary file include vulnerability in the application: https://github.com/knqyf263/hitcon-ctf-2018-one-line-php-challenge/blob/18d2860a21ce763379d0b091a60ddf1b57cd620a/index.php. The exploit uses the session file upload progress feature to add arbitrary content in the attacker's session file, and includes it. Uploading and including can be made on different URLs.

The exploit will work as long as there is at least one URL on which file uploads are allowed, so I think that a whitelist is not the right approach. You would need to disable file uploads entirely, or to make sure that whitelisted URLs are not accessible (but then the same layer than controls access can also disable uploads).

One way to make the exploit ineffective would be to obfuscate/encrypt session files: #3759 @devnexen. This can also be implemented with a custom SessionHandler: https://externals.io/message/117740#117748. With the caveat that the arbitrary file upload vulnerability would likely allow the attacker to disclose the encryption key.

There are other ways to exploit these vulnerabilities without controlling a local or remote file: https://blog.lexfo.fr/wrapwrap-php-filters-suffix.html. This relies on filter:// URLs and the convert filter to manifest arbitrary characters. IMHO we should make it more difficult to accidentally include arbitrary URLs.

[iluuu1994]

In terms of alternative approaches, there's also the enable_post_data_reading INI setting, which can be set to 0, and then request_parse_body() can be used instead to conditionally consume the request content and actually create the file.

[chopins]

In terms of alternative approaches, there's also the enable_post_data_reading INI setting, which can be set to 0, and then request_parse_body() can be used instead to conditionally consume the request content and actually create the file.

This function cannot independently control requests of type multipart/form-data; files are still uploaded after using it.

[chopins]

@iluuu1994
The "hitcon-ctf-2018-one-line-php-challenge" just reminded me of the arbitrary file upload issue.
Additionally, after some thought, I realized that by adding dedicated control for the multipart/form-data type and combining it with an authorization token along with the request_parse_body() function, flexible, authorization-based file uploads can be achieved.