Скачать презентацию CANDID Preventing SQL Injection Attacks Using Dynamic Скачать презентацию CANDID Preventing SQL Injection Attacks Using Dynamic

2e98a6220c23898b0dd257498bb245aa.ppt

  • Количество слайдов: 19

CANDID : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations V. N. Venkatakrishnan Assistant CANDID : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations V. N. Venkatakrishnan Assistant Professor, Computer Science University of Illinois at Chicago Joint work with: Sruthi Bandhakavi (UIUC) Prithvi Bisht (UIC) and P. Madhusudan (UIUC)

SQL Injection : Typical Query Phonebook Record Manager SELECT * FROM phonebook WHERE username SQL Injection : Typical Query Phonebook Record Manager SELECT * FROM phonebook WHERE username = Username John Password open_sesame Display Delete Submit Web browser User Input Web Page ‘John’ AND password = ‘open_sesame’ John’s phonebook entries are displayed Application Server Query Result Set Database

SQL Injection : Typical Query Phonebook Record Manager SELECT * FROM phonebook WHERE username SQL Injection : Typical Query Phonebook Record Manager SELECT * FROM phonebook WHERE username = ‘John’ OR 1=1 --AND password = Username John’ OR 1=1 -‘not needed’ Password not needed Display Delete Submit Web browser User Input Web Page All phonebook entries are displayed Application Server Query Result Set Database

XS S SQL Injection Attacks are a Serious Threat CVE Vulnerabilities (2004) L SQ XS S SQL Injection Attacks are a Serious Threat CVE Vulnerabilities (2004) L SQ tion ec Inj S XS L SQ ction e Inj CVE Vulnerabilities (2006) Card. Systems security breach(2006): 263, 000 customer credit card numbers stolen, 40 Million more exposed

Talk Overview Web Application CANDID Program Transformer Safe Web Application [ACM CCS’ 07] Talk Overview Web Application CANDID Program Transformer Safe Web Application [ACM CCS’ 07]

SQL Injection • Most systems separate code from data • SQL queries can be SQL Injection • Most systems separate code from data • SQL queries can be constructed by arbitrary • • sequences of programming constructs that involve string operations • Concatenation, substring …. Such construct also involve (untrusted) user inputs • Inputs should be mere “data”, but in case of SQL results in “code” Result: Queries intended by the programmer can be “changed” by untrusted user input

Parse Structure for a Benign Query <sql_query> <where_clause> Select * from Table <cond_term> <cond> Parse Structure for a Benign Query Select * from Table WHERE username = ‘John’ AND password = ‘os’

Parse Structure for a Attack Query <sql_query> <where_clause> <cond_term> <comment> <cond_term> Select * from Parse Structure for a Attack Query Select * from Table WHERE username = ‘John’ OR 1=1 -- AND …

Attacks Change Query Structure Boyd et. al [BK 04], ANCS ; Buehrer et. al. Attacks Change Query Structure Boyd et. al [BK 04], ANCS ; Buehrer et. al. [BWS 05], SEM; Halfond et. al. [HO 05], ASE; Nguyen-Tuong et. al. [NGGSE 05], SEC; Pietraszek et. al[PB 05], RAID; Valeur et. al. [VMV 05], DIMVA; Su et. al. [SW 06], POPL. . . WHERE username = ‘John’ OR 1=1 --’ AND. . . WHERE username = ‘John’ AND password = ‘os’ Benign Query Attack Query

Prepared Statements • mysql> PREPARE <sql_query> stmt_name FROM Prepared Statements • mysql> PREPARE stmt_name FROM " SELECT * FROM phonebook WHERE username = ? AND password = ? ” placeholder for input • Separates query • structure from data Statements are NOT parsed for every user input WHERE username = ‘? ’ AND password = ‘? ’

Legacy Applications • For existing applications adding PREPARE statements • will prevent SQL injection Legacy Applications • For existing applications adding PREPARE statements • will prevent SQL injection attacks Hard to do automatically with static techniques • Need to guess the structure of query at each query • issue location Query issued at a location depends on path taken in program • Human assisted efforts can add PREPARE statements • Costly effort • Problem: Is it possible to dynamically infer the benign query structure?

High level idea : Dynamic Candidate Evaluations • Create benign sample inputs (Candidate Inputs) High level idea : Dynamic Candidate Evaluations • Create benign sample inputs (Candidate Inputs) for every user input • Execute the program simultaneously over actual inputs and candidate inputs • Generate a candidate query along with the actual query • The candidate query is always non-attacking • Actual query is possibly malicious • Issue the actual query only if parse structures match Actual I/P Candidate I/P Actual Query Application Candidate Query Match SQL Parser DB No Match How can we guess benign candidate inputs for every execuction?

Finding Benign Candidate Inputs • Have to create a set of candidate inputs which Finding Benign Candidate Inputs • Have to create a set of candidate inputs which • Are Benign • Issue a query at the • same query issue location By following the same path in the program • Problem: Hard • In the most general case it is undecidable Candidate Path Actual Path Query Issue Location

Our Solution : Use Manifestly benign inputs Phonebook Record Manager User Name Password • Our Solution : Use Manifestly benign inputs Phonebook Record Manager User Name Password • For every string create a John • os Display Submit Delete • • • sample string of ‘a’ s having the same length Candidate Input: uname = ‘aaaa’ pwd = ‘aa’ Shadow every intermediate string variable that depends on input For integer or boolean variable, use the originals Follow the original control flow

Evaluate conditionals only on actual inputs Candidate Input : uname = “aaaa” pwd = Evaluate conditionals only on actual inputs Candidate Input : uname = “aaaa” pwd = “aa” display = true input str uname, str pwd, bool display true User Input : uname = “john” pwd = “os” display = false Candidate Input : uname = “aaaa” pwd = “aa” false display? query = ‘SELECT * from phonebook WHERE username = ‘ + uname + ’ AND password = ’ + pwd +’ query = ‘DELETE * from phonebook WHERE username = ‘ + uname + ’ AND password = ’ + pwd +’ Actual Query: DELETE * from phonebook WHERE username = ‘john’ AND password = ’ os’ Candidate Query: DELETE * from phonebook WHERE username = ‘aaaa’ AND password = ’aa’

CANDID Program Transformation Example i/p str uname; i/p str pwd; i/p bool delete; str CANDID Program Transformation Example i/p str uname; i/p str pwd; i/p bool delete; str uname_c; str pwd_c; uname = input_1, pwd = input_2, delete = input_3; uname_c = create. Sample(uname) , pwd_c = create. Sample(pwd); false true display? query = DELETE * from phonebook WHERE username = ‘ + uname + ’ AND password = ’ + pwd +’ query_c = DELETE * from phonebook WHERE username = ‘ + uname_c + ’ AND password = ’ + pwd_c +’; query = SELECT * from phonebook WHERE username = ‘ + uname + ’ AND password = ’ + pwd +’ ; query_c = SELECT * from phonebook WHERE username = ‘ + uname_c + ’ AND password = ’ + pwd_c +’; if(match_queries(query, query_c) == true) execute_query(query)

Resilience of CANDID Input Splitting “Alan Turing” space_index = 4 fn = input[0. . Resilience of CANDID Input Splitting “Alan Turing” space_index = 4 fn = input[0. . 3] = “Alan” ln = input[5. . 9] = “Turing” Input “aaaaaa” Input Instrumented Splitting Input Splitting Function space_index = 4 fn_c = input_c[0. . 3] = “aaaa” ln_c = input_c[5. . 9] = “aaaaaa” SELECT. . . WHERE first_name = “Alan” AND last_name = “Turing” Query SELECT. . . WHERE first_name = “aaaa” AND last_name = “aaaaaa”

CANDID Implementation Architecture n. Offline View java bytecode Original Program n. Online Instrumented Web CANDID Implementation Architecture n. Offline View java bytecode Original Program n. Online Instrumented Web Application Java Bytecode transformer View Web Server Tomcat server SQL Parse Tree Checker java DB Browser Instrumented Web Application java bytecode My. Sql

Thank You Questions? Acknowledgments: xkcd. com Thank You Questions? Acknowledgments: xkcd. com