1 / 26

SQL Injection

SQL Injection. Introduction, Demo and Overview. What is SQL Injection?. Insertion of SQL statements into application inputs to corrupt, exploit, or otherwise damage an application database.

prudence-bender
Download Presentation

SQL Injection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SQL Injection Introduction, Demo and Overview

  2. What is SQL Injection? • Insertion of SQL statements into application inputs to corrupt, exploit, or otherwise damage an application database. • Most commonly done directly through web forms, but can be directed through URL hacking, request hacking using debugging tools, or using bots that emulate browsers and manipulate web requests.

  3. What does it do? • Simplest Hacks are used to bypass database level authentication. • Bot attacks on publicly facing web sites are frequently in two stages: • Stage 1: force SQL into the application to display database metadata such as table and column structures. • Stage 2: Use the metadata to attack the database. • Humans often implement state 2 after getting a hit by a bot. • Most common result is to insert HTML tags into database tables: • Corrupted content is displayed in web application. • Malicious tags result in the malware downloads to anyone viewing a web site using inline JavaScript, iFrames, etc., embedded in database content.

  4. Generic Problem: Input Validation • Very Old problem: • HTTP get and post are not secure request mechanisms and were not designed to be secure. • Perl CGI was vulnerable to inline Perl fragments • All forms of buffer overflows are failures to validate user input. • Very Common Problem: • Web requests are typically passed to server processes as an associative array of strings. • The fastest way to respond to a request is to use the raw user input. • Injections results from lazy programming practices in applications and oversights in server software.

  5. Related Side Effects of Poor Input Validation • Cross site scripting • Malware injection • Buffer overflow attacks • Denial of Service • SQL Injection

  6. Demo of Vulnerable Site

  7. Prevention of SQL Injection • SQL Injection can be prevented using: • Design Principles: • Avoiding application structures that leave apps vulnerable • Coding Practices: • Preventing bad SQL fragments from being executed • Blocking bad input/input sanitation • Database Practices: • Making the database less vulnerable to any type of attack • Infrastructure Support: • Preventing attacks on any application

  8. Design Principle-No Anonymous User Input Data • Force users to create an account, which is verified with an email. • Use Captcha or similar graphics to text entry to prevent automated/bot data entry into systems. • Log all data entry by web request – who, what, where, when and from which IP.

  9. Design Principle - Authentication • Eliminate all database based usernames and passwords stores. • A login page is the entry point into an application and must allow anonymous data entry. • SQL injection is frequently used to bypass security. • Many inexpensive and free alternatives exist for authentication stores • OpenLDAP is easy, free, and access is through LDAP calls and not SQL. • Usernames and passwords can be reused in different application without reusing a database. Caution: Do not mix internal and external users in the same LDAP store if possible.

  10. Design Principle- Avoid free text where possible and never accept HTML tags • Constraining inputs to drop downs and formatted text boxes simplifies validations necessary to trap SQL injection attempts • HTML tags are a very common malware vector. • Better to break up input into multiple text fields. • Use formatting options through drop downs, check boxes and other fixed input fields. Caution: Client side HTML and JavaScript is bypassed very easily.

  11. Coding Practice – No Dynamic SQL • Pure dynamic SQL serves as the most common form of SQL injection attacks: sqlString = “SELECT… From [myTable] WHERE name =‘”.myInputValue.”’ “; • Very easy to force input into a structured form using some variation of bind values or parameterized SQL statements • Java prepared statements • .NET using sql bind with value parameters • mySQLi and Pear within PHP • Bind variables are treated as pure input and are not in general executed. Caution: Not a bulletproof approach, just a best practice.

  12. Coding Practice – Strong type checking before interacting with the database • On the server, a request processor must perform strong type checking: • Ensure numbers are numbers, dates are dates, values from form elements are correct such as indexes from drop downs, etc. • Limit the range of values accepted if possible. • Use the parsing functions that come natively with many programming languages if available such as in Java or .NET • It is very important in weakly typed languages such as PHP to force type checking.

  13. Coding Practice – Enforce input lengths and formats • Limit the size of all strings on both the client and the server. • Setting the length on a input box or using JavaScript is easily bypassed. • Reject any request where any value exceeds a maximum expected length. • Ensure any string inputs conform to input masks whenever possible, for example: • When strings are used to describe numbers to preserve leading zeros ensure all characters are numbers • Filter for any unexpected characters. Caution: Rules must be implemented on the client and on the server.

  14. Coding Practice – Sanitize all user input before any other processing • The safest and most secure practice is to iterate through a web request and filter all unexpected characters. • If all special characters are removed, function calls, URI encoding, and other common ways of adding SQL predicates or embedded HTML tags are simply blocked. • Remove unwanted spaces • Reject requests with anomalies and log the activity for analysis.

  15. Coding Practice – Mask all errors from the user with user friendly output • Never display sql errors or other raw system errors back to the user. • Can provide additional attack vectors for hackers. • Whenever an exception occurs, display a generic message, and log the actual error and user input. • Whenever a request fails validation or sanitation checks, use a generic response, terminate the user’s session, and log the error in detail. Caution: NEVER echo user input back to the user without sanitizing the request. This is the most common form of cross site scripting.

  16. Coding Practice – Use Detailed Logs • Detailed logging introduces additional storage and process overhead, but it is invaluable in debugging and in identifying security weaknesses. • Unexpected conditions, rejected requests, and similar errors are usually the first sign your web application is under attack.

  17. Coding Practices – Use frameworks • Every popular web development platform has validation frameworks. • Leverage existing frameworks to implement validations: • Zend for PHP • Several frameworks for Java • Frameworks can centralize many security related tasks. • .NET has an emerging MVC model which should help centralize tasks like input sanitation.

  18. Database Practice – Use two accounts • Create Two accounts: • Database Owner • Has rights over all the objects in a database or schema. • Equivalent to DBA level access for a database/schema. • Used to build out and maintain an application database. • Never used by web applications. • Application Account/Database proxy account • Has minimal rights needed for application: • All rights to each object are explicitly declared. • Owns no objects directly. • No access to metadata in db platform. • Restricted login locations if possible.

  19. Database Practices – Strong Typing • Columns must be strongly typed: • Numbers as Numbers. • Characters limited to the exact maximum required. • Dates stored as dates • If performance is acceptable use check constraints or triggers: • Force format masks and character ranges such as 0-9 for SSN, etc. • Use look up tables for reference values and enforce foreign keys.

  20. Database Practices – Stored Procedures and views • Views: • Only expose those columns needed by the application. • Allow for more granular column by column permissions. • Stored Procedures: • Application account get execution rights only. • All tables and views are invisible. • Can reduce number of database interactions. • Simplifies transaction management. • Not appropriate for all application environments/tools.

  21. Infrastructure Practice – Deploy an IDS specifically checking for SQL Injection • Several IDS systems exist to specifically monitor web traffic for SQL Injection • Each request is examined for SQL injection signatures. • Bad requests are filtered and logged. • Protects all applications against most common errors. • Excellent first step until all web applications can be reviewed for vulnerabilities. Caution: Signatures will always eventually be defeated.

  22. Infrastructure Practice – Do automated log scanning • Use a central logging tool looking for SQL Injection behavior: • SQL Errors • Queries against metadata from web apps • Use manual scanning tools such as grep, awk, and log parsers to look for unauthorized queries/sql requests

  23. Infrastructure Practice – Use security scanning tools • The best security measure is one that catches problems before they are revealed. • As part of QAT or UAT testing, applications must be automatically scanned for vulnerabilities. • Reveals vulnerabilities above and beyond simple penetration testing. • Many excellent products: • Rational APPSCAN from IBM (was Watchfire) • Acunetix

  24. Platform Specific Issues • PHP, Java, and other web scripting languages can sanitize users requests very easily. • Requests can be manipulated and values overwritten. • MVC type models in Java and include directives in other scripting languages make this trivial. • .NET 2.0 and higher poses a tougher challenge because request objects are read only • Implementing sanitation undoes many of the advantages of .NET programming. • Using ISAPI type filters that pre-process requests requires a great deal of redundant coding. • Weak typing in many of the Open Source web scripting languages introduces additional demands for vigilance in these platforms.

  25. Conclusion • Security is a continual process of vigilance. • Every block/measure eventually has a counter • Good habits within application development and design can avoid most injection/overflow type exploits. • Application security requires action by developers, designers and administrators • Most SQL Injection attacks can be blocked with very simple measures, which can be labor intensive to implement.

  26. References • Regular Expressions for filtering: • http://www.securityfocus.com/infocus/1768 • Example of source hacking: • http://video.google.com/videosearch?q=sql+injection&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&sa=X&oi=video_result_group&resnum=5&ct=title# • Application Scanning Software: • http://www-01.ibm.com/software/awdtools/appscan/

More Related