OWASP Backend Security Project PHP Security Programming

= Overview =

PHP developer should be aware of threats that can be exposed on vulnerable PHP code. This article is going to address two of those threat in the following sections:
 * SQL Injection
 * LDAP Injection

Since both of them are well known attacks vectors we're going to address some valid techniques to defend against:
 * Escaping Quotes on both input parameters and HTTP Request Header
 * Usage of Prepared Statements to query backend DBMS
 * Data Validation
 * Safe error handling

But that's not all. Since a backend datastore should be accessed though a authentication developer should be aware on where to store such a access credentials as well.

Recent research activities has shown that is possible to detect intrusion attempts from a WEB Application by embedding an Application Layer IDS inside your application.

SQL Injection
Here follows a tipical Login Form where users credentials are stored on a Backend DBMS. To successfull validate user credentials an authenticated connection to Backend DBMS is needed. Application developer decided to store the Database Connection String parameters in a .inc file as shown in the example:

auth.php

<?php include('./db.inc');

function sAuthenticateUser($username, $password){ $authenticatedUserName=""; if ($link = iMysqlConnect) {

$query = "SELECT username FROM users"; $query .=               " WHERE username = '".$username."'"; $query .=               " AND   password = md5('".$password."')"; $result = mysql_query($query);

if ($result) { if ($row = mysql_fetch_row($result)) { $authenticatedUserName = $row[0]; }   }  }

return $authenticatedUserName;

}

if ($sUserName = sAuthenticateUser($_POST["username"], $_POST["password"])) {

/* successfull authentication code goes here */ ...  ... } else {

/* unsuccessfull authentication code goes here */ ...  ... }

?>

db.inc



Vulnerability


 * SQL Injection
 * by using some inference techniques it's possible to enumerate a backend Database and even worst it could be possible to interact with underlying operating system
 * Authentication Bypass
 * by exploiting a SQL Injection vulnerability Authentication an evil user can bypass authentication by suppliying :
 * username ' OR 1=1 #
 * password anything
 * Information Disclosure
 * db.inc contents could be retrieved by an evil user

Remediation
 * Make .inc unavailable to remote user
 * As we'll see it's possible to avoid .inc file retrieval from a remote user
 * Escaping Quotes
 * when evil users supplies username ' OR 1=1 # quotes should be escaped in such in username \' OR 1=1 #
 * Prepared Statements
 * Prepared Statements prevents SQL Injection attacks by giving to the backend DBMS an execution plan of a query where parameters are replaced by variables. Variables will be instantiated with values and query will be executed. Since running an execution plan with parameters containing SQL Expressions, Operators or statements fails, we can get ride of Injection.
 * Data Validation
 * Input parameters should be validated in both data type and value. Developers should be aware that PHP is not a strongly type language. Everything it's a string when talking about Input Parameters and Headers.
 * Embedd an Application Layer IDS
 * PHPIDS it's a promising Open Source Project well mantained and with interesting features. An optimazed RegExp engine can be embedded in your PHP code to analyze input parameter in order to determine if ther contains a known attack vecto. Benchmark performed by project developers shows that there is no performance penality at all.

As you can see there are many way to protect your PHP Code against SQL Injection Attack vectors. Wich ones to use is up to you by the way as stated by the Security in Depth it would be great to use all of them.

LDAP Injection
Here follows a tipical Login Form where users credentials are stored on a Backend LDAP Directory. To successfull validate user credentials an authenticated connection to Backend DBMS is needed. Application developer decided to store the LDAP Connection String parameters in a .inc file as shown in the example:

ldap.inc: 

auth.php: include('ldap.inc');

function authLdap($sUsername, $sPassword) { $ldap_ch=ldap_connect("localhost");

if (!$ldap_ch) { return FALSE; }

$bind = ldap_bind($ldap_ch, LDAP_DIRECTORY_ADMIN, LDAP_DIRECTORY_PASS);

if (!$bind) { return FALSE; }

$sSearchFilter = "(&(uid=$sUsername)(userPassword=$sPassword))"; $result = ldap_search($ldap_ch, " dc=domain,dc=com", $sSearchFilter);

if (!$result) { return FALSE; } $info = ldap_get_entries($ldap_ch, $result);

if (!($info) || ($info["count"] == 0)) { return FALSE; }

return TRUE;

}

$sUsername = $_GET['username']; $sPassword = $_GET['password'];

$bIsAuth=authLdap($sUsername, $sPassword);

if (! $bIsAuth ) { /* Unauthorized access, handle exception */ ...  ... }

/* User has been succesfull authenticated */

Vulnerability


 * Authentication Bypass
 * by exploiting a LDAP Injection vulnerability evil user can bypass authentication by suppliying username * and password *
 * Information Disclosure
 * ldap.inc contents could be retrieved by an evil user

Remediation
 * Make .inc unavailable to remote user
 * As we'll see it's possible to avoid .inc file retrieval from a remote user
 * Authenticate Users through LDAP Bind
 * Since LDAP define a BIND method which requires a valid user credential we can use ldap_bind rather than setting up a complex machinery with ldap_search
 * Data Validation
 * Input parameters should be validated in both data type and value. Developers should be aware that PHP is not a strongly type language. Everything it's a string when talking about Input Parameters and Headers.
 * Embedd an Application Layer IDS
 * PHPIDS it's a promising Open Source Project well mantained and with interesting features. An optimazed RegExp engine can be embedded in your PHP code to analyze input parameter in order to determine if ther contains a known attack vecto. Benchmark performed by project developers shows that there is no performance penality at all.

As you can see there are many way to protect your PHP Code against LDAP Injection Attack vectors. Wich ones to use is up to you by the way as stated by the Security in Depth it would be great to use all of them.

= Description =

This section will address developement methodologies to prevents attacks such as:
 * SQL Injection
 * LDAP Injection

PHP preventing SQL Injection
PHP Applications interact with Backend DBMS by using the old connectors style (eg: mysql_connect, mysql_query, pg_connect and so on) or the recent Portable Data Objects Layer, form here on refered as PDO. PDO has been introduced in PHP starting from 5.1, it represents an Abstract Database Layer lying between PHP and Backend DBMS. It mean's that it's possible to back-point an exesting application to use a different DBMS by just changing a connection string. To this aim it adopts a modular architecture with low-level driver to handle different DBMS. Be aware that at the moment of writing it's Oracle Drive is marked as experimental, so it's not well supported.

Differente techniques to prevents SQL Injection in PHP will be shown in following sections. Since every Backend DBMS shall require authentication to PHP Code let's start by showing how to safely store such a credentials.

DBMS authentication credentials
Developers should be very carefull on how, and subsequently where, store authentication credentials to authenticate against backend DBMS before start to query. It's tipical to put such credentials in a .inc file (by using some define) to subsequenlty include credentials from a PHP Code. Such a .inc file if left world wide readable by both local users and web server uid can be easly retrieve by an evil user. There are some techniques to be used to prevents this kinds of Information Disclousure:

 Order allow,deny Deny from all 
 * Configure Front-End Apache WEB Server to deny serving request to .inc files
 * requires user intervention on Apache configuration!




 * configuring php_ini settings in apache to set some default values to mysql_connect

/etc/apache2/sites-enabled/000-owasp

 DocumentRoot /var/www/apache2/ php_value mysql.default_host 127.0.0.1 php_value mysql.default_user owaspuser php_value mysql.default_password owasppassword ....    ....     .... 
 * some DBMS doesn't allow to retrieve connection parameters from apache config file

dbmshandler.php


 * at the moment of write it only works when backend Database Engine is MySQL


 * using Apache SetEnv

/etc/apache2/sites-enabled/000-owasp

 DocumentRoot /var/www/apache2/ SetEnv DBHOST "127.0.0.1" SetEnv DBUSER "owaspuser" SetEnv DBPASS "owasppassword" ....    ....     .... 

dbmshandler.php




 * requires user intervention on Apache configuration

Example using PDO MySQL driver:

/etc/apache2/sites-enabled/000-owasp

 DocumentRoot /var/www/apache2/ SetEnv PDO_DSN "mysql:host=localhost;dbname=owasp" SetEnv PDO_USER "owaspuser" SetEnv PDO_PASS "owasppassword" ....    ....     .... 

dbmshandler.php

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

/* handle PDO connection success */ ...              ...            return $oPdo; } catch (PDOException $e) { /* handle PDO connection error */ ...              ...           return NULL; } } ?>

Escaping Quotes
As shown on previous sections quotes shall be escaped in some way. PHP came to you with magic_quotes_gpc configuration directive.It's aim is to escape quotes from HTTP Request by examing both GET/POST data and Cookie value and replacing every single quotes with \'. The truth is that any other data contained into the HTTP Request Header is not escaped.

Let'say a PHP Application access the User-Agent Header to perform a statistic on browser used by users to navigate sites. Sinche magic_quotes_gpc doesn't escape such a header value it's possible to create a custom HTTP Request containing evil characters to SQL Inject remote PHP Code. Last but not least it isn't portable on every DBMS as well. For example Microsoft SQL Server use a differente Quote Escape.

Due to the above issues it's usage is strongly discouraged. Since it's enabled on WEB Server developers should:
 * check if enabled
 * if so: request shall be rollbacked to it's original

function magic_strip_slashes { if (get_magic_quotes) {

// GET if (is_array($_GET)) { foreach ($_GET as $key => $value) { $_GET[$key] = stripslashes($value); }      }

// POST if (is_array($_POST)) { foreach ($_GET as $key => $value) { $_POST[$key] = stripslashes($value); }      }

// COOKIE if (is_array($_COOKIE)) { foreach ($_GET as $key => $value) { $_COOKIE[$key] = stripslashes($value); }      }    } }

Quote Escaping shall be performed with DBMS related functions such as: function sEscapeString($sDatabase, $sQuery) { $sResult=NULL; switch ($sDatabase) { case "mysql": $sResult = mysql_real_escape_string($sQuery); break; case "postgresql": $sResult = pg_escape_string($sQuery); break;
 * MySQL: mysql_real_escape_string
 * PostgreSQL: pg_escape_string

case "mssql": $sResult = str_replace("'", "''",$sQuery); break;

case "oracle": $sResult = str_replace("'", "''",$sQuery); break; }

return $sResult; } }

Since both Oracle and Microsoft SQL Server connectors doesn't have a real escape_string function software developer can create his own escapeing functions or use addslasshes.

With properly quotes escaping we can prevent Authentication Bypass vulnerability in Example 1:

auth.php

<?php include('./dbmshandler.php);

function sAuthenticateUser($username, $password){ $authenticatedUserName=""; if ($link = iMysqlConnect) {

$query = "SELECT username FROM users"; $query .=               " WHERE username = '".$username."'"; $query .=               " AND   password = md5('".$password."')";

/* escape quotes */ $result = sEscapeString("mysql", $query);

if ($result) { if ($row = mysql_fetch_row($result)) { $authenticatedUserName = $row[0]; }   }  }

return $authenticatedUserName; }

/* start by rollback magic_quotes_gpc action (if any) */

magic_strip_slashes;

if ($sUserName = sAuthenticateUser($_POST["username"], $_POST["password"])) {

/* successfull authentication code goes here */ ...  ... } else {

/* unsuccessfull authentication code goes here */ ...  ... }

PHP Portable Data Objects implements a quote method on PDO class but it's worst noticing that not all underlying PDO Drivers implements this method. On the other side PDO::query method by defualt escape quotes on SQL query string as shown in following example.

Example using PDO MySQL driver:

auth.php

query($query)->fetch; if ($row) { return $row['username']; }    } catch (PDOException e) { /* handle execption and SQL Injection Attempt */ ....        ....         return NULL; }   }

/* start by rollback magic_quotes_gpc action (if any) */

magic_strip_slashes;

if ($sUserName = sAuthenticateUser($_POST["username"], $_POST["password"])) {

/* successfull authentication code goes here */ ...  ... } else {

/* unsuccessfull authentication code goes here */ ...  ... }

Escaping Quotes is not enough to prevent SQL Injection Attacks. Even if works well on login forms it doesn't give you a complete security defence agains SQL Injection Attacks sinche Quote Escape functions can still be evaded by encoding chars to theire ASCII decimal value. Further defence are needed:
 * Prepared Statements
 * Data Validation

Prepared Statements
Prepared Statements is the ability to preparse and generate an execution plan for SQL Queries. Such an execution plan will be instantiated with typed parameters. If supplied parameters are of incorrect type or contains a nested query the execution of plan will fails. This prevents an evil user to successfully inject SQL Statements on Backend DBMS.

stmt_init; if ($stmt->prepare("SELECT * FROM books WHERE ID =?")) { $stmt->bind_param("i",$id); $stmt->execute; /* Retrieves book entry and fill $aBook array */ ...       ...

/* Free prepared statement allocated resources */ $stmt->close; }

return $aBook;

}

/* MAIN */

/* Cast GET 'id' variable to integer */ $iID = (int)$_GET['id'];

$aBookEntry = getBookByID($iID);

if ($aBookEntry) { /* Display retrieved book entry */ ...   ... }

?>

PHP Portable Data Objects emulate prepared statements for drivers with no natively supports. Here follows an example of prepared statements usage with PHP PDO

Example using PDO: <?php include('./dbmshandler.php');

function getBookByID($id) { $aBook = NULL; $oPdo = SQLConnect;

if ($oPdo) { $stmt = $oPdo->prepare("SELECT * FROM books WHERE ID =?"); $stmt->bindParam(1, $id, PDO::PARAM_INT); if ($smmt->execute) { $aBook = $stmt->fetch(PDO::FETCH_ASSOC); }   }

return $aBook;

}

Prepared statements rapresent a valid defence agains SQL Injection attacks. But it's still not enough since they allow an evil user to inject session variable such as @@version:
 * http://www.example.com/news.php?id=@@version

Data Validation techniques helps developers to prevents SQL Injection Attacks when properly used.

Data Validation
Modern WEB Applications are supposed to interacts with users throught input data. Input data can be supplied through a HTML Form and WEB Application retrieves such a data through a GET/POST variable. Input data can contains malicious values to exploit some security flaws in WEB Applications. As a general rule data validation should be performed on both input and output values, since they both depends on each other. data should be rejected unless it matches a criteria. Developers should define a restriced range for valid data and reject everything else. Such a criteria will include:
 * Data Type
 * Data Length;
 * Data Value

A typical Data Validation workflow will be:
 * Get the data to be validated
 * Check if it should be a numerical or string
 * Look at it's size in byte to avoid errors when database table columns has some constraint in value size
 * Check if data contains a valid value (EMail, phone number, date, and so on).

To this aims PHP can help developers with :
 * casting operators
 * regexp functions

Numeric Data

PHP is not a strongly typed languages it means that every input data is a string by default. If you want to validate a numeric value you should casting operator. Casting an input data to int ensure that:


 * if data is numeric you get its value
 * if data doesn't contains a number casting will returns 0
 * if data includes a number casting will returns its numeric portion

Example

...   $iId = (int)$_GET['id']; if ( $iId != $_GET['id']) { /* User supplied data is not numeric, handle exception */ ...     return; }

if ($iId > MAX_ID_VALUE || $iId < MIN_ID_VALUE) { /* User supplied data is numerica but it doesn't contains an allowed value, handle exception */

}

/* $iId is safe */

 String Data

Strings data validation is a bit tricker since it can contains malicious values. It means that it should be validated on what data is supposed to include. Data can contains:
 * EMail Address
 * Phone Number
 * URL
 * Name
 * Date

and so on.

To this aim WEB Developers should match Input Data against a Regular Expression to match what Data is supposed to inclues. Here follows some example.

Example: Validating an Email Address

...   $sEmail = $_POST['email']; if (! preg_match("/^[\w-]+(?:\.[\w-]+)*@(?:[\w-]+\.)+[a-zA-Z]{2,7}$/", $sEmail)) { /* User supplied data is not a valid email address, handle exception */ ...     return; }

/* $sEmail is safe, check len */

if (strlen($sEmail) > MAX_EMAIL_LEN) { /* User supplied data is to big for backend database, handle exception */ ...     return; }

Example: Validating an Italian Phone Number  ...   $sPhoneNumber = $_POST['phonenumber'];

if (! preg_match(, "/[0-9]+[-\/ ]?[0-9]+$/", $sPhoneNumber)) { /* User supplied data is not a phone number, handle exception */ ...     return; }

/* $sPhoneNumber is safe, check len */

if (strlen($sPhoneNumber) > MAX_PHONENUMBER_LEN) { /* User supplied data is to big for backend database, handle exception */ ...     return; }

If you don't want to get frustrated with all those regexp take into considerations to use one of the following PHP Filters: well mantained it's still well working and defines a valid approach to performa Data Validation.
 * OWASP PHP Filters
 * OWASP PHP Filters project allow programmers an easy way to perform data validation. Even if project is quite old and not
 * PHP Data Filtering
 * Available from PHP installation

Logging Errors
Malicious users typicaly attempt to explot SQL Injection Vulnerabilities by looking at some Error Codes on dynamic pages. When PHP fails to query Backend Database an error message will be returned to users if error are not handled on a safe way. WEB Developers uncorrectly debug SQL Errors by displaying some kind of error message on WEB Page when query fails. This approach should not be considered safe since Errors should never be displayed to users.

Users should also never deduce that something wrong happens otherwise it could be considered a flaw to further more exploits a vulnerability. To this aim we're going to how to safely handle errors.

function unavailable_resource_handler { /* Handle an 'Unavailable Resource' event without supplying further information to user *     * Example: *   die('Resource not available'); *           *      */     ..     ..

}

function sql_error_handler ($sQuery, $sMsg) { /* Log failed SQL Query statement */ error_log ($sQuery, 3, "/var/log/site/sqlquery_error.log"); /* Log error message */ error_log ($sMsg, 3, "/var/log/site/site_error.log");

/* Notify user that resource is unavailable */ unavailable_resource_handler; }

Before of applying an Error Log Handler, such as the above, be sure to audit every function return values to avoid error propagation.

LDAP Authentication
As previously states LDAP Authentication in PHP should be handled with ldap_bind functin in such a way:

function authLdap($sUsername, $sPassword) { $ldap_ch=ldap_connect("ldap://localhost"); if ($ldap_ch) {

$ldap_user = "uid=$sUsername, ou=Utenti, dc=domain, dc= com"; $ldap_password = $sPassword;

$bind = @ldap_bind($ldap_ch, $ldap_user, $ldap_password); return $bind; }

return FALSE;

}

$sUsername = $_GET['username']; $sPassword = $_GET['password'];

$bIsAuth=authLdap($sUsername, $sPassword);

if (! $bIsAuth ) { /* Unauthorized access, handle exception */ ...  ... }

/* User has been succesfull authenticated */

LDAP Authentication Credentials
Whenever a Backend Directory Server shall not be used to authenticate user is good practice not to query with an anonymous bind. Doind so you need a safe way to store LDAP Bind access credentials. The same techniques of previous section shall be used as well.

Data Validation
Data Validation occours on the same way as in PHP Preventing SQL Injection. Here follows previous LDAP Login Form example with data validation, where both username and password are allowed to contains only alfa numeric values.

$sUsername = $_GET['username']; $sPassword = $_GET['password'];

if (! preg_match("/[a-zA-Z0-9]+$/", $username) {  /* username doesn't contains valid characters, handle exception */   ..   ..   return; }

if (! preg_match("/[a-zA-Z0-9]+$/", $password) {  /* password doesn't contains valid characters, handle exception */   ..   ..   return; }

$bIsAuth=authLdap($sUsername, $sPassword);

if (! $bIsAuth ) { /* Unauthorized access, handle exception */ ...  ... }

/* User has been succesfull authenticated */

Logging Errors
As in PHP Preventing SQL Injection we're going to define a safe way to handle LDAP Errors. An previously stated incorrect error handling may raise Information Disclousure vulnerbality and a malicious user may furthermore exploit this vulnerability to perform some kind of a attack.

function unavailable_resource_handler { /* Handle an 'Unavailable Resource' event without supplying further information to user *     * Example: *   die('Resource not available'); *           *      */     ..     ..

}

function ldap_error_handler ($sQuery, $sMsg) { /* Log failed LDAP Query statement */ error_log ($sQuery, 3, "/var/log/site/ldapquery_error.log"); /* Log error message */ error_log ($sMsg, 3, "/var/log/site/site_error.log");

/* Notify user that resource is unavailable */ unavailable_resource_handler; }

Detecting Intrusions from WEBAPP
PHPIDS (PHP-Intrusion Detection System) is a well mantained and fast security layer for PHP based web application. It allows to embed a WEB Application IDS into a PHP WEB Application. It performs a transparent Input Data Validation on each HTTP Request to look forward for Malicious Input. It means that Developer shouldn't explicitly analyze and thrust Input Data. PHP IDS will automatically look for exploit attempts. PHPIDS simply recognizes when an attacker tries to break your WEB Application and let you decide how to reacts.

To install PHPIDS:
 * download and unpack in your application or include folder.
 * open phpids/lib/IDS/Config/Config.ini file and edit the following element to reflect PHPIDS complete installation path:
 * filter_path
 * tmp_path
 * path in both Logging and Caching section

Here is a typical usage of PHPIDS:

init_ids.php <?php set_include_path(get_include_path . PATH_SEPARATOR . './lib/'); require_once 'IDS/Init.php';

function phpIDSInit { $request = array(   	              'REQUEST' => $_REQUEST,                         'GET'     => $_GET,                      'POST'    => $_POST,                       'COOKIE'  => $_COOKIE                    );

$init = IDS_Init::init('./lib/IDS/Config/Config.ini'); $ids = new IDS_Monitor($request, $init); return $ids->run;

}

?>

main.php <?php require_once './init_ids.php'; $sIDSAlert = phpIDSInit;

if ($sIDSAlert) { /* PHPIDS raise an alert, handle exception */ ....      ....       die }

/* PHPIDS determined that request is safe */ ... ...

?>

= References =


 * OWASP : "OWASP Guide Project" - http://www.owasp.org/index.php/OWASP_Guide_Project
 * OWASP : "OWASP PHP Filters" - http://www.owasp.org/index.php/OWASP_PHP_Filters
 * OWASP : "OWASP PHP Project" - http://www.owasp.org/index.php/Category:OWASP_PHP_Project
 * OWASP : "PHP Top 5 - http://www.owasp.org/index.php/PHP_Top_5"
 * PHP : "MySQL Improved Extension" - http://it2.php.net/manual/en/book.mysqli.php
 * PHP : "Data Filtering" - http://it.php.net/manual/en/book.filter.php
 * Ilia Alshanetsky : "architect's Guide to PHP Security" - http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf
 * PHPIDS : http://php-ids.org/