Your SlideShare is downloading. ×
Sql injection brief for slideshare
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sql injection brief for slideshare

876
views

Published on

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

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
876
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. One Possible Network Graphic source Source Microsoft TechNet (Hacking: Fight Back)UFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  • 4. Web Apps: Attacker Friendly™ Users WWW DBMS EveUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  • 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. 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. 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. 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. 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. 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. 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. Live Exploit DemonstrationUFBP  WA&DB  Access Control  SQLIA  Demo  ARM
  • 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. 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. Questions?

×