SQL Injection Attacks cs586


Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Tyler
  • Tyler
  • Stacy
  • Stacy
  • Tyler
  • https://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/http://www.postgresql.org/docs/7.2/static/privileges.htmlhttp://msdn.microsoft.com/en-us/library/ff648339.aspx#paght000002_additionalconsiderationsTyler
  • https://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/http://www.php.net/manual/en/exception.getmessage.phpTyler
  • https://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/Tyler
  • http://weblogs.sqlteam.com/jamesw/archive/2011/10/03/a-list-of-sql-best-practices.aspxTyler
  • Stacy
  • Stacy
  • Stacy
  • Last Name = Fake" OR "a" = "a
  • SQL Injection Attacks cs586

    1. 1. SQL Injection Attacks Tyler Fetters Stacy Watts 3.13.2013CS586 – Introduction to Databases Portland State University
    2. 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  Questions2
    3. 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. 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, Candid4
    5. 5. Best Practices5
    6. 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. 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 user7
    8. 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 network8  Example Bank Teller
    9. 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 attacks9
    10. 10. Common Mistakes10
    11. 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 the11 table
    12. 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 information12
    13. 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‟Brian13
    14. 14. Questions14
    15. 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