OWASP - User contributions [en]

User:Roy Vanegas

2016-05-19T03:14:59Z

Roy Vanegas: Update when I started teaching.

I began programming in 1996, first for the web, then in languages such as Java and C. I have a bachelor’s degree in computer science and a master’s degree in hardware/software interaction design.

I’ve been teaching web programming and design to high school students, continuing education students, and undergraduate and graduate students since 2005.

Testing for Clickjacking (OTG-CLIENT-009)

2016-05-19T03:14:14Z

Roy Vanegas: Some editing of the content to make it easier to read, and replacing inch- and foot-marks with proper quotes.

{{Template:OWASP Testing Guide v4}}

== Summary ==
“Clickjacking” (which is a subset of “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting with seemingly harmless web pages. The term “Clickjacking” was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking a button that appears to perform another operation. This is a “client side” security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed with CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (through, for example, social engineering). Like other attacks, a common prerequisite is that the victim is authenticated against the attacker’s target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions they never intended to perform through an “ad hoc” positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce users’ actions on the target site, even if anti-CSRF tokens are being used. So, it’s important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a “proof of concept” to exploit the vulnerability.

The first step in discovering if a website is vulnerable is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible with Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all parameters of each request and response flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disables all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induce a false positive by inserting the beginning of the frame busting script into a request's parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if all is ok, the transfer is done. In the following listing a snippet of code of the last step is presented (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look like a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under the seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code to create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

PHP Security Cheat Sheet

2015-01-03T21:59:07Z

Roy Vanegas: /* Untrusted data */ Wrapped every super global mention under the “Untrused data” section in <code> tags.

= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 81.8% of web servers deploying it, according to W3 Techs.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the language. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

PHP is a 'grown' language rather than deliberately engineered, making writing insecure PHP applications far too easy and common. If you want to use PHP securely, then you should be aware of all it's pitfalls.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions (for example greater than and less than), and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions by default, making it difficult to write correct code.

====Exceptions and error handling====

Almost all PHP builtins, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In many other languages, and most high level languages that compete with PHP, error conditions that are caused by developer errors, or runtime errors that the developer has failed to anticipate, will cause the program to stop running, which is the safest thing to do.

Consider the following code which attempts to limit access to a certain function using a database query that checks to see if the username is on a black list:

$db_link = mysqli_connect('localhost', 'dbuser', 'dbpassword', 'dbname');

function can_access_feature($current_user) {
global $db_link;
$username = mysqli_real_escape_string($db_link, $current_user->username);
$res = mysqli_query($db_link, "SELECT COUNT(id) FROM blacklisted_users WHERE username = '$username';");
$row = mysqli_fetch_array($res);
if ((int)$row[0] > 0) {
return false;
} else {
return true;
}
}

if (!can_access_feature($current_user)) {
exit();
}

// Code for feature here

There are various runtime errors that could occur in this - for example, the database connection could fail, due to a wrong password or the server being down etc., or the connection could be closed by the server after it was opened client side. In these cases, by default the <code>mysqli_</code> functions will issue warnings or notices, but will not throw exceptions or fatal errors. This means that the code simply carries on! The variable <code>$row</code> becomes <code>NULL</code>, and PHP will evaluate <code>$row[0]</code> also as <code>NULL</code>, and <code>(int)$row[0]</code> as <code>0</code>, due to weak typing. Eventually the <code>can_access_feature</code> function returns <code>true</code>, giving access to all users, whether they are on the blacklist or not.

If these native database APIs are used, error checking should be added at every point. However, since this requires additional work, and is easily missed, this is insecure by default. It also requires a lot of boilerplate.
This is why accessing a database should always be done by using [http://php.net/manual/en/intro.pdo.php PHP Data Objects (PDO)] specified with the [http://php.net/manual/en/pdo.error-handling.php ERRMODE_WARNING or ERRMODE_EXCEPTION flags] unless there is a clearly compelling reason to use native drivers and careful error checking.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems. Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

PHP also provides an 'array' data structure, which is used extensively in all PHP code and internally, that is a confusing mix between an array and a dictionary. This confusion can cause even experienced PHP developers to introduce critical security vulnerabilities such as [https://www.drupal.org/SA-CORE-2014-005 Drupal SA-CORE-2014-005] (see [http://cgit.drupalcode.org/drupal/commit/?id=26a7752c34321fd9cb889308f507ca6bdb777f08 the patch]).

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with <code>$supplied_nonce</code> being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the use of the <code>==</code> (equality) operator instead of the <code>===</code> (identity) operator, the comparison succeeds (since the expression <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

Exactly the same issue, combined with the confusion of PHP's 'array' data structure, can be exploited in issues such as [https://www.drupal.org/SA-CORE-2014-005 Drupal SA-CORE-2014-005] - see [http://www.zoubi.me/blog/drupageddon-sa-core-2014-005-drupal-7-sql-injection-exploit-demo example exploit].

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are <code>$_SERVER</code>, <code>$_GET</code>, <code>$_POST</code>, <code>$_REQUEST</code>, <code>$_FILES</code> and <code>$_COOKIE</code>. Not all data in <code>$_SERVER</code> can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with <code>HTTP_</code>).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

See the PHP docs on [http://php.net/manual/en/mysqli.quickstart.prepared-statements.php MySQLi prepared statements] and [http://php.net/manual/en/pdo.prepare.php PDO prepared statements]

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you should use query builder that is provided by a framework. Do not roll your own.

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

* Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

* Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

[mailto:L.Plant.98@cantab.net Luke Plant]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2015-01-03T21:55:58Z

Roy Vanegas: Combined paragraphs 1 and 2 under “Unhelpful builtins” into one paragraph.

= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 81.8% of web servers deploying it, according to W3 Techs.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the language. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

PHP is a 'grown' language rather than deliberately engineered, making writing insecure PHP applications far too easy and common. If you want to use PHP securely, then you should be aware of all it's pitfalls.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions (for example greater than and less than), and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions by default, making it difficult to write correct code.

====Exceptions and error handling====

Almost all PHP builtins, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In many other languages, and most high level languages that compete with PHP, error conditions that are caused by developer errors, or runtime errors that the developer has failed to anticipate, will cause the program to stop running, which is the safest thing to do.

Consider the following code which attempts to limit access to a certain function using a database query that checks to see if the username is on a black list:

$db_link = mysqli_connect('localhost', 'dbuser', 'dbpassword', 'dbname');

function can_access_feature($current_user) {
global $db_link;
$username = mysqli_real_escape_string($db_link, $current_user->username);
$res = mysqli_query($db_link, "SELECT COUNT(id) FROM blacklisted_users WHERE username = '$username';");
$row = mysqli_fetch_array($res);
if ((int)$row[0] > 0) {
return false;
} else {
return true;
}
}

if (!can_access_feature($current_user)) {
exit();
}

// Code for feature here

There are various runtime errors that could occur in this - for example, the database connection could fail, due to a wrong password or the server being down etc., or the connection could be closed by the server after it was opened client side. In these cases, by default the <code>mysqli_</code> functions will issue warnings or notices, but will not throw exceptions or fatal errors. This means that the code simply carries on! The variable <code>$row</code> becomes <code>NULL</code>, and PHP will evaluate <code>$row[0]</code> also as <code>NULL</code>, and <code>(int)$row[0]</code> as <code>0</code>, due to weak typing. Eventually the <code>can_access_feature</code> function returns <code>true</code>, giving access to all users, whether they are on the blacklist or not.

If these native database APIs are used, error checking should be added at every point. However, since this requires additional work, and is easily missed, this is insecure by default. It also requires a lot of boilerplate.
This is why accessing a database should always be done by using [http://php.net/manual/en/intro.pdo.php PHP Data Objects (PDO)] specified with the [http://php.net/manual/en/pdo.error-handling.php ERRMODE_WARNING or ERRMODE_EXCEPTION flags] unless there is a clearly compelling reason to use native drivers and careful error checking.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems. Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

PHP also provides an 'array' data structure, which is used extensively in all PHP code and internally, that is a confusing mix between an array and a dictionary. This confusion can cause even experienced PHP developers to introduce critical security vulnerabilities such as [https://www.drupal.org/SA-CORE-2014-005 Drupal SA-CORE-2014-005] (see [http://cgit.drupalcode.org/drupal/commit/?id=26a7752c34321fd9cb889308f507ca6bdb777f08 the patch]).

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with <code>$supplied_nonce</code> being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the use of the <code>==</code> (equality) operator instead of the <code>===</code> (identity) operator, the comparison succeeds (since the expression <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

Exactly the same issue, combined with the confusion of PHP's 'array' data structure, can be exploited in issues such as [https://www.drupal.org/SA-CORE-2014-005 Drupal SA-CORE-2014-005] - see [http://www.zoubi.me/blog/drupageddon-sa-core-2014-005-drupal-7-sql-injection-exploit-demo example exploit].

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

See the PHP docs on [http://php.net/manual/en/mysqli.quickstart.prepared-statements.php MySQLi prepared statements] and [http://php.net/manual/en/pdo.prepare.php PDO prepared statements]

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you should use query builder that is provided by a framework. Do not roll your own.

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

* Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

* Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

[mailto:L.Plant.98@cantab.net Luke Plant]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2014-03-25T12:41:02Z

Roy Vanegas: Removed an extra line break following the “php.ini” subsection.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 81.8% of web servers deploying it, according to W3 Techs.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the latter. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

Serious issues abound in all aspects of PHP, making it difficult to write secure PHP applications. If you’re forced to use PHP, then you must be aware of all its pitfalls.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions, and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions, making it difficult to write correct code.

====Exceptions and error handling====

Almost all core PHP code, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems.

Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with <code>$supplied_nonce</code> being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the use of the <code>==</code> (equality) operator instead of the <code>===</code> (identity) operator, the comparison succeeds (since the expression <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

====MySQLi Prepared Statements Wrapper====
The following function, performs a SQL query, returns its results as a 2D array (if query was SELECT) and does all that with prepared statements using MySQLi fast MySQL interface:

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->num_rows) {
$out = array();
while (null != ($r = $result->fetch_array(MYSQLI_ASSOC)))
$out [] = $r;
return $out;
}
return null;
} else {
if (!$stmt = $DB->prepare($Query))
trigger_error("Unable to prepare statement: {$Query}, reason: " . $DB->error . "");
array_shift($args); //remove $Query from args
//the following three lines are the only way to copy an array values in PHP
$a = array();
foreach ($args as $k => &$v)
$a[$k] = &$v;
$types = str_repeat("s", count($args)); //all params are strings, works well on MySQL and SQLite
array_unshift($a, $types);
call_user_func_array(array($stmt, 'bind_param'), $a);
$stmt->execute();
//fetching all results in a 2D array
$metadata = $stmt->result_metadata();
$out = array();
$fields = array();
if (!$metadata)
return null;
$length = 0;
while (null != ($field = mysqli_fetch_field($metadata))) {
$fields [] = &$out [$field->name];
$length+=$field->length;
}
call_user_func_array(array(
$stmt, "bind_result"
), $fields);
$output = array();
$count = 0;
while ($stmt->fetch()) {
foreach ($out as $k => $v)
$output [$count] [$k] = $v;
$count++;
}
$stmt->free_result();
return ($count == 0) ? null : $output;
}
}

Now you could do your every query like the example below:

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT ?" , 5 , "Username" , 2);

Every instance of ? is bound with an argument of the list, not ''replaced'' with it. MySQL 5.5+ supports ? as ORDER BY and LIMIT clause specifiers. If you're using a database that doesn't support them, see next section.

'''REMEMBER:''' When you use this approach, you should ''NEVER'' concat strings for a SQL query.

====PDO Prepared Statement Wrapper====
The following function, does the same thing as the above function but using PDO. You can use it with every PDO supported driver.

try {
$DB = new PDO("{$Driver}:dbname={$DatabaseName};host={$Host};", $Username, $Password);
} catch (Exception $e) {
trigger_error("PDO connection error: " . $e->getMessage());
}

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->rowCount()) {
return $result->fetchAll(PDO::FETCH_ASSOC);
}
return null;
} else {
if (!$stmt = $DB->prepare($Query)) {
$Error = $DB->errorInfo();
trigger_error("Unable to prepare statement: {$Query}, reason: {$Error[2]}");
}
array_shift($args); //remove $Query from args
$i = 0;
foreach ($args as &$v)
$stmt->bindValue(++$i, $v);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
}

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT 5" , 5 , "Username" );

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you need to do two things:

====Not Supported Fields====
When some field does not support binding (like LIMIT clause in PDO), you need to '''whitelist''' the data you're about to use. LIMIT always requires an integer, so cast the variable to an integer. ORDER BY needs a field name, so whitelist it with field names:

function whitelist($Needle,$Haystack)
{
if (!in_array($Needle,$Haystack))
return reset($Haystack); //first element
return $Needle;
}

$Limit = $_GET['lim'];
$Limit = $Limit * 1; //type cast, integers are safe

$Order = $_GET['sort'];
$Order=whitelist($Order,Array("ID","Username","Password"));

This is very important. If you think you're tired and you rather blacklist than whitelist, you’re bound to fail.

====Dynamic Queries====
Now this is a highly delicate situation. Whenever hackers fail to injection SQL in your common application scenarios, they go for Advanced Search features or similars, because those features rely on dynamic queries and dynamic queries are almost always insecurely implemented.

When you're building a dynamic query, the only way is whitelisting. Whitelist every field name, every boolean operator (it should be OR or AND, nothing else) and after building your query, use prepared statements:

$Query="SELECT * FROM table WHERE ";
foreach ($_GET['fields'] as $g)
$Query.=whitelist($g,Array("list","of","possible","fields","here"))."=?";
$Values=$_GET['values'];
array_unshift($Query); //add to the beginning
$res=call_user_func_array(SQL, $Values);

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Access Control Cheat Sheet=
This section aims to mitigate access control issues, as well as '''Insecure Direct Object Reference''' issues.

=Cryptography Cheat Sheet=

=File Inclusion Cheat Sheet=

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

=Sources of Taint=

= OLD. PHP General Guidelines for Secure Web Applications =

== PHP Version ==
Use '''PHP 5.3.8'''. Stable versions are always safer then the beta ones.

== Framework==
Use a framework like '''Zend''' or '''Symfony'''. Try not to re-write the code again and again. Also avoid dead codes.

== Directory==
Code with most of your code outside of the webroot. This is automatic for Symfony and Zend. Stick to these frameworks.

== Hashing Extension ==
Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

== Cryptographic Extension ==
Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

== Authentication and Authorization ==
There is no authentication or authorization classes in native PHP. Use '''ZF''' or '''Symfony''' instead.

== Input nput validation ==
Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($dirty['foo']);

== Use PDO or ORM ==
Use PDO with prepared statements or an ORM like Doctrine

== Use PHP Unit and Jenkins ==
When developing PHP code, make sure you develop with PHP Unit and Jenkins - see http://qualityassuranceinphpprojects.com/pages/tools.html for more details.

== Use Stefan Esser's Hardened PHP Patch ==
Consider using Stefan Esser's Hardened PHP patch - http://www.hardened-php.net/suhosin/index.html
(not maintained now, but the concepts are very powerful)

== Avoid Global Variables==
In terms of secure coding with PHP, do not use globals unless absolutely necessary
Check your php.ini to ensure register_globals is off Do not run at all with this setting enabled It's extremely dangerous (register_globals has been disabled since 5.0 / 2006, but .... most PHP 4 code needs it, so many hosters have it turned on)

== Protection against RFI==
Ensure allow_url_fopen and allow_url_include are both disabled to protect against RFI But don't cause issues by using the pattern include $user_supplied_data or require "base" + $user_supplied_data - it's just unsafe as you can input /etc/passwd and PHP will try to include it

== Regexes (!)==
Watch for executable regexes (!)

== Session Rotation ==
Session rotation is very easy - just after authentication, plonk in session_regenerate_id() and you‘re done.

== Be aware of PHP filters ==
PHP filters can be tricky and complex. Be extra-conscious when using them.

== Logging ==
Set display_errors to 0, and set up logging to go to a file you control, or at least syslog. This is the most commonly neglected area of PHP configuration

== Output encoding ==
Output encoding is entirely up to you. Just do it, ESAPI for PHP is ready for this job.

These are transparent to you and you need to know about them. php://input: takes input from the console gzip: takes compressed input and might bypass input validation http://au2.php.net/manual/en/filters.php

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2014-03-25T03:46:14Z

Roy Vanegas: Re-wrote the last paragraph under the “PHP overview” section

PHP Security Cheat Sheet

2014-03-25T03:17:10Z

Roy Vanegas: Updated the PHP usage stats.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 81.8% of web servers deploying it, according to W3 Techs.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the latter. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

There are, unfortunately, serious issues in all areas that make it difficult to write secure PHP applications. These are difficult to work around if you are forced to use PHP, but you need to be aware of them.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions, and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions, making it difficult to write correct code.

====Exceptions and error handling====

Almost all core PHP code, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems.

Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with <code>$supplied_nonce</code> being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the use of the <code>==</code> (equality) operator instead of the <code>===</code> (identity) operator, the comparison succeeds (since the expression <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

====MySQLi Prepared Statements Wrapper====
The following function, performs a SQL query, returns its results as a 2D array (if query was SELECT) and does all that with prepared statements using MySQLi fast MySQL interface:

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->num_rows) {
$out = array();
while (null != ($r = $result->fetch_array(MYSQLI_ASSOC)))
$out [] = $r;
return $out;
}
return null;
} else {
if (!$stmt = $DB->prepare($Query))
trigger_error("Unable to prepare statement: {$Query}, reason: " . $DB->error . "");
array_shift($args); //remove $Query from args
//the following three lines are the only way to copy an array values in PHP
$a = array();
foreach ($args as $k => &$v)
$a[$k] = &$v;
$types = str_repeat("s", count($args)); //all params are strings, works well on MySQL and SQLite
array_unshift($a, $types);
call_user_func_array(array($stmt, 'bind_param'), $a);
$stmt->execute();
//fetching all results in a 2D array
$metadata = $stmt->result_metadata();
$out = array();
$fields = array();
if (!$metadata)
return null;
$length = 0;
while (null != ($field = mysqli_fetch_field($metadata))) {
$fields [] = &$out [$field->name];
$length+=$field->length;
}
call_user_func_array(array(
$stmt, "bind_result"
), $fields);
$output = array();
$count = 0;
while ($stmt->fetch()) {
foreach ($out as $k => $v)
$output [$count] [$k] = $v;
$count++;
}
$stmt->free_result();
return ($count == 0) ? null : $output;
}
}

Now you could do your every query like the example below:

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT ?" , 5 , "Username" , 2);

Every instance of ? is bound with an argument of the list, not ''replaced'' with it. MySQL 5.5+ supports ? as ORDER BY and LIMIT clause specifiers. If you're using a database that doesn't support them, see next section.

'''REMEMBER:''' When you use this approach, you should ''NEVER'' concat strings for a SQL query.

====PDO Prepared Statement Wrapper====
The following function, does the same thing as the above function but using PDO. You can use it with every PDO supported driver.

try {
$DB = new PDO("{$Driver}:dbname={$DatabaseName};host={$Host};", $Username, $Password);
} catch (Exception $e) {
trigger_error("PDO connection error: " . $e->getMessage());
}

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->rowCount()) {
return $result->fetchAll(PDO::FETCH_ASSOC);
}
return null;
} else {
if (!$stmt = $DB->prepare($Query)) {
$Error = $DB->errorInfo();
trigger_error("Unable to prepare statement: {$Query}, reason: {$Error[2]}");
}
array_shift($args); //remove $Query from args
$i = 0;
foreach ($args as &$v)
$stmt->bindValue(++$i, $v);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
}

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT 5" , 5 , "Username" );

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you need to do two things:

====Not Supported Fields====
When some field does not support binding (like LIMIT clause in PDO), you need to '''whitelist''' the data you're about to use. LIMIT always requires an integer, so cast the variable to an integer. ORDER BY needs a field name, so whitelist it with field names:

function whitelist($Needle,$Haystack)
{
if (!in_array($Needle,$Haystack))
return reset($Haystack); //first element
return $Needle;
}

$Limit = $_GET['lim'];
$Limit = $Limit * 1; //type cast, integers are safe

$Order = $_GET['sort'];
$Order=whitelist($Order,Array("ID","Username","Password"));

This is very important. If you think you're tired and you rather blacklist than whitelist, you’re bound to fail.

====Dynamic Queries====
Now this is a highly delicate situation. Whenever hackers fail to injection SQL in your common application scenarios, they go for Advanced Search features or similars, because those features rely on dynamic queries and dynamic queries are almost always insecurely implemented.

When you're building a dynamic query, the only way is whitelisting. Whitelist every field name, every boolean operator (it should be OR or AND, nothing else) and after building your query, use prepared statements:

$Query="SELECT * FROM table WHERE ";
foreach ($_GET['fields'] as $g)
$Query.=whitelist($g,Array("list","of","possible","fields","here"))."=?";
$Values=$_GET['values'];
array_unshift($Query); //add to the beginning
$res=call_user_func_array(SQL, $Values);

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Access Control Cheat Sheet=
This section aims to mitigate access control issues, as well as '''Insecure Direct Object Reference''' issues.

=Cryptography Cheat Sheet=

=File Inclusion Cheat Sheet=

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

=Sources of Taint=

= OLD. PHP General Guidelines for Secure Web Applications =

== PHP Version ==
Use '''PHP 5.3.8'''. Stable versions are always safer then the beta ones.

== Framework==
Use a framework like '''Zend''' or '''Symfony'''. Try not to re-write the code again and again. Also avoid dead codes.

== Directory==
Code with most of your code outside of the webroot. This is automatic for Symfony and Zend. Stick to these frameworks.

== Hashing Extension ==
Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

== Cryptographic Extension ==
Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

== Authentication and Authorization ==
There is no authentication or authorization classes in native PHP. Use '''ZF''' or '''Symfony''' instead.

== Input nput validation ==
Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($dirty['foo']);

== Use PDO or ORM ==
Use PDO with prepared statements or an ORM like Doctrine

== Use PHP Unit and Jenkins ==
When developing PHP code, make sure you develop with PHP Unit and Jenkins - see http://qualityassuranceinphpprojects.com/pages/tools.html for more details.

== Use Stefan Esser's Hardened PHP Patch ==
Consider using Stefan Esser's Hardened PHP patch - http://www.hardened-php.net/suhosin/index.html
(not maintained now, but the concepts are very powerful)

== Avoid Global Variables==
In terms of secure coding with PHP, do not use globals unless absolutely necessary
Check your php.ini to ensure register_globals is off Do not run at all with this setting enabled It's extremely dangerous (register_globals has been disabled since 5.0 / 2006, but .... most PHP 4 code needs it, so many hosters have it turned on)

== Protection against RFI==
Ensure allow_url_fopen and allow_url_include are both disabled to protect against RFI But don't cause issues by using the pattern include $user_supplied_data or require "base" + $user_supplied_data - it's just unsafe as you can input /etc/passwd and PHP will try to include it

== Regexes (!)==
Watch for executable regexes (!)

== Session Rotation ==
Session rotation is very easy - just after authentication, plonk in session_regenerate_id() and you‘re done.

== Be aware of PHP filters ==
PHP filters can be tricky and complex. Be extra-conscious when using them.

== Logging ==
Set display_errors to 0, and set up logging to go to a file you control, or at least syslog. This is the most commonly neglected area of PHP configuration

== Output encoding ==
Output encoding is entirely up to you. Just do it, ESAPI for PHP is ready for this job.

These are transparent to you and you need to know about them. php://input: takes input from the console gzip: takes compressed input and might bypass input validation http://au2.php.net/manual/en/filters.php

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Talk:PHP Security Cheat Sheet

2014-03-18T03:45:47Z

Roy Vanegas: Just signing my name.

=== NOTOC ===

I want to keep the TOC in so this is standard like other cheat sheets in this series (Jim Nov 25 2012)

=== TBD ===
I'm (mis-)using the <code><nowiki>{{TBD: ...}}</nowiki></code> wiki syntax to mark texts and paragraphs "to be discussed".
[[User:Achim|Achim]], 3-jul-2012

==php.ini==

I think your error configuration is not good. You have to set display_errors and display_startup_errors to On, otherwise it would be too hard to debug your code (yes you need debugging even on the server). The better practice, is to set to to On by default, and use a framework (a piece of code) to redirect that to a log for general user, and keep it on the screen for admins/developers.
I've seen infinite developers set it to off, then set it to On for debugging, and leave it there.

: OWASP makes suggestions for security not for compfy debugging. Security is the goal.
: Hence '''Off''' is the choice for produktive systems. --[[User:Achim|Achim]], 5-jul-2012

:: I don't know if you've experienced it or not, but this is exactly the difference between an open community and a commercial rigid ISO workgroup. We provide solutions that people actually use, not solutions that are perfect if we lived on the moon. This error handling issue is very important. Also the startup error should be on, otherwise users only think the site is dead. There shuold be a critical error level, delivered to the admin via SMS or Email, so that these errors are handled properly.

Why the hell is file_uploads off? Are you one of those guys who believe everything should be off to provide a secure system?

: Yes (but there is a hint that some settings need to be adapted to real systems:) --[[User:Achim|Achim]], 5-jul-2012

:: Could you elaborate the security risks with file_uploads?

Also disabling functions and etc. its a very bad practice. This is only used in dull shared web hosting systems, and nobody gets their hosts.

: Either we try to make a crappy PHP secure, or you have to live with brain-dead develpers using something like <code>system($_REQUEST['killme'])</code>
: --[[User:Achim|Achim]], 5-jul-2012

:: Develoeprs should be aware of dangerous functions. Some IDE's deliver warnings when variables are used in dangerous functions, we could create a tool that would scan the code and tell so. This is the same scenario as the first issue.

Most usage of PHP is available source code (Wordpress, Joomla, MyBB, etc.) and they all use these abilities. What you're indicating just says "dont follow this cheat sheet", no offence!

: the cheat sheet is about security, not about using insecure frameworks. --[[User:Achim|Achim]], 5-jul-2012

:: 15% of websites are powered with Wordpress, and they are among the most secure of all :)) Do you expect every admin to pay a few thousand bucks for it?

We gotta discuss session handling, there's a lot of issues there.

Allow_url_fopen Off is not secure at all. my most recent paper lists 12 methods of converting and LFI to a RFI, if somehow has an LFI flaw in the code, url_fopen On or Off wont matter.

: Right. But if set on, it's definitely insecure and very easy to exploit. --[[User:Achim|Achim]], 5-jul-2012

:: I'm just saying LFI is enough big of a threat that we need to '''educate''' developers about it. If we don't, there are absolutely no countermeasures.

The memory and execution time limit defined there, is very bad practice. This limit kills the php script, and results in numerous errors which are extremely hard to debug. They do not mitigate DOS, you can simply run 10 scripts instead of 1. The optimum values are 32MB memory, 30 second execution time, with ability to extend it in user code.

: It's a suggestion, feel free to adapt it to proper values. Just using the default may bring you to some risks. --[[User:Achim|Achim]], 5-jul-2012

:: We need to find a solution to put a cognitive limit, otherwise there's no ''JUST" value for it. I need to delve my head into PHP manuals.

Please get back to me on this, or my email at owasp@abiusx.com

--[[User:Abbas Naderi|Abbas Naderi]]

Hi Abbas, could you add some clarification for ORM? Not everyone knows the acronym which diminishes the general readability and usability. Thanks! --[[User:Peter Mosmans|Peter Mosmans]] 04:47, 16 October 2012 (UTC)

== Citing 72% of servers stat ==

Can someone provide the source for the statistic under the “PHP overview” section that 72% of web servers run PHP. Also, is that 72% of ''all'' servers worldwide?
— [[User:Roy Vanegas|Roy Vanegas]] ([[User talk:Roy Vanegas|talk]]) 22:45, 17 March 2014 (CDT)

Talk:PHP Security Cheat Sheet

2014-03-18T03:41:40Z

Roy Vanegas: /* Citing 72% of servers stat */ new section

PHP Security Cheat Sheet

2014-03-17T22:31:38Z

Roy Vanegas: Identified the equality vs identity operators under the section “Input handling.”

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 72% of web servers deploying it.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the latter. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

There are, unfortunately, serious issues in all areas that make it difficult to write secure PHP applications. These are difficult to work around if you are forced to use PHP, but you need to be aware of them.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions, and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions, making it difficult to write correct code.

====Exceptions and error handling====

Almost all core PHP code, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems.

Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with <code>$supplied_nonce</code> being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the use of the <code>==</code> (equality) operator instead of the <code>===</code> (identity) operator, the comparison succeeds (since the expression <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

====MySQLi Prepared Statements Wrapper====
The following function, performs a SQL query, returns its results as a 2D array (if query was SELECT) and does all that with prepared statements using MySQLi fast MySQL interface:

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->num_rows) {
$out = array();
while (null != ($r = $result->fetch_array(MYSQLI_ASSOC)))
$out [] = $r;
return $out;
}
return null;
} else {
if (!$stmt = $DB->prepare($Query))
trigger_error("Unable to prepare statement: {$Query}, reason: " . $DB->error . "");
array_shift($args); //remove $Query from args
//the following three lines are the only way to copy an array values in PHP
$a = array();
foreach ($args as $k => &$v)
$a[$k] = &$v;
$types = str_repeat("s", count($args)); //all params are strings, works well on MySQL and SQLite
array_unshift($a, $types);
call_user_func_array(array($stmt, 'bind_param'), $a);
$stmt->execute();
//fetching all results in a 2D array
$metadata = $stmt->result_metadata();
$out = array();
$fields = array();
if (!$metadata)
return null;
$length = 0;
while (null != ($field = mysqli_fetch_field($metadata))) {
$fields [] = &$out [$field->name];
$length+=$field->length;
}
call_user_func_array(array(
$stmt, "bind_result"
), $fields);
$output = array();
$count = 0;
while ($stmt->fetch()) {
foreach ($out as $k => $v)
$output [$count] [$k] = $v;
$count++;
}
$stmt->free_result();
return ($count == 0) ? null : $output;
}
}

Now you could do your every query like the example below:

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT ?" , 5 , "Username" , 2);

Every instance of ? is bound with an argument of the list, not ''replaced'' with it. MySQL 5.5+ supports ? as ORDER BY and LIMIT clause specifiers. If you're using a database that doesn't support them, see next section.

'''REMEMBER:''' When you use this approach, you should ''NEVER'' concat strings for a SQL query.

====PDO Prepared Statement Wrapper====
The following function, does the same thing as the above function but using PDO. You can use it with every PDO supported driver.

try {
$DB = new PDO("{$Driver}:dbname={$DatabaseName};host={$Host};", $Username, $Password);
} catch (Exception $e) {
trigger_error("PDO connection error: " . $e->getMessage());
}

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->rowCount()) {
return $result->fetchAll(PDO::FETCH_ASSOC);
}
return null;
} else {
if (!$stmt = $DB->prepare($Query)) {
$Error = $DB->errorInfo();
trigger_error("Unable to prepare statement: {$Query}, reason: {$Error[2]}");
}
array_shift($args); //remove $Query from args
$i = 0;
foreach ($args as &$v)
$stmt->bindValue(++$i, $v);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
}

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT 5" , 5 , "Username" );

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you need to do two things:

====Not Supported Fields====
When some field does not support binding (like LIMIT clause in PDO), you need to '''whitelist''' the data you're about to use. LIMIT always requires an integer, so cast the variable to an integer. ORDER BY needs a field name, so whitelist it with field names:

function whitelist($Needle,$Haystack)
{
if (!in_array($Needle,$Haystack))
return reset($Haystack); //first element
return $Needle;
}

$Limit = $_GET['lim'];
$Limit = $Limit * 1; //type cast, integers are safe

$Order = $_GET['sort'];
$Order=whitelist($Order,Array("ID","Username","Password"));

This is very important. If you think you're tired and you rather blacklist than whitelist, you’re bound to fail.

====Dynamic Queries====
Now this is a highly delicate situation. Whenever hackers fail to injection SQL in your common application scenarios, they go for Advanced Search features or similars, because those features rely on dynamic queries and dynamic queries are almost always insecurely implemented.

When you're building a dynamic query, the only way is whitelisting. Whitelist every field name, every boolean operator (it should be OR or AND, nothing else) and after building your query, use prepared statements:

$Query="SELECT * FROM table WHERE ";
foreach ($_GET['fields'] as $g)
$Query.=whitelist($g,Array("list","of","possible","fields","here"))."=?";
$Values=$_GET['values'];
array_unshift($Query); //add to the beginning
$res=call_user_func_array(SQL, $Values);

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Access Control Cheat Sheet=
This section aims to mitigate access control issues, as well as '''Insecure Direct Object Reference''' issues.

=Cryptography Cheat Sheet=

=File Inclusion Cheat Sheet=

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

=Sources of Taint=

= OLD. PHP General Guidelines for Secure Web Applications =

== PHP Version ==
Use '''PHP 5.3.8'''. Stable versions are always safer then the beta ones.

== Framework==
Use a framework like '''Zend''' or '''Symfony'''. Try not to re-write the code again and again. Also avoid dead codes.

== Directory==
Code with most of your code outside of the webroot. This is automatic for Symfony and Zend. Stick to these frameworks.

== Hashing Extension ==
Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

== Cryptographic Extension ==
Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

== Authentication and Authorization ==
There is no authentication or authorization classes in native PHP. Use '''ZF''' or '''Symfony''' instead.

== Input nput validation ==
Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($dirty['foo']);

== Use PDO or ORM ==
Use PDO with prepared statements or an ORM like Doctrine

== Use PHP Unit and Jenkins ==
When developing PHP code, make sure you develop with PHP Unit and Jenkins - see http://qualityassuranceinphpprojects.com/pages/tools.html for more details.

== Use Stefan Esser's Hardened PHP Patch ==
Consider using Stefan Esser's Hardened PHP patch - http://www.hardened-php.net/suhosin/index.html
(not maintained now, but the concepts are very powerful)

== Avoid Global Variables==
In terms of secure coding with PHP, do not use globals unless absolutely necessary
Check your php.ini to ensure register_globals is off Do not run at all with this setting enabled It's extremely dangerous (register_globals has been disabled since 5.0 / 2006, but .... most PHP 4 code needs it, so many hosters have it turned on)

== Protection against RFI==
Ensure allow_url_fopen and allow_url_include are both disabled to protect against RFI But don't cause issues by using the pattern include $user_supplied_data or require "base" + $user_supplied_data - it's just unsafe as you can input /etc/passwd and PHP will try to include it

== Regexes (!)==
Watch for executable regexes (!)

== Session Rotation ==
Session rotation is very easy - just after authentication, plonk in session_regenerate_id() and you‘re done.

== Be aware of PHP filters ==
PHP filters can be tricky and complex. Be extra-conscious when using them.

== Logging ==
Set display_errors to 0, and set up logging to go to a file you control, or at least syslog. This is the most commonly neglected area of PHP configuration

== Output encoding ==
Output encoding is entirely up to you. Just do it, ESAPI for PHP is ready for this job.

These are transparent to you and you need to know about them. php://input: takes input from the console gzip: takes compressed input and might bypass input validation http://au2.php.net/manual/en/filters.php

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2014-03-17T22:26:39Z

Roy Vanegas: More minor edits: replacing inch marks and foot marks with correct apostrophes and quotes; replacing the dash with en- or em-dashes. Wrapping function names in <code> tags.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 72% of web servers deploying it.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with typical web framework features built-in to the latter. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

There are, unfortunately, serious issues in all areas that make it difficult to write secure PHP applications. These are difficult to work around if you are forced to use PHP, but you need to be aware of them.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an incorrect type into the expected type. This feature very often masks errors by the developer or injections of unexpected data, leading to vulnerabilities (see “Input handling” below for an example).

Try to use functions and operators that do not do implicit type conversions (e.g. <code>===</code> and not <code>==</code>). Not all operators have strict versions, and many built-in functions (like <code>in_array</code>) use weakly typed comparison functions, making it difficult to write correct code.

====Exceptions and error handling====

Almost all core PHP code, and many PHP libraries, do not use exceptions, but instead report errors in other ways (such as via notices) that allow the faulty code to carry on running. This has the effect of masking many bugs. In other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting] function, and never attempt to suppress error messages — always follow the warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many configuration settings, including fundamental changes to things like how errors are handled. This can make it very difficult to write code that works correctly in all circumstances. Different libraries can have different expectations or requirements about these settings, making it difficult to correctly use 3rd party code. Some are mentioned below under “Configuration.”

====Unhelpful builtins====

PHP comes with many built-in functions, such as <code>addslashes</code>, <code>mysql_escape_string</code> and
<code>mysql_real_escape_string</code>, that appear to provide security, but are often buggy and, in fact, are unhelpful ways to deal with security problems.

Some of these built-ins are being deprecated and removed, but due to backwards compatibility policies this takes a long time.

===Framework issues===

====URL routing====

PHP’s built-in URL routing mechanism is to use files ending in “.php” in the directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename are appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use <code>.htaccess</code> to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with $supplied_nonce being an array. The function <code>strcmp()</code> will then return <code>NULL</code> (instead of throwing an exception, which would be much more useful), and then, due to weak typing and the <code>==</code> operator instead of <code>===</code>, the comparison succeeds (since <code>NULL == 0</code> is true according to PHP), and the attacker will be able to reset the password without providing a correct nonce.

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

====MySQLi Prepared Statements Wrapper====
The following function, performs a SQL query, returns its results as a 2D array (if query was SELECT) and does all that with prepared statements using MySQLi fast MySQL interface:

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->num_rows) {
$out = array();
while (null != ($r = $result->fetch_array(MYSQLI_ASSOC)))
$out [] = $r;
return $out;
}
return null;
} else {
if (!$stmt = $DB->prepare($Query))
trigger_error("Unable to prepare statement: {$Query}, reason: " . $DB->error . "");
array_shift($args); //remove $Query from args
//the following three lines are the only way to copy an array values in PHP
$a = array();
foreach ($args as $k => &$v)
$a[$k] = &$v;
$types = str_repeat("s", count($args)); //all params are strings, works well on MySQL and SQLite
array_unshift($a, $types);
call_user_func_array(array($stmt, 'bind_param'), $a);
$stmt->execute();
//fetching all results in a 2D array
$metadata = $stmt->result_metadata();
$out = array();
$fields = array();
if (!$metadata)
return null;
$length = 0;
while (null != ($field = mysqli_fetch_field($metadata))) {
$fields [] = &$out [$field->name];
$length+=$field->length;
}
call_user_func_array(array(
$stmt, "bind_result"
), $fields);
$output = array();
$count = 0;
while ($stmt->fetch()) {
foreach ($out as $k => $v)
$output [$count] [$k] = $v;
$count++;
}
$stmt->free_result();
return ($count == 0) ? null : $output;
}
}

Now you could do your every query like the example below:

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT ?" , 5 , "Username" , 2);

Every instance of ? is bound with an argument of the list, not ''replaced'' with it. MySQL 5.5+ supports ? as ORDER BY and LIMIT clause specifiers. If you're using a database that doesn't support them, see next section.

'''REMEMBER:''' When you use this approach, you should ''NEVER'' concat strings for a SQL query.

====PDO Prepared Statement Wrapper====
The following function, does the same thing as the above function but using PDO. You can use it with every PDO supported driver.

try {
$DB = new PDO("{$Driver}:dbname={$DatabaseName};host={$Host};", $Username, $Password);
} catch (Exception $e) {
trigger_error("PDO connection error: " . $e->getMessage());
}

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->rowCount()) {
return $result->fetchAll(PDO::FETCH_ASSOC);
}
return null;
} else {
if (!$stmt = $DB->prepare($Query)) {
$Error = $DB->errorInfo();
trigger_error("Unable to prepare statement: {$Query}, reason: {$Error[2]}");
}
array_shift($args); //remove $Query from args
$i = 0;
foreach ($args as &$v)
$stmt->bindValue(++$i, $v);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
}

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT 5" , 5 , "Username" );

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you need to do two things:

====Not Supported Fields====
When some field does not support binding (like LIMIT clause in PDO), you need to '''whitelist''' the data you're about to use. LIMIT always requires an integer, so cast the variable to an integer. ORDER BY needs a field name, so whitelist it with field names:

function whitelist($Needle,$Haystack)
{
if (!in_array($Needle,$Haystack))
return reset($Haystack); //first element
return $Needle;
}

$Limit = $_GET['lim'];
$Limit = $Limit * 1; //type cast, integers are safe

$Order = $_GET['sort'];
$Order=whitelist($Order,Array("ID","Username","Password"));

This is very important. If you think you're tired and you rather blacklist than whitelist, you’re bound to fail.

====Dynamic Queries====
Now this is a highly delicate situation. Whenever hackers fail to injection SQL in your common application scenarios, they go for Advanced Search features or similars, because those features rely on dynamic queries and dynamic queries are almost always insecurely implemented.

When you're building a dynamic query, the only way is whitelisting. Whitelist every field name, every boolean operator (it should be OR or AND, nothing else) and after building your query, use prepared statements:

$Query="SELECT * FROM table WHERE ";
foreach ($_GET['fields'] as $g)
$Query.=whitelist($g,Array("list","of","possible","fields","here"))."=?";
$Values=$_GET['values'];
array_unshift($Query); //add to the beginning
$res=call_user_func_array(SQL, $Values);

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Access Control Cheat Sheet=
This section aims to mitigate access control issues, as well as '''Insecure Direct Object Reference''' issues.

=Cryptography Cheat Sheet=

=File Inclusion Cheat Sheet=

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

=Sources of Taint=

= OLD. PHP General Guidelines for Secure Web Applications =

== PHP Version ==
Use '''PHP 5.3.8'''. Stable versions are always safer then the beta ones.

== Framework==
Use a framework like '''Zend''' or '''Symfony'''. Try not to re-write the code again and again. Also avoid dead codes.

== Directory==
Code with most of your code outside of the webroot. This is automatic for Symfony and Zend. Stick to these frameworks.

== Hashing Extension ==
Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

== Cryptographic Extension ==
Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

== Authentication and Authorization ==
There is no authentication or authorization classes in native PHP. Use '''ZF''' or '''Symfony''' instead.

== Input nput validation ==
Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($dirty['foo']);

== Use PDO or ORM ==
Use PDO with prepared statements or an ORM like Doctrine

== Use PHP Unit and Jenkins ==
When developing PHP code, make sure you develop with PHP Unit and Jenkins - see http://qualityassuranceinphpprojects.com/pages/tools.html for more details.

== Use Stefan Esser's Hardened PHP Patch ==
Consider using Stefan Esser's Hardened PHP patch - http://www.hardened-php.net/suhosin/index.html
(not maintained now, but the concepts are very powerful)

== Avoid Global Variables==
In terms of secure coding with PHP, do not use globals unless absolutely necessary
Check your php.ini to ensure register_globals is off Do not run at all with this setting enabled It's extremely dangerous (register_globals has been disabled since 5.0 / 2006, but .... most PHP 4 code needs it, so many hosters have it turned on)

== Protection against RFI==
Ensure allow_url_fopen and allow_url_include are both disabled to protect against RFI But don't cause issues by using the pattern include $user_supplied_data or require "base" + $user_supplied_data - it's just unsafe as you can input /etc/passwd and PHP will try to include it

== Regexes (!)==
Watch for executable regexes (!)

== Session Rotation ==
Session rotation is very easy - just after authentication, plonk in session_regenerate_id() and you‘re done.

== Be aware of PHP filters ==
PHP filters can be tricky and complex. Be extra-conscious when using them.

== Logging ==
Set display_errors to 0, and set up logging to go to a file you control, or at least syslog. This is the most commonly neglected area of PHP configuration

== Output encoding ==
Output encoding is entirely up to you. Just do it, ESAPI for PHP is ready for this job.

These are transparent to you and you need to know about them. php://input: takes input from the console gzip: takes compressed input and might bypass input validation http://au2.php.net/manual/en/filters.php

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

User:Roy Vanegas

2014-03-17T18:46:12Z

Roy Vanegas:

PHP Security Cheat Sheet

2014-03-17T18:41:40Z

Roy Vanegas: Fixed a few misspelled words, some light grammar issues in the first two paragraphs, some indentation issues, and corrected one or more quotes.

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =
This page intends to provide basic PHP security tips for developers and administrators. Keep in mind that tips mentioned in this page may not be sufficient for securing your web application.

==PHP overview==

PHP is the most commonly used server-side programming language, with 72% of web servers deploying it.

An open source technology, PHP is unusual in that it is both a language ''and'' a web framework, with the latter containing the typical features of a web framework built-in. Like all web languages, there is also a large community of libraries etc. that contribute to the security (or otherwise) of programming in PHP. All three aspects (language, framework, and libraries) need to be taken into consideration when trying to secure a PHP site.

There are, unfortunately, serious issues in all areas that make it difficult to
write secure PHP applications. These are difficult to work around if you are
forced to use PHP, but you need to be aware of them.

===Language issues===

====Weak typing====

PHP is weakly typed, which means that it will automatically convert data of an
incorrect type into the expected type. This feature very often masks errors by
the developer or injections of unexpected data, leading to vulnerabilities (see
below under "Input handling" for an example).

Try to use functions and operators that do not do implicit type conversions
(e.g. === and not ==). Not all operators have strict versions, and many built-in
functions (like ‘in_array’) use weakly typed comparison functions, making it
difficult to write correct code.

====Exceptions and error handling====

Almost all core PHP code, and many PHP libraries, do not use exceptions, but
instead report errors in other ways (such as via notices) that allow the faulty
code to carry on running. This has the effect of masking many bugs. In other
languages, error conditions that are caused by developer errors will cause the
program to stop running, which is the safest thing to do.

It is often best to turn up error reporting as high as possible using the
[http://www.php.net/manual/en/function.error-reporting.php error_reporting]
function, and never attempt to suppress error messages - always follow the
warnings and write code that is more robust.

====php.ini====

The behaviour of PHP code often depends strongly on the values of many
configuration settings, including fundamental changes to things like how errors
are handled. This can make it very difficult to write code that works correctly
in all circumstances. Different libraries can have different expectations or
requirements about these settings, making it difficult to correctly use 3rd
party code. Some are mentioned below under ‘Configuration.’

====Unhelpful builtins====

PHP comes with many builtin functions like 'addslashes', 'mysql_escape_string' and
'mysql_real_escape_string' which appear to provide security, but are often buggy and,
in fact, are unhelpful ways to deal with security problems.

Some of these builtins are being deprecated and removed, but due to backwards compatibility
policies this takes a long time.

===Framework issues===

====URL routing====

PHP's built-in URL routing mechanism is to use files ending in ".php" in the
directory structure. This opens up several vulnerabilities:

* Remote execution vulnerability for every file upload feature that does not sanitise the filename. Ensure that when saving uploaded files, the content and filename is appropriately sanitised.

* Source code, including config files, are stored in publicly accessible directories along with files that are meant to be downloaded (such as static assets). Misconfiguration (or lack of configuration) can mean that source code or config files that contain secret information can be downloaded by attackers. You can use .htaccess to limit access. This is not ideal, because it is insecure by default, but there is no other alternative.

====Input handling====

Instead of treating HTTP input as simple strings, PHP will build arrays from HTTP input, at the control of the client. This can lead to confusion about data, and can easily lead to security bugs. For example, consider this simplified code from a "one time nonce" mechanism that might be used, for example in a password reset code:

$supplied_nonce = $_GET['nonce'];
$correct_nonce = get_correct_value_somehow();

if (strcmp($supplied_nonce, $correct_nonce) == 0) {
// Go ahead and reset the password
} else {
echo 'Sorry, incorrect link';
}

If an attacker uses a querystring like this:

http://example.com/?nonce[]=a

then we end up with $supplied_nonce being an array. strcmp() will then return
NULL (instead of throwing an exception, which would be much more useful), and then
due to weak typing and the '==' operator instead of '===', the
comparison succeeds (since "NULL == 0" is true according to PHP), and the
attacker will be able to reset the password without providing a correct nonce.

====Template language====

PHP is essentially a template language. However, it doesn't do HTML escaping by
default, which makes it very problematic for use in a web application - see
section on XSS below.

====Other inadequacies====

There are other important things that a web framework should supply, such as a
CSRF protection mechanism that is on by default. Because PHP comes with a
rudimentary web framework that is functional enough to allow people to create
web sites, many people will do so without any knowledge that they need CSRF
protection.

===Third party PHP code===

Libraries and projects written in PHP are often insecure due to the problems
highlighted above, especially when proper web frameworks are not used. Do not
trust PHP code that you find on the web, as many security vulnerabilities can
hide in seemingly innocent code.

Poorly written PHP code often results in warnings being emitted, which can cause
problems. A common solution is to turn off all notices, which is exactly the opposite
of what ought to be done (see above), and leads to progressively worse code.

==Update PHP Now==
'''Important Note: ''' PHP 5.2.x is officially unsupported now. This means that in the near future, when a common security flaw on PHP 5.2.x is discovered, PHP 5.2.x powered website may become vulnerable. ''It is of utmost important that you upgrade your PHP to 5.3.x or 5.4.x right now.''

Also keep in mind that you should regularly upgrade your PHP distribution on an operational server. Every day new flaws are discovered and announced in PHP and attackers use these new flaws on random servers frequently.

=Configuration=

The behaviour of PHP is strongly affected by configuration, which can be done through the "php.ini" file, Apache configuration directives and runtime mechanisms - see http://www.php.net/manual/en/configuration.php

There are many security related configuration options. Some are listed below:

==SetHandler==

PHP code should be configured to run using a 'SetHandler' directive. In many instances, it is wrongly configured using an 'AddHander' directive. This works, but also makes other files executable as PHP code - for example, a file name "foo.php.txt" will be handled as PHP code, which can be a very serious remote execution vulnerability if "foo.php.txt" was not intended to be executed (e.g. example code) or came from a malicious file upload.

=Untrusted data=
All data that is a product, or subproduct, of user input is to NOT be trusted. They have to either be validated, using the correct methodology, or filtered, before considering them untainted.

Super globals which are not to be trusted are $_SERVER, $_GET, $_POST, $_REQUEST, $_FILES and $_COOKIE. Not all data in $_SERVER can be faked by the user, but a considerable amount in it can, particularly and specially everything that deals with HTTP headers (they start with HTTP_).

==File uploads==

Files received from a user pose various security threats, especially if other users can download these files. In particular:

* Any file served as HTML can be used to do an XSS attack
* Any file treated as PHP can be used to do an extremely serious attack - a remote execution vulnerability.

Since PHP is designed to make it very easy to execute PHP code (just a file with the right extension), it is particularly important for PHP sites (any site with PHP installed and configured) to ensure that uploaded files are only saved with sanitised file names.

==Common mistakes on the processing of $_FILES array==
It is common to find code snippets online doing something similar to the following code:

if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}

However, the type is not determined by using heuristics that validate it, but by simply reading the data sent by the HTTP request, which is created by a client. A better, yet not perfect, way of validating file types is to use finfo class.

$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_name']);
$mimeType = $finfo->buffer($fileContents);

Where $mimeType is a better checked file type. This uses more resources on the server, but can prevent the user from sending a dangerous file and fooling the code into trusting it as an image, which would normally be regarded as a safe file type.

==Use of $_REQUEST==
Using $_REQUEST is strongly discouraged. This super global is not recommended since it includes not only POST and GET data, but also the cookies sent by the request. This can lead to confusion and makes your code prone to mistakes, which could lead to security problems.

=Database Cheat Sheet=
Since a single SQL Injection vulnerability permits the hacking of your website, and every hacker first tries SQL injection flaws, fixing SQL injections are the first step to securing your PHP powered application. Abide to the following rules:

==Never concatenate or interpolate data in SQL==

Never build up a string of SQL that includes user data, either by concatenation:

$sql = "SELECT * FROM users WHERE username = '" . $username . "';";

or interpolation, which is essentially the same:

$sql = "SELECT * FROM users WHERE username = '$username';";

If '$username' has come from an untrusted source (and you must assume it has, since you cannot easily see that in source code), it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended, including deleting your entire database etc.

==Escaping is not safe==
'''mysql_real_escape_string''' is not safe. Don't rely on it for your SQL injection prevention.

'''Why:'''
When you use mysql_real_escape_string on every variable and then concat it to your query, ''you are bound to forget that at least once'', and once is all it takes. You can't force yourself in any way to never forget. In addition, you have to ensure that you use quotes in the SQL as well, which is not a natural thing to do if you are assuming the data is numeric, for example. Instead use prepared statements, or equivalent APIs that always do the correct kind of SQL escaping for you. (Most ORMs will do this escaping, as well as creating the SQL for you).

==Use Prepared Statements==
Prepared statements are very secure. In a prepared statement, data is separated from the SQL command, so that everything user inputs is considered data and put into the table the way it was.

====MySQLi Prepared Statements Wrapper====
The following function, performs a SQL query, returns its results as a 2D array (if query was SELECT) and does all that with prepared statements using MySQLi fast MySQL interface:

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->num_rows) {
$out = array();
while (null != ($r = $result->fetch_array(MYSQLI_ASSOC)))
$out [] = $r;
return $out;
}
return null;
} else {
if (!$stmt = $DB->prepare($Query))
trigger_error("Unable to prepare statement: {$Query}, reason: " . $DB->error . "");
array_shift($args); //remove $Query from args
//the following three lines are the only way to copy an array values in PHP
$a = array();
foreach ($args as $k => &$v)
$a[$k] = &$v;
$types = str_repeat("s", count($args)); //all params are strings, works well on MySQL and SQLite
array_unshift($a, $types);
call_user_func_array(array($stmt, 'bind_param'), $a);
$stmt->execute();
//fetching all results in a 2D array
$metadata = $stmt->result_metadata();
$out = array();
$fields = array();
if (!$metadata)
return null;
$length = 0;
while (null != ($field = mysqli_fetch_field($metadata))) {
$fields [] = &$out [$field->name];
$length+=$field->length;
}
call_user_func_array(array(
$stmt, "bind_result"
), $fields);
$output = array();
$count = 0;
while ($stmt->fetch()) {
foreach ($out as $k => $v)
$output [$count] [$k] = $v;
$count++;
}
$stmt->free_result();
return ($count == 0) ? null : $output;
}
}

Now you could do your every query like the example below:

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT ?" , 5 , "Username" , 2);

Every instance of ? is bound with an argument of the list, not ''replaced'' with it. MySQL 5.5+ supports ? as ORDER BY and LIMIT clause specifiers. If you're using a database that doesn't support them, see next section.

'''REMEMBER:''' When you use this approach, you should ''NEVER'' concat strings for a SQL query.

====PDO Prepared Statement Wrapper====
The following function, does the same thing as the above function but using PDO. You can use it with every PDO supported driver.

try {
$DB = new PDO("{$Driver}:dbname={$DatabaseName};host={$Host};", $Username, $Password);
} catch (Exception $e) {
trigger_error("PDO connection error: " . $e->getMessage());
}

function SQL($Query) {
global $DB;
$args = func_get_args();
if (count($args) == 1) {
$result = $DB->query($Query);
if ($result->rowCount()) {
return $result->fetchAll(PDO::FETCH_ASSOC);
}
return null;
} else {
if (!$stmt = $DB->prepare($Query)) {
$Error = $DB->errorInfo();
trigger_error("Unable to prepare statement: {$Query}, reason: {$Error[2]}");
}
array_shift($args); //remove $Query from args
$i = 0;
foreach ($args as &$v)
$stmt->bindValue(++$i, $v);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_ASSOC);
}
}

$res=SQL("SELECT * FROM users WHERE ID>? ORDER BY ? ASC LIMIT 5" , 5 , "Username" );

===Where prepared statements do not work===
The problem is, when you need to build dynamic queries, or need to set variables not supported as a prepared variable, or your database engine does not support prepared statements. For example, PDO MySQL does not support ? as LIMIT specifier. In these cases, you need to do two things:

====Not Supported Fields====
When some field does not support binding (like LIMIT clause in PDO), you need to '''whitelist''' the data you're about to use. LIMIT always requires an integer, so cast the variable to an integer. ORDER BY needs a field name, so whitelist it with field names:

function whitelist($Needle,$Haystack)
{
if (!in_array($Needle,$Haystack))
return reset($Haystack); //first element
return $Needle;
}

$Limit = $_GET['lim'];
$Limit = $Limit * 1; //type cast, integers are safe

$Order = $_GET['sort'];
$Order=whitelist($Order,Array("ID","Username","Password"));

This is very important. If you think you're tired and you rather blacklist than whitelist, you’re bound to fail.

====Dynamic Queries====
Now this is a highly delicate situation. Whenever hackers fail to injection SQL in your common application scenarios, they go for Advanced Search features or similars, because those features rely on dynamic queries and dynamic queries are almost always insecurely implemented.

When you're building a dynamic query, the only way is whitelisting. Whitelist every field name, every boolean operator (it should be OR or AND, nothing else) and after building your query, use prepared statements:

$Query="SELECT * FROM table WHERE ";
foreach ($_GET['fields'] as $g)
$Query.=whitelist($g,Array("list","of","possible","fields","here"))."=?";
$Values=$_GET['values'];
array_unshift($Query); //add to the beginning
$res=call_user_func_array(SQL, $Values);

==ORM==
ORMs (Object Relational Mappers) are good security practice. If you're using an ORM (like [http://www.doctrine-project.org/ Doctrine]) in your PHP project, you're still prone to SQL attacks. Although injecting queries in ORM's is much harder, keep in mind that concatenating ORM queries makes for the same flaws that concatenating SQL queries, so '''NEVER''' concatenate strings sent to a database. ORM's support prepared statements as well.

==Encoding Issues==

===Use UTF-8 unless necessary===
Many new attack vectors rely on encoding bypassing. Use UTF-8 as your database and application charset unless you have a mandatory requirement to use another encoding.

$DB = new mysqli($Host, $Username, $Password, $DatabaseName);
if (mysqli_connect_errno())
trigger_error("Unable to connect to MySQLi database.");
$DB->set_charset('UTF-8');

=Other Injection Cheat Sheet=
SQL aside, there are a few more injections possible ''and common'' in PHP:

==Shell Injection==
A few PHP functions namely

* shell_exec
* exec
* passthru
* system
* [http://no2.php.net/manual/en/language.operators.execution.php backtick operator] ( ` )

run a string as shell scripts and commands. Input provided to these functions (specially backtick operator that is not like a function). Depending on your configuration, shell script injection can cause your application settings and configuration to leak, or your whole server to be hijacked. This is a very dangerous injection and is somehow considered the haven of an attacker.

Never pass tainted input to these functions - that is input somehow manipulated by the user - unless you're absolutely sure there's no way for it to be dangerous (which you never are without whitelisting). Escaping and any other countermeasures are ineffective, there are plenty of vectors for bypassing each and every one of them; don't believe what novice developers tell you.

==Code Injection==
All interpreted languages such as PHP, have some function that accepts a string and runs that in that language. In PHP this function is named eval().
Using eval is a very bad practice, not just for security. If you're absolutely sure you have no other way but eval, use it without any tainted input. Eval is usually also slower.

Function preg_replace() should not be used with unsanitised user input, because the payload will be [http://stackoverflow.com/a/4292439 eval()'ed].

preg_replace("/.*/e","system('echo /etc/passwd')");

Reflection also could have code injection flaws. Refer to the appropriate reflection documentations, since it is an advanced topic.

==Other Injections==
LDAP, XPath and any other third party application that runs a string, is vulnerable to injection. Always keep in mind that some strings are not data, but commands and thus should be secure before passing to third party libraries.

=XSS Cheat Sheet=

There are two scenarios when it comes to XSS, each one to be mitigated accordingly:

== No Tags ==

Most of the time, there is no need for user supplied data to contain unescaped HTML tags when output. For example when you're about to dump a textbox value, or output user data in a cell.

If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). '''However, this is not recommended'''. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.

Instead of this, you should use a template engine that applies HTML escaping '''by default''' - see below. All HTML should be passed out through the template engine.

If you cannot switch to a secure template engine, you can use the function below on all untrusted data.

'''Keep in mind that this scenario won't mitigate XSS when you use user input in dangerous elements (style, script, image's src, a, etc.)''', but mostly you don't. Also keep in mind that every output that is not intended to contain HTML tags should be sent to the browser filtered with the following function.

//xss mitigation functions
function xssafe($data,$encoding='UTF-8')
{
return htmlspecialchars($data,ENT_QUOTES | ENT_HTML401,$encoding);
}
function xecho($data)
{
echo xssafe($data);
}

//usage example
<input type='text' name='test' value='<?php
xecho ("' onclick='alert(1)");
?>' />

==Untrusted Tags==
When you need to allow users to supply HTML tags that are used in your output, such as rich blog comments, forum posts, blog posts and etc., but cannot trust the user, you have to use a '''Secure Encoding''' library. This is usually hard and slow, and that's why most applications have XSS vulnerabilities in them. OWASP ESAPI has a bunch of codecs for encoding different sections of data. There's also OWASP AntiSammy and HTMLPurifier for PHP. Each of these require lots of configuration and learning to perform well, but you need them when you want that good of an application.

==Templating engines==

There are several templating engines that can help the programmer (and designer) to output data and protect from most XSS vulnerabilities. While their primary goal isn't security, but improving the designing experience, most important templating engines automatically escape the variables on output and force the developer to explicitly indicate if there is a variable that shouldn't be escaped. This makes output of variables have a white-list behavior. There exist several of these engines. A good example is twig[http://twig.sensiolabs.org/]. Other popular template engines are Smarty, Haanga and Rain TPL.

Templating engines that follow a white-list approach to escaping are essential for properly dealing with XSS, because if you are manually applying escaping, it is too easy to forget, and developers should always use systems that are secure by default if they take security seriously.

==Other Tips==

* Don't have a '''trusted section''' in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Every output should be cleared by the functions provided above, if it has a variable in it. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.

* HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)

* The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.

* [[Reflected XSS]] is as dangerous as normal XSS, and usually comes at the most dusty corners of an application. Seek it and mitigate it.

=CSRF Cheat Sheet=
CSRF mitigation is easy in theory, but hard to implement correctly. First, a few tips about CSRF:

* Every request that does something noteworthy, should be CSRF mitigated. Noteworthy things are changes to the system, and reads that take a long time.
* CSRF mostly happens on GET, but is easy to happen on POST. Don't ever think that post is secure.

The [[PHP_CSRF_Guard|OWASP PHP CSRFGuard]] is a code snippet that shows how to mitigate CSRF. Only copy pasting it is not enough. In the near future, a copy-pasteable version would be available (hopefully). For now, mix that with the following tips:

* Use re-authentication for critical operations (change password, recovery email, etc.)
* If you're not sure whether your operation is CSRF proof, consider adding CAPTCHAs (however CAPTCHAs are inconvenience for users)
* If you're performing operations based on other parts of a request (neither GET nor POST) e.g Cookies or HTTP Headers, you might need to add CSRF tokens there as well.
* AJAX powered forms need to re-create their CSRF tokens. Use the function provided above (in code snippet) for that and never rely on Javascript.
* CSRF on GET or Cookies will lead to inconvenience, consider your design and architecture for best practices.

=Authentication and Session Management Cheat Sheet=
PHP doesn't ship with a readily available authentication module, you need to implement your own or use a PHP framework, unfortunately most PHP frameworks are far from perfect in this manner, due to the fact that they are developed by open source developer community rather than security experts. A few instructive and useful tips are listed below:

==Session Management==
PHP's default session facilities are considered safe, the generated PHPSessionID is random enough, but the storage is not necessarily safe:

* Session files are stored in temp (/tmp) folder and are world writable unless suPHP installed, so any LFI or other leak might end-up manipulating them.
* Sessions are stored in files in default configuration, which is terribly slow for highly visited websites. You can store them on a memory folder (if UNIX).
* You can implement your own session mechanism, without ever relying on PHP for it. If you did that, store session data in a database. You could use all, some or none of the PHP functionality for session handling if you go with that.

===Session Hijacking Prevention===
It is good practice to bind sessions to IP addresses, that would prevent most session hijacking scenarios (but not all), however some users might use anonymity tools (such as TOR) and they would have problems with your service.

To implement this, simply store the client IP in the session first time it is created, and enforce it to be the same afterwards. The code snippet below returns client IP address:

$IP = getenv ( "REMOTE_ADDR" );

Keep in mind that in local environments, a valid IP is not returned, and usually the string ''':::1''' or ''':::127''' might pop up, thus adapt your IP checking logic. Also beware of versions of this code which make use of the HTTP_X_FORWARDED_FOR variable as this data is effectively user input and therefore susceptible to spoofing (more information [http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/ here] and [http://security.stackexchange.com/a/34327/37 here] )

===Invalidate Session ID===
You should invalidate (unset cookie, unset session storage, remove traces) of a session whenever a violation occurs (e.g 2 IP addresses are observed). A log event would prove useful. Many applications also notify the logged in user (e.g GMail).

===Rolling of Session ID===
You should roll session ID whenever elevation occurs, e.g when a user logs in, the session ID of the session should be changed, since it's importance is changed.

===Exposed Session ID===
Session IDs are considered confidential, your application should not expose them anywhere (specially when bound to a logged in user). Try not to use URLs as session ID medium.

Transfer session ID over TLS whenever session holds confidential information, otherwise a passive attacker would be able to perform session hijacking.

===Session Fixation===
Invalidate the Session id after user login (or even after each request) with [http://www.php.net/session_regenerate_id session_regenerate_id()].

===Session Expiration===
A session should expire after a certain amount of inactivity, and after a certain time of activity as well. The expiration process means invalidating and removing a session, and creating a new one when another request is met.

Also keep the '''log out''' button close, and unset all traces of the session on log out.

====Inactivity Timeout====
Expire a session if current request is X seconds later than the last request. For this you should update session data with time of the request each time a request is made. The common practice time is 30 minutes, but highly depends on application criteria.

This expiration helps when a user is logged in on a publicly accessible machine, but forgets to log out. It also helps with session hijacking.

====General Timeout====
Expire a session if current session has been active for a certain amount of time, even if active. This helps keeping track of things. The amount differs but something between a day and a week is usually good. To implement this you need to store start time of a session.

===Cookies===
Handling cookies in a PHP script has some tricks to it:

====Never Serialize====
Never serialize data stored in a cookie. It can easily be manipulated, resulting in adding variables to your scope.

====Proper Deletion====
To delete a cookie safely, use the following snippet:

setcookie ($name, "", 1);
setcookie ($name, false);
unset($_COOKIE[$name]);
The first line ensures that cookie expires in browser, the second line is the standard way of removing a cookie (thus you can't store false in a cookie). The third line removes the cookie from your script. Many guides tell developers to use time() - 3600 for expiry, but it might not work if browser time is not correct.

You can also use '''session_name()''' to retrieve the name default PHP session cookie.

====HTTP Only====
Most modern browsers support HTTP-only cookies. These cookies are only accessible via HTTP(s) requests and not JavaScript, so XSS snippets can not access them. They are very good practice, but are not satisfactory since there are many flaws discovered in major browsers that lead to exposure of HTTP only cookies to JavaScript.

To use HTTP-only cookies in PHP (5.2+), you should perform session cookie setting [http://php.net/manual/en/function.setcookie.php manually] (not using '''session_start'''):

#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

#usage
if (!setcookie("MySessionID", $secureRandomSessionID, $generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("could not set HTTP-only cookie");

The '''path''' parameter sets the path which cookie is valid for, e.g if you have your website at example.com/some/folder the path should be /some/folder or other applications residing at example.com could also see your cookie. If you're on a whole domain, don't mind it. '''Domain''' parameter enforces the domain, if you're accessible on multiple domains or IPs ignore this, otherwise set it accordingly. If '''secure''' parameter is set, cookie can only be transmitted over HTTPS. See the example below:

$r=setcookie("SECSESSID","1203j01j0s1209jw0s21jxd01h029y779g724jahsa9opk123973",time()+60*60*24*7 /*a week*/,"/","owasp.org",true,true);
if (!$r) die("Could not set session cookie.");

====Internet Explorer issues====
Many version of Internet Explorer tend to have problems with cookies. Mostly setting Expire time to 0 fixes their issues.

==Authentication==

===Remember Me===
Many websites are vulnerable on remember me features. The correct practice is to generate a one-time token for a user and store it in the cookie. The token should also reside in data store of the application to be validated and assigned to user. This token should have '''no relevance''' to username and/or password of the user, a secure long-enough random number is a good practice.

It is better if you imply locking and prevent brute-force on remember me tokens, and make them long enough, otherwise an attacker could brute-force remember me tokens until he gets access to a logged in user without credentials.

* '''Never store username/password or any relevant information in the cookie.'''

=Access Control Cheat Sheet=
This section aims to mitigate access control issues, as well as '''Insecure Direct Object Reference''' issues.

=Cryptography Cheat Sheet=

=File Inclusion Cheat Sheet=

=Configuration and Deployment Cheat Sheet=
Please see [[PHP Configuration Cheat Sheet]].

=Sources of Taint=

= OLD. PHP General Guidelines for Secure Web Applications =

== PHP Version ==
Use '''PHP 5.3.8'''. Stable versions are always safer then the beta ones.

== Framework==
Use a framework like '''Zend''' or '''Symfony'''. Try not to re-write the code again and again. Also avoid dead codes.

== Directory==
Code with most of your code outside of the webroot. This is automatic for Symfony and Zend. Stick to these frameworks.

== Hashing Extension ==
Not every PHP installation has a working '''mhash''' extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256

== Cryptographic Extension ==
Not every PHP installation has a working '''mcrypt''' extension, and without it you can't do AES. Do check if you need it.

== Authentication and Authorization ==
There is no authentication or authorization classes in native PHP. Use '''ZF''' or '''Symfony''' instead.

== Input nput validation ==
Use $_dirty['foo'] = $_GET['foo'] and then $foo = validate_foo($dirty['foo']);

== Use PDO or ORM ==
Use PDO with prepared statements or an ORM like Doctrine

== Use PHP Unit and Jenkins ==
When developing PHP code, make sure you develop with PHP Unit and Jenkins - see http://qualityassuranceinphpprojects.com/pages/tools.html for more details.

== Use Stefan Esser's Hardened PHP Patch ==
Consider using Stefan Esser's Hardened PHP patch - http://www.hardened-php.net/suhosin/index.html
(not maintained now, but the concepts are very powerful)

== Avoid Global Variables==
In terms of secure coding with PHP, do not use globals unless absolutely necessary
Check your php.ini to ensure register_globals is off Do not run at all with this setting enabled It's extremely dangerous (register_globals has been disabled since 5.0 / 2006, but .... most PHP 4 code needs it, so many hosters have it turned on)

== Protection against RFI==
Ensure allow_url_fopen and allow_url_include are both disabled to protect against RFI But don't cause issues by using the pattern include $user_supplied_data or require "base" + $user_supplied_data - it's just unsafe as you can input /etc/passwd and PHP will try to include it

== Regexes (!)==
Watch for executable regexes (!)

== Session Rotation ==
Session rotation is very easy - just after authentication, plonk in session_regenerate_id() and you‘re done.

== Be aware of PHP filters ==
PHP filters can be tricky and complex. Be extra-conscious when using them.

== Logging ==
Set display_errors to 0, and set up logging to go to a file you control, or at least syslog. This is the most commonly neglected area of PHP configuration

== Output encoding ==
Output encoding is entirely up to you. Just do it, ESAPI for PHP is ready for this job.

These are transparent to you and you need to know about them. php://input: takes input from the console gzip: takes compressed input and might bypass input validation http://au2.php.net/manual/en/filters.php

= Authors and Primary Editors =

[[User:Abbas Naderi|Abbas Naderi Afooshteh]] ([mailto:abbas.naderi@owasp.org abbas.naderi@owasp.org])

[[User:Achim|Achim]] - [mailto:achim_at_owasp.org Achim at owasp.org]

[mailto:vanderaj@owasp.org Andrew van der Stock]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]