php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70501 MAX_FILE_SIZE does not abort upload
Submitted: 2015-09-15 11:06 UTC Modified: 2016-06-24 18:46 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: olafvdspek at gmail dot com Assigned:
Status: Open Package: *Web Server problem
PHP Version: 5.6.13 OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: olafvdspek at gmail dot com
New email:
PHP Version: OS:

 

 [2015-09-15 11:06 UTC] olafvdspek at gmail dot com
Description:
------------
> This form element should always be used as it saves users the trouble of waiting for a big file being transferred only to find that it was too large and the transfer failed.

As far as I know this bit is incorrect. It does NOT avoid a too-large file from being uploaded as the value is only checked AFTER the file was uploaded completely.

http://php.net/manual/en/features.file-upload.post-method.php

IMO MAX_FILE_SIZE is useless and should be dropped entirely.

Test script:
---------------
-


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-15 11:54 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2015-09-15 11:54 UTC] requinix@php.net
The sentence before that is
> The MAX_FILE_SIZE hidden field (measured in bytes) must precede the file input
> field, and its value is the maximum filesize accepted by PHP.

If you have a repro script that has this field appearing before the file input and the value is still ignored, please share it so the problem can be fixed.
 [2015-09-15 11:57 UTC] olafvdspek at gmail dot com
-Status: Feedback +Status: Open
 [2015-09-15 11:57 UTC] olafvdspek at gmail dot com
The value isn't ignored, but it's checked AFTER the entire file was uploaded.
 [2015-09-15 21:38 UTC] requinix@php.net
As far as I can tell the intention of MAX_FILE_SIZE was to abort the upload, so the fact that files continue to be uploaded (which I've confirmed happens with PHP 5.5 + Apache 2.4 + mod_php) seems to be a bug. Perhaps rather than getting rid of something deemed useless, it can be fixed to work as expected.
 [2016-06-24 18:45 UTC] cmb@php.net
-Summary: MAX_FILE_SIZE docs incorrect +Summary: MAX_FILE_SIZE does not abort upload -Package: Documentation problem +Package: *Web Server problem
 [2016-06-24 18:45 UTC] cmb@php.net
Indeed, this is quite certainly not a doc bug, see
<https://github.com/php/php-src/blob/php-7.0.8/main/rfc1867.c#L1049-L1053>.
 [2016-06-24 18:46 UTC] cmb@php.net
-Type: Documentation Problem +Type: Bug
 [2018-11-25 22:14 UTC] petk@php.net
Confirming this bug also here. The MAX_FILE_SIZE post data value check is never reached since the upload_max_file size ini directive is always set (no matter if you comment it out of php.ini it will be by default 2MB). This hidden value will only work if you set upload_max_filesize to 0 or -1 (like unsetting it). On top of that, edge case is vulnerable to changing the value on the user side (it is a hidden field after all and not a setting in the code).

Considering that it has been used in only an extreme edge case for the past several PHP versions and frameworks don't use it anymore it might be a good idea to remove it or better yet refactor it in the core code to something that works. Because with current PHP versions the only check that is done is the upload_max_filesize ini directive on the php side. And, preferably, also a manual check inside the code on the server side comparing a manual configuration value to a file size of the uploaded file.
 [2018-11-26 18:59 UTC] petk@php.net
Correcting my explanation above: When using MAX_FILE_SIZE, it will be used in two cases. One, if you unset the upload_max_filesize (to 0 or -1) (bad idea anyway, or two, if you set upload_max_filesize to be bigger than MAX_FILE_SIZE.

Actually, the MAX_FILE_SIZE option is useful after all because some app might set the ini directive upload_max_filesize to some setting for all files in the app, and additionally manually set different MAX_FILE_SIZE for multiple upload forms in the same app (let's say one for images and one for videos).

And it does stop the upload, but differently than reader might expect on the first glance. Uploading will be stopped when the MAX_FILE_SIZE is reached on the server (not at the beginning of the upload process). With extremely large files, for example hundreds of MB or GBs, this still is relevant today actually. However, for better user experience all decent forms might want to think about adding form client side validation as well (even file size can be determined at the time of this writing by the browser and JavaScript).

So, I was wrong a bit here and too hasty with previous comment conclusions. However, relying on this feature is not something that is secure since it can be spoofed on the client (browser) side easily.

Probably this would be better fixed with a better explanation in the documentation instead.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Jul 21 13:01:25 2019 UTC