1 / 26

Proposing SQL Statement Coverage Metrics

Proposing SQL Statement Coverage Metrics. Ben Smith Yonghee Shin Laurie Williams. Agenda. Motivation and Objective Testing for Security SQL Injection Vulnerabilities/Attacks Terms and Metrics Case Study Limitations Future Work. Cyber Vulnerabilities, cont’d.

senta
Download Presentation

Proposing SQL Statement Coverage Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposing SQL Statement Coverage Metrics Ben Smith Yonghee Shin Laurie Williams 1

  2. Agenda • Motivation and Objective • Testing for Security • SQL Injection Vulnerabilities/Attacks • Terms and Metrics • Case Study • Limitations • Future Work 2

  3. 3

  4. Cyber Vulnerabilities, cont’d • Averages from NVD 2003 – 2007 [1] • Input validation vulnerabilities comprise >50% of reported total • SQL Injection Vulnerabilities comprise 11% of reported total 4

  5. Objective To propose coverage metrics which determine the adequacy of a test set’s ability to mitigate SQL injection attacks. 5

  6. Unintended Functionality Missing or Incorrect Functionality Security Testing [2] Application as Coded Intended Functionality (Requirements Specification) 6

  7. SQL Injection Attacks $username = $_POST[‘username’]; $password = $_POST[‘password’]; $result = mysql_query( “select * from users where username = ‘’ OR 1=1 ---’ AND password = ‘$password’”); $firstresult = mysql_fetch_array($result); $role = $firstresult[‘role’]; $_COOKIE[‘userrole’] = $role $username = $_POST[‘username’]; $password = $_POST[‘password’]; $result = mysql_query( “select * from users where username = ‘$username’ AND password = ‘$password’”); $firstresult = mysql_fetch_array($result); $role = $firstresult[‘role’]; $_COOKIE[‘userrole’] = $role; ‘ OR 1=1 -- 7

  8. Web Application Security Web App Data Internet Query Query 8

  9. Coverage Analysis 9

  10. Theory Higher SQL Coverage Metrics  Higher System Security 10

  11. Research Plan SQL Coverage Metrics Blacklist/Input Validation Testing 11

  12. Terms and Metrics (1) Target Statement: a SQL statement which could cause a security problem when malicious input is used, for example: java.sql.Connection conn = factory.getConnection(); java.sql.PreparedStatement ps = conn.prepareStatement("UPDATE globalVariables SET value = ? WHERE name = ?;"); ps.setInt(1, value); ps.setString(2, name); java.sql.ResultSet rs = ps.executeQuery(); 12

  13. Terms and Metrics (2) Input Variable: any variable in the server-side production code which is dynamically user-assigned and sent to the database management system. For example, java.sql.Connection conn = factory.getConnection(); java.sql.PreparedStatement ps = conn.prepareStatement("UPDATE globalVariables SET value = ? WHERE name = ?;"); ps.setInt(1, value); ps.setString(2, name); java.sql.ResultSet rs = ps.executeQuery(); 13

  14. Terms and Metrics (3) Target Statement Coverage: the percentage of target statements in the production code executed/covered at least once by the test set. Input Variable Coverage: the percentage of input variables in the production code executed/covered at least once by the test set. 14

  15. Role-based web healthcare application Developed by NC State students in a security testing class Aims to be HIPAA-compliant ~7700 SLOC, 143 production classes Tomcat + MySQL 84% line coverage Case Study: iTrust [3] 15

  16. Case Study: Overview • Manually instrument iTrust to record the first execution of each target statement • Run the built-in unit tests to reveal the coverage result for both SQL statement coverage and input variable coverage • Warning: Formative Research!! 16

  17. Case Study: Results 17

  18. A few more results… • Three-tiered web applications • SQL • Tomcat • Provided test sets • Examples • Hispacta • IceScrum • Care2x? 18

  19. A few more results… 19

  20. Threats to Validity • Human error • Inaccurate analysis • May not be feasible in other systems, languages or operational environments • iTrust is highly testable, and well-tested 20

  21. Future Work • Empirical studies • SQL coverage in other open source systems • Linking SQL coverage to higher security levels • Automation • Dynamic Queries • Identification • Finer-grained metrics • Use as platform for blacklist/whitelist testing 21

  22. Very Future Work SQL Coverage Metrics Blacklist/Input Validation Testing A Framework 22

  23. References [1] United States National Vulnerability Database. http://nvd.nist.gov [2] H. H. Thompson, "Why security testing is hard," Security & Privacy Magazine, IEEE, vol. 1, no. 4, pp. 83-86, 2003. [3] iTrust website. http://sourceforge.net/projects/iTrust 23

  24. Questions? • Feedback & Comments Welcome! 24

  25. Dynamic Queries java.sql.Connection conn = factory.getConnection(); java.sql.PreparedStatement ps = null; if (user.isAdmin()) { ps = conn.prepareStatement(“select * from adminTable;"); } else { ps = conn.prepareStatement(“select * from generalTable;”); } ps.executeQuery(); 25

  26. Case Study: Instrumentation java.sql.Connection conn = factory.getConnection(); java.sql.PreparedStatement ps = conn.prepareStatement("UPDATE globalVariables set SET VALUE = ? WHERE Name = ‘Timeout’;"); ps.setInt(1, mins); SQLMarker.mark(1, 1); java.sql.ResultSet rs = ps.executeQuery(); 26

More Related