Download 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.
• 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.
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.
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.
Related Side Effects of Poor Input
Validation
•
•
•
•
•
Cross site scripting
Malware injection
Buffer overflow attacks
Denial of Service
SQL Injection
Demo of Vulnerable Site
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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:enUS:official&client=firefox-a&um=1&ie=UTF8&sa=X&oi=video_result_group&resnum=5&ct=title#
• Application Scanning Software:
– http://www-01.ibm.com/software/awdtools/appscan/