Post on 16-Jan-2016
1
SQL INJECTION&
COUNTERMEASURES
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
8
First-order injection
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
13
SELECT accountsFROM usersWHERE login = ? AND pass = ? AND pin = ?
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
15
SELECT accountsFROM usersWHERE login = ‘’ or 1=1 --’ AND pass = ‘’
AND pin =
Illegal/Logically Incorrect Queries
• Inject statements that cause a syntax, type conversion, or logical error into the database
16
SELECT accountsFROM usersWHERE 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.”
Union Query
• Inject a statement of the form:UNION SELECT <rest of injected query>
17
SELECT accounts FROM users WHERE login = ‘’ UNION SELECT cardNo from CreditCards whereacctNo = 10032 --‘ AND pass = ‘’ AND pin =
Piggy-Backed Queries
• Include new and distinct queries that “piggy-back” on the original query
18
SELECT accounts FROM users WHERE login = ‘doe’ AND pass = ‘’; drop table users --’ AND pin =
Stored Procedures
• Try to execute stored procedures present in the database
19
Stored Procedures
20
SELECT accounts FROM users WHERE login = ‘doe’ AND pass = ‘’; shutdown;--’ AND pin =
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
24
SELECT accounts FROM users WHERE login = ‘doe’; exec(char(0x73697574646f776e)) --’
AND pass = ‘’ AND pin =
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 SQL-Injection 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
42
Normal user
Runtime monitoring
• Check queries against SQL query model
43
Malicious user
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
49
CLIENT PROXY DBMS
Using API the DBMS provides
Simply change port number
Evaluation
• Evaluation with respect to attack types
50
The end.
51