Detecting SQL Injection Vulnerabilities in Web Services

CISUC

Department of Informatics Engineering

University of Coimbra

LAD

C

2009

Detecting SQL Injection

Vulnerabilities in Web

Services

Nuno Antunes,

Marco Vieira

Outline

n

Web Services

n

Web Security Scanners

n

New Approach for the Detection of SQL

Injection Vulnerabilities in WS

n

Experimental Evaluation

n

Conclusions

Web Services

n

Web services are becoming a strategic

component in a wide range of organizations

n

Components that can be remotely invoked

n

Well defined interface

n

Web services are extremely exposed to

attacks

n

Any existing vulnerability will most probably be

uncovered/exploited

n

Both providers and consumers need to

Examples of Vulnerabilities

public String auth(String login, String pass)

throw SQLException {

String sql = "SELECT * FROM users WHERE "+

"username='" + login + "' AND "+

"password='" + pass + "'";

ResultSet rs = statement.executeQuery(sql);

(…)

}

public void delete(String str) throw SQLException{

String sql = "DELETE FROM table

"WHERE

id='" + str + "'";

statement.executeUpdate(sql);

}

' OR 1=1

--"

SELECT * FROM users WHERE username='

'

OR 1=1 --

' AND

password=''“;

"DELETE FROM table WHERE id='

' OR '' = '

'";

Web Security Scanners

n

Easy and widely-used way to test

applications searching vulnerabilities

n

Use fuzzing techniques to attack applications

n

Penetration testing

n

Perform thousands of tests in an automated

way

n

What is the effectiveness of these tools?

n

Can programmers rely on these tools?

Experimental Study

n

Apply leading commercial scanners in public

web services

n

300 Web Services tested

n

Randomly selected

n

4 Scanners used

n

Approach:

n

Preparation

: select services and scanners

n

Execution

: test the services using the scanners

n

Verification

: identify false positives

Vulnerability Types

VS1.1

VS1.2

VS2

VS3

# Vuln.

# WS

# Vuln.

# WS

# Vuln.

# WS

# Vuln.

# WS

SQL Injection

217

38

225

38

25

5

35

11

XPath Injection

10

1

10

1

0

0

0

0

Code Execution

1

1

1

1

0

0

0

0

Possible Parameter Based

Buffer Overflow

0

0

0

0

0

0

4

3

Possible Username or

Password Disclosure

0

0

0

0

0

0

47

3

Possible Server Path

Disclosure

0

0

0

0

0

0

17

5

Total

228

40

236

40

25

5

103

22

SQL Injection

116

116

17

21

14

26

8

5

87

83

9

0

25

50

75

100

125

150

175

200

225

VS1.1

VS1.2

VS2

VS3

False Positives

Doubtful

Confirmed Vulnerabilities

40%

37%

11,6%

6,5%

32%

25,7%

Can we do better?

n

Yes, we can!

J

n

We propose a new approach to detect SQL Injection

vulnerabilities in web services code

n

Main improvements:

n

A representative workload to exercise the services and

understand the expected behavior

n

A broader set of attacks

n

Well defined rules to analyze the service's responses

n

To improve coverage and remove false positives

n

Completely automatic

Execution Steps

1.

Prepare the tests

1.1. Gather information about the web service’ operations,

call parameters, data types, and input domains

1.2. Generate the workload

2.

Execute the tests

2.1. Execute the workload to understand the expected

behavior of the service in the absence of attacks

2.2. Perform the attacks to trigger faulty behaviors and

disclose SQL Injection vulnerabilities

3.

Analyze the responses to detect and confirm

Prepare the Tests: Gather Information

n

Web service interfaces are described as a

WSDL file

n

This file is processed automatically to obtain:

n

Operations

n

Call parameters

n

Data types

n

The valid values for each parameter (i.e., input

Prepare the Tests: Generate the Workload

n

Two options:

n

User-defined workload

n

Random workload

n

Random workload is generated automatically

n

Generate test values for each input parameter

n

Generate test calls for each operation

n

Select test calls for each operation

n

It may be unfeasible to use a workload based on all the test

calls generated (e.g., due to time constraints)

Execute the Tests: Type of Attacks

n

Examples:

n

A total of 137 types

Execute the Tests: Attacks Generation

n

Mutation of the workload test calls

n

Valid values are replaced by malicious values

n

Number of attacks can be extremely large, e.g.:

n

3 operations with 5 parameters each

n

A workload with 25 test calls per operation

n

137 attack types

è

52500 attacks

n

The tool allows specifying the number of test

calls to be used for the attack load generation

n

The original test calls are ranked based on their ability to

help us detecting vulnerabilities

n

e.g. test calls that that lead to valid web service responses (i.e.,

Analyze the Responses

n

W

n

Valid

call

n

A

n

Attack

Experimental Evaluation

n

Web services tested

n

262 public web services

n

Four steps:

n

Preparation

: select a large set of web services.

n

Execution

: use the vulnerability scanners to scan the

services to identify potential vulnerabilities

n

Verification

: perform manual testing to confirm that the

vulnerabilities identified do exist

n

Analysis

: analyze the results and compare the

What about false positives? (1)

n

Manual checking

n

Reported vulnerabilities are false positives if:

n

The error/answer obtained is related to a robustness

problem and not to a SQL command

n

e.g., NumberFormatException

n

The error/value in response is not caused by the

elements "injected" by the tool

n

i.e., the same problem occurs when the service is executed

What about false positives? (2)

n

Reported vulnerabilities are confirmed if:

n

It is possible to observe that a SQL command was

invalidated by the values "injected" by the tool

n

The “injected” values lead to exceptions raised by the

database server

n

It is possible to access unauthorized services or web

pages

n

e.g., by breaking the authentication process using SQL

Injection

n

If none of these rules can be applied then a

Detection Coverage

n

Based on limited knowledge

Conclusions

n

Results show that our approach achieves

much better results than commercial tools

n

Concerning both coverage and false positives

n

Our tool was able to detect vulnerabilities that

were not detected by the commercial scanners

n

And, at the same time, was able to eliminate most of

the false positives

n

We show that it is possible to improve the

state of the art in vulnerabilities detection

n

Future work includes extending our approach to

Questions?

Results for TPC-App Web Services

n

Access to the source code

n

Asked a team of security experts to find SQL Injection

Vulnerabilities

False Positives and Coverage

n

The team of security experts detected 26

vulnerabilities

n

4 (~15%) were confirmed as false positives

n

Our tool detected 18 vulnerabilities

n

Plus two false positives

n

All the vulnerabilities detected by the tools

were also identified by the security team

n

The coverage of our tool was ~81%