Application Layer Intrusion Detection for SQL Injection (2006)

My research in computer science, presented to the ACM Southeastern Conference in March, 2006.

The paper is available free of charge from my website at http://rietta.com/papers/rietta_acmse2006.pdf. Originally published on my Georgia Tech website prior to my graduation.

It's available through the ACM Digital Library at:
http://dl.acm.org/citation.cfm?id=1185564

See the citations for the underlaying paper in Google Scholar:
http://scholar.google.com/scholar?hl=en&q=application+layer+intrusion+detection+for+sql+injection&btnG=&as_sdt=1%2C11&as_sdtp=

Transcript

1. Application Layer Intrusion Detection for SQL Injection by Frank S. Rietta For ACMSE’06, 11 March 2006
2. 2 Presentation Overview •  Three big dangers of SQL Injection Attacks •  Web Apps, and ineffective DBMS access control, open the door to increased exposure •  Database-host-based IDS methods •  ARM yourself against Injection Attacks
3. 3 Introduction to the SQL Injection Threat •  Three big dangers of SQL Injection Attacks •  Web Apps, and ineffective DBMS access control, open the door to increased exposure •  Database-host-based IDS methods •  ARM yourself against Injection Attacks
4. 4 The Big Three Dangers of SQLIA’s SQL Injection Attacks (SQLIA’s) can lead to: •  Information disclosure •  Unauthorized tampering with data •  Arbitrary code execution
5. 5 Introduction to Vulnerable Web Applications •  Three big dangers of SQL Injection Attacks •  Web Apps, and ineffective DBMS access control, open the door to increased exposure •  Database-host-based IDS methods •  ARM yourself against Injection Attacks While SQLIA’s are not unique to web applications, they are often wide open for access and allow increased exposure to surveillance by attackers.
6. 6 Web Applications: The Good, Bad, & Ugly •  Web applications are everywhere to be found and generally open to the Internet •  Pass data through firewalls and network security •  Provide access to databases! DBMS WWW Users
7. 7 Ineffective DBMS Access Control •  “God” users often have unnecessary permissions to one or more databases. •  Role-based access control would be appropriate for many applications, but is often not used. •  Developers leave security entirely up to the application, rendering the DBMS powerless to mitigate SQL injection risks.
8. 8 SQL Templates and String Manipulation •  Often SQL statements are formed by filling user and application supplied data into a preexisting query template. •  A SQLIA is the result of clever user-supplied input changing the meaning of the query through. •  Parameterization attacks are the most common venue for exploitation.
9. 9 1st Order Parameter Replacement SELECT * FROM Directory WHERE LastName LIKE ‘${NAME}’ ; SELECT * FROM Directory WHERE LastName LIKE ‘frank’ OR 1=1 UNION SELECT user, password FROM mysql.user WHERE ‘q’=‘q’ OR ‘’ Fetches a full listing of MySQL user table, including passwords!
10. 10 2nd Order Parameter Replacement SELECT * FROM Listing WHERE LastName=‘${NAME}’ OR LastName =‘${NAME}’ SELECT * FROM Listing WHERE LastName = ‘Bob’ OR 1=1 OR LastName = ‘Bob’ OR 1=1 Tautologies are typical in SQL injection attacks. Usually always evaluating to true.
11. 11 Unquoted Numerical Parameter UPDATE Financial_Records SET Salary = ${NEW_SALARY} WHERE Name = '${NAME}' Without quotes in the template, any string literal other than a number will be part of the SQL statement and will not be treated as a literal by the DBMS, resulting in a direct injection.
12. 12 Review of Parameterization Attacks •  A template has one or more parameters placed to make the SQL query for submission to the DBMS •  Dangling parameters are often exploited •  Unquoted numerical parameters are the the easiest to exploit •  Trampoline attacks use values retrieved from the database to attack parameters in new queries
13. 13 IDS Sensors for Network Security •  Three big dangers of SQL Injection Attacks •  Web Apps, and ineffective DBMS access control, open the door to increased exposure •  Database-host-based IDS methods •  ARM yourself against Injection Attacks Many IDS’s are network-centric, but app. layer sensors can take advantage of context & domain knowledge.
14. 14 General Intrusion Detection Methods •  Signatures •  Honey Tokens •  Anomaly Detection
15. 15 Proposed Anomaly Detection Model •  Consider SQL traffic for a particular application and user in its full context •  Utilize domain knowledge of SQL •  Look for things such as: •  Unexpected constructs •  Query length and encoding •  Keyword usage •  Compare weighted average to a threshold •  Similar to the approach used by SpamAssassin
16. 16 Improving Coding Practices for Security •  Three big dangers of SQL Injection Attacks •  Web Apps open the door to increased exposure •  Database-host-based IDS methods •  ARM yourself against Injection Attacks Security is not the sum of security features. An IDS, network or app. layer, is not a silver bullet.
17. 17 Improving Coding Practices for SQL •  Certain dangerous language features, such as unquoted numbers should be avoided. •  Coding policies, that is “best practices,” should be developed in such a way as to be automatically enforced. •  Validate all input strings from both users and database query results!
18. 18 Please Remember to Validate All Input •  Accept it •  Reject it •  Manipulate it Image source www.historiccamdencounty.com When writing applications, be sure to validate ALL input strings. There are three, and only three, options when given a piece of data:
19. 19 Related Work Not Mentioned in the Paper •  F. Valeur, D. Mutz, and G. Viega published a paper, in the conference of Detection of Intrusions and Malware Vulnerability Assessment (DIMVA), July 2005, proposing a machine-learning-based IDS for SQLIA’s. •  William Halfond, Jeremy Viegas, and Alessandro Orso have a forthcoming paper on Classification and Countermeasures for SQLIA’s.
20. 20 Contributors •  Dr. Shamkant Navathe, professor of Computer Science, sponsored this project as a capstone undergraduate research class. He provided valuable feedback throughout the writing process. •  Harrison Caudill provided feedback and helped convert the original OO document to LaTeX. •  Jonathan Cullifer and Eric McCorkle both helped proofread the paper and provided feedback. •  My mother patiently reviewed my writing despite not understanding the technical details.
21. 21 Questions?
22. 22 The Really Big Picture Data & Code Integrity Strong Auth. Access Ctrl. Efficiency Availability Security Reliability
23. 23 An Example Parse Tree OR LastName = 'Bob' 1 = 1 WHERE FirstName = 'Bob' 1 = 1 OR OR