________________________________
De: Ashley Sheridan <a...@ashleysheridan.co.uk>
Para: m...@nikha.org; Domain nikha.org <m...@nikha.org>
Cc: php-general@lists.php.net
Enviadas: Quarta-feira, 25 de Setembro de 2013 2:22
Assunto: Re: [PHP] Apache
"Domain nikha.org" <m...@nikha.org> wrote:
>Ashley Sheridan am Montag, 23. September 2013 - 21:35:
>
>> No, no, no! That is not a good stand-in for fundamental security
>> principles!
>>
>> This is a better method for ensuring an image is really an image:
>>
>> <?php
>> if(isset($_FILES['file']))
>> {
>> list($width, $height) = getimagesize($_FILES['file']['tmp_name']);
>> if($width && $height)
>> {
>> $source = imagecreatefromjpeg($_FILES['file']['tmp_name']);
>> $dest = imagecreatetruecolor($width, $height);
>>
>> imagecopyresampled($dest, $source,
>> 0, 0, 0, 0,
>> $width, $height, $width, $height);
>> imagejpeg($dest, basename($_FILES['file']['tmp_name']));
>> }
>> else
>> echo "{$_FILES['file']['name']} is not a jpeg";
>> }
>> ?>
>> <form enctype="multipart/form-data" method="post">
>> <input type="file" name="file"/>
>> <input type="submit" name="submit" value="submit"/>
>> </form>
>>
>> Obviously it's only rough, and checks only for jpeg images, but
>that's
>> easy to alter. I've just tested this with a regular jpeg, the same
>jpeg
>> with PHP code concatenated onto the end (which still appears to be a
>> valid image to viewing/editing software) and a pure PHP file with a
>.jpg
>> extension. In the case of the first 2, a new jpeg is generated with
>the
>> same image and without the code. The third example just echoes out an
>> error.
>>
>
>Dear Ashley, nice, but useless for this problem!
>
The problem was to do with an image upload, so no, not useless.
>First, because users may upload other things than images! PDF's, audio
>files, videos etc!
In an earlier email I detailed some methods for validating other types, such as
DomDocument for HTML, XML, svg, etc, or fpdf for PDF.
And on behalf images: GD you are using handles only
>jpeg, gif and png. There are about hunderd other image types on the
>way,
At the moment those are the 3 raster formats you can use on the web, so those
are the ones that pose an issue. If you're using anything else, it's not for
web and doesn't need to be in a publicly accessible location.
>users can upload! How to detect them, if the extension is missleading?
The extension comes from the user. Never trust the user, ever.
>
>And even if we succeed: As your script demonstrates very well,
>malicious
>code does not affect the rendering of the image.
My script does effectively strip out malicious code though, even if it can't
easily be seen.
The hacker says: Hi,
>this is a nice picture, play it, and then, please do this--follows his
>code, that can be a desaster for the whole system.
Social engineering is a whole different issue.
>
>Yes, your script seems to purge the image file, simply because GD does
>not copy the malware code. But why are you sure about that? You cannot
>see that code, OK, but may be it was executed in the plain GD
>environement?
GD isn't a PHP parser, and PHP doesn't execute the image before GD touches it.
Infact, Apache isn't even involved between GD and the image at that point, so
it won't suffer from this bad config.
What you are doing is dangerous, because you force the
>execution of things that should be never executed!
Erm, no, the image isn't being executed.
>
>"no no no" forget it. After all we cannot exclude that users come in
>with malware.
If you think it's fine that a user be able to upload malware, then you're going
to have a very bad time.
But we MUST exclude, it is executed on the web server.
This is important too, but in this profession belt and braces is best I
believe.
>That is the Apache chainsaw massacre as Steward whould say. And
>probably
>it can be avoided by purging the filenames (not the files!).
>
>Nevertheless, the standard configuration of the Apache servers is
>basically unacceptable. It must execute user requests and never ever
>user files! Period.
>
>Have nice days,
>Niklaus
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
Thanks,
Ash
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry for this late post but I'm amazed nobody consulted the doco.
The php.net site has a whole section titled "Handling File Uploads".
Also check out finfo_open and finfo_file.
If your are a windoze user you need a dll.
If you want Apache to handle PUT requests you MUST tell it to run a script as
it cannot write to web root.
HTH
Robert
