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.

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 Injection
UFBP  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
Eve
UFBP  WA&DB  Access Control  SQLIA  Demo  ARM

5. CIA Violations
SQLIA destroy Confidentiality, Integrity, and
Accessibility.
• Information Disclosure
• Unauthorized Tampering with Data
• Arbitrary Code Execution
UFBP  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.
6
UFBP  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 attacks
UFBP  WA&DB  Access Control  SQLIA  Demo  ARM

12. Live Exploit Demonstration
UFBP  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?