The Top Security Vulnerabilities

Unvalidated data

Never trust anything you get from a Web browser. The browser is completely outside of your control, and it’s easy to fake values like the HTTP referrer. It’s also easy to fake a hidden field in a form.

More importantly, when dealing with forms, for example, validate the data carefully. Use a “deny all, permit a little” policy. For example, if a registration form has a field for the user name, allow only alphabetical characters and perhaps the numbers 0–9, rather than simply rejecting particular special characters. Use regular expressions to limit data to exactly what you require.

Packages like PEAR, provide built-in mechanisms for validating forms and do a lot to help cover weaknesses you might otherwise neglect. Also, where things like include files are concerned, watch out for logic like this:

include($_GET[‘page’]);

Make sure you check the value of $_GET[‘page’] against a list of files your code is designed to include:

$pages = array(
‘news.php’, ‘downloads.php’, ‘links.php’
);
if (in_array($_GET[‘page’], $pages)) {
include $_GET[‘page’];
} else {
include ‘not_found.php’;
}

Without such checks, it’s very easy for an attacker to use code similar to this to execute other PHP scripts – even ones you didn’t write.

Also Read: SQL Injection – A Complete Understanding Tutorial

Broken access control

Fundamental logic of this form is easy to get wrong if you don’t know what you’re doing. For example, often, developers check a user name/password combination against a database using logic like this:

if ($numRows != 0) {
// allow access …
}

That means they let users in even if they found more than one matching entry in the database, which, if your site also has security holes like command injection flaws (see below), may provide attackers access to a lot more than you were expecting.

It’s easy to make mistakes in situations you think are secure when, in fact, the logic can be bypassed easily. In general, use respected third party libraries such as PEAR::Auth and PEAR::LiveUser wherever possible.

Also, investigate Web testing frameworks such as SimpleTest, which provide the ability to test your site from the point of view of a Web browser.

Session and Cookie Vulnerabilities

Watch out for session hijacking possibilities. On sites where you really need secure authentication (e.g. ecommerce sites), use SSL to serve the site to the browser, to ensure the conversation is encrypted and that no one is listening
in. If you’re passing session IDs via the URL, as you will for WML-based sites, make sure that you’re not placing the session ID in URLs that point to remote sites. Also, when passing visitors to a remote site, forward them via an intermediate script that strips out any possible HTTP referrer information that contains the session ID. In general, it’s better to handle sessions with cookies.

If you’re working with your own cookie-based authentication, store an identifying session ID in the cookie only, not the user name and password.

Cross Site Scripting (XSS)

By using the legitimate mechanisms your site provides, it’s possible for attackers to post on your site, for example, JavaScript that results in other users giving away their session IDs, thereby allowing the attacker to hijack their
session. Less serious, but equally embarrassing, is simply posting HTML that “scrambles” the layout of your page, perhaps closing a table tag prematurely.

Also Read: Top 40 XSS Revision Questions with Answers

Use a “deny all, permit a little” approach, or, better yet, employ a separate markup language such as BBCode, while eliminating HTML with PHP functions like strip_tags and htmlentities.

Basically there are 3 types of XSS –

Reflected Cross Site Scripting (RXSS)
Stored Cross Site Scripting (SXSS)
DOM based Cross Site Scripting (DXSS)

Command Injection

Command injection occurs when an attacker is able to influence the way PHP interacts with external systems, such as the file system or a database. An SQL injection is a prime example, which occurs when an attacker uses a form or
URL to modify a database query. The bottom line is: escape all data you receive from a user before you use it in a query.

Error Handling

An experienced attacker will be able to gain a lot of important information about your system from your error messages. Although this comes under the heading of “security by obscurity” (which is no substitute for having a really secure application), for a live site, it’s a good idea to instruct PHP to log error messages to a file, rather than display them to the browser.

Also Read: Different Server Configuration Techniques for Custom Errors

Insecure Use of Cryptography

First of all, when it comes to cryptography, don’t roll your own. Second, remember that if it’s an algorithm that’s meant to be decoded, then someone (other than you) is also capable of decoding it. Remember that, strictly
speaking, MD5 is not an encryption algorithm (i.e. you cannot decrypt an MD5 string to obtain the original data); it’s a message digest algorithm.

But if you don’t need to decrypt a value then use MD5, which is available through PHP’s md5 function. This allows you to compare the encrypted versions of two pieces of data (e.g. a stored password and that entered by a user), which avoids the risks involved in working with encrypted values that could possibly be decrypted by an attacker.

Administration Flaws

Allowing an attacker to gain the same access you have to your site is clearly bad news. Avoid FTP and telnet in favor of SCP/SFTP and SSH, respectively. Linux distributions usually have the required client tools pre-installed. For
Windows, check out putty for SSH access and WinSCP for SCP/SFTP.

FTP and telnet expose your password to network sniffers. Make sure that any Web administration tools your host provides are used only over an SSL connection. If you’re using third party software, such as phpBB, change the default administrator password immediately, and stay informed about potential security flaws.

Configuration and Patching

When installing PHP, the configuration file php.ini-recommended makes the best starting point to make sure you’ve got the package configured correctly. If you’re using a hosting company, they should take care of most of the issues
for you, such as patching software as vulnerabilities are announced. Still, it’s worth staying up to date on your own, using sites like Security Focus and others listed at DMOZ.

You may also like: