0% found this document useful (0 votes)
5 views7 pages

Week 3 SQL Injection

SQL Injection is a hacking technique that allows unauthorized access to databases through manipulated SQL commands in input fields or URLs. It can lead to severe consequences, including data breaches and unauthorized data manipulation, and is categorized into In-band, Inferential, and Out-of-band SQLi. To protect against SQL Injection, best practices include validating user input, using Object Relational Mapping (ORM), and employing prepared statements.

Uploaded by

Blueprint Mih
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views7 pages

Week 3 SQL Injection

SQL Injection is a hacking technique that allows unauthorized access to databases through manipulated SQL commands in input fields or URLs. It can lead to severe consequences, including data breaches and unauthorized data manipulation, and is categorized into In-band, Inferential, and Out-of-band SQLi. To protect against SQL Injection, best practices include validating user input, using Object Relational Mapping (ORM), and employing prepared statements.

Uploaded by

Blueprint Mih
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

SQL Injection

SQL Injection is a technique where SQL commands are executed from the form input
fields or URL query parameters. This leads to unauthorized access to the database (a
type of hacking).
If SQL injection is successful, unauthorized people may read, create, update or even
delete records from the database tables. This technique is mainly used by but not
limited to hackers, pentesters, QAs and security researchers.

Example 1: SQL Injection Using Multiple Statement


Suppose we have a search form to search products by their ID on our website. The PHP
code snippet to search product would look something like,
$prod_id = $_GET["prod_id"];
$sql = "SELECT * FROM Products WHERE product_id = " . $prod_id;

Let's take a look if user submits 20, how SQL is interpreted,


SELECT * FROM Products WHERE product_id = 20

Nothing suspicious, right?


What if user inputs 20; DROP TABLE Products;? Let's take a look at SQL statement
again,
SELECT * FROM Products WHERE product_id = 20; DROP TABLE Products;

Now this SQL statement also deletes the Products table from the database based on
input data. This was possible becaues most database systems can execute multiple
statements at the same time.
Example: SQL Injection

Example 2: SQL Injection Using Always True Condition


Another way to perform SQL injection is by passing a condition that always results
in TRUE so that the data is always fetched no matter what.
Let's take a look at another PHP code snippet where we have a login form in our
website and we need to fetch users by providing credentials.
$username = $_POST["username"];
$password = $_POST["password"];

$sql = "SELECT * FROM Users WHERE username = \"" . $username . "\" AND password =
\"" . $password . "\"";
If user inputs username as root and password as pass, the SQL will interpret,
SELECT * FROM Users WHERE username = "root" AND password = "pass"

This code snippet looks fine when user inputs correct username and password.
What if the user inputs username as invalid_user" OR "1"="1 and password

as invalid_pass" OR "1"="1? Let's take a look at how SQL interprets.


SELECT * FROM Users WHERE username = "invalid_user" OR "1"="1" AND password =
"invalid_pass" OR "1"="1"
Since, "1"="1" is always true, no matter what the username and password user enters,
SQL will fetch all the users from the database.
Types of SQL Injection (SQLi)
SQL Injection can be used in a range of ways to cause serious problems. By levering SQL
Injection, an attacker could bypass authentication, access, modify and delete data within
a database. In some cases, SQL Injection can even be used to execute commands on the
operating system, potentially allowing an attacker to escalate to more damaging attacks
inside of a network that sits behind a firewall.
SQL Injection can be classified into three major categories – In-band SQLi, Inferential
SQLi and Out-of-band SQLi.

A. In-band SQLi (Classic SQLi)


In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks.
In-band SQL Injection occurs when an attacker is able to use the same communication
channel to both launch the attack and gather results.
The two most common types of in-band SQL Injection are Error-based SQLi and Union-
based SQLi.
i. Error-based SQLi
Error-based SQLi is an in-band SQL Injection technique that relies on error messages
thrown by the database server to obtain information about the structure of the database.
In some cases, error-based SQL injection alone is enough for an attacker to enumerate an
entire database. While errors are very useful during the development phase of a web
application, they should be disabled on a live site, or logged to a file with restricted access
instead.
ii. Union-based SQLi
Union-based SQLi is an in-band SQL injection technique that leverages the UNION SQL
operator to combine the results of two or more SELECT statements into a single result
which is then returned as part of the HTTP response.
B. Inferential SQLi (Blind SQLi)
Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to exploit,
however, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi
attack, no data is actually transferred via the web application and the attacker would not
be able to see the result of an attack in-band (which is why such attacks are commonly
referred to as “blind SQL Injection attacks”). Instead, an attacker is able to reconstruct the
database structure by sending payloads, observing the web application’s response and
the resulting behavior of the database server.
The two types of inferential SQL Injection are Blind-boolean-based SQLi and Blind-time-
based SQLi.
i. Boolean-based (content-based) Blind SQLi
Boolean-based SQL Injection is an inferential SQL Injection technique that relies on
sending an SQL query to the database which forces the application to return a different
result depending on whether the query returns a TRUE or FALSE result.
Depending on the result, the content within the HTTP response will change, or remain
the same. This allows an attacker to infer if the payload used returned true or false, even
though no data from the database is returned. This attack is typically slow (especially on
large databases) since an attacker would need to enumerate a database, character by
character.
ii. Time-based Blind SQLi
Time-based SQL Injection is an inferential SQL Injection technique that relies on sending
an SQL query to the database which forces the database to wait for a specified amount of
time (in seconds) before responding. The response time will indicate to the attacker
whether the result of the query is TRUE or FALSE.
Depending on the result, an HTTP response will be returned with a delay, or returned
immediately. This allows an attacker to infer if the payload used returned true or false,
even though no data from the database is returned. This attack is typically slow
(especially on large databases) since an attacker would need to enumerate a database
character by character.
C. Out-of-band SQLi
Out-of-band SQL Injection is not very common, mostly because it depends on features
being enabled on the database server being used by the web application. Out-of-band
SQL Injection occurs when an attacker is unable to use the same channel to launch the
attack and gather results.
Out-of-band techniques, offer an attacker an alternative to inferential time-based
techniques, especially if the server responses are not very stable (making an inferential
time-based attack unreliable).
Out-of-band SQLi techniques would rely on the database server’s ability to make DNS or
HTTP requests to deliver data to an attacker. Such is the case with Microsoft SQL
Server’s xp_dirtree command, which can be used to make DNS requests to a server an
attacker controls; as well as Oracle Database’s UTL_HTTP package, which can be used to
send HTTP requests from SQL and PL/SQL to a server an attacker controls.

How to Protect SQL Statements from Injections


i. Validate User Input
We should always validate user's input data before actually sending them to the
database. Some best practices include, trimming spaces, parsing special characters,
limiting the input size, etc.
For example,
$data = $_POST["name"];
$data = trim($data);
$data = stripslashes($data);
$data = htmlspecialchars($data);

ii. Using ORMs


ORM (Object Relational Mapping) is a tool that basically parses SQL statements into
programming language code and vice-versa.
If we use ORM's, we don't have to write raw SQL for the most part. Since ORM's are
designed by following good practices and security protocols, they are safe and easy to
use.
For example,
SELECT * FROM Users WHERE id = 5;
will look like
User::where(“id”,5)
in eloquent.

iii. Using Prepared Statements


Another best idea to protect SQL statements from being injected is by using prepared
statements.
Prepared statements are basically SQL statements but with placeholders. The passed
arguments are just replaced in place of placeholders.
For example,
$sql = "INSERT INTO Users (first_name, last_name, email) VALUES (?, ?, ?)";
mysqli_stmt_bind_param($sql, "sss", $first_name, $last_name, $email);
$first_name = "Harry";
$last_name = "Potter";
$email = "[email protected]";
mysqli_stmt_execute($stmt);
Here, the values are only placed in place of ? and the structure of SQL statements are
preserved.
SQL Injection is a very common way of hacking any web application. Almost 51% of
hacking done each year is done by injecting SQL.
If we use raw SQL statements while building our application, we must test and verify
them thoroughly.
Also, if we are building a real world application, it's always a good idea to use
frameworks (such as Django, Laravel, ASP.net etc.) instead of writing code from the
scratch. It's because these frameworks handle SQL injection as well as many commonly
occuring issues by default.

You might also like