Well, that didn't sound too good... So I tried to implement the example code given in the php tmpfile() documentation and it wouldn't do anything, which suggests that I don't have access to the /tmp directory. Also, the FAQ's section on my server's website say that /tmp is not shared between the servers. So, looks like /tmp option is out... So, let me see if I understand the situation I'm looking at here: The bad side: -- I don't have any place to put uploaded files outside of my webtree, which makes it tough to ensure these files cannot be surfed to once they are uploaded, and also means I have to do my security checks while the files are within my webtree and potentially accessible. (BAD). -- Any php script on my server (created by me or somehow maliciously uploaded) can do whatever it wants within my account because all php scripts run as me. (also BAD). The good side: -- Uploaded files can be chmod so that nobody can read them, then I chmod them when I need to use them. This adds a layer of protection for completely uploaded files. I assume this will not help with files while they are getting their security checks, since PHP has to be able to read and execute them in order to run the checks (get_image_size, etc.)? -- Since I'm only allowing image uploads, I can strictly filter which files are allowed to be uploaded (with extension checks and get_image_size). (Plus all the stuff talked about in the PHP Security Guide provided by the PHP Security Consortium for html POSTs, MySQL stuff, cookies, etc. Well, all of it that I can implement without having access to a directory outside of my webtree anyway). So, given this situation (if I've got it right), I have two questions: 1) With the above "as is", am I just asking for anyone to come in and tear my site apart? I am not an experienced web developer (obviously), but I love to read. Is that enough to build a secure site, or am I just way in over my head? 2) Imaging that I can convince my host to rebuild my site so that I have access to directories outside of my webtree and can check and save uploaded files there, does that make the situation substantially better? Or is the "PHP running as me" thing enough alone to raise some serious serious problems (perhaps less around the image uploading but more around a login page or something)? As always, thank you so much for your help. Andy On 9/25/06, Richard Lynch <ceo@xxxxxxxxx> wrote:
On Sun, September 24, 2006 11:04 pm, Andy Hultgren wrote: > I really appreciate your help with this. > > To answer your first question: when people surf to my site they see > the > stuff "next to" (outside) .public_html/, not anything within > .public_html/. > (Thanks by the way for explaining the .dirName invisibility thing, > that's > one confusing thing not to worry about anymore!) Hmmm. Okay, so you definitely do not have any space outside the webtree. That's bad. Anything you upload is stuck being available to the public, to some degree. :-( You *may* be able to utilize /tmp See if you can write a short little script with http://php.net/tmpfile This will give you and idea if you can stash things in /tmp, at least until you can confirm that they are not Evil. > To answer your second question: the "uploadedFiles/" directory is > 0100, but > not the file. The uploaded file itself is 0640. So your login is allowed to read files within the directory, but not to list what's in the directory. Your login and your group can read the file itself. Your login can write the file as well. See next question/answer. > Third question: it runs as the same username I use to login to my > server's > ftp site. This information wasn't in the output of the phpinfo() > function > (that I could find). I did some searching on php.net and found this > entry > under the get_current_user() function ( > http://us3.php.net/manual/en/function.get-current-user.php, top user > contributed note): > ** > *to get the username of the process owner (rather than the file > owner), you > can use: > **<?php > $processUser = posix_getpwuid(posix_geteuid**()); > print $processUser['name'**]; > ?> * > ** > I used this code to find out the user PHP runs as. Is that what you > were > looking for? Yes. And since PHP runs as "you" with your login, it can do everything listed above. So you probably cannot surf to the DIRECTORY and get a listing (even if DirectoryIndex is on) but if you know the name of the file in advance, you can surf to it. So if you want to make a file not readable, you have to chmod it so that *YOU* cannot read it. This will be a PITA because then you'll need to chmod it back any time you want to mess with it. As the owner of a file, you are allowed to chmod it so that you yourself cannot read it -- kind of like locking it away in a safe -- and then you have to chmod it back to readable (open the safe) to read it. You still "own" the file, so you can always chmod it anywhich way you want, at any time. Running your webserver as "you" gives it a lot of power -- And makes some things much easier/better in terms of letting it do what you need it to do. It also gives it TOO MUCH power, since it can do ANYTHING you can do. So there can be no distinction between what you allow your web pages to do, and what you can do yourself. This is why most hosts run the webserver as "nobody" or a similar user with extremely limited powers. Most of the security advice you will find "out there" is written with the assumption that your webserver runs as "nobody" (or similar) and that you have space to store files outside your webtree. You are either going to have to really spend a lot of time thinking hard about security to even hope to do the Right Thing if you stay with this host -- and most of the advice you'll find out on the 'net won't apply to your situation, and may even seem to "work" but be very Bad Advice. -- Like Music? http://l-i-e.com/artists.htm
