Injection attacks (Part 3)

SQL Injection

SQL stands for structured query language, and if we go by the literal meaning of SQL Injection – we are injecting a SQL query…..but Y..?????

If the application is vulnerable to SQL injection we can do a lot of exploitation –

  • Enumerate the DB
  • Modify the DB entries
  • Data disclosure
  • Delete the DB entries or the DB itself
  • Shutdown DB
  • Authentication bypassing

 

DEMO

1) Lets search for a movie

1

2)Checking the URL, we see that search string is there in the URL

2

3)Changing the arguments in the URL as shown below

3
Here we break the SQL query with a and then forcing a true condition. will comment the rest of the code.

4)See the output

4

All the entries are displayed

5)Now let’s change the URL as below

5SQL
title=1’union select 1,2,3,4,5,6,7–

By hit and trial we get that there are 7 columns, if the no of columns are more or less, u might get an error

6SQL
Here we have the output. Now whatever i change in the URL above(2,3,4 or 5). I will be able to see result down in that column

7)Finding the Version

7SQL
Change the 3 in the previous URL to version()
8SQL
Since we have replaced 3 with the version statement , now we see the version in release column

8)Digging the database

9SQL
Replacing the no 3 with database()
10SQL
Database name is bWAPP

9)Finding the table names

11SQL
Finding the table names from information_schema
12SQL
–snipped– table names shown in the release column

10)Now we need the database information from tables

13SQL

14SQL

11)Grouping what we got in he above query

15SQL

16SQL

12)Finding the column names

17SQL
where table_name=”users” —
18SQL
So the users table has these columns

13)Digging the GOLD – USERNAME AND PASSWORD

19SQL
group_concat(login.password) -> self explanatory
20SQL
User name is AIM and rest is password. You can also provide group_concat(login,0x3a,password). This will introduce a : between the username and password.

 

OK, My application is vulnerable to SQL injection ,

WHAT SHOULD I DO THEN..? – REMEDIATION

SQL injection occurs when user data is directly fed to the code, blindly.We expect the user to enter a string giving no thought that what might happen if a query is entered.

Below is a vulnerable code 

public boolen isValid(string username, string password)
{
string sql= ” SELECT * FROM user WHERE username =’ ” + username + ” ‘ AND password=’ ” + password;
result = query(sql);
}

  • No input validation is done – user can enter any string of any length in both username and password.

We have different ways to fix SQL injection.

  • Input validation
  • Output encoding
  • White listing
  • Blacklisting
  • Parametrised queries

INPUT VALIDATION

Input can be validated for

  • Length
  • Type
  • Content

Create a function for validating the input

function match(){

username_pattern = pattern.compile(“^[a-z]{4,20}$”); /* This will make sure that the username is using only a-z characters and has a length between 4-20 ccharacters */

/*We can add further code to verify and match the username and even throw an exception in case it does not match*/

}

DOWNSIDE

  • Difficult to do this for complex inputs like emails can have ‘@’ etc.

BLACKLISTING   WHITELISTING

Blacklisting(rejecting known bad) is a not very recommended approach as it will have a lot of false positives.Consider blocking the word SELECT and DELETE.These are common English words and hence it becomes very difficult to judge whether it has been used as a part of query or malicious input.

Whitelisting(accepting the known good data) depending on the type , size, length, data range , data content.

Food for thought -How to incorporate username -> O’Henry since ‘ will break the SQL query

The recommendation is to use this technique along with other techniques like output encoding.

OUTPUT ENCODING

Create a function or a class to encode the input

Function safeEncoder(Input)

{

//Code Return an encoded value

}

DOWNSIDE

Different databases handle implementation of encoded data in a different way. If your application uses different databases e.g. One kind of DB for testing and one kind of DB for production, it becomes almost impossible to go for this option in that case.

PARAMETRISED QUERIES

Ultimate solution

“Data remains data and does not become part of the code”, and that is achieved with parametrised queries

What to parametrise..??????
Only data values to be parametrised and not keywords and identifiers else u might end up introducing SQL injection

Below is a raw example of doing this

string query = “select * from users where users = ? and password =?”;
preparesStatement lookUser = connection.prepareStatement(query)

lookUser.setString(1, username);
lookUser.setString(2, password);

lookUser.executeQuery();

This will set the 1st field as username and 2nd field as password.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s