The best way to handle file uploads is to:
1) Store the filename somewhere in the DB, rename the file to a random
string without extension and store the mapping in the DB as well.
2) When sending the file, set the header content to the filename and output
the content of the file via PHP (ex: by readfile).
Aziz
This way even if the file is PHP code, it will be of no issue to you.
On Thu, Sep 19, 2013 at 9:05 AM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 19 Sep 2013, at 13:58, "Design in Motion Webdesign" <
> i...@designinmotion.be> wrote:
>
> > it has nothing to do with ".php" in the file name. What the hacker did,
> was uploading a .gif file with some malicious php code included to your
> webserver. Then he called the .gif file from his own website by using a php
> script containing some code like require_once('
> http://www.yoursite.com/images/yourimage.gif'). At that moment the php
> code inside the .gif file has been executed.
>
> In possibly the most pointless way ever! In that scenario the script would
> be executed on the "hacker"'s server (assuming Apache is set up correctly),
> so there's no point in her managing to put it on your server at all!
>
> Arno: If you can request that file using a web browser, and it gets
> executed as PHP on your server then there is an error in the Apache
> configuration.
>
> Easy test: create a file in a text editor containing some PHP (<?php
> phpinfo(); ?> would be enough) and upload it to the www root of your site
> and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in
> your browser. If you see the PHP code or an error then you're fine. If you
> see PHP's info page then you need to change web host as quickly as
> possible. I don't care if they fix it - the fact their server was
> configured to do this by default is enough for me to never trust them again.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
