Will my site be secure?

Question

Hello all!

I'm just about to release a website I've designed into the wild, but before I do, I would love some help determining whether I have made any silly security mistakes. Since I'm using shared hosting rather than dedicated, this is a very important concern. After much research and tutorial-reading I've done the following:

• All PHP scripts (including database credentials) are owned by me, with 700 (-rwx------) 400 (-r--------) permissions.
• Session files are stored in a directory owned by me, with 700 (drwx------) permissions (so people sharing the same host as me cannot hijack sessions).
• When the user logs in they are assigned a new session ID, to prevent session fixation.
• PHP include files are stored in a directory outside of the public webspace, with 700 (drwx------) 100 (d--x------) permissions.
• The admin section of the site is secured with SSL and reCAPTCHA.
• Every piece of data that is used in a mysql query is escaped with mysql_real_escape_string to prevent SQL injection.
• Mysql queries are handled using prepared statements via the mysqli PHP plugin. This should prevent SQL injection.
• Plaintext input is put through htmlspecialchars() in an attempt to stop XSS, and other types of input are sanitised by typecasting them.
• The admin password is stored as an MD5 SHA-256 hash salted SHA-512 hash.
• Sessions expire after 1 hour of inactivity.

This is my first real world web design project and I'm terrified that I may have forgotten something or left some security hole open. If you can spot any omissions or you have any further suggestions please let me know!

Thanks in advance.

Answer 1

It's also a good idea to sanitize all request inputs made to your site. I personally just clean up _REQUEST with every request and use that.

You would also need to strip most HTML markup from being posted to your server in case you wish to create some form of CMS. That tackles XSS, make sure to keep an eye for that.

But anyways, speaking from my experience, my first couple of projects didn't really have to be 100% secure. Not sure about you but the fact those projects never gained momentum nor had a large user base brings some peace of mind knowing that few "bad people" will come across it meaning harm.

Answer 2

Best practices for building websites, including security, have been covered before.

What things should a programmer implementing the technical details of a web site address before making the site public? If Jeff Atwood can forget about HttpOnly cookies, sitemaps, and cross-site request forgeries all in the same site, what important thing could I be forgetting as well?

http://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

Answer 3

Absolutely not.

Admin password stored as plain text? Even if it's in a database, even if it's owned by root and have 700 permissions it's not safe. Hash the password at the very least. I really don't understand why you would have SSL securing the admin area if the password is stored plain text.

All PHP scripts (including database credentials) are owned by me, with 700 (-rwx------) permissions.

This is fine.

All public content (scripts, css, etc) is owned by me, with 744 (-rwxr--r--) permissions.

Great...?

Session files are stored in a folder owned by me, with 700 (-rwx------) permissions (so people sharing the same host as me cannot hijack sessions).

Would be a long shot but I'd buy it.

When the user logs in they are assigned a new session ID, to prevent session fixation.

Good. Do you also have a session expiration set to something reasonable? 15 minutes? Ip checks to ensure they don't try to hijack the session?

PHP include files are stored outside of the public webspace, also with 700 (-rwx------) permissions.

Excellent. This is good.

The admin section of the site is secured with SSL.

SSL, might be overkill but worth while.

Every piece of data that is used in a mysql query is escaped with mysql_real_escape_string to prevent SQL injection.

All of the above is done very well. I wouldn't expect any issues but a lot of that depends on how the site was coded. I can't think off the top of my head bad programming practices the lead to severe insecurity but there could be several.

Okay. Here's why I would just say "okay." Every piece of data is one thing, I would prefer to use some sort of ORM / Active Record style syntax for querying simply because it eliminates the headache of making sure everything is escaped.

Answer 4

It is a continuing battle, now you need to ensure accounts are secure. You should:

1. Add scripts to keep passwords from being brute forced
2. Ensure passwords are secure and stored securely (if you store them plaintext, the site fails).
3. Ensure that all inputs are secure.
4. Also, NEVER have anything writable that doesn't need to be (Use, 666 or 644 if you need things to be writable.)

Also, you didn't mention injection hacks through XSS.

Answer 5

• Secure all GET values.
• Write your robot.txt.

Answer 6

All PHP scripts (including database credentials) are owned by me, with 700 (-rwx------) permissions.

Most of the things you mention as being -rwx------ should not have execute permission turned on. .css and .js certainly don't, and I don't think the PHP scripts need x either, unless your host does something like the Apache XBitHack to indicate the .php files can be executed.

All of those (essentially plain text) files can be 600 instead of 700, and could probably even be 400 -r-------- so they can't easily be overwritten.

Only the directory (aka "folder") that you mention has to be -rwx------ so its contents can be accessed.

Every piece of data that is used in a mysql query is escaped with mysql_real_escape_string to prevent SQL injection.

If you can use prepared statements, that is better than escaping.

BTW, I tend not to sanitize user input when I receive it; rather, I sanitize it before writing it -- but I've always had to store exactly what the user typed, not an escaped representation of what they typed. If it's escaped on input to make it safe for HTML display, when it's written to a PDF I generate on the server then it's wrong.

Answer 7

All PHP scripts (including database credentials) are owned by me, with 700 (-rwx------) permissions.

If your files are permed 700, only you can read the file... which means that if your Web server can read the file to serve it up, it's running as you or as root (ick!).

Ideally, the Web server should be running as an unprivileged user who only has read access to any files/directories in your public Web root.

Answer 8

How are you generating your session IDs? You should make sure that they are large (32 bits at minimum) and generated completely randomly (not based on any sort of hashing or sequential iteration etc). If your session IDs are too small, or even slightly predictable, an attacker might be able to brute force active session IDs and hijack user sessions.

Also, are you passing your session IDs over HTTPS? Many people use HTTPS for their login POST, but forget to secure the session IDs. Make sure your cookies are being passed over an HTTPS connection, and it is good practice to set the HTTPS_ONLY flag on the cookie that contains the session ID so the browser knows to only pass the cookie to secure servers (and not some kid in the coffee shop).

Answer 9

You should test each release of your site with skipfish. It can help you find many vulnerabilities.

Answer 10

Others have raised several good points. I'll comment on one: mysql_real_escape_string.

Yes, it's probably secure if you do in fact use it everywhere, but it's also easier to mess up. Rule of thumb: never paste user input into SQL queries. Use the modern PHP data access facilities (I don't remember what they're called, but the mysql_* functions are the old, pre-5.x way of doing things) and use prepared statements. With prepared queries, you create your query with placeholders (typically "?") for the input values and then "bind" the query parameters as a separate call. You don't need to worry about escaping input (in fact, you shouldn't escape it), and you're SQL-injection-free (the database engine takes care of inserting the query data properly). If you always use prepared statements, then you don't leave the opportunity to forget one string escape and blow a hole in your application. It also frees you from having to worry about where data is escaped, making sure you don't escape it twice, and a similar concerns.

Answer 11

A few more things:

Just hashing your passwords may not be enough, so make sure you use a salt value to make lookups on those hashes harder. This is a much more common attack on hashes than decoding them.

Secondly, make sure that you run some checks on your sessions to further prevent hijacking. For instance, check if the user's IP and UA haven't changed, and kill the session if they have.

Answer 12

As many others suggested, use prepared statemens to be more safe with sql injection.

Please note that using mysql_real_escape for every kind of input may lead you to a certain level of security, but its not the best practice: you should treat every input depending on what you you expect the input to be.

For example, if you expect a input to be an integer number, mysql_real_escape is useless, try (int)$_GET['var_name'] instead.