SQL INJECTION
&
COUNTERMEASURES
1
Outline
• Introduce SQL Injection
• SQL Injection Attack Types
• Prevention of SQL Injection Attack
(Countermeasures)
2
What is SQL injection?
• A class of code-injection attacks, in which data
provided by the user is included in an SQL
query in such a way that part of the user’s
input is treated as SQL code
3
Example of SQL injection
4
How does it happen?
5
How dangerous is it?
• The most critical Web application security risk
(OWASP)
6
SQL injection
• Two important characteristics:
– Injection mechanism
– Attack intent
7
Injection Mechanism
•
•
•
•
Injection through user input
Injection through cookies
Injection through server variables
Second-order injection
First-order
injection
8
Injection Mechanism
First-order injection
• The application processes
the input, causing the
attacker’s injected SQL
query to execute.
Second-order injection
• The application stores that
input for future use (usually in
the database), and responds
to the request.
• The attacker submits a second
(different) request.
• To handle the second request,
the application retrieves the
stored input and processes it,
causing the attacker’s injected
SQL query to execute.
9
Second-order injection
• Example
10
Attack Intent
•
•
•
•
•
Identifying injectable parameters
Performing database finger-printing
Determining database schema
Extracting data
Adding or modifying data
11
Attack Intent
•
•
•
•
•
Performing denial of service
Evading detection
Bypassing authentication
Executing remote commands
Performing privilege escalation
12
Example application
SELECT
FROM
WHERE
accounts
users
login = ? AND pass = ? AND pin = ?
13
SQLIA Types
• Present the different kinds of SQLIAs known to
date
• Many of them are used together or
sequentially, depending on the specific goals
of the attacker
14
Tautologies
• Inject code in one or more conditional
statements so that they always evaluate to
true
SELECT
FROM
WHERE
accounts
users
login = ‘’ or 1=1 --’ AND pass = ‘’
AND pin =
15
Illegal/Logically Incorrect Queries
• Inject statements that cause a syntax, type
conversion, or logical error into the database
SELECT
FROM
WHERE
accounts
users
login = ‘’ AND pass = ‘’
AND pin = convert(int, (select name
from sysobjects where xtype = ‘u’))
”Microsoft OLE DB Provider for SQL Server (0x80040E07) Error
converting nvarchar value ’CreditCards’ to a column of data
type int.”
16
Union Query
• Inject a statement of the form:
UNION SELECT <rest of injected query>
SELECT accounts FROM users WHERE login = ‘’ UNION
SELECT cardNo from CreditCards where
acctNo = 10032 --‘ AND pass = ‘’ AND pin =
17
Piggy-Backed Queries
• Include new and distinct queries that “piggyback” on the original query
SELECT accounts FROM users WHERE login = ‘doe’
AND pass = ‘’; drop table users --’ AND pin =
18
Stored Procedures
• Try to execute stored procedures present in
the database
19
Stored Procedures
SELECT accounts FROM users WHERE login = ‘doe’
AND pass = ‘’; shutdown;--’ AND pin =
20
Inference
• Inject commands into the site and then
observe how the function/response of the
website changes
– Blind injection
– Timing attacks
21
Blind SQL injection
• The information must be inferred from the
behavior of the page by asking the server
true/false questions
22
Timing Attacks
• Gain information by observing timing delays in
the response of the database
23
Alternate Encoding
• Employ alternate methods of encoding attack
strings
SELECT accounts FROM users
WHERE login = ‘doe’; exec(char(0x73697574646f776e)) --’
AND pass = ‘’ AND pin =
24
Prevention of SQLIAs
• The root cause of SQL injection vulnerabilities
is insufficient input validation
• Solution:
– Defensive coding practices
– Detection & Prevention techniques
25
Defensive coding practices
•
•
•
•
Input type checking
Encoding of inputs
Positive pattern matching
Identification of all input sources
26
Defensive coding practices
• Prone to human error
• Not as rigorously & completely applied as
automated techniques
• Weakened by the widespread promotion of
so-called “pseudo-remedies”
27
Detection & Prevention techniques
• Web Application SQL Injection Preventer
(WASP)
• AMNESIA
• SQLrand
• ….
28
Web Application SQL Injection
Preventer (WASP)
• Basic idea: allow only developer-trusted
strings to form sensitive parts of a query
• Solution:
– Positive tainting
– Syntax-aware evaluation
29
Positive tainting
• Identify & mark trusted data instead of untrusted
data
• Some features:
–
–
–
–
Use a white-list, rather than black-list
Incompleteness -> false positives
Straightforward & less error prone
WASP provides developers with a mechanism for
specifying sources of external data that should be
trusted
30
Syntax-aware evaluation
• Cannot simply forbid the use of untrusted
data in queries
• Some features:
– Consider the context in which trusted & untrusted
data is used: permit untrusted data to be only in
string and numeric literals
– Performed right before the query is sent to the
database
31
Implementation
32
Empirical Evaluation
• Testing for false negatives
• Testing for false positives
• Overhead measurements
33
Testing for false negatives
34
Testing for false positives
35
Overhead measurements
36
AMNESIA
• Analysis and Monitoring for NEutralizing SQLInjection Attacks
• Basic insights:
– Code contains enough information to accurately
model all legitimate queries
– A SQLIA will violate the predicted model
37
AMNESIA
• Solution: uses a combination of static analysis
& runtime monitoring
• 4 main steps:
– Identify hotspots
– Build SQL-query models
– Instrument application
– Runtime monitoring
38
Identify hotspots
39
Build SQL query model
• Use Java String Analysis to construct
character-level automata
• Parse automata to group characters into SQL
tokens
40
Instrument application
• For each hotspot, we insert a call to the
monitor before the call to the database
41
Runtime monitoring
• Check queries against SQL query model
Normal user
42
Runtime monitoring
• Check queries against SQL query model
Malicious user
43
Implementation
44
SQLrand
• Extends the application of Instruction-Set
Randomization to the SQL: appending a
random integer to SQL standard keywords
• Example:
45
SQLrand system architecture
46
Implementation
• Two primary components:
– De-randomization element
– Communication protocol between the client &
database system
47
De-randomization element
• Required a modified SQL parser that expected
the suffix of integers applied to all keywords
• Utilized two popular tools for writing
compilers and parsers: flex & yacc
48
Communication protocol
• As a “middle man”, the proxy had to conceal
its identity by masquerading as the database
to the client & vice versa
CLIENT
PROXY
Simply change
port number
DBMS
Using API the
DBMS provides
49
Evaluation
• Evaluation with respect to attack types
50
The end.
51