Detecting SQL Injection Vulnerabilities in Web Services Nuno - - PowerPoint PPT Presentation

CISUC Department of Informatics Engineering University of Coimbra

LADC 2009

Detecting SQL Injection Vulnerabilities in Web Services

Nuno Antunes, Marco Vieira {nmsa, mvieira}@dei.uc.pt

2

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

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

3

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

assess services’ security

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

4

Web Services Environment

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

5

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 '' = ''"; ' OR ''='

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

6

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?

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

7

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 n Analysis: analysis and systematization of results

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

8

Scanners

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

9

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 Code Execution 1 1 1 1 Possible Parameter Based Buffer Overflow 4 3 Possible Username or Password Disclosure 47 3 Possible Server Path Disclosure 17 5 Total 228 40 236 40 25 5 103 22

Overall results analysis

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

10

SQL Injection

116 116 17 21 14 26 8 5 87 83 9 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% 14%

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

11

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

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

12

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

the vulnerabilities

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

13

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

domains) have to be provided by the user

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

14

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)

n It is up to the user to specify the size of this subset

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

15

Execute the Tests: Configuration

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

16

Execute the Tests: Type of Attacks

n Examples: n A total of 137 types

n The list can be continuously improved n Just add new attack patterns to a configuration file

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

17

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.,

no error) are in the top of the list

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

18

Analyze the Responses

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

n W

n Valid

call

n A

n Attack

call

19

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

effectiveness of our tool to the commercial ones

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

20

Raw Results for Public Web Services

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

21

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

with valid inputs

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

22

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

reported vulnerability is classified as doubtful

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

23

Results for Public Web Services

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

24

Detection Coverage

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

n Based on limited knowledge

n Probably we don’t know all the existing vulnerabilities

25

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

different types of vulnerabilities and to other domains

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

26

Questions?

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

n http://eden.dei.uc.pt/~mvieira/

27

Results for TPC-App Web Services

n Access to the source code

n Asked a team of security experts to find SQL Injection

Vulnerabilities

n Thorough code inspection and penetration tests

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil

28

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% n The false positives rate was 10%

Marco Vieira LADC 2009, September 01-04, João Pessoa, Brazil