Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What security issues should I look out for in PHP

Tags:

security

php

(In no particular order)

  1. Always check that register globals are OFF
  2. Always check that magic quotes are OFF
  3. Make sure you understand SQL injection attacks
  4. Turn OFF error reporting in production

EDIT: For the "newbies" out there this is a basic why (and since I have time to explain this):

  1. Register globals is an aberration. It's the ultimate security hole ever. For example, if register_globals is on, the url http://www.yourdomain.com/foo.php?isAdmin=1 will declare $isAdmin as a global variable with no code required. I don't know why this "feature" has made it's way to PHP, but the people behind this should have the following tattooed on their forehead: "I invented PHP Register Globals" so we can flee them like pest when we see them!

  2. Magic quotes is another dumb idea that has made it's way to PHP. Basically, when ON PHP will escape quotes automatically (' become \' and " become \") to help with SQL injection attacks. The concept is not bad (help avoid injection attacks), but escaping all GET, POST and COOKIE values make your code so much complex (for example, have to unescape everytime when displaying and data). Plus if one day you switch this setting OFF without doing any change to your code, all your code and/or data is broken and (even more) vulnerable to injection attacks (yes even when ON you are vulnerable).

  3. Your databse data is your most valuable thing on your site. You don't want people to mess with it, so protect yourself and read things about it and code with this in mind.

  4. Again this can lead to security concerns. The error message can give hints to hackes on how your code works. Also these messages don't mean anything to your visitors, so why show them?


Avoid using register_globals.

Warning: This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.


  • Cross Site Scripting (XSS) Wiki, Google
  • Cross Site Request Forgery (XSRF/CSRF) Wiki, Google (thanks Rook)
    • Session Fixation Wiki, Google
  • SQL Injection (SQLi) Wiki, Google
  • Turn off error messages in Production environments
  • Keep any "include" code in a directory that is not web-accessible (either deny access or keep it outside of the webroot)
  • Here's an article I wrote about storing passwords in a secure way, and if you don't feel like taking my word for it, check the links at the bottom.
  • Also linked in my article, but given its own separate link here, is a paper published by M.I.T. called The DOs and DON'Ts of Client Authentication on the Web [PDF]. While some of its info (recommendation to use MD5 hash, for one) is somewhat out of date simply because of what-we-know-now versus what-we-knew-then, the overall principles are very strong and should be considered.
  • One of Rooks' links reminded me of another important set of restrictions
    • Turn off Register Globals (This is the default now, so I hadn't mentioned it before)
    • When dealing with file uploads, be sure to use is_uploaded_file() to validate that a file was uploaded and move_uploaded_file() instead of copy() or rename().
      • Read this section of the PHP Manual if you need to know why (and you do).
  • Since I've now mentioned him twice, check out Rooks's Answer (https://stackoverflow.com/questions/2275771/what-are-the-most-important-safety-precautions-that-a-php-developer-needs-to-know#2275788) as it includes a link to a document which contains (Non-PHP-Specific) information on the most important security concerns (and this therefore probably the right answer).

here is a link of good PHP security programming practices.

http://phpsec.org/

Most of the security issues revolve around user input (naturally) and making sure they don't screw you over. Always make sure you validate your input.

http://htmlfixit.com/cgi-tutes/tutorial_PHP_Security_Issues.php


  1. Always sanitize and validate data passed from the page
  2. In conjunction with #1, always properly escape your output
  3. Always turn display_errors off in production
  4. If using a DB backend use a driver that supports/emulates prepared statements and use without prejudice :-)