Editing SQL injection (section)

==Ways to exploit==

Although the root cause of all SQL injections is the same, there are different techniques to exploit it. Some of them are discussed below:

===Getting direct output or action===

Imagine a program creates a SQL statement using the following string assignment command :

<syntaxhighlight lang="javascript" inline>var statement = "SELECT * FROM users WHERE name = '" + userName + "'";</syntaxhighlight>

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as:

<pre>' OR '1'='1</pre>
or using comments to even block the rest of the query (there are three types of SQL comments<ref>{{citation|title=IBM Informix Guide to SQL: Syntax|chapter=How to Enter SQL Comments|publisher=IBM|chapter-url=http://publibfp.dhe.ibm.com/epubs/pdf/c2736111.pdf|pages=13–14|access-date=2018-06-04|archive-date=February 24, 2021|archive-url=https://web.archive.org/web/20210224035314/http://publibfp.dhe.ibm.com/epubs/pdf/c2736111.pdf|url-status=dead|language=en}}</ref>). All three lines have a space at the end:
<pre>' OR '1'='1' --
' OR '1'='1' {
' OR '1'='1' /* </pre>

renders one of the following SQL statements by the parent language:

<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = '' OR '1'='1';</syntaxhighlight>
<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = '' OR '1'='1' -- ';</syntaxhighlight>

If this code were to be used in authentication procedure then this example could be used to force the selection of every data field (*) from ''all'' users rather than from one specific user name as the coder intended,  because the evaluation of '1'='1' is always true.

The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "userinfo" table (in essence revealing the information of every user), using an [[API]] that allows multiple statements:

<syntaxhighlight lang="sql" inline="">a';</syntaxhighlight><syntaxhighlight lang="sql" inline="">DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</syntaxhighlight>

This input renders the final SQL statement as follows and specified:

<syntaxhighlight lang="sql">SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';</syntaxhighlight>

While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as [[PHP]]'s <code>mysql_query()</code> function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.

===Blind SQL injection===
Blind SQL injection is used when a web application is vulnerable to a SQL injection, but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page.
This type of attack has traditionally been considered time-intensive because a new statement needed to be crafted for each bit recovered, and depending on its structure, the attack may consist of many unsuccessful requests. Recent advancements have allowed each request to recover multiple bits, with no unsuccessful requests, allowing for more consistent and efficient extraction.<ref>{{cite web|url=http://howto.hackallthethings.com/2016/07/extracting-multiple-bits-per-request.html|title=Extracting Multiple Bits Per Request From Full-blind SQL Injection Vulnerabilities|publisher=Hack All The Things|access-date=July 8, 2016|url-status=dead|archive-url=https://web.archive.org/web/20160708190141/http://howto.hackallthethings.com/2016/07/extracting-multiple-bits-per-request.html|archive-date=July 8, 2016|language=en}}</ref> There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.<ref>{{cite web|url=http://www.justinclarke.com/archives/2006/03/sqlbrute.html|title=Using SQLBrute to brute force data from a blind SQL injection point|publisher=Justin Clarke|access-date=October 18, 2008|url-status=dead|archive-url=https://web.archive.org/web/20080614203711/http://www.justinclarke.com/archives/2006/03/sqlbrute.html<!-- Bot retrieved archive -->|archive-date=June 14, 2008|language=en}}</ref>

====Conditional responses====
One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen. As an example, a book review website uses a [[query string]] to determine which book review to display. So the [[URL]] <code><nowiki>https://books.example.com/review?id=5</nowiki></code> would cause the server to run the query
<syntaxhighlight lang="sql">SELECT * FROM bookreviews WHERE ID = '5';</syntaxhighlight>
from which it would populate the review page with data from the review with [[Identifier|ID]] 5, stored in the [[Table (database)|table]] bookreviews. The query happens completely on the server; the user does not know the names of the database, table, or fields, nor does the user know the query string. The user only sees that the above URL returns a book review. A [[Security hacker|hacker]] can load the URLs <code><syntaxhighlight lang="sql" inline>https://books.example.com/review?id=5' OR '1'='1</syntaxhighlight></code> and <code><syntaxhighlight lang="sql" inline>https://books.example.com/review?id=5' AND '1'='2</syntaxhighlight></code>, which may result in queries
<syntaxhighlight lang="sql">SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';</syntaxhighlight>
respectively. If the original review loads with the "1=1" URL and a blank or error page is returned from the "1=2" URL, and the returned page has not been created to alert the user the input is invalid, or in other words, has been caught by an input test script, the site is likely vulnerable to an SQL injection attack as the query will likely have passed through successfully in both cases. The hacker may proceed with this query string designed to reveal the version number of [[MySQL]] running on the server: <code><syntaxhighlight lang="mysql" inline>https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4</syntaxhighlight></code>, which would show the book review on a server running MySQL 4 and a blank or error page otherwise. The hacker can continue to use code within query strings to achieve their goal directly, or to glean more information from the server in hopes of discovering another avenue of attack.<ref>{{cite web|url=http://forum.intern0t.org/web-hacking-war-games/818-blind-sql-injection.html|title=Blind SQL Injection tutorial|author=macd3v|access-date=6 December 2012|url-status=dead|archive-url=https://web.archive.org/web/20121214193021/http://forum.intern0t.org/web-hacking-war-games/818-blind-sql-injection.html|archive-date=December 14, 2012 |language=en}}</ref><ref>{{cite web|title=TDSS botnet: full disclosure |url=http://nobunkum.ru/analytics/en-tdss-botnet|access-date=6 December 2012|author=Andrey Rassokhin|author2=Dmitry Oleksyuk|url-status=dead |archive-url=https://web.archive.org/web/20121209032723/http://nobunkum.ru/analytics/en-tdss-botnet|archive-date=December 9, 2012 |language=en}}</ref>

===Second-order SQL injection===
Second-order SQL injection occurs when an application only guards its SQL against immediate user input, but has a less strict policy when dealing with data already stored in the system. Therefore, although such application would manage to safely process the user input and store it without issue, it would store the malicious SQL statement as well. Then, when another part of that application would use that data in a query that isn't protected from SQL injection, this malicious statement might get executed.{{Citation needed|date=March 2025}} This attack requires more knowledge of how submitted values are later used.  Automated web application security scanners would not easily detect this type of SQL injection and may need to be manually instructed where to check for evidence that it is being attempted.

In order to protect from this kind of attack, all SQL processing must be uniformly secure, despite the data source.