By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,521 Members | 1,407 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,521 IT Pros & Developers. It's quick & easy.

Hacker attack. What do they want?

P: n/a
Fro
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?

Feb 23 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
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!
Feb 23 '08 #2

P: n/a
On Feb 23, 11:21 pm, Fro <showandbesh...@gmail.comwrote:
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.
Feb 24 '08 #3

P: n/a
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.
Feb 24 '08 #4

P: n/a
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/
Feb 25 '08 #5

P: n/a
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
Feb 25 '08 #6

P: n/a
On Feb 23, 9:21 pm, Fro <showandbesh...@gmail.comwrote:
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.
Feb 25 '08 #7

P: n/a
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.
Feb 25 '08 #8

P: n/a
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.;-).
Feb 25 '08 #9

P: n/a
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/
Feb 25 '08 #10

P: n/a
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.
Feb 25 '08 #11

P: n/a
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/
Feb 26 '08 #12

P: n/a
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!!!
Feb 26 '08 #13

P: n/a
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.
Feb 26 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.