SQL injection is a web security vulnerability that allows attackers to interfere with or gain access to a database through a web application. It occurs when user input is not validated for SQL keywords and special characters that could modify the intended SQL queries. Attackers can use SQL injection to read sensitive data from the database, modify database contents, or even execute administrative operations. Proper input validation and output encoding can help prevent SQL injection attacks.

1. SQL INJECTION
Suraj Tiwari

2. What is Sql Injection ?.
SQL Injection (SQLi) refers to an injection attack wherein an attacker can execute malicious SQL statements
(also commonly referred to as a malicious payload) that control a web application’s database server (also
commonly referred to as a Relational Database Management System – RDBMS). Since an SQL Injection
vulnerability could possibly affect any website or web application that makes use of an SQL-based
database, the vulnerability is one of the oldest, most prevalent and most dangerous of web application
vulnerabilities.

3. How sql injection work.
In order to run malicious SQL queries against a database server, an attacker must first find an input within
the web application that is included inside of an SQL query.
In order for an SQL Injection attack to take place, the vulnerable website needs to directly include user input
within an SQL statement. An attacker can then insert a payload that will be included as part of the SQL
query and run against the database server.
Simple example:
A simple example of an SQL Injection payload could be something as simple as setting the password field
to
password’ OR 1=1

4. Pseudo-code
# Define POST variables
uname = request.POST['username']
passwd = request.POST['password']
# SQL query vulnerable to SQLi
sql = “SELECT id FROM users WHERE username=’” + uname + “’ AND password=’” + passwd + “’”
# Execute the SQL statement
database.execute(sql)
This would result in the following SQL query being run against the database server.
SELECT id FROM users WHERE username=’username’ AND password=’password’ OR 1=1’

5. Comment base
An attacker can also comment out the rest of the SQL statement to control the execution of the SQL query
further.
-- MySQL, MSSQL, Oracle, PostgreSQL, SQLite
' OR '1'='1' --
' OR '1'='1' /*
-- MySQL
' OR '1'='1' #
-- Access (using null characters)
' OR '1'='1' %00
' OR '1'='1' %16

6. Types of sql Injection
Sql
Injection
Types
Escape
Charatcter
Incorrect
Type
handling
Blind
Sql
Injection
Condition
al
Response
Second order
Sql
Injection

7. Incorrectly filtered escape characters
This form of SQL injection occurs when user input is not filtered for escape characters and is then passed
into an SQL statement. This results in the potential manipulation of the statements performed on the
database by the end-user of the application.
The following line of code illustrates this vulnerability:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"

8. Incorrect type handling
This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked for type
constraints. This could take place when a numeric field is to be used in a SQL statement, but the
programmer makes no checks to validate that the user supplied input is numeric.
For example:
statement := "SELECT * FROM userinfo WHERE id =" + a_variable + ";"
will drop (delete) the "users" table from the database, since the SQL becomes:
SELECT * FROM userinfo WHERE id=1; DROP TABLE users;

9. Blind sql Injection
Blind SQL Injection is used when a web application is vulnerable to an 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.] There are
several tools that can automate these attacks once the location of the vulnerability and the target
information has been established.

10. Conditional response
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
Example:
the URL http://books.example.com/showReview.php?ID=5 would cause the server to run the query
SELECT * FROM bookreviews WHERE ID = 'Value(ID)';

11. Second order sql Injection
Second order SQL injection occurs when submitted values contain malicious commands that are stored
rather than executed immediately. In some cases, the application may correctly encode an SQL statement
and store it as valid SQL. Then, another part of that application without controls to protect against SQL
injection might execute that stored SQL statement. 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

12. Some common examples
SELECT ItemName, ItemDescription
FROM Items
WHERE ItemNumber = 999 OR 1=1
This will show you all the recorde which is save in field ItemName and ItemDescription
SELECT ItemName, ItemDescription
FROM Items
WHERE ItemNumber = 999; DROP TABLE USERS
This will drop all the records of table users table

13. Sql Prevention and Mitigation
There are several effective ways to prevent SQLI attacks from taking place, as well as
protecting against them, should they occur.
The first step is input validation (a.k.a. sanitization), which is the practice of writing code that
can identify illegitimate user inputs.

14. Sql Prevention and Mitigation
While input validation should always be considered best practice, it is rarely a foolproof solution. The reality
is that, in most cases, it is simply not feasible to map out all legal and illegal inputs—at least not without
causing a large amount of false positives, which interfere with user experience and an application’s
functionality.
Modern web application firewalls are also often integrated with other security solutions. From these, a WAF
can receive additional information that further augments its security capabilities.

15. THANK
YOU