SQL Injection

 a web security vulnerability that allows

an attacker to interfere with the
queries that an application makes to
its database.
SQL injection (SQLi)  can allow an attacker to view data that
they are not normally able to retrieve.
 might include data that belongs to
other users, or any other data that the
application can access.
 can escalate a SQL injection attack to
compromise the underlying server or
Attacker other back-end infrastructure.
 can also enable them to perform
denial-of-service attacks.

How to detect SQL injection vulnerabilities

 You can detect SQL injection manually using a systematic set of tests against every
entry point in the application. To do this, you would typically submit:

 The single quote character ' and look for errors or other anomalies.

 Some SQL-specific syntax that evaluates to the base (original) value of the entry
point, and to a different value, and look for systematic differences in the
application responses.

 Boolean conditions such as OR 1=1 and OR 1=2, and look for differences in the
application's responses.

 Payloads designed to trigger time delays when executed within a SQL query, and
look for differences in the time taken to respond.

 OAST payloads designed to trigger an out-of-band network interaction when

executed within a SQL query, and monitor any resulting interactions.
SQL injection in different parts of the query
 Most SQL injection vulnerabilities occur within the WHERE clause of a SELECT query.
 SQL injection vulnerabilities can occur at any location within the query, and within
different query types.
 In UPDATE statements, within the updated values or the WHERE clause.
 In INSERT statements, within the inserted values.
 In SELECT statements, within the table or column name.
 In SELECT statements, within the ORDER BY clause.

SQL injection examples

 There are lots of SQL injection vulnerabilities, attacks, and techniques, that occur in
different situations. Some common SQL injection examples include:

 Retrieving hidden data, where you can modify a SQL query to return additional
results.
 Subverting application logic, where you can change a query to interfere with the
application's logic.
 UNION attacks, where you can retrieve data from different database tables.
 Blind SQL injection, where the results of a query you control are not returned in
the application's responses.

Retrieving hidden data

 is a comment indicator in SQL.
 this means that the rest of the query is
-- interpreted as a comment, effectively
removing it.

WARNING: If your condition reaches an UPDATE or DELETE statement, for

example, it can result in an accidental loss of data.

Second-order SQL injection

  occurs when the application processes
user input from an HTTP request and
First-order SQL injection incorporates the input into a SQL
query in an unsafe way.

 occurs when the application takes user

input from an HTTP request and
stores it for future use.
 is usually done by placing the input
into a database, but no vulnerability
Second-order SQL injection occurs at the point where the data is
stored.
 often occurs in situations where
developers are aware of SQL injection
vulnerabilities, and so safely handle
the initial placement of the input into
the database.

How to prevent SQL injection

 You can prevent most instances of SQL injection using parameterized queries
instead of string concatenation within the query. These parameterized queries are
also know as "prepared statements".

PHP MySQL Prepared

Statements
 are very useful against SQL
injections.
 is a feature used to execute the same
(or similar) SQL statements repeatedly
with high efficiency.

 Prepare: An SQL statement template is

created and sent to the database.
Certain values are left unspecified,
Prepared statements called parameters (labeled "?")

 reduce parsing time as the preparation

on the query is done only once
(although the statement is executed
multiple times)

 are very useful against SQL injections,

because parameter values, which are
transmitted later using a different
protocol, need not be correctly escaped

 Bound parameters minimize

bandwidth to the server as you need
send only the parameters each time,
and not the whole query
 Prepared Statements / parameterized  is used to execute the same statement
statement repeatedly with high efficiency and
protect against SQL injections.
 consists of two stages: prepare and
execute.
prepare  prepare stage a statement
template is sent to the database
server. The server performs a syntax
check and initializes server internal
resources for later use.
 is followed by execute.
execute  During execute the client binds
parameter values and sends them to
the server. The server executes the
statement with the bound values
using the previously created internal
resources.

Repeated execution
 A prepared statement can be executed repeatedly. Upon every execution the current
value of the bound variable is evaluated and sent to the server. The statement is not
parsed again. The statement template is not transferred to the server again.

 Using the mysqli_result interface offers the additional benefit of flexible client-
side result set navigation.
 Bound variables are sent to the server separately from the query and thus
cannot interfere with it.
 The API does not include emulation for client-side prepared statement emulation.
 separation is sometimes considered the only security feature to prevent SQL
injection, but the same degree of security can be achieved with non-prepared
statements, if all the values are formatted correctly.