php/web security tips

[Red Squirrel]

Anyone know of a good site explaining in details what are best practices to ensure a secure website? Stuff like avoiding sql injections, chmodding stuff properly, etc... and perhaps more advanced topics, as those I'm quite aware of, but I'm sure theres more stuff to know about.

My site was recently hacked, so I want to review everything over again and see how they could of gotten in as its only bound to happen again.

 

[kamper]

Be very afraid of any code that allows upload. That's going to be the big injection point. Also, review everything that is within the htdocs folder an make sure that you either don't mind people seeing it or it's protected by a .htaccess file or something. I once had a stupid blog hacked because the weakly encrypted password was available for download and a picture upload page that I never used simply assumed that everything you gave it was actually a picture.

Make sure the webserver is running as a non privileged user and take away write permissions from that user on everything you possibly can. Obviously make sure the files are also owned by an different user so that the webserver can't change the permissions. A chroot is always nice for minimizing the damage of a hack and it cuts down hugely on the amount of stuff you have to review if you get nailed (if you don't decide to wipe and reload).

Sql injection probably requires a bit more in-depth of a code review (are you running your own code or others?). Also, cross site scripting is lots of fun. It can mostly be avoided (I think) by making sure you never let someone from the internet post content to your site without your application escaping all <, > and &s. Where that escaping takes place is of crucial importance (later is better) because there are lots of interesting ways to sneak them in like using % escapes in urls. In general, if anything your users input could ever be treated as structured code in some way (like sql or html or javascript) you need to plan for it and escape all special characters so that it gets treated as plain text. Even the markup used for this forum has been hacked with interesting results.

Another obvious thing is to never pass passwords over http:// if you can help it. Session cookies are just as dangerous for that matter. Putting session information in a url is sometimes considered dangerous as it's visible and can easily be accidentally copied and pasted into public places. Some security standards (like PCI) require that you put autocomplete="off" attributes in your forms and or inputs to keep things like credit card numbers from being saved in plain text on client machines. That's a bit of a long shot (especially since it's not part of any html standard) but it's not a bad idea.

Also, (obvious again) pay attention to vulnerability information for all the software you use and generally try to stay with the latest because there's nothing dumber than getting hacked through a well-known hole you could have patched easily. Security by patching is a bit of a crapshoot but it's still necessary because you can't personally verify everything you use.

That's my little paranoid list off the top of my head but I'm sure there are more interesting, effective techniques that I've missed.

 

[Red Squirrel]

Yeah sql injection is something I always look for. If ' " ` and such are escapped properly I'm pretty much safe right? or is there more to it? What I normally do is right off the bat I convert those chars to their html counterparts, so " becomes " and so on. I'm thinking it was some kind of upload script I got hit by, even though most if all, check against file type, maybe they found a way to circumvent it. The folders that did have stuff in them were also chmodded 777, so thats one thing to watch for, though some simply require it. (upload scripts or scripts that work with files) but I converted this ancient shout box script to use mysql, so its one folder less to have set at 777.

I'm also big on server side validation of submitted data. Just because the client side form constraints the user, does not mean the http post packet can't be sent without the form.

I've also retired using ftp completely, I'm using only sftp now. I rarely login to cpanel so that way I don't have to send my password in clear text. Though I don't think this is how I got hacked. Sniffing someone's packets is not as easy as it sounds, you still need to be able to branch on their data stream somehow and with everything going into multiplexed fiber/copper its kind of hard to pick a single stream.

 

[kamper]

Originally posted by: RedSquirrel
Yeah sql injection is something I always look for. If ' " ` and such are escapped properly I'm pretty much safe right? or is there more to it?

Most databases connection libraries should escape things for you and this is a much better idea than trying to do it yourself. They do mess up every now and then (a while ago both mysql and postgres had a problem with not correctly handling double width characters or something like that) but they'll be far more reliable than your own code.

What I normally do is right off the bat I convert those chars to their html counterparts, so " becomes " and so on.

I think something got escaped on you here

I'm thinking it was some kind of upload script I got hit by, even though most if all, check against file type, maybe they found a way to circumvent it. The folders that did have stuff in them were also chmodded 777, so thats one thing to watch for, though some simply require it. (upload scripts or scripts that work with files) but I converted this ancient shout box script to use mysql, so its one folder less to have set at 777.

I'd really like to hear what you think is a valid requirement for using 777.

I'm also big on server side validation of submitted data. Just because the client side form constraints the user, does not mean the http post packet can't be sent without the form.

That goes without saying

I've also retired using ftp completely, I'm using only sftp now. I rarely login to cpanel so that way I don't have to send my password in clear text. Though I don't think this is how I got hacked. Sniffing someone's packets is not as easy as it sounds, you still need to be able to branch on their data stream somehow and with everything going into multiplexed fiber/copper its kind of hard to pick a single stream.

It might look hard from a hacker's perspective, but you don't want to have to worry about every single time you connect to the internet from a different place. It's not really a good idea to trust any sort of public wifi and you don't necessarily know who controls the data between the wireless ap and the isp's network. Sure it's unlikely, but using highly reliable, consistent end-to-end encryption is always way simpler. As you realize, of course

 

[Red Squirrel]

777 is needed for upload folders, or is there a way around that? (ex: forum attachments)

What I've been thinking of doing for attachments is making the uploads go in a folder that has restricted access, and having the forum script fetch the data and display it with the correct mime type (ignoring stuff like php of course). That would require a total forum redesign though, for now I just explicity blocked execution of php in the folders that need to be chmodded 777. Either way, to access such folder, the hacker needs to have gotten into the server which is a problem on its own. Though one could always just get an account and go from there, too.

 

[kamper]

I don't follow at all why you need 777. I assume only the webserver user (probably 'www') is going to need access to it right? So either make the folder owned by www or by a group that www is part of and make it 660 or something like that. You're right, if it's a dedicated web server then the 777 probably won't cause problems, it's just a really bad habit to default to such open permissions to avoid having to think about the problem.