OWASP - User contributions [en]

PHP Security Cheat Sheet

2014-12-03T14:36:53Z

Boy Baukema: Removed some more insulting opinionated statements on use of native database drivers in favor of helpful advice on using PDO.

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

==PHP overview==

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

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

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

===Language issues===

====Weak typing====

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

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

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

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

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

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

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

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

// Code for feature here

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

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

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

====php.ini====

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

====Unhelpful builtins====

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

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

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

===Framework issues===

====URL routing====

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

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

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

====Input handling====

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

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

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

If an attacker uses a querystring like this:

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

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

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

====Template language====

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

====Other inadequacies====

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

===Third party PHP code===

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

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

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

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

=Configuration=

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

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

==SetHandler==

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

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

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

==File uploads==

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

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

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

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

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

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

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

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

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

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

==Never concatenate or interpolate data in SQL==

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

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

or interpolation, which is essentially the same:

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

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

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

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

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

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

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

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

==Encoding Issues==

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

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

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

==Shell Injection==
A few PHP functions namely

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

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

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

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

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

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

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

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

=XSS Cheat Sheet=

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

== No Tags ==

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

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

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

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

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

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

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

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

==Templating engines==

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

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

==Other Tips==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$IP = getenv ( "REMOTE_ADDR" );

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

==Authentication==

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

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

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

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

= Authors and Primary Editors =

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

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

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

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

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

PHP Security Cheat Sheet

2014-12-03T14:14:11Z

Boy Baukema: Rephrased insulting statement hindering adoption that developers would not use PHP unless forced.

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

==PHP overview==

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

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

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

===Language issues===

====Weak typing====

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

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

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

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

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

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

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

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

// Code for feature here

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

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

Category:OWASP Application Security Verification Standard Project

2014-10-22T14:50:14Z

Boy Baukema: /* Downloads */ Use Media links instead of hardcoded links that may change in the future.

= Home =

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|2400x160px|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls.

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leaders ==

Sahba Kazerooni<br/>
Daniel Cuthbert

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten]
*[http://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide]

== Ohloh ==

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

[https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf Download] the standard in English.

== News and Events ==
* [11 Aug 2014] Version 2.0 released!
* [28 Mar 2014] List of contributors added
* [27 Mar 2014] New wiki template!

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.pdf|download PDF - 1.6 MB]])
* ASVS 2.0 in English ([[Media:OWASP_ASVS_Version_2.docx|download Word - 1.0MB]])

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Contributed'''
* Simple English Excel Reporting ([[Media:Asvs_v2_items.xlsx|download Excel - 50KB]])
* Simple French Excel Reporting ([[Media:Asvs_v2_items_fr.xlsx|download Excel - 35KB]])

= Acknowledgements =

== Volunteers ==

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]

The ASVS project is always on the lookout for volunteers who are interested in translating ASVS into another language.

[http://owasp-project-management.googlecode.com/svn/trunk/documentation/asvs-translating.pdf Translation Onboarding Instructions]

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 2.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]

Category:OWASP Application Security Verification Standard Project

2014-10-22T14:48:48Z

Boy Baukema: /* Downloads */

= Home =

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|2400x160px|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls.

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leaders ==

Sahba Kazerooni<br/>
Daniel Cuthbert

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten]
*[http://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide]

== Ohloh ==

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

[https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf Download] the standard in English.

== News and Events ==
* [11 Aug 2014] Version 2.0 released!
* [28 Mar 2014] List of contributors added
* [27 Mar 2014] New wiki template!

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf download PDF - 1.6 MB])
* ASVS 2.0 in English ([https://www.owasp.org/images/a/a9/OWASP_ASVS_Version_2.docx download Word - 1.0MB])

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Contributed'''
* Simple English Excel Reporting ([[Media:Asvs_v2_items.xlsx|download Excel - 50KB]])
* Simple French Excel Reporting ([[Media:Asvs_v2_items_fr.xlsx|download Excel - 35KB]])

= Acknowledgements =

== Volunteers ==

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]

The ASVS project is always on the lookout for volunteers who are interested in translating ASVS into another language.

[http://owasp-project-management.googlecode.com/svn/trunk/documentation/asvs-translating.pdf Translation Onboarding Instructions]

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 2.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]

Category:OWASP Application Security Verification Standard Project

2014-10-22T14:42:00Z

Boy Baukema: /* Downloads */

= Home =

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|2400x160px|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

The primary aim of the '''OWASP Application Security Verification Standard (ASVS) Project''' is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:

*'''Use as a metric''' - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
*'''Use as guidance''' - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
*'''Use during procurement''' - Provide a basis for specifying application security verification requirements in contracts.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is ASVS? ==

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls.

== Email List ==

[[Image:Asvs-bulb.jpg]] [https://lists.owasp.org/mailman/listinfo/owasp-application-security-verification-standard Project Email List]

== Project Leaders ==

Sahba Kazerooni<br/>
Daniel Cuthbert

== Related Projects ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten]
*[http://www.owasp.org/index.php/Category:OWASP_Guide_Project OWASP Development Guide]

== Ohloh ==

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

[https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf Download] the standard in English.

== News and Events ==
* [11 Aug 2014] Version 2.0 released!
* [28 Mar 2014] List of contributors added
* [27 Mar 2014] New wiki template!

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

= Downloads =

'''Application Security Verification Standard 2.0 (final)'''

* ASVS 2.0 in English ([https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf download PDF - 1.6 MB])
* ASVS 2.0 in English ([https://www.owasp.org/images/a/a9/OWASP_ASVS_Version_2.docx download Word - 1.0MB])

We are looking for translators for this version. If you can help us, please contact the project mail list!

'''Contributed'''
* Simple English Excel Reporting ([File:Asvs_v2_items.xlsx download Excel - 50KB])
* Simple French Excel Reporting ([File:Asvs_v2_items_fr.xlsx download Excel - 35KB])

= Acknowledgements =

== Volunteers ==

=== Version 2 (2014) ===

Project leaders
*Sahba Kazerooni
*Daniel Cuthbert

Lead authors
*Andrew van der Stock
*Sahba Kazerooni
*Daniel Cuthbert
*Krishna Raja

Other reviewers and contributors
*Jerome Athias
*Boy Baukema
*Archangel Cuison
*Sebastien.Deleersnyder
*Antonio Fontes
*Evan Gaustad
*Safuat Hamdy
*Ari Kesäniemi
*Scott Luc
*Jim Manico
*Mait Peekma
*Pekka Sillanpää
*Jeff Sergeant
*Etienne Stalmans
*Colin Watson

=== Version 2009 ===

Project leader
*Mike Boberski

Lead authors
*Mike Boberski
*Jeff Williams
*Dave Wichers

Other reviewers and contributors

Pierre Parrend (OWASP Summer of Code), Andrew van der Stock, Nam Nguyen, John Martin, Gaurang Shah, Theodore Winograd, Stan Wisseman, Barry Boyd, Steve Coyle, Paul Douthit, Ken Huang, Dave Hausladen, Mandeep Khera Scott Matsumoto, John Steven, Stephen de Vries, Dan Cornell, Shouvik Bardhan, Dr. Sarbari Gupta, Eoin Keary, Richard Campbell, Matt Presson, Jeff LoSapio, Liz Fong, George Lawless, Dave van Stein, Terrie Diaz, Ketan Dilipkumar Vyas, Bedirhan Urgun, Dr. Thomas Braun, Colin Watson, Jeremiah Grossman.

== OWASP Summer of Code 2008 ==

The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.

= Glossary =

[[Image:Asvs-letters.jpg]]'''ASVS Terminology'''

*'''Access Control''' – A means of restricting access to files, referenced functions, URLs, and data based on the identity of users and/or groups to which they belong.
*'''Application Component''' – An individual or group of source files, libraries, and/or executables, as defined by the verifier for a particular application.
*'''Application Security''' – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks.
*'''Application Security Verification''' – The technical assessment of an application against the OWASP ASVS.
*'''Application Security Verification Report''' – A report that documents the overall results and supporting analysis produced by the verifier for a particular application.
*'''Application Security Verification Standard (ASVS)''' – An OWASP standard that defines four levels of application security verification for applications.
*'''Authentication''' – The verification of the claimed identity of an application user.
*'''Automated Verification''' – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems.
*'''Back Doors''' – A type of malicious code that allows unauthorized access to an application.
*'''Blacklist''' – A list of data or operations that are not permitted, for example a list of characters that are not allowed as input.
*'''Common Criteria (CC)''' – A multipart standard that can be used as the basis for the verification of the design and implementation of security controls in IT products.
*'''Communication Security''' – The protection of application data when it is transmitted between application components, between clients and servers, and between external systems and the application.
*'''Design Verification''' – The technical assessment of the security architecture of an application.
*'''Internal Verification''' – The technical assessment of specific aspects of the security architecture of an application as defined in the OWASP ASVS.
*'''Cryptographic module''' – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys.
*'''Denial of Service (DOS) Attacks''' – The flooding of an application with more requests than it can handle.
*'''Dynamic Verification''' – The use of automated tools that use vulnerability signatures to find problems during the execution of an application.
*'''Easter Eggs''' – A type of malicious code that does not run until a specific user input event occurs.
*'''External Systems''' – A server-side application or service that is not part of the application.
*'''FIPS 140-2''' – A standard that can be used as the basis for the verification of the design and implementation of cryptographic modules
*'''Input Validation''' – The canonicalization and validation of untrusted user input.
*'''Malicious Code''' – Code introduced into an application during its development unbeknownst to the application owner which circumvents the application’s intended security policy. Not the same as malware such as a virus or worm!
*'''Malware''' – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator.
*'''Open Web Application Security Project (OWASP)''' – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: http://www.owasp.org/
*'''Output Validation''' – The canonicalization and validation of application output to Web browsers and to external systems.
*'''OWASP Enterprise Security API (ESAPI)''' – A free and open collection of all the security methods that developers need to build secure Web applications. See: http://www.owasp.org/index.php/ESAPI
*'''OWASP Risk Rating Methodology''' – A risk rating methodology that has been customized for application security. See: http://www.owasp.org/index.php/How_to_value_the_real_risk
*'''OWASP Testing Guide''' – A document designed to help organizations understand what comprises a testing program, and to help them identify the steps needed to build and operate that testing program. See: http://www.owasp.org/index.php/Category:OWASP_Testing_Project
*'''OWASP Top Ten''' – A document that represents a broad consensus about what the most critical Web application security flaws are. See: http://www.owasp.org/index.php/Top10
*'''Positive''' – See whitelist.
*'''Salami Attack''' – A type of malicious code that is used to redirect small amounts of money without detection in financial transactions.
*'''Security Architecture''' – An abstraction of an application’s design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data.
*'''Security Control''' – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record).
*'''Security Configuration''' – The runtime configuration of an application that affects how security controls are used.
*'''Static Verification''' – The use of automated tools that use vulnerability signatures to find problems in application source code.
*'''Target of Verification (TOV)''' – If you are performing an application security verification according to the OWASP ASVS requirements, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV.
*'''Threat Modeling''' - A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets.
*'''Time Bomb''' – A type of malicious code that does not run until a preconfigured time or date elapses.
*'''Verifier''' - The person or team that is reviewing an application against the OWASP ASVS requirements.
*'''Whitelist''' – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation.

= ASVS Users =
[[Image:Asvs-handshake.JPG]]

A broad range of companies and agencies around the globe have added ASVS to their software assurance tool boxes, including [http://www.aspectsecurity.com Aspect Security], [http://www.astyran.com Astyran], [http://www.boozallen.com Booz Allen Hamilton], [http://casabasecurity.com Casaba Security], [http://www.cgi.com/web/en/industries/governments/us_federal/services_solutions.htm CGI Federal], [http://denimgroup.com Denim Group], [http://etebaran.com Etebaran Informatics], [http://www.mindedsecurity.com Minded Security], [http://www.nixu.com Nixu], [http://www.pstestware.com/ ps_testware], [http://www.proactiverisk.com Proactive Risk], [http://quince.co.uk Quince Associates Limited (SeeMyData)], [http://www.serpro.gov.br/ Serviço Federal de Processamento de Dados (SERPRO)], [http://www.udistrital.edu.co/ Universidad Distrital Francisco José de Caldas] Organizations listed are not accredited by OWASP. Neither their products or services have been endorsed by OWASP. Use of ASVS may include for example providing verification services using the standard. Use of ASVS may also include for example performing internal evaluation of products with the OWASP ASVS in mind, and NOT making any claims of meeting any given level in the standard. Please let us know how your organization is using OWASP ASVS. Include your name, organization's name, and brief description of how you use the standard. The project lead can be reached [mailto:sahba@securitycompass.com here].

= Precedents-Interpretations =

'''PI-0001: Are there levels between the levels?'''

*Issue: Are there levels between the levels for the cases where "The specification for an application may require OWASP ASVS Level N, but it could also include other additional detailed requirements such as from a higher ASVS level"?
*Resolution: No. Use of alternate level definitions or notations such as "ASVS Level 1B+" is discouraged.
*References: ASVS section "Application Security Verification Levels"

'''PI-0002: Is use of a master key simply another level of indirection?'''

*Issue: If a master key is stored as plaintext, isn't using a master key simply another level of indirection?
*Resolution: No. There is a strong rationale for having a "master key" stored in a secure location that is used to encrypt all other secrets. In many applications, there are lots of secrets stored in many different locations. This greatly increases the likelihood that one of them will be compromised. Having a single master key makes managing the protection considerably simpler and is not simply a level of indirection.
*References: ASVS verification requirement V2.14

'''PI-0003: What is a "TOV" or "Target of Verification"?'''

*Issue: New terminology
*Resolution: If you are performing an application security verification according to ASVS, the verification will be of a particular application. This application is called the "Target of Verification" or simply the TOV. The TOV should be identified in verification documentation as follows:
**TOV Identification – <name and version of the application> or <Application name>, <application version>, dynamic testing was performed in a staging environment, not the production environment
**TOV Developer – <insert name of the developer or verification customer>
*References: ASVS section "Approach"

= Internationalization =

[[Image:Asvs-writing.JPG]]

The ASVS project is always on the lookout for volunteers who are interested in translating ASVS into another language.

[http://owasp-project-management.googlecode.com/svn/trunk/documentation/asvs-translating.pdf Translation Onboarding Instructions]

= Archive - Previous Version =

'''*Please note that ASVS is currently on version 2.0. The information on this page is for archival purposes only.*'''

[[Image:Asvs-step1.jpg]]'1. About ASVS 1.0'

*Video presentation in English [https://www.youtube.com/watch?v=Ba6ncpIfaJA (YouTube)]
*ASVS vs. WASC et al [http://www.owasp.org/index.php/ASVS_vs_WASC_Et_Al (Wiki)]

[[Image:Asvs-step2.jpg]]'2. Get ASVS 1.0'

*ASVS in Bahasa Indonesia (Indonesian language) ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-id.pdf PDF])
*ASVS in Bahasa Malaysia (Malay) (Currently under development!)
*ASVS in Chinese(Currently under development!)
*ASVS in English ([http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf PDF], [http://www.owasp.org/images/3/35/OWASP_ASVS_2009_Web_App_Std_Release.doc Word], [http://code.google.com/p/owasp-asvs/wiki/ASVS '''Online'''], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-xml.zip XML])
*ASVS in French ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-fr.odt OpenOffice])
*ASVS in German ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])
*ASVS in Hungarian (Currently under development!)
*ASVS in Japanese ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-jp.doc Word])
*ASVS in Persian (Farsi) ([http://abiusx.com/archive/document/OWASP-ASVS-fa-20111115.pdf PDF]) beta 0.7
*ASVS in Polish ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pl.pdf PDF])
*ASVS in Portuguese-Brazil ([http://owasp-asvs.googlecode.com/files/asvs-webapp-release-2009-pt-br.pdf PDF])
*ASVS in Spanish (Currently under development!)
*ASVS in Thai (Currently under development!)

[[Image:Asvs-step3.jpg]]'3. Learn ASVS 1.0'

*ASVS Article: Getting Started Using ASVS ([http://www.owasp.org/images/f/f8/OWASP_ASVS_Article_-_Getting_Started_Using_ASVS.pdf PDF])
*ASVS Article: Code Reviews and Other Verification Activities: USELESS Unless Acted Upon IMMEDIATELY [http://www.owasp.org/index.php/Code_Reviews_and_Other_Verification_Activities:_USELESS_Unless_Acted_Upon_IMMEDIATELY (Wiki)]
*ASVS Article: Agile Software Development: Don't Forget EVIL User Stories ([http://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories Wiki])
*ASVS Article: Man vs. Code ([http://www.owasp.org/index.php/Man_vs._Code Wiki])
*ASVS Article: Getting started designing for a level of assurance ([http://www.owasp.org/images/0/01/Getting_started_designing_for_a_level_of_assurance.pdf PDF])
*ASVS Template: Sample verification fee schedule template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])
*ASVS Template: Sample verification report template ([http://www.owasp.org/index.php/Image:Sample_ASVS_Report_Template.doc Word])
*ASVS Training: An ASVS training presentation ([http://www.owasp.org/index.php/Image:OWASP_AU_Secure_Architecture_and_Coding.ppt PowerPoint])
*ASVS Presentation: Executive-Level Presentation ([http://www.owasp.org/images/9/99/About_OWASP_ASVS_Executive_Presentation.ppt PowerPoint])
*ASVS Presentation: Presentation Abstract ([http://www.owasp.org/images/1/10/OWASP_ASVS_Presentation_Abstract.doc Word])
*Articles [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#Articles_Below_-_More_About_ASVS_and_Using_It (More About ASVS and Using It)]

__NOTOC__ <headertabs />

[[Category:OWASP_Project|Application Security Verification Standard Project]]
[[Category:OWASP_Document]]
[[Category:OWASP_Download]]
[[Category:OWASP_Release_Quality_Document|OWASP Stable Quality Document]]

File:Asvs v2 items fr.xlsx

2014-10-22T14:41:48Z

Boy Baukema: Simple French Excel reporting template. With the following columns: * ASVS Item # * Requirement * Level 1 * Level 2 * Level 3 * Test Complete? * Result

Simple French Excel reporting template.
With the following columns:
* ASVS Item #
* Requirement
* Level 1
* Level 2
* Level 3
* Test Complete?
* Result

File:Asvs v2 items.xlsx

2014-10-22T14:38:57Z

Boy Baukema: Simple English Excel reporting template. With the following columns: * ASVS Item # * Requirement * Level 1 * Level 2 * Level 3 * Test Complete? * Result

Simple English Excel reporting template. With the following columns:
* ASVS Item #
* Requirement
* Level 1
* Level 2
* Level 3
* Test Complete?
* Result

OWASP Risk Rating Methodology

2014-02-05T13:22:47Z

Boy Baukema: Fixed values for the skill levels (low skills is higher risk)

{{Template:OWASP Testing Guide v4}}

==The OWASP Risk Rating Methodology==

Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using [[threat modeling]]. Later, you may find security issues using [[code review]] or [[penetration testing]]. Or you may not discover a problem until the application is in production and is actually compromised.

By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that you don't get distracted by minor risks while ignoring more serious risks that are less well understood.

Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organizations. But a vulnerability that is critical to one organization may not be very important to another. So a basic framework is presented here that you ''should customize'' for your organization.

The authors have tried hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on customization for more information about tailoring the model for use in your organization.

==Approach==

There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security.

Let's start with the standard risk model:

'''Risk = Likelihood * Impact'''

In the sections below, we break down the factors that make up "likelihood" and "impact" for application security and show how to combine them to determine the overall severity for the risk.

* [[#Step 1: Identifying a Risk]]
* [[#Step 2: Factors for Estimating Likelihood]]
* [[#Step 3: Factors for Estimating Impact]]
* [[#Step 4: Determining Severity of the Risk]]
* [[#Step 5: Deciding What to Fix]]
* [[#Step 6: Customizing Your Risk Rating Model]]

==Step 1: Identifying a Risk==

The first step is to identify a security risk that needs to be rated. You'll need to gather information about the [[threat agent]] involved, the [[attack]] they're using, the [[vulnerability]] involved, and the [[impact]] of a successful exploit on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution by using the worst-case option, as that will result in the highest overall risk.

==Step 2: Factors for Estimating Likelihood==

Once you've identified a potential risk, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient.

There are a number of factors that can help us figure this out. The first set of factors are related to the [[threat agent]] involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors.

Note that each factor has a set of options, and each option has a likelihood rating from 0 to 9 associated with it. We'll use these numbers later to estimate the overall likelihood.

===[[Threat Agent]] Factors===

The first set of factors are related to the [[threat agent]] involved. The goal here is to estimate the likelihood of a successful attack by this group of threat agents. Use the worst-case threat agent.

; Skill level
: How technically skilled is this group of threat agents? Security penetration skills (1), network and programming skills (4), advanced computer user (6), some technical skills (7), no technical skills (9)

; Motive
: How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9)

; Opportunity
: What resources and opportunity are required for this group of threat agents to find and exploit this vulnerability? full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)

; Size
: How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)

===[[Vulnerability]] Factors===

The next set of factors are related to the [[vulnerability]] involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.

; Ease of discovery
: How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9)

; Ease of exploit
: How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)

; Awareness
: How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9)

; Intrusion detection
: How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)

==Step 3: Factors for Estimating Impact==

When considering the impact of a successful attack, it's important to realize that there are two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other is the "business impact" on the business and company operating the application.

Ultimately, the business impact is more important. However, you may not have access to all the information required to figure out the business consequences of a successful exploit. In this case, providing as much detail about the technical risk will enable the appropriate business representative to make a decision about the business risk.

Again, each factor has a set of options, and each option has an impact rating from 0 to 9 associated with it. We'll use these numbers later to estimate the overall impact.

===Technical Impact Factors===

Technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.

; Loss of confidentiality
: How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)

; Loss of integrity
: How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)

; Loss of availability
: How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)

; Loss of accountability
: Are the threat agents' actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9)

===Business Impact Factors===

The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems.

Many companies have an asset classification guide and/or a business impact reference to help formalize what is important to their business. These standards can help you focus on what's truly important for security. If these aren't available, then talk with people who understand the business to get their take on what's important.

The factors below are common areas for many businesses, but this area is even more unique to a company than the factors related to threat agent, vulnerability, and technical impact.

; Financial damage
: How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)

; Reputation damage
: Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)

; Non-compliance
: How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7)

; Privacy violation
: How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)

==Step 4: Determining the Severity of the Risk==

In this step we're going to put together the likelihood estimate and the impact estimate to calculate an overall severity for this risk. All you need to do here is figure out whether the likelihood is LOW, MEDIUM, or HIGH and then do the same for impact. We'll just split our 0 to 9 scale into three parts.

<table border="1" width="40%" align="center">
<tr>
<td align="center" colspan="2"><b>Likelihood and Impact Levels</b></td>
</tr>
<tr>
<td align="center" width="50%">0 to <3</td>
<td align="center" width="50%" bgcolor="lightgreen">LOW</td>
</tr>
<tr>
<td align="center">3 to <6</td>
<td align="center" bgcolor="yellow">MEDIUM</td>
</tr>
<tr>
<td align="center">6 to 9</td>
<td align="center" bgcolor="red">HIGH</td>
</tr>
</table>

===Informal Method===

In many environments, there is nothing wrong with "eyeballing" the factors and simply capturing the answers. You should think through the factors and identify the key "driving" factors that are controlling the result. You may discover that your initial impression was wrong by considering aspects of the risk that weren't obvious.

===Repeatable Method===

If you need to defend your ratings or make them repeatable, then you may want to go through a more formal process of rating the factors and calculating the result. Remember that there is quite a lot of uncertainty in these estimates, and that these factors are intended to help you arrive at a sensible result. This process can be supported by automated tools to make the calculation easier.

The first step is to select one of the options associated with each factor and enter the associated number in the table. Then you simply take the average of the scores to calculate the overall likelihood. For example:

<table border="1" align="center">
<tr>
<td colspan="4" align="center"><b>Threat agent factors</b></td>
<td></td>
<td colspan="4" align="center"><b>Vulnerability factors</b></td>
</tr>
<tr>
<td align="center" width="10%">Skill level</td>
<td align="center" width="10%">Motive</td>
<td align="center" width="10%">Opportunity</td>
<td align="center" width="10%">Size</td>
<td align="center" width="2%"></td>
<td align="center" width="10%">Ease of discovery</td>
<td align="center" width="10%">Ease of exploit</td>
<td align="center" width="10%">Awareness</td>
<td align="center" width="10%">Intrusion detection</td>
</tr>
<tr>
<td align="center">5</td>
<td align="center">2</td>
<td align="center">7</td>
<td align="center">1</td>
<td align="center"></td>
<td align="center">3</td>
<td align="center">6</td>
<td align="center">9</td>
<td align="center">2</td>
</tr>
<tr>
<td colspan="9" align="center" bgcolor="lightblue">Overall likelihood=4.375 (MEDIUM)</td>
</tr>
</table>

Next, we need to figure out the overall impact. The process is similar here. In many cases the answer will be obvious, but you can make an estimate based on the factors, or you can average the scores for each of the factors. Again, less than 3 is LOW, 3 to less than 6 is MEDIUM, and 6 to 9 is HIGH. For example:

<table border="1" align="center">
<tr>
<td colspan="4" align="center"><b>Technical Impact</b></td>
<td></td>
<td colspan="4" align="center"><b>Business Impact</b></td>
</tr>
<tr>
<td align="center" width="10%">Loss of confidentiality</td>
<td align="center" width="10%">Loss of integrity</td>
<td align="center" width="10%">Loss of availability</td>
<td align="center" width="10%">Loss of accountability</td>
<td align="center" width="2%"></td>
<td align="center" width="10%">Financial damage</td>
<td align="center" width="10%">Reputation damage</td>
<td align="center" width="10%">Non-compliance</td>
<td align="center" width="10%">Privacy violation</td>
</tr>
<tr>
<td align="center">9</td>
<td align="center">7</td>
<td align="center">5</td>
<td align="center">8</td>
<td align="center"></td>
<td align="center">1</td>
<td align="center">2</td>
<td align="center">1</td>
<td align="center">5</td>
</tr>
<tr>
<td colspan="4" align="center" bgcolor="lightblue">Overall technical impact=7.25 (HIGH)</td>
<td></td>
<td colspan="4" align="center" bgcolor="lightblue">Overall business impact=2.25 (LOW)</td>
</tr>
</table>

===Determining Severity===

However we arrived at the likelihood and impact estimates, we can now combine them to get a final severity rating for this risk. Note that if you have good business impact information, you should use that instead of the technical impact information. But if you have no information about the business, then technical impact is the next best thing.

<table border="1" align="center">
<tr>
<td align="center" colspan="5"><b>Overall Risk Severity</b></td>
</tr>
<tr>
<td align="center" width="15%" rowspan="4"><b>Impact</b></td>
<td align="center" width="15%">HIGH</td>
<td align="center" width="15%" bgcolor="orange">Medium</td>
<td align="center" width="15%" bgcolor="red">High</td>
<td align="center" width="15%" bgcolor="pink">Critical</td>
</tr>
<tr>
<td align="center">MEDIUM</td>
<td align="center" bgcolor="yellow">Low</td>
<td align="center" bgcolor="orange">Medium</td>
<td align="center" bgcolor="red">High</td>
</tr>
<tr>
<td align="center">LOW</td>
<td align="center" bgcolor="lightgreen">Note</td>
<td align="center" bgcolor="yellow">Low</td>
<td align="center" bgcolor="orange">Medium</td>
</tr>
<tr>
<td align="center"> </td>
<td align="center">LOW</td>
<td align="center">MEDIUM</td>
<td align="center">HIGH</td>
</tr>
<tr>
<td align="center"> </td>
<td align="center" colspan="4"><b>Likelihood</b></td>
</tr>
</table>

In the example above, the likelihood is MEDIUM, and the technical impact is HIGH, so from a purely technical perspective, it appears that the overall severity is HIGH. However, note that the business impact is actually LOW, so the overall severity is best described as LOW as well. This is why understanding the business context of the vulnerabilities you are evaluating is so critical to making good risk decisions. Failure to understand this context can lead to the lack of trust between the business and security teams that is present in many organizations.

==Step 5: Deciding What to Fix==

After you've classified the risks to your application, you'll have a prioritized list of what to fix. As a general rule, you should fix the most severe risks first. It simply doesn't help your overall risk profile to fix less important risks, even if they're easy or cheap to fix.

Remember, not all risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2,000 of fraud per year, it would take 50 years return on investment to stamp out the loss. But remember there may be reputation damage from the fraud that could cost the organization much more.

==Step 6: Customizing Your Risk Rating Model==

Having a risk ranking framework that's customizable for a business is critical for adoption. A tailored model is much more likely to produce results that match people's perceptions about what is a serious risk. You can waste lots of time arguing about the risk ratings if they're not supported by a model like this. There are several ways to tailor this model for your organization.

===Adding factors===

You can choose different factors that better represent what's important for your organization. For example, a military application might add impact factors related to loss of human life or classified information. You might also add likelihood factors, such as the window of opportunity for an attacker or encryption algorithm strength.

===Customizing options===

There are some sample options associated with each factor, but the model will be much more effective if you customize these options to your business. For example, use the names of the different teams and your names for different classifications of information. You can also change the scores associated with the options. The best way to identify the right scores is to compare the ratings produced by the model with ratings produced by a team of experts. You can tune the model by carefully adjusting the scores to match.

===Weighting factors===

The model above assumes that all the factors are equally important. You can weight the factors to emphasize the factors that are more significant for your business. This makes the model a bit more complex, as you'll need to use a weighted average. But otherwise everything works the same. Again, you can tune the model by matching it against risk ratings you agree are accurate.

==References==

* Managing Information Security Risk: Organization, Mission, and Information System View [http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf]

* Industry standard vulnerability severity and risk rankings (CVSS) [http://www.first.org/cvss/]

* Security-enhancing process models (CLASP) [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project]

* Cheat Sheet: Web Application Security Frame - MSDN - Microsoft [http://msdn.microsoft.com/en-us/library/ff649461.aspx]

* [[Threat_Risk_Modeling|Threat Risk Modeling]]

* Pratical Threat Analysis [http://www.ptatechnologies.com/]

* Application Security Risk Assessment Guidelines [http://kb.wisc.edu/page.php?id=20262]

* A Platform for Risk Analysis of Security Critical Systems [http://sourceforge.net/projects/coras/]

* Model-driven Development and Analysis of Secure Information Systems [http://heim.ifi.uio.no/~ketils/securis/]

* Value Driven Security Threat Modeling Based on Attack Path Analysis [http://origin-www.computer.org/csdl/proceedings/hicss/2007/2755/00/27550280a.pdf]