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
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Â
SQL Injection Attacks cs586
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
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
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