|
|
Posted by Michael Fesser on 10/15/07 16:12
..oO(william.hooper@gmail.com)
>Great I will do that.. will edit my htaccess file. Thanks for not
>taking over my pc by the way. I was pretty silly not to think about
>php files!
Your scripts are still insecure and widely open the door to the entire
server! You should take the scripts down until you know how to write
such things in a secure manner!
Your blacklist approach by disallowing .php files to be uploaded doesn't
work. Dependent on the server configuration there are some more ways to
make it interpret a file as PHP, you can't catch them all. I was still
able to upload and execute my own script, which would have allowed me
not only to read, but to modifiy or even delete any file on the whole
server that PHP has write access to! The only thing I actually did
remove was that script, but you can still find the name I used in the
server's logfiles.
Your main problem is that you allow the upload of any arbitrary files
and let the users download them directly. This is extremely dangerous,
because it's not your script, but the webserver who finally delivers the
files! And the server might have its own opinion about how to handle the
requested file, because that's his job: "A PHP file? Let's execute it."
There are two possible solutions:
1) Use a whitelist approach, i.e. block everything but some file types
you explicitly allow. You still have to check that the uploaded files
are really what they claim to be by inspecting the content, not only by
looking at the file extension. That's quite easy for images (PHP already
has functions for that), but can be a bit more difficult for other file
types.
The better way:
2) Don't let users download the files directly. Store them outside the
document root and use a download script that delivers the files back.
For known types you should send the correct Content-Type header back
(for example 'image/jpeg' for JPEG images), some files maybe as plain
text ('text/plain'), anything else as 'application/octet-stream'. Now
it's not the server's responsibility anymore to handle the requested
file, but it's always your script, which pretty much prevents code
injection (at least at this point - there might be other big holes in
your scripts).
Micha
Navigation:
[Reply to this message]
|