What they are, steps you can take to prevent them, a brief overview. 3/13/2013 winter term 2013 at Portland State University for the Introduction to Databases class. Presented by Stacy Watts and Tyler Fetters

1. SQL Injection Attacks
Tyler Fetters
Stacy Watts
3.13.2013
CS586 – Introduction to Databases
Portland State University

2. Today‟s Topics
 What is a SQL Injection Attack
 Security in SQL
 How to lock down a dbms
 Best Practices
 Common Mistakes
 SQL Injection Attack Example
 Questions
2

3. SQL Injection Attack - Definition
 SQL injection consists of the possibility the
user has to inject fragments of SQL queries in
Web application input fields.
 If these fields or the resulting SQL query to be
sent to the database are not properly
validated, then it might be possible for the
attacker to access unauthorized data, reverse
engineer the database structure, or even to
insert/delete data [1]
3

4. Security in SQL – dbms Lock Down
 Keep your PostgreSQL version up-to-date
 Network design should include firewalls
 Track user Input
 Analyze the correctness of SQL statements
 Additional security
 SQL Randomization
 Appending random numbers to all statements, and rejecting
any not containing such numbers
 Black Box testing your solution prior to release
 Third party software options for testing and
locking
 Examples: SQLMap, V1p3R, Candid
4

5. Best Practices
5

6. Security in SQL – Best Practices
 Parameterize all Queries
 Example From Week 7 – Guest Lecture
 Stored Procedures and Permissions
 All code can be implemented using stored procedures
on the DB
 Use the account with the lowest permissions needed for
the task
 In PostgreSQL there are the following privileges:
 SELECT (read), INSERT (append), UPDATE
(write), DELETE, RULE, REFERENCES (foreign key), and
TRIGGER.
6  Eg. GRANT SELECT ON accounts TO external;

7. Security in SQL – Best Practices
 Input Validation Checks
 Implement code that ensures correct inputs are
given.
 Some examples:
 A name input should not contain an “=“ with it
 A zip code should only contain numbers
 Avoid printing error codes directly
 Use Try and Catch Mechanisms
 Within the Catch Provide meaningful error messages to the
user
7

8. Security in SQL – Best Practices
 Encrypt Secure Data
 Passwords should be encrypted or hashed not
stored as text
 What about CC info? Or SSN?
 Data Segregation
 Store secure data in a separate database from non-
secure data
 Not accessible from outside of the network
8
 Example Bank Teller

9. Security in SQL – Best Practices
 Keep your database Schema hidden
 Avoid using select *….
 Use the table and attribute aliases
 Avoid obvious nomenclature and schema
 i.e. User (first_name, last_name, user_name, password)
 Log and Audit you dbms
 Verify users and permissions
 Require high security passwords and passwords be
updated
 Remove any non-essential/not approved tables
 Helps to find potential threat attempts and prevent
future attacks
9

10. Common Mistakes
10

11. Security in SQL – Common Mistakes
 Turning off the default security configuration
 The idea might be to make input easier for the user by
allowing any input
 Not a good idea. Know what might happen by turning off a
security measure before doing so.
 Security through Obscurity
 As long as the machine is connected to the internet and
responsive, attacks are possible
 “In operational environments, it has been noted that
applications experience an average of 71 attempts an hour.”
[3]
 Accessing Tables Directly
 If the information is for viewing, use a view, don‟t expose the
11
table

12. Security in SQL – Common Mistakes
 Obvious nomenclature and schema
 Once access is gained even if the schema is protected it might
be possible to guess User (Name, Password) as a relation.
 Even without, possible to damage with drop table.
 Not checking logs, or performing audits
 No assumptions about data integrity
 User Permissions pitfalls
 Setting user permission tiers too high
 Setting global user permissions for ease of administration
 The user the application uses to connect to the database
should never be the owner of the objects created in the
database
 Storing sensitive data without encryption
 Eg: social security number, current location, credit card
information
12

13. SQL Injection Attack Example
 Go to the following url and complete the survey
 http://sqlinjection.70sites.com/
 Now we will Run a SQL injection attack
 SQL Injection Attack
 $lastn = stripslashes($lastn);
 Used to remove built in security of “” on „ or “
 Might be done for names like O‟Brian
13

14. Questions
14

15. References
 [1] http://en.wikipedia.org/wiki/SQL_injection_attack
 [2] http://wiki.postgresql.org/wiki/Sql_injection
 [3]http://blog.imperva.com/2011/09/sql-injection-by-the-numbers.html
 [4]http://savepoint.blog.br/o-minimo-que-voce-deveria-aprender-para-se-defender-de-ataques-de-injecao-
de-sql-no-postgresql/
 [5]http://wiki.postgresql.org/wiki/9.1%E7%AC%AC%E4%B8%89%E5%8D%81%E4%B8%80%E7%AB%A0
 [6]https://www.simple-talk.com/sql/learn-sql-server/sql-injection-
defense-in-depth/
 [7]http://www.postgresql.org/docs/7.2/static/privileges.html
 [8]http://msdn.microsoft.com/en-us/library/ff648339.aspx# paght000002
_additionalconsiderations
 [9]https://www.simple-talk.com/sql/learn-sql-server/sql-injection-
defense-in-depth/
 [10]http://www.php.net/manual/en/exception.getmessage.php
 [11]https://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-
depth/
 [12]http://weblogs.sqlteam.com/jamesw/archive/2011/10/03/a-list-of-sql-best-
15 practices.aspx