Detecting file upload size on the client side? - php

I'm using PHP for file uploads. In the PHP manual it shows an example using a MAX_FILE_SIZE hidden field, saying that it will detect on the client side (i.e. the browser) whether the file is too large or not.
I've just tried the example in Firefox, Chrome and IE and it doesn't work. The file is always uploaded, even if it is way larger than the specified hidden field.
Incidentally, if the file is larger than MAX_FILE_SIZE then calling move_uploaded_file doesn't work, so it seems the variable is having an effect server-side, but not client-side.

On MAX_FILE_SIZE
Read This:
...At http://pk.php.net/manual/en/features.file-upload.post-method.php and equivalent locations in other formats, it is stated
that browsers take the value of a MAX_FILE_SIZE form field into
account.
This information is repeated elsewhere on the web and in books, but
appears to originate from the PHP documentation (it does not appear in
terms of other server-side technologies).
There is nothing in any of the HTML, HTTP or related specs to indicate
that this is the case (in particular RFC 1867 which introduced file
uploads to HTML doesn't mention it, so it isn't even a case of a kludge
that was mentioned in the first RFC and then dropped) nor does it make
sense in the context of the HTML specs (there is nothing to indicate any
relationship between that particular hidden input and the file input).
The only statements about hidden fields I could find in any of them was
warnings in the security considerations sections against user-agents
basing any file-related operations on anything mentioned in a hidden
field.
No browsers appear to perform this as an "extension". Indeed given that
there are potentially other possible meanings for a hidden field with
that name in an application handling several file uploads, it would have
to be considered a design flaw any any did.
I submit that there is no such mechanism in mainstream browsers (if any
at all) and indeed shouldn't be. Reference to it should be dropped from
documentation.
I'd further suggest that since this idea has propagated from this
documentation elsewhere that a note about it not working should to be
added.
If a mechanism is required or desired for more rapidly handling this
sort of file handling issue then it requires functionality to allow PHP
to intercept streams being uploaded before request completion, which
would be completely different to how this documentation suggest it
should be dealt with, even if it was true...
http://www.juangiordana.com.ar/blog/2007/12/08/max_file_size-erroneo/
the code below come from swfUpload php implementation:
// Check post_max_size (http://us3.php.net/manual/en/features.file-upload.php#73762)
$POST_MAX_SIZE = ini_get('post_max_size');
$unit = strtoupper(substr($POST_MAX_SIZE, -1));
$multiplier = ($unit == 'M' ? 1048576 : ($unit == 'K' ? 1024 : ($unit == 'G' ? 1073741824 : 1)));
if ((int)$_SERVER['CONTENT_LENGTH'] > $multiplier*(int)$POST_MAX_SIZE && $POST_MAX_SIZE) {
header("HTTP/1.1 500 Internal Server Error");
echo "POST exceeded maximum allowed size.";
exit(0);
}
// Validate the file size (Warning the largest files supported by this code is 2GB)
$max_file_size_in_bytes = 2147483647;
$file_size = #filesize($_FILES[$upload_name]["tmp_name"]);
if (!$file_size || $file_size > $max_file_size_in_bytes) {
HandleError("File exceeds the maximum allowed size");
exit(0);
}

This probably only works on Firefox 3.6 for now:
<script type="text/javascript">
function checkSize()
{
var input = document.getElementById("upload");
// check for browser support (may need to be modified)
if(input.files && input.files.length == 1)
{
if (input.files[0].fileSize > 1024) /* or maybe .size */
{
alert("The file must be less than 1KB");
return false;
}
}
return true;
}
</script>
<form method="post" enctype="multipart/form-data" onsubmit="return checkSize()">
<input type="file" id="upload" />
<input type="submit" />
</form>
See http://www.w3.org/TR/FileAPI/.

As far as I know there is no simple, cross-browser solution to achieve this. The only working solutions are Flash or Java based since these technologies can access filesystem and get file info.
Example scripts: YUI2 Uploader, FancyUpload, SWFUpload

If you are using MAX_FILE_SIZE hidden field properly, the file uploading will just stop when the uploaded size reaches the specified value. And thus saves users the trouble of waiting for a big file being transferred.
You have to check whether the file upload is stopped, in the server side by using the error code generated.
if($_FILES['userfile']['error'] == 2)
{
die("Maximum file size Exceeded");
}

Related

How to upload a safe image with PHP?

I know there is a big amount of questions about this but I cannot get one that involves all I want to be aware of.
What I want to do is to allow the users of my webpage to upload images with a form. And I want to do this process secure, or at least as much secure I can.
I do not know too much about security in terms of deep inside of it, but I am aware of about all the consequences that a insecure webpage can produce. And I cannot be quiet thinking that my webpage is insecure or that anyone is not going to enter into my webpage because it does not have enough visits(I am realist).
At this point, I know that all the checks about security have to be done on server side instead of client side (or in both).
I know that a file can be fooled as an image and run malicious code so I searched about methods to avoid this. This is what I could find to check before store the image on the server:
From $_FILES:
$_FILES['file']['name']: To check that the file that I have uploaded have a name. To know that the file exists.
$_FILES['file']['error']: To check if the image have an error.
$_FILES['file']['size']: To check that the size of the image is bigger than 0.
$_FILES['file']['type']: To check that the type of the file is an image but it is not recommended because PHP does not check it.
General functions:
Check magic numbers to verify the image type.
exif_imagetype(): To check the type of an image.
getimagesize(): To check if it returns a 0 which means that the file is not an image.
imagecreatefromstring(): To create a new image giving a string. If it cannot be created, then is not an image.
imagepng: To create a PNG image to remove all meta-data (using imagecreatetruecolor() and imagecopy()).
But the problem I have is that I do not know if I should use all of these methods or just avoid or add some of them (because some of them seems redundant).
And my questions are:
Should I use all of them?
Have I to add another one method to be more secure?
Could be the order in which I filter the file critic? I mean, is it better to use one filter before another and viceversa? If so, what should be the order and why?
Note: I am not searching about personal opinion. I tried to gather all info I could, but I cannot be sure if it is ok or not talking about security terms. If you can put examples of something that it is forgotten it would be great.
Thanks in advance!
To answer your questions:
You don't need to use all of those methods, and which ones you use are going to be based on personal opinion. Meaning to say, there is more than one perfectly secure way to do it so don't be suprised if you get multiple different answers.
See examples below for additional checks you might have left out
Yes, the order definitely matters.
Depending on your application, the logic for any secure upload should flow something like this:
Is the user logged in? (optional)
// make sure user is logged in
if (!$user->loggedIn()) {
// redirect
}
Does the user have permission? (optional)
// make sure user has permission
if (!$user->isAllowed()) {
// redirect
}
Was the form submitted?
// make sure form was submitted
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
Is the form input valid?
// validate CSRF token
// ...
// make sure there were no form errors
if ($_FILES['file']['error'] == UPLOAD_ERR_OK) {
// make sure the file size is good
if ($_FILES['file']['size'] <= MAX_FILE_UPLOAD) {
// make sure we have a valid image type
$type = exif_imagetype($_FILES['file']['tmp_name']);
if ($type !== false) {
// make sure we check the type against a whitelist
if (in_array(ltrim(image_type_to_extension($type), '.'), array('jpeg', 'jpg', 'png'))) {
Even after validating, never trust user input
// give the file a unique name
$hash = hash_file('sha1', $_FILES['file']['tmp_name']);
$ext = image_type_to_extension($type);
$fname = $hash . $ext;
Save the file (or optionally recreate it with a library to strip out meta-data) but NEVER in a publicly accessible directory
$upload_path = '/path/to/private/folder';
move_uploaded_file($_FILES['file']['tmp_name'], "$upload_path/$fname");
The steps above are perfectly secure and more than reasonable, of course there is always a risk that some other part of your application or server might be vulnerable.
I would do the following with an apparent image upload:
1) Use is_uploaded_file() to ensure you've not been fooled into working on something else entirely
if(!is_uploaded_file($yourfile))
return false;
2) Check the mimetype with exif_imagetype() and block anything you don't want
$allowed_images = array(IMAGETYPE_BMP, IMAGETYPE_GIF, IMAGETYPE_JPEG, IMAGETYPE_PNG);
$uType = exif_imagetype($yourfile);
if(!in_array($uType, $allowed_images))
{
unlink($yourfile);
return false;
}
3) Use Imagick to remake the image and remove all comments and metadata:
$image = new Imagick($yourfile);
$image->resizeImage($image->getImageWidth(), $image->getImageHeight(), Imagick::FILTER_CATROM, 1);
$image->stripImage(); // remove all comments and similar metadata
4) Write the replacement image to the filesystem and erase the original file:
$image->writeImage("/path/to/new/image");
unlink($yourfile);
5) Upload this image to S3.
// your S3 code here
6) Make a note of the image's S3 URL in the database or wherever.
// your database code here
7) Erase the replacement image.
unlink("/path/to/new/image");
If you get enough responses, you might have a good answer! :-)
Operating System
Make sure you have a dedicated volume for the files. Or, at minimum, have quota set on the directory. Make sure you have enough inodes and such, if on Linux/Unix. A bunch of small files can be just as deadly as a few gigantic files. Have a dedicated uploads directory. Set where the temp files should go in your php.ini. Make sure your file permission are safe (chmod), too. Use Linux ACLs, if necessary, to fine tune permissions. Test, test, test.
PHP
Incorporate the knowledge found here into your uploaded file handling algorithm PHP Manual: POST method uploads. Take the MAX_FILE_SIZE bit with a grain of salt.
Make sure you know what your max up load file size is. Set it accordingly. There may be other file related settings. Be sure to lock those in before getting around to the $_FILES superglobal.
Do not work with the uploaded files directly, and do not use the name attribute at all to give the file a real file name. Use, is_uploaded_file() and move_uploaded_file() appropriately.
Use tmp_name appropriately.
Be wary of null bytes on file names! Yes, you still need to filter and validate any string that represents user input (especially if you intend on using it any way).
First things first, check for the presence of a file.
Second, check the size in bytes.
If anything in #5 or #6 fail, the validation process should end. For a robust routine, incorporate the idea that at sometime you may want to upload multiple files at one time (PHP Manual: Uploading Multiple Files). In that case, the $_FILES superglobal may not look like you would expect. See the link above for more details.
GD
You've got the general idea about using these functions to open the submitted file (without using the user submitted name, that is). Just come up with a logical series of progressive steps. I don't have those steps, but if meta-data can be a problem, that would seem high on the list of GD stuff to try early (after basic file presence and size stuff). I could be wrong though.

How to require a file upload from a user - php?

I'm trying to create a large, multi-page, PHP web application for work where a client enters information and receives output (think tax software). However, I can't seem to figure out how to require that a file is uploaded by the client. By files, I mean mostly PDF, txt, JPEG, etc.
There are several file upload fields that must be uploaded for the output to contain all of the necessary information to work, and several other file upload fields that are optional.
I would like to do this in PHP if possible, since as I understand it, Javascript could be turned off and that would stop the validation.
On the PHP file that processes the form you'd want to use something like this:
if (isset ($_FILES['myfile']['tmp_name']) && !empty ($_FILES['myfile']['tmp_name'])) {
// process file upload
} else {
echo 'You must upload a file in the "myfile" field to proceed!';
}
This would be in addition to other proper form validation techniques of course.
if(!isset($_FILES["fileinputname"][]))
{
die("Upload files, you must.");
}
You should check out this article
also, for html validation, you can use this.
(Most people don't like it, it's personal preference for many people)
may work, but html validation can be bypassed. IE and Safari don't support it.
http://www.w3schools.com/html5/att_input_required.asp
First of all, you shouldn't validate your forms with JavaScript only, a server-side validation should always be done.
Regarding your question, when you upload a file with PHP, you have its information in the $_FILES array. You will need to look there to know if a file has been uploaded or if it is in the right format, etc.

empty $_POST and $_FILE variable when uploading large files

I was trying to upload a file which is 20MB in size. Now default form upload size is 8MB. When I upload such a file i get $_POST and $_FILE variables empty. Now I want to put a check on file size. If I get both these variables empty, how can I put such a check ?? Please give me suggestions
Barring any code errors, its most likely your 20MB exceeds your upload limit.
Change this permanently from your php.ini file.
Use
ini_set("upload_max_filesize", "30M");
to set your max upload size for that session only. And for POST
Use this
ini_set("post_max_size", "30M");
To check the sizes
echo ini_get("post_max_size") . "\n";
echo ini_get("upload_max_filesize");
No idea what you actually want. But you can probe the recieved content size using:
$_SERVER["CONTENT_LENGTH"]
This should tell how big the POST request body would have been. (The number might be higher than the actual received content, in case of an aborted upload.)
Checkout php://input, the allowed 8mb part of it should be there.
For example echo file_get_contents('php://input');
You can dynamically set your max file size for upload.
write down below statement in your upload function where you are trying to upload file.
this will enhance limit up to 50 MB
ini_set("upload_max_filesize", "50M");
If you want to check file variables, you can user alternative HTTP_POST_FILES
$theFileSize = $HTTP_POST_FILES['file']['size'];
Hope this may help you.
Thanks.
Use MAX_FILE_SIZE as a hidden input field, this will stop the user waiting if the file is larger than the limit and won't execute your code so the variables won't be empty...
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. 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. Keep in mind: fooling this
setting on the browser side is quite easy, so never rely on files with
a greater size being blocked by this feature. It is merely a
convenience feature for users on the client side of the application.
The PHP settings (on the server side) for maximum-size, however,
cannot be fooled.
http://www.php.net/manual/en/features.file-upload.post-method.php

Why can't the upload field select a new file after jQuery-validate returns an error?

I'm coding a form using PHP and jQuery. I have a file upload field to which I applied the following jQuery-validate rules:
image: {
accept: "jpeg|jpg|png|gif",
required: "#edit_ID:blank"
}
The file upload field must only accept jpeg/jpg, png, or gif images. It is required only if the field with the ID "edit_ID" is left blank.
This is my file upload field:
<input type="file" id="image" name="image" class="input1" />
The file upload field selects files without any problem, but when jQuery returns an error because of a violated rule, even if I select a new file from my computer the file I selected before the error appeared remains there. It's as if it becomes disabled after jQuery-validate gives an error.
I tried removing the rules set for this field, tested it, and encountered no problem.
Does anybody have an idea what's causing this problem?
Thanks.
P.S.: I encounter the problem in Firefox (v.3.6.9) and IE (v.8) but not in Google Chrome (v.5).
This will not answer your original question, technically.
But, it's not a good idea to trust client side programming to do image validation; your program can be fooled. Since you are using PHP anyway, why not use PHP to do some server side validation?
All files uploaded are stored in the $_FILES array. You can check file type like so:
<?php
foreach($_FILES as $file)
{
if(!empty($file['type'])) //only check if there's a valid file type
{
if($file['type'] != 'image/jpeg' && $file['type'] != 'image/png' && $file['type'] != 'image/gif')
{
//this file is not any one of the accepted formats, so long!
}
else{//do your processing}
}
else{//error invalid file}
}
?>
In case you want instant validations, you can still use AJAX, instead of relying solely on the client side to do the validation.

MAX_FILE_SIZE in PHP - what's the point?

I was trying to make a file upload form and checked the PHP documentation to refresh my memory on the subject. Here is a link to the relevant article. All of a sudden I noticed this message:
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. 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. Keep in mind: fooling this setting on the browser side is quite easy, so never rely on files with a greater size being blocked by this feature. It is merely a convenience feature for users on the client side of the application. The PHP settings (on the server side) for maximum-size, however, cannot be fooled.
OK... Say what? First it tells that it must precede the file upload field. Then it tells us that it is merely for convenience. And besides - it's on client side anyway so anyone can mess with it. After googling around I also found information that there are no known browsers that support it.
WTF? Why is it said that it must precede the file upload field if it seems to be (for all intents and purposes) absolutely pointless? Should I bother putting it in my HTML at all?
After failed attempt to find any authoritative information about MAX_FILE_INFO i've decided to resort to drastic measures - and peeked at PHP's holy source.
I scanned entire PHP source recursively using grep:
grep -ri MAX_FILE_SIZE .
The only place that mentioned this variable was (excluding tests folder) - rfc1867.c file.
Completely expectable since rfc1867 standard deals with file uploads.
Related C code:
......
if (!strcasecmp(param, "MAX_FILE_SIZE")) {
max_file_size = atol(value);
}
......
......
if (PG(upload_max_filesize) > 0 && (total_bytes+blen) > PG(upload_max_filesize)) {
cancel_upload = UPLOAD_ERROR_A;
} else if (max_file_size && ((total_bytes+blen) > max_file_size)) {
cancel_upload = UPLOAD_ERROR_B;
} else if
....
So - here's short explanation of above code:
1) first we get the value of MAX_FILE_SIZE into max_file_size variable.
2) Then we check if max_file_size value exists and if the sum of already accepted bytes (total_bytes) + the size of bytes in the buffer(blen) exceeds max_file_size.
3) If 2 is true - at this point we cancel upload with some error code that's been set by this constant: UPLOAD_ERROR_B
BUT - as you can see - right before checking max_file_size variable - PHP performs EXACTLY THE SAME CHECK for upload_max_filesize variable!!!
So - there we have it.
Conclusion:
IMHO - op is right - there is 0 point in including MAX_FILE_SIZE into your forms! Simply set upload_max_filesize in your php.ini file or dynamically via ini_set().
At the moment there are no browsers that actually care about the MAX_FILE_SIZE directive so it is pretty pointless. I suppose it does give you more granular control over max sizes on upload (as the poster above stated) rather than going with php.ini's, but personally I just ignore it, and you probably should too. It will certainly not stop a user uploading a larger than required file - the manual is fairly misleading in this regard.
Until we find browsers that support it, there's no point on the client side.
However, on the server side, MAX_FILE_SIZE does affect the values you get from $_FILES['your_file'].
Assuming the browser's request actually made it through post_max_size, usually this is what PHP gives:
array(5) {
["name"]=> string(11) "my_upload.dll"
["type"]=> string(24) "application/x-msdownload"
["tmp_name"]=> string(26) "C:\WINDOWS\Temp\php86A.tmp"
["error"]=> int(0) // UPLOAD_ERR_OK
["size"]=> int(238592)
}
But if uploaded file size exceeds MAX_FILE_SIZE, you'd see:
array(5) {
["name"]=> string(11) "my_upload.dll"
["type"]=> string(0) ""
["tmp_name"]=> string(0) ""
["error"]=> int(2) // UPLOAD_ERR_FORM_SIZE
["size"]=> int(0)
}
And the part on "MAX_FILE_SIZE must precede the file input field" is not a joke. It actually works because PHP will interpret the browser's POST request payload sequentially:
<input name=F1 type=file>
<input name=F2 type=file>
F1 and F2 will not be affected by MAX_FILE_SIZE
<input name=MAX_FILE_SIZE value=1024 type=hidden>
<input name=F3 type=file>
<input name=F4 type=file>
F3 and F4 will have MAX_FILE_SIZE = 1024 bytes
<input name=MAX_FILE_SIZE value=0 type=hidden>
<input name=F5 type=file>
<input name=F6 type=file>
F5 and F6 will have MAX_FILE_SIZE = 0 (infinite)
<input name=MAX_FILE_SIZE value=1 type=hidden>
<input name=F7 type=file>
<input name=F8 type=file>
F7 and F8 will have MAX_FILE_SIZE = 1 byte
Also note that PHP interprets MAX_FILE_SIZE case insensitively, so maX_fILe_sIZE and Max_File_SIZE would work too.
I believe the point is that conformant browsers would prevent form submission in the case where the user selected a file that was too large, which would save them having to perform at least a partial upload (which could take a while) of a file that was going to be rejected.
On the server side, PHP still checks and enforces the various limits set in PHP.ini, and will reference the fact that an upload was too large in the normal manner, i.e. an error code set in $_FILES. You might think of the field as an analogy to JavaScript validation - we might do a quick client-side check for the user's convenience, but we still do a proper server-side test and enforce it for all requests.
As others have stated, there don't appear to be any browsers that actually bother to perform this check, making it relatively useless.
What follows is me being wrong, please read the other answers which are better-informed, and accurate (AFAIK).
I think the point is exactly as it states:
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
Yes, it can be fooled, and so shouldn't be relied on to prevent larger files from being uploaded, but for non-malicious users if the uploaded file is bigger than the integer in this field, PHP disallows this upload and presents an error code in the $_FILES array (source - comments on php.net).
I use it to set file size limit when a particular application needs smaller files than the limit in php.ini. My php scripts check it, but it is set in the HTML form. Different forms have different file size limits. I am not sure if this has much to do with the intended use, but it makes it easier to reuse my scripts. It would be good if it could be checked at the browser level, but it's not the only reason it is useful.

Categories