SQLi – A Bird’s Eye View
Posted by mindfiretesting
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 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
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 .
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.
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.
Usually these following places of a website are vulnerable to SQLi –
- Form Fields
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:
- Server Variables
- SQL Map (Open source penetration tool)
- SQL HYPERLINK (Firefox Add-on)
- SQLiX (by OWASP)
- SQL Ninja (Supported Platform : Linux, Mac OS X, iOS)
Posted on April 7, 2014, in Manual Testing, Security Testing and tagged Automated Testing, Automation testing services, Classification of SQLi, Cookies testing, Impact of injection, Injection Location, Manual Testing, Mindfire Solutions, Nibedita Sahoo, Offshore performance testing, Open source penetration tool, outsource stress testing, OWASP community, QA Engineer, Risk base testing, Security Testing, SQL Map, SQLi testing, Testing Services, What is SQLi. Bookmark the permalink. 1 Comment.