detecting sql injection vulnerabilities in web servicesnmsa/pdf/2009-ladc-presentation.pdf · cisuc...

CISUC Department of Informatics Engineering University of Coimbra LA

DC

20

09

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


4

Web Services Environment


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 ''='


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?


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


8

Scanners


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

Overall results analysis


10

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%

14%


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


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


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


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


15

Execute the Tests: Configuration


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


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


18

Analyze the Responses


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


20

Raw Results for Public Web Services


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


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


23

Results for Public Web Services


24

Detection Coverage


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


26

Questions?


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


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%


detecting sql injection vulnerabilities in web servicesnmsa/pdf/2009-ladc-presentation.pdf · cisuc...

Documents