1 SQL INJECTION & COUNTERMEASURES. Outline Introduce SQL Injection SQL Injection Attack Types Prevention of SQL Injection Attack (Countermeasures) 2.

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