|
|
|
|
||||||
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
Hi,
my site allows to upload images. For that reasons I have created a directory which have "drwxrwxrwx"-permission. I.e. everybody can write in that directory. I understand that it is not save, because everybody can upload to this directory some scripts which would destroy my file system or store some information. To make things a little bit better I put there the following .htaccess file: php_flag engine off IndexIgnore * So it means that php-scripts cannot be executed in this directory. But what about the shell scripts? How could I prevent an execution of the shell script in this directory? My php script which upload files to the directory takes only files which have *.jpg extension. Today I found out that in the directory I have a file (called 854.jpg) which is an sub-directory! How did they did it? Well I understand, that jpg extension does not guarantee the file is an jpg-image, but I did not know that this file can be a directory! The problem is that subdirectory "854.jpg" does not have the above mentioned .htaccess file. So the owner of the directory can make there whatever it wants. How can I solve this problem? |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
> my site allows to upload images. For that reasons I have created a
> directory which have "drwxrwxrwx"-permission. I.e. everybody can write > in that directory. Nice, but who else writes in that directory than the web server user? > I understand that it is not safe, because everybody > can upload to this directory some scripts which would destroy my file > system or store some information. To make things a little bit better I > put there the following .htaccess file: > php_flag engine off > IndexIgnore * When you move the temp file to the final location, YOU (the webserver) can give it any name YOU want. The fact that the directory is world-writeable AND has an .htaccess file should ring a bell: If you keep the file names, anyone can upload an .htaccess file... > So it means that php-scripts cannot be executed in this directory. Given the above, are you sure? > But > what about the shell scripts? How could I prevent an execution of the > shell script in this directory? By not making them executable. You can chmod the file if it is executable. > My php script which upload files to the directory takes only files > which have *.jpg extension. Today I found out that in the directory I > have a file (called 854.jpg) which is an sub-directory! How did they > did it? Well I understand, that jpg extension does not guarantee the > file is an jpg-image, but I did not know that this file can be a > directory! > > The problem is that subdirectory "854.jpg" does not have the above > mentioned .htaccess file. So the owner of the directory can make there > whatever it wants. How can I solve this problem? > By putting the things that appear in the .htaccess file in the normal config. There is really no reason for .htaccess files, other than lack of access to system maintainers. Furthermore, you can check if it is a directory upon upload. Good luck! |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
On Feb 23, 11:21 pm, Fro <showandbesh...@gmail.com> wrote:
> Hi, > > my site allows to upload images. For that reasons I have created a > directory which have "drwxrwxrwx"-permission. I.e. everybody can write > in that directory. I understand that it is not save, because everybody > can upload to this directory some scripts which would destroy my file > system or store some information. To make things a little bit better I > put there the following .htaccess file: > php_flag engine off > IndexIgnore * > > So it means that php-scripts cannot be executed in this directory. But > what about the shell scripts? How could I prevent an execution of the > shell script in this directory? > > My php script which upload files to the directory takes only files > which have *.jpg extension. Today I found out that in the directory I > have a file (called 854.jpg) which is an sub-directory! How did they > did it? Well I understand, that jpg extension does not guarantee the > file is an jpg-image, but I did not know that this file can be a > directory! > > The problem is that subdirectory "854.jpg" does not have the above > mentioned .htaccess file. So the owner of the directory can make there > whatever it wants. How can I solve this problem? You have to give write and execute privilages to users just before the upload and change chmod to 644 or 744 or whatever immediately after upload. If you able to logged these attackers ip addresses you should ban these ip's to connect. Furthermore for security reasons disable some php functions such as exec(), ftp, etc. |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
Fro wrote:
> Hi, > > my site allows to upload images. For that reasons I have created a > directory which have "drwxrwxrwx"-permission. I.e. everybody can write > in that directory. I do believe you could use drw-rw-rw- permissions. Leaving off the execute permission would prevent creating a subdirectory. |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
bill wrote:
> I do believe you could use drw-rw-rw- permissions. Leaving off the > execute permission would prevent creating a subdirectory. It would prevent everyone from reading the directory listing. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 15:54.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ |
|
|
|
#6 |
|
Messages: n/a
Hébergeur: |
Toby A Inkster wrote:
> bill wrote: > >> I do believe you could use drw-rw-rw- permissions. Leaving off the >> execute permission would prevent creating a subdirectory. > > It would prevent everyone from reading the directory listing. > Thanks Toby, you are correct, of course. bill |
|
|
|
#7 |
|
Messages: n/a
Hébergeur: |
On Feb 23, 9:21 pm, Fro <showandbesh...@gmail.com> wrote:
> Hi, > > my site allows to upload images. For that reasons I have created a > directory which have "drwxrwxrwx"-permission. I.e. everybody can write > in that directory. I understand that it is not save, because everybody > can upload to this directory some scripts which would destroy my file > system or store some information. To make things a little bit better I > put there the following .htaccess file: > php_flag engine off > IndexIgnore * > > So it means that php-scripts cannot be executed in this directory. But > what about the shell scripts? How could I prevent an execution of the > shell script in this directory? > > My php script which upload files to the directory takes only files > which have *.jpg extension. Today I found out that in the directory I > have a file (called 854.jpg) which is an sub-directory! How did they > did it? Well I understand, that jpg extension does not guarantee the > file is an jpg-image, but I did not know that this file can be a > directory! > > The problem is that subdirectory "854.jpg" does not have the above > mentioned .htaccess file. So the owner of the directory can make there > whatever it wants. How can I solve this problem? * Do you use is_file and is_uploaded_file to verify that the script is dealing with an actual file and not some kind of other filesystem object, and that it is a file that's been uploaded and not inserted some other way? * Does your script check the MIME type of the uploaded file? The $_FILES superglobal contains a mime element you can check. If this isn't 'image/jped' or 'image/pjpeg' then reject the upload and delete it from your temp directory. * Is your .htaccess file set read only? If not it can be overwritten by the script. * Does your script check the name of the uploaded file and makes sure it's not something dangerous? If the filename is .htaccess or some other potentially dangerous name then you should reject the upload. |
|
|
|
#8 |
|
Messages: n/a
Hébergeur: |
Fro pisze:
> Hi, > > (CUT) Mabe You should just use ftp functions to put files in some other dir (not accesible directly through web server)? You can then still use php to access them when needed (move, display or whatever...) ? It would make unnecessary to keep world-writable directory and keep You safe. |
|
|
|
#9 |
|
Messages: n/a
Hébergeur: |
Gordon wrote:
> * Does your script check the MIME type of the uploaded file? The > $_FILES superglobal contains a mime element you can check. If this > isn't 'image/jped' or 'image/pjpeg' then reject the upload and delete it > from your temp directory. This is virtually worthless from a security point of view. The MIME type is reported by the client's browser, so cannot be relied upon. A better test would be to check that the the file's contents seemed to be a valid JPEG. One way of doing this would be to read the file into a string (or to save memory, just the first few bytes) and check that bytes 7 to 10 match the string "JFIF". Better still, use GD or similar to open the file and check it's a valid image. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 20:32.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ |
|
|
|
#10 |
|
Messages: n/a
Hébergeur: |
Dape wrote:
> Fro pisze: >> Hi, >> > > (CUT) > > Mabe You should just use ftp functions to put files in some other dir > (not accesible directly through web server)? > You can then still use php to access them when needed (move, display or > whatever...) ? It would make unnecessary to keep world-writable > directory and keep You safe. Or simply put them in a databe. Its almost impossible to execute them from there.;-). |
|
|
|
#11 |
|
Messages: n/a
Hébergeur: |
On Feb 25, 2:19 pm, Toby A Inkster <usenet200...@tobyinkster.co.uk>
wrote: > Gordon wrote: > > * Does your script check the MIME type of the uploaded file? The > > $_FILES superglobal contains a mime element you can check. If this > > isn't 'image/jped' or 'image/pjpeg' then reject the upload and delete it > > from your temp directory. > > This is virtually worthless from a security point of view. The MIME type > is reported by the client's browser, so cannot be relied upon. > > A better test would be to check that the the file's contents seemed to be > a valid JPEG. One way of doing this would be to read the file into a > string (or to save memory, just the first few bytes) and check that bytes > 7 to 10 match the string "JFIF". > > Better still, use GD or similar to open the file and check it's a valid > image. > > -- > Toby A Inkster BSc (Hons) ARCS > [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] > [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 26 days, 20:32.] > > Bottled Water > http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ You're right, but I think if you're going to do that then GD is the way to do it. There's nothing stopping somebody from making the first line of a malicious file a comment that contains the JPEG magic string. |
|
|
|
#12 |
|
Messages: n/a
Hébergeur: |
Fro a écrit :
> Hi, > > my site allows to upload images. For that reasons I have created a > directory which have "drwxrwxrwx"-permission. I.e. everybody can write > in that directory. ....... > For such use,you have to give 222 permission: everybody can write, without read, without exec!!! |
|
|
|
#13 |
|
Messages: n/a
Hébergeur: |
Gordon wrote:
> You're right, but I think if you're going to do that then GD is the way > to do it. There's nothing stopping somebody from making the first line > of a malicious file a comment that contains the JPEG magic string. True, but if they don't know *how* you're checking that the file is a JPEG (i.e. /^.{6}JFIF/) then they might not think to forge those bytes. You could be doubly-sure by checking for: if ( preg_match('/^.{6}JFIF/', $firstfewbytes) && (!preg_match('/^(.ELF|\#\!)/', $firstfewbytes)) { // file is safe } -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 27 days, 17:47.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ |
|
|
|
#14 |
|
Messages: n/a
Hébergeur: |
I would suggest building a more robust interface - use something like
http://www.digitalgemstones.com/script/ImgUploader.php to make uploading files easy and secure, then build your own interface - it doesn't have to be much more complex than the natural one Apache servers up - but if you built it, you can control it. The problem with opening up security holes like that is, you're going to be very hard pressed to ensure that you've covered all your bases as far as only allowing valid access - much better, even if it's more work in the short term, to build it yourself. |
|
![]() |
| Outils de la discussion | |
|
|