SQLi – A Bird’s Eye View

Since the day I started my QA role, I was always interested in security aspect of applications. My interest and curiosity revealed SQL injection is the top most vulnerability world-wide. I read many articles, tried some tools and tried breaking applications. My journey is interesting. So thought like why not sharing my experience and throw some more light towards it.

Since long time, SQL injection (nick name SQLi) has been one of the most high risk vulnerabilities to websites that causes compromise of sensitive customer and application data. In 2013, SQLi was rated as top most attack on OWASP. The reason being it’s common, it’s very easy to exploit and the impact is so severe.

What is SQLi?

SQLi is an attack in which the hacker tries to inject arbitrary malicious data into the input fields / URLs which causes the data to be executed in backend SQL server and gives some undesired results.

Even by executing code (SQL statement) through vulnerable input parameters, the attackers can directly interact with the back end server.

Risk

Risk involved in SQLi is high and treated as the one of the most damaging vulnerabilities. Through a successful SQL injection attack, an attacker can –

  • Retrieve sensitive information from the database
  • Modify data (insert/update/delete) in database,
  • Bypass authentication and execute administration operations on the database
  • Upload scripts / inject malicious code
  • in worst case, issue shell commands to the operating system 

In a nut-shell, we can view it as breach of CAAI (Confidentiality, Authentication, Authorization, and Integrity).

Classification of SQLi:

SQLi can be classified into different categories based on –

  • Communication channel
  • Server Response
  • Impact of injection
  • Injection Location

Communication Channel:

Through SQLi, data can be extracted directly via the same channel as input or sometimes it needs a different channel to get / dump the data back to attacker domain.

When data is extracted directly via the same channel as input, it’s known as Inband/Inline SQLi. This is the most straight forward mechanism.

e.g . If there is a URL – http://www.victimdomain.com/user.aspx that takes id (GUID) as a parameter and the attacker enters www. victimdomain.com/user.aspx?id=’xyz’, it gives the error details. Similar type of errors provides enough information to the attacker to do more guess work and inject SQL code into URL.

When it required a different channel to get / dump the data back to attacker domain, it’s known as Out-of-Band SQLi .

Server Response:

Some websites throw error back to the webpages. The error details from the website provide enough internal information which aids in successful exploitation – popularly known as Error based SQLi.

e.g. –

Server Response

Server Response

 

Some other websites (even if they are vulnerable to SQLi) don’t show the error details to the attacker directly which makes them difficult to be the victim of SQLi . In that case, the attacker tries to find vulnerability through blind assumptions – known as blind SQLi.

e.g. – SELECT field list FROM table
WHERE field = ‘anything’ OR ‘x’=’x’;
‘ or 0=0 –
‘ or 1=1—
hi’ or 1=1 –
hi’ or ‘a’=’a

Impact of Injection:

When the impact of injection is direct (i.e. injection directly delivers result), it’s considered as first-order SQLi .

Sometimes an injection doesn’t yield successful result immediately but impacts some other places using which the attacker can take advantage later or of some other pages . This type of injection is known as second-order injection.

Injection Location:

Usually these following places of a website are vulnerable to SQLi –

  • URLs
Injection Location-URL

Injection Location-URL

  • Form Fields
Impact of Injection-Form Fields

Impact of Injection-Form Fields

  • Cookies
Impact of Injection-Cookies

Impact of Injection-Cookies

We will edit the language_id variable. To figure out the SQL injection flaw, we will add a quote “ ‘ ” in the field content of the variable language_id.

After refreshing the page, or clicking on other internal link of the application, the application submits the request using the edited HTTP cookie. The result is triggered an SQL error:

Impact of Injection-Database error

Impact of Injection-Database error

 

  • Server Variables

Statistics:

Statistics-Distribution of Attack Techniques

Statistics-Distribution of Attack Techniques

Popular Tools:

Defences:

Defences-SQLi

Defences-SQLi

 

Written By: – Nibedita Sahoo, QA Engineer, Mindfire Solutions

Advertisements

Posted on April 7, 2014, in Manual Testing, Security Testing and tagged , , , , , , , , , , , , , , , , , , , . Bookmark the permalink. 1 Comment.

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

%d bloggers like this: