Application Security Part 1

Although web applications have progressed immensely over the past few years, a huge volume of applications still suffer from attacks made by hackers. We are going to look at what hackers look for in a site that may be vulnerable to anything from SQL injection to XSS Attacks.

Given user input an application will execute malicious code, unbeknown to the developer or owner of the website, this could lead to malfunction and/or ultimately complete failure of the website. Numerous high profile websites have been attacked in the past, and out of these attacks we have learned a great deal about how to protect our websites.

In this first part we’ll have a look at SQL Injection and how to prevent any possible attacks.

What is SQL Injection?

Is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks.

SQL Injection is probably the most malicious attack that you could suffer exploiting the database and bending it to the malicious user’s will, on a daily basis these kinds of attacks affects hundreds of websites, lets look at a couple of tips at securing a user’s input.

How SQL Injection is used

On the server side we have more control over content filtering, with most languages already having unique methods to filter and escape user input data. Some will argue the fact that filtering ever piece of data you want to use is unnecessary and resource consuming and others will argue that this gives more control over what you want to filter and you could never exactly know what a type of content is going to be entered by a user unless you predefine standards of variable naming conventions.

Lets have a look at an example of a form that gets posted to the server from which the data then gets inserted into the database;

Array
(
    [username] => John
    [password] => MyPass
)

Lets assume from the example data posted by the form that the server page is going to use the user name & password  to execute SQL, to query the database for information. So our SQL might like something like the following:

SELECT id FROM members
       WHERE username = 'John'
         AND password = 'MyPass';

Now if a malicious user was to come across our website and see that there is a login box he would attempt to break into our system by injection a string which would either allow him access or give him critical information about our database.

The following is a common example of what a malicious user will insert into a form

Array
(
    [username] => admin
    [password] => x' AND 1=(SELECT COUNT(*) FROM tabname); --
)

SELECT id FROM members
       WHERE username = 'admin'
         AND password = 'x' AND 1=(SELECT COUNT(*) FROM table); --';

By trying to select information from a table the malicious user may be able to probe our database for insecurities, and when successful exploit these insecurities and if the input is not sanitized properly, there may be nothing that prevents the user from stringing his own unrelated command at the end of the query.

SELECT id FROM members
       WHERE username = 'admin'
         AND password = 'x'; DROP TABLE members; --';

This is one of the more worst case scenarios where if the table members did exist it would be dropped, in other cases information may be injected into our tables, sensitive information may be compromised. With clearly well-formed SQL,  we don’t expect to see any server errors, but with many websites precautions aren’t taken to insure that if and when SQL errors appear they do not display to the casual user.

Validating User Input

By not trusting the user from the get-go we can assume that one user will inevitably try using sql injection to attack your website, to try and curb attacks from the client side we can use client side form validation to validate any input from a user. This can be achieved by using javascript and regex to validate the input according to specific patterns.

These 2 patterns will let us check for specific values namely, strings and integers, thus allowing us to filter what comes through to the server and potentially into our database.

 stringVal = /[^a-zA-Z]/g; // Pattern without special characters
 intVal    = /[\D]/g; // Pattern for a numeric value

The following will output an alert box telling us that the value we tried to validate was indeed not a integer, thus we’d have to presume the user was either trying to attack our website or entered the wrong value. Safely escaping something that could have potentially cost us our database.

if (intVal.test("One")) {
      alert("This is an numeric value");
} else {
      alert("No numeric value found.");
}

Sanitizing User Input

PHP has a few significant functions built in to try and stop these kinds of attacks, one type being the escape string functions, PHP has different functions for different database types, one of them being mysql_real_escape_string(); depending on your database type I suggest you look up on php.net which function is applicable to your database. The downside to these functions are they are dependent on extensions and/or libraries.

These functions escape any single quotes in a string that  could lead to a SQL Injection attack, by default never ever trust user input data, especially especially data which will be inserted into the database.

mysql_real_escape_string($_POST['password']);

Thus allowing us to securely commit our changes to the database.

SELECT id FROM members
       WHERE username = 'admin'
         AND password = 'x\'; DROP TABLE members; --';