Detecting SQL Injection Vulnerabilities in Web Services

Transcription

1 Detecting SQL Injection Vulnerabilities in Web Services Nuno Antunes, {nmsa, LADC 2009 CISUC Department of Informatics Engineering University of Coimbra

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 2

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 3

4 Web Services Environment 4

5 Examples of Vulnerabilities ' OR 1=1 -- public String auth(string login, String pass) throw SQLException { String sql = "SELECT * FROM users WHERE "+ "username='" + login + "' AND "+ "password='" + pass + "'"; } "SELECT ResultSet * FROM rs = users statement.executequery(sql); WHERE username='' OR 1=1 -- ' AND ( ) password='' ; ' OR ''=' public void delete(string str) throw SQLException{ String sql = "DELETE FROM table "WHERE id='" + str + "'"; statement.executeupdate(sql); } "DELETE FROM table WHERE id='' OR '' = ''"; 5

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

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 7

8 Scanners 8

9 Overall results analysis Vulnerability Types VS1.1 VS1.2 VS2 VS3 # Vuln. # WS # Vuln. # WS # Vuln. # WS # Vuln. # WS SQL Injection XPath Injection Code Execution Possible Parameter Based Buffer Overflow Possible Username or Password Disclosure Possible Server Path Disclosure Total

10 SQL Injection % 6,5% % 11,6% False Positives Doubtful Confirmed Vulnerabilities % 25,7% VS1.1 VS1.2 VS2 VS3 14% 10

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 11

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 12

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 13

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 14

15 Execute the Tests: Configuration 15

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 16

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

18 Analyze the Responses n W n Valid call n A n Attack call 18

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 19

20 Raw Results for Public Web Services 20

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 21

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 22

23 Results for Public Web Services 23

24 Detection Coverage n Based on limited knowledge n Probably we don t know all the existing vulnerabilities 24

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 25

26 Questions? n 26

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 27

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