95 lines
3.0 KiB
Plaintext
95 lines
3.0 KiB
Plaintext
= SQLI =
|
|
|
|
SQLI or SQL injection is a type of attack where sql is placed into a field in
|
|
an application, as is directly passed to a DBMS.
|
|
|
|
An attack typically works by prematurely terminating a text string and
|
|
appending a new command. Because the inserted command may have additional
|
|
strings appended to it before it is executed, SQLI attack string generally end
|
|
with a comment or `--`.
|
|
|
|
== Typical attack avenues ==
|
|
|
|
=== user input ===
|
|
|
|
Attacker crafts some input field text to send to server, that is then passed to
|
|
a database without first being sanatized.
|
|
|
|
=== server variables ===
|
|
|
|
Server varaibles include HTTP headers, network protocol headers, and enviroment
|
|
variables. Web applications use these for logging usage stats and IDing browsing
|
|
trends. If put in a database without sanitiztation, when the data is later
|
|
queried by some application, it could be placed back into a database request,
|
|
triggering an attack.
|
|
|
|
=== Second order injection ===
|
|
|
|
This occours when incomplete prevention mechanisms against SQLi attacks are in
|
|
place. This happens when the attacker provides some data to the system that is
|
|
first processed by the server, but after processing becomes an attack vector.
|
|
|
|
=== Cookies ===
|
|
|
|
When client returns to a web application server, cookies restore client state.
|
|
Because client can control the cookie, attacker can alter cookies such that
|
|
when the pplication server builds an SQL Query based on the cookies content,
|
|
the structure/function of query is modified.
|
|
|
|
=== Physical user input ===
|
|
|
|
Attacker may construct physical things outside of the realm of web requests.
|
|
This includes QR codes, RFID tags, or paper forms scanned with optical
|
|
character recognition.
|
|
|
|
== Inband attacks ==
|
|
|
|
Inband attacks use the same communication channel for injecting SQL as for
|
|
retreiving it.
|
|
|
|
=== tautology ===
|
|
|
|
Consider the PHP code example
|
|
|
|
{{{
|
|
$query = "SELECT info FROM user WHERE name='$_GET["name"]' AND pwd='$_GET["pwd"]'"
|
|
}}}
|
|
|
|
If the attacker submits `" ' OR 1=1 --` for the `name` field, the resulting
|
|
query would be
|
|
`SELECT info FROM user WHERE name=' ' OR 1=1 --AND pwd='$_GET["pwd"]'`
|
|
|
|
This would disable the password check, and return all rows to the application.
|
|
|
|
=== Piggybacked queries ===
|
|
|
|
Attacker can send another query after the intended query, allowing them to
|
|
extract more information.
|
|
|
|
== Inferential attack ==
|
|
|
|
Inferential attacks occour when there is no actual transfer of data, but the
|
|
attack is able to reconstruct the information by sending particular requests
|
|
and observing the resulting behavior of the websites/database.
|
|
|
|
=== Illegal or incorrect queries ===
|
|
|
|
A reconsiance step for attackers. By intenionally creating errors, attacker is
|
|
able to gather info from very verbose error pages
|
|
|
|
=== Blind SQL injection ===
|
|
|
|
Attacker infer the data present in a database system even when the system is
|
|
secure enough to not show verbose error messages. The attacker asks server T/F
|
|
questions. If the query is true, the site functions like normal.
|
|
|
|
== Solutions ==
|
|
|
|
* Defensive coding
|
|
* Paramterized query insertion
|
|
* Use Typesafe SQL DOM
|
|
|
|
== Also see ==
|
|
|
|
* [[sql]]
|