6

I'm usually pretty resourceful about finding information on my own, but when it comes to this subject, it's really daunting the sheer amount of stuff there is out there. I'm getting a bit of information overload.

I've found dozens of articles on individual security topics, but I can't get a sense of the bigger picture and how it all comes together in practice.

I need to see a bird's-eye roadmap. Take this hypothetical example:

A Simple Hypothetical "Comments" Section:

  • Sign up: create a password/username combo that is to be stored safely in a MySQL table.

  • Log in.

  • Leave a comment.

What would be a "security roadmap" to follow on this most basic case?

It doesn't help that every tutorial and PHP book on the planet uses the MySQL extensions, which, if I understand correctly, is a bad idea?

Community
  • 1
  • 1
o_o_o--
  • 975
  • 9
  • 20
  • You're right about MySql extension being a poor choice. Don't use them in the present times. – asprin Sep 04 '12 at 05:45
  • I just wanted to let you know that I've updated the main answer to this question, because the information it gave about password hashing was dangerously incorrectly. There's a great [question on Stack Overflow](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) about how to properly handle passwords. – Brendan Long Sep 20 '12 at 20:55
  • @BrendanLong thanks! -- I wonder why so many tutorials and books keep using outdated practices. Especially books that actually cost money, it would be nice if they followed the best current security practices. – o_o_o-- Sep 21 '12 at 00:57
  • Take a look at this article for a good starting point: http://net.tutsplus.com/tutorials/php/sanitize-and-validate-data-with-php-filters/ – Ben Rowe Sep 04 '12 at 05:47

3 Answers3

9

A. In general…

  1. I’m assuming here that the programmer is not also the server administrator, and that the server admin more or less knows how to configure LAMP correctly and securely by default.

    Of course, if necessary, a programmer can override most PHP settings in a custom php.ini file located in the web root.

  2. Use an MVC framework.

    I use CakePHP. The framework itself goes a long way to ensure fundamentally sound and secure coding practices.

B. Incoming data…

  1. Sanitize and validate all data contained in $_GET, $_POST, $_COOKIE, and $_REQUEST before programmatically manipulating the data.

  2. SQL Injection

    Definition: Code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.

    Prevention: Parameterised queries using a library such as mysqli or PDO. See the OWASP SQL Injection cheat sheet (string escaping functions like mysql_real_escape_string are not recommended)

  3. Cross Site Scripting (XSS)

    Definition: Security vulnerability typically found in web applications that allows code injection by malicious web users into the web pages viewed by other users. Examples of such code include client-side scripts (i.e., JavaScript).

    Prevention: Context-dependent output escaping and encoding. See the OWASP XSS prevention cheat sheet.

C. Browser requests…

  1. Cross Site Request Forgery (CSRF)

    Definition: Type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

    Prevention: Generate a unique “token”, typically when a browser session starts. Pass the token in all POST and GET requests. Following the POST/GET action, check for the existence of the token in the session and then confirm the token sent by POST/GET is identical to the token stored in the session. (An MVC framework like CakePHP makes this relatively easy to implement uniformly throughout your application.)

D. Sessions…

  1. Destroy session data when killing a session

    After a session is complete (”logout”), destroy its data and don’t just clear the cookie (a malicious user could otherwise just re-instate the cookie and use the session again). Unset all indexes in $_SESSION by assigning it to an empty array.

  2. Store sessions as files above the web root or in a database

    The default path for saving sessions on the server can be hijacked -- especially in a shared hosting environment.

E. Passwords…

  1. Enforce the selection of strong passwords

    • Require numbers, symbols, upper and lowercase letters in passwords

    • Password length should be around 12 to 14 characters

  2. Hash and Salt all passwords

    Do not use sha1(), md5() or hash() to hash passwords. They're not designed for this. You will want to use a function like bcrypt or PBDFK2. There's some really good suggestions on this question. Your salt value should be completely random, and stored in the database (it's not really a secret). An additional secret value (generally called "pepper") can be stored in your application and prepended to passwords before using bcrypt, but it's not clear how much security this really adds.

F. In a custom php.ini located in web root…

  1. Disable register_globals

    Prevention: register_globals = Off

  2. Disable magic quotes

    Prevention: magic_quotes_gpc = Off

  3. Disable error reporting

    Prevention: display_errors = Off

  4. Enable error logging and save log file to a directory above web root

    Prevention:

    log_errors = On; 
ignore_repeated_errors = On; 
html_errors = Off; 
error_log = /path/above/webroot/logs/php_error_log

  5. Store session data inside a directory above web root

    Prevention: session.save_path = /path/above/webroot/sessions

G. In a .htaccess file located in web root…

  1. Disable directory listings site-wide

    Prevention: Options -Indexes

H. Valuable/Sensitive files…

  1. Prevent unauthorized access/downloads by storing such files above the web root

    This includes site administration/members-only sections and site/database configuration files!!

  2. Use an intermediary script to serve the files inline or as an attachment

  3. Keep your scripts(WordPress, PHPMyAdmin, etc.) updated.

  4. Only allow access to PHPMyAdmin when you are using it. This prevents people from being able to use zero-day exploits on your install.

I. Uploaded files…

  1. Validate file name stored in $_FILES before using it for any kind of data manipulation

  2. Be aware that the provided mime type can be spoofed or otherwise wrong

  3. Move all user-uploaded files to a directory above web root!!!

  4. Don’t execute/serve uploaded files with include()

  5. Try to not serve files with content types of “application/octet-stream,” “application/unknown,” or “plain/text”

J. Misc…

  1. All “utility” files/programs in the web root created and used by the developer during the development of a site/application, that are not intended or required to be accessed by future site users, or otherwise pose some kind of security risk, should be removed when the site goes live.

    For example, this includes a phpinfo.php file (a files that prints the results of phpinfo()), database utility scripts, etc.

Community
  • 1
  • 1
Shail
  • 1,565
  • 11
  • 24
  • I'm guessing this was voted down because the password section was dangerously incorrect. I've updated it to contain the actual recommendations by security experts. [PHP is adding some new functions](https://wiki.php.net/rfc/password_hash) just because so many people get this wrong. – Brendan Long Sep 20 '12 at 20:56
1

Well, to make it safe, first start with constructing the mysql side before moving to the server side programming (e.g. php). Create stored procedures, views, prepared statements.. transactions perhaps. They are their to make the application more secure..too bad php programmers dont use them often.

Then when you come to the server side programming, use pdo (I like it more than mysqli), it enables you to bind parameters (which is a safe strategy used in asp.net too).

You could also use validation strategies.. to see if input is an email, a credit card..etc that would give you a white list of things to expect (building a black list is a less secure idea..I remember reading this from some hacking book).

Escaping and filtering can be used depending on what you want, on passwords you may want to strip tags, but with comments you might not..

Good luck!

Dmitry Makovetskiyd
  • 6,942
  • 32
  • 100
  • 160
0

The usual advice is to sanitize all input that comes from the client. Usually you want to weed out any form of code in your input. Those are the objectives. Here are the lines of defense available.

Firstly, if the design of the program is tight the problem can be alleviated - for instance, having proper form validation which weeds out unwanted symbols would prevent SQL injection or cross site scripting. A rather open ended input, like comments, is tricker though.

Secondly, you have to clean the input. Usually there are a few line of defense. You can strip out tags or escape them, though that won't help with the more sophisticated injections. You can escape the output when displaying them.

Thirdly, you can also secure how you store the input with parameterized query. That mostly will prevent SQL injections.

There are open-source libraries that help with sanitizing your input, for example, HTML Purifier

So to summarize:

  • Model your input correctly. What input is acceptable and what are not

    Strip or escape input tags when saving to DB, or clean them when displaying.

    Use parameterized queries, which MySQL does support

Extrakun
  • 19,057
  • 21
  • 82
  • 129