In this article, guide or tutorial (call it whatever you want), you will se what the hosters and developers should do to avoid the major security risks when using a *nix system and PHP + MySQL. This do cover the basics of PHP and MySQL security and will tell you methods to avoid the most used hacking attempts.

Safe_mode

Safemode activates a couple of settings that will:
* Force PHP to check UID permission before opening files.
* Prevent some calls, such as system(), from working. This is unless safe_mode_exec_dir is set.
* Set open_basedir to allow hosters to force file access to stay within a virtual directory.

There are though ways around safe_mode. Most PHP exploits use methods to get around the safe_mode restrictions.

One tips for the hosters is to not just turn on safe_mode without knowing what the actions are. You are not safe just because you turned on safe mode.

Safe Mode has also been removed totally in PHP 6.0.

Magic quotes and addslashes()
Lot’s of people recommend the use of addslashes(). This is however a prety poor advice today when connecting to a mysql database.
To prevent SQL injections, the best thing to do is to use a combination of methods. However, the best method is definately to use PDO or mysql_real_escape_string(). As a hoster, you should quickly upgrade to the latest PHP version to encourage safer and more secure functions for the users and their software.

So - how do I know if I’m vulnerable?

If the users can do remote code execution, you are in fact lucky if you’re still alive.
How do you see if you allow this then?
One thing could be if you check if this works on your site:

$file = $_POST[‘file’];
include $file;
</php>
or this
<pre lang="php">
$txt = $_POST[‘txt’];
eval(“echo $txt”);

Other functions that can be dangerous are fopen, fsockopen, popen and system. The last two functions are direct command execution and allows remote attackers to execude code on the system.

If you want to protect yourself against this you can as a DEVELOPER:
Control that all your $_POST and $_GET arrays are secure and that file operations such as includes/requires, eval statements and every type of file operation is validated before use.
When you write new software you should limit the use of dynamic inputs as this is the most common security whole in php scripts.

As a HOSTER you should, to provide security, disable allow_url_fopen in the php.ini, enable safe_mode and set open_basedir restrictions.

XSS - Cross-site scripting

Another huge and commonly used security whole is XSS or Cross-site scripting.
This refers to HTML injections or user agent injections which can effect all types of servers. This doesn’t hurt the server itself but makes the site leak information and the users that access the website can bring their information to wrong parts, such as their credit card or password.

An insecure output can look like this:

echo $_POST['text'];

While, if you want to be atleast quite secure, you can use the function htmlentities.

Developers
* Switch off register_globals and make sure that all the variables are properly initialized.
* Take user input from correct location, ie $_POST or $_GET, rather then relying on register_globals or $_REQUEST.
* Validate user input for syntax, length and type.
* Text can only be visable after using HTML entities.
* Variables that are sent back should be URL encoded using urlencode().

Hosters
Hosters can’t configure the server to be XSS (cross site scripting) safe but can remove all applications that have XSS attacks in their history. This means that the developers has to have XSS protection or their software will not be used at all.

SQL Injections
The most common and widely used hacking attempt is to use a SQL injection.
What can the developer do to protect the site and server from any SQL injection then?

* Validate the data when having dynamic SQL queries.
* Use PDO (Included in PHP 5.1 and later)
* At least use functions like mysql_real_escape_string().

Nowadays every developer should migrate to PHP 5.1 and use PDO since it has a SAFE SQL interface wich avoid all these issues.

addslashes() is not enough to avoid injections.
The php magic quotes, which automatically adds slashes to input data on the basis of database destination, is not enough as a security method either.

Developers
* Migrate to PHP 5.1 and use PDO.
* Use mysql_real_escape_string()
* Validate the data!
* Have a .htaccess file to ensure that register_globals and magic_quotes are forced off to provide properly initialization anv validation for the inputs.

Hosters
Provide PHP 5.1 and PDO for their clients. Configure MySQL to be the most secure as possible. Users should not be granted admin privileges and the database should be running in a chroot environment to avoid as much damage as possible if a successful attack has reached.

PHP Configuration

It is quite suprising that there is no real secure PHP configuration by default. Here’s a list of settings that should be set:
* register_globals (off by default in modern PHP, should be set off)
* allow_url_fopen (enabled by default, should be set off)
* magic_quotes_gpc (on by default, should be set off)
* magic_quotes_runtime (off by default, should be set off)
* safe_mode and open_basedir (disabled by default, should be enabled and configured correctly. But be aware that safe_mode isn’t really safe and can be totally useless)

Developers should during installation test using ini_get() for common hosting mistakes such as allowing things usch as register_globals or magic_quotes_gpc.

Summary

What can the developers and hosters then do to make sure they are safe towards hacking? It’s not possible to be bulletproof in this business, but if you keep your software up to date and make sure all the common mistakes are undone you will in general be safe. Here’s a compilation of what the developers and hosters should think of when securing their scripts and systems.

Developers
* Ensure that all variables are properly initialized before use.
* Ensure that the users only can affect file operations to the degree you had in your mind creating the function.
* Ensure that your scripts are totally compatible with safe mode restrictiongs and will work under things such as suPHP.
* Move the secrets and logs out of the web roots if scripts are supposed to work on a shared hosting environment.
* Use PDO for MySQL queries.
* Validate the data with length, type and every kind of method you can think of.

Hosters
* Enable safe_mode (be aware that it though isn’t really safe and can be useless)
* Use open_basedir restrictions!
* Make sure that users have a place outside web root to store logs and secrets.
* Run PHP under a least privilege model, as a user or via use of PHPsuExec or suPHP.

Tavis Ormandy is the guy from the Google Security Team who “makes it happend”.

He’s a researcher on the Google Security Team and faces the unpleasent responsibility of passing all googles products pass the security tests. Tavis is also an open-source contributer, working as a co-lead of the Gentoo Security Team as well. He is one of the faces that should make the Linux Gentoo distribution safe.

In September 2006, Tavis reported vulnerabilities in the gunzip decompressor on behalf of Google. Here is the link to the report made by Tavis: http://www.scary.beasts.org/security/tavis_gzip.txt

He has also discovered lot’s of other vulnerabilities such as PCRE (Perl Compitable Regular Expressions) and Perl Unicode Regular Expression buffer overflow. Links to these hacks can be found here: (PCRE) (UNICODE)

Summary: We should be glad of Tavis work since he’s making the web and the servers safer by contributing and telling the software creators before making the exploits public.

Here’s some collected links that can be interesting:
Tavis Ormandy’s blog
Secwatch profile
Milw0rm profile

Wondering which people that really have influence on the web, OS and overall security in the world? There are dozens of hackers and programmers that effect the security in software and websites but there are some who stand above most others.

cdsrc will cover up five of the most influental persons in the security matter, starting off with Tavis Ormandy from the Google Security team.

The article about Tavis Ormandy will be released in a couple of days.

Since PHP 5.1.2 the hash function is enabled by default. To create a sha256 hash you simply write:

hash("sha256", $data, false);

There you have your sha256 hash!

SQL injections are common nowadays and plenty of sites get hacked because of insecure database calls.

Making it bulletproof against injections is hard and will take time, but making safer calls are essential and doesn’t take that long to make.

So, what is a SQL injection?

To clearify it I will give a very easy example:

A database may look something like this:
ID | USERNAME | PASSWORD

When you make a call to that database your query can look something like this:

SELECT * FROM database_name WHERE id = '2'

So far no problems.. But when you code it, it will be something like this (the insecure way):

$sql = "SELECT * FROM database_name WHERE id = '".$_POST['id']."'";

If you make that query and has a id that is “2″, there will be no problem, but if you change it to something else, you will get some problems.

What if $_POST[’id’] would contain something like: ‘ or 1=1– ?

The query would now be:

$sql = "SELECT * FROM database_name WHERE id = '' or 1=1--";

That would automaticly select the whole database since that “or 1=1″ definetly is true.

That was a very short description of what a SQL injection is so how can we now prevent without using any PDO? Using PDO may be the most secure way but requires more knowledge too.

Three lines of code will secure your code against the most known injections and will make it a lot harder to inject your site and hack it. One of this lines will take care of XSS hacking methods too:

1
2
3

$_POST = array_map("htmlspecialchars", $_POST);	# Will secure from XSS
$_POST = array_map("trim", $_POST); # Remove spaces before and after posts
$_POST = array_map("mysql_real_escape_string", $_POST); # Protects from most known SQL injections

Just add these lines in the top include file and you will always have your $_POST protected from the most known SQL injections. One easy way of securing your web applications a little further.