Diving into SQL Injection - Part I

This post is for all those people out there who know what SQL Injection roughly is but have no idea how to practically exploit SQLi vulnerabilities.I will be going through the most rudimentary concepts in SQL Injection and hence this post is not suitable for people wanting to learn advanced concepts in SQL injection.

What is SQL Injection?

Wikipedia says "SQL injection is a SQL injection is a code injection technique, used to attack data driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database. "

Now most of you would be aware of what this means only in theory. In this post I plan to show to show some of the basic attack vectors which you can craft to exploit the SQLi vulnerabilities. Although, these  attack vectors(cleverly crafted SQL queries) may be very basic, it is essential that we understand this before proceeding to the next level.

We will just be looking at authentication bypass in this post and further topics in the coming posts.

• Authentication Bypass:

Most of us would have seen login pages of different sites like gmail,yahoo etc. Most of them ask us to enter the username and password. The question is what if we could bypass such authentication pages i.e logging in without having the actual details . Most of the vulnerabilities arise from insecure coding practices that developers tend to adopt .Let's see how we can exploit the vulnerability  which is introduced due to lack of secure coding practice on the server side

.

Below is a sample php code which checks for login credentials.

$q = "SELECT * FROM users where username='".$username."' AND password = '".md5($pass)."'" ;

Notice that the $username is what we enter in the username field is not at all being sanitized. By sanitized I mean, it is not checking for illegal characters .

The question is how do we take advantage  of this now.We have to craft our username in such a way that it bypasses the authentication.

suppose you know that there is a user called admin, then you could use

admin' -- // . In this case the query becomes select * from users where username= 'admin' -- // AND  password = '".md5($pass)."'" ;

Now why the two hifens -- ?

The reason is that they are the comment line characters in most sql interpreters. # is another such comment line character

why the //?

This is not necessary.You could just put a space instead of these but remember that you need to put a space otherwise there wont be a space between the -- and AND i.e the query looks somewhat like select * from users where username= 'admin' --AND  password = '".md5($pass)."'" ; which doesn't work.

Note: It's likely that you might miss the space and hence the //

In case you don't know any valid user, you could try this to bypass authentication

' or 1=1 -- //

let's construct the back end query with this user input in mind

select * from users where username='' or 1=1 -- // AND  password = '".md5($pass)."'" ; 

By using the expression or 1=1 we are evaluating the username to TRUE  and as done already we are commenting the password part using the --.

Now what does this query return from the backend database?

Since there is no username specified, this is an obvious question. The query actually returns the first row from the users table.

That's it for now. I will introduce more attack vectors and try to explain them in the coming posts.