Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sql injection brief for slideshare

1,136 views

Published on

2006 presentation by Frank Rietta on Web Applications and SQL Injection Attacks.

The content is even more relevant today, six years later, given the explosion in web-based systems being built with PHP, Ruby on Rails, and other web application frameworks.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Sql injection brief for slideshare

  1. 1. Web Applications and SQL Injection Attacks SQLIA’s are not unique to web applications, but the open nature gives access and sufficient time to attackers. Validate all input strings from both users and database query results! © 2006, 2012 Rietta Inc. All Rights Reserved. by Frank S. Rietta
  2. 2. Presentation Overview 1. Universal Firewall Bypass Protocol (UFBP) 2. Web Apps and Databases 3. Access Control 4. SQL Injection Attacks 5. Demo 6. ARM Yourself Against SQL InjectionUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  3. 3. One Possible Network Graphic source Source Microsoft TechNet (Hacking: Fight Back)UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  4. 4. Web Apps: Attacker Friendly™ Users WWW DBMS EveUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  5. 5. CIA Violations SQLIA destroy Confidentiality, Integrity, and Accessibility. • Information Disclosure • Unauthorized Tampering with Data • Arbitrary Code ExecutionUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  6. 6. Ineffective DBMS Access Control • Too many “god” users! • RBAC is often not used • Developers leave security entirely up to the application, rendering the DBMS powerless to mitigate SQL injection risks. 6UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  7. 7. SQL Templates and String Manipulation • 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. • Parameterization attacks are the most common venue for exploitation.UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  8. 8. 1st Order Parameter Replacement SELECT * FROM Directory WHERE Last_Name LIKE „${NAME}‟ ; SELECT * FROM Directory WHERE Last_Name 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!UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  9. 9. 2nd Order Parameter Replacement SELECT * FROM Listing WHERE Last_Name=„${NAME}‟ OR LastName =„${NAME}‟ SELECT * FROM Listing WHERE Last_Name = „Bob‟ OR 1=1 OR Last_Name = „Bob‟ OR 1=1 Tautologies are typical in SQL injection attacks. Usually always evaluating to true.UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  10. 10. 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.UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  11. 11. 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 easiest to exploit • Trampoline attacksUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  12. 12. Live Exploit DemonstrationUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  13. 13. ARM Yourself Against SQL Injection When writing applications, be sure to validate ALL input strings. There are three, and only three, options when given a piece of data: • Accept it • Reject it • Manipulate it Image source www.historiccamdencounty.com 13
  14. 14. 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!
  15. 15. Questions?

×