1 / 19

Candid : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations

Candid : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations. 2008. 09. 25 Presented by Jeong-hoon , Park. Outline. SQL Command Injection Attack (SQLCIA) Prepare Statements High level idea: Dynamic Candidate Evaluations Proposed Method Evaluation.

bryson
Télécharger la présentation

Candid : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations

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. Candid : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations 2008. 09. 25 Presented by Jeong-hoon, Park

  2. Outline • SQL Command Injection Attack (SQLCIA) • Prepare Statements • High level idea: Dynamic Candidate Evaluations • Proposed Method • Evaluation

  3. SQL Command Injection Attack (SQLCIA) PhoneBook Record Manager User Name John Password 123 Display Delete submit SELECT * FROM phonebook WHERE username= ‘John’ AND Password = ‘123’ John’s phonebookentries are displayed

  4. SQL Command Injection Attack (SQLCIA) – CONT. PhoneBook Record Manager User Name John’ OR 1=1 -- Password what? Display Delete submit SELECT * FROM phonebook WHERE username= ‘John’ OR 1=1 -- ’ AND Password = ‘what?’ Allphonebook entries are displayed Attack!!!

  5. SQL Command Injection Attack (SQLCIA) – CONT.

  6. SQL Command Injection Attack (SQLCIA) – CONT.

  7. SQL Command Injection Attack (SQLCIA) – CONT. • Most Systems separate code from data • SQL queries can be constructed by arbitrary sequences of programming constructs that involve string operations like • Concatenation, substring… • Such Construct also involve (trusted / untrusted) user inputs. • Queries intended by the programmer can be “changed” by untrusted user input.

  8. SQL Command Injection Attack (SQLCIA) – CONT. SELECT * FROM phonebook WHERE username= ‘John’ AND Password = ‘123’ Benign Query <sql_query> <literal> <id> <where_clause> <cond_term> <cond_term> <cond> <cond> <literal> <id> WHERE username= ‘John’ AND Password = ‘123’

  9. SQL Command Injection Attack (SQLCIA) – CONT. SELECT * FROM phonebook WHERE username= ‘John’ OR 1=1 -- ’ AND Password = ‘what?’ Attack Query <sql_query> <cond_term> <literal> <id> <where_clause> <cond_term> < comment> <cond> <cond> <literal> <literal> WHERE username= ‘John’ OR 1=1 -- ’ AND Password = ‘what?’

  10. Prepare Statements • Prepare statement in Commercial DBMS is useful in preventing the SQLCIA • It separates query structure from data • Statements are not parsed for every user input • ex) • Mysql> PREPARE stmt_name FROM “SELECT * FRM phonebook WHERE username=? AND password=?”

  11. Prepare Statements – CONT. • The way to prevent SQLCIA is replacing all the query statements in legacy application by the PREPARE statements • But, replacing them automatically with static techniques is very hard. • Require to guess the structure of query at each query issue location in program code. • Query issued at a location depends on path taken in program • So, Problem is • How can we dynamically infer the benign query structure?

  12. High level idea: Dynamic candidate Evaluations Actual Input Database Actual Query matching Application SQL Parser Candidate Input Candidate Query Non-matching

  13. High level idea: Dynamic candidate Evaluations – CONT. • But, It is undecidablebecause the candidate inputs • Should be Benign • Issue a query at the same query issue location by following the same path in the program PhoneBook Record Manager User Name John Password 123 Display Delete submit

  14. Proposed Method • Manifestly benign inputs • For every string create a sample string of ‘a’s having the same length. • Candidate Input: • Uname=‘aaaa’ • Pwd = ‘aaa’ • For integer or boolean variable, use original input • Follow the original control flow by using original inputs PhoneBook Record Manager User Name John Password 123 Display Delete submit

  15. Proposed Method – CONT. User Input: uname=“John” pwd=“12d” display=false Candidate Input: uname=“aaaa” pwd=“aaa” Input: String uname, String pwd, booleandisplay Candidate Input(2): uname=“aaaa” pwd=“aaa” display=true Display? display == false display == true “select * from phonebook where username=‘” + uname +” ‘ and password=‘” + pwd +”’ ”; “delete from phonebook where username=‘” + uname +” ‘ and password=‘” + pwd +”’ ”; Actual Query: Delete from phonebook where username=‘John’ and password=‘12d’ Candidate Query: Delete from phonebook where username=‘aaaa’ and password=‘aaa’

  16. Proposed Method – CONT. Web Application CANDID Program Transformer Safe Web Application

  17. Proposed Method – CONT. • Transformation Example Input: String uname, String pwd, booleandisplay String uname_c, String pwd_c Uname=input_1, pwd=input_2, delete=input_3; Uname_c=createSample(uname), pwd_c= createSample(pwd); Display? display == true Query=“Select * from phonebook where username=‘” + uname +” ‘ and password=‘” + pwd +”’ ”; Query_c=“Select * from phonebook where username=‘” + uname_c +” ‘ and password=‘” + pwd_c +”’ ”; display == false Query=“delete from phonebook where username=‘” + uname +” ‘ and password=‘” + pwd +”’ ”; Query_c=“delete from phonebook where username=‘” + uname_c +” ‘ and password=‘” + pwd_c +”’ ”; execute_query(query) If(match_queries(query,query_c)==true) execute_query(query)

  18. Proposed Method – CONT. • Implementation Architecture • Offline View • Online View Original Program JAVA Bytecode Transformer Instrumented Program Web Server SQL Parser Tree Checker Database Browser Instrumented Program

  19. Evaluation Attack Evaluation Result Performance Overhead

More Related