SQL Injection White Paper.pdf

(797 KB) Pobierz
1.Overview and introduction to web applications and SQL injection
SQL Injection
Are Your Web Applications Vulnerable?
A White Paper from SPI Dynamics
Author: Kevin Spett
© 2002 SPI Dynamics, Inc. All Right Reserved. No reproduction or redistribution without written permission.
Page 1
707883851.008.png 707883851.009.png 707883851.010.png
TABLE OF CONTENTS
© 2002 SPI Dynamics, Inc. All Right Reserved. No reproduction or redistribution without written permission.
Page 2
707883851.011.png 707883851.001.png
1. Overview and introduction to web applications and
SQL injection
1.1. Overview
SQL injection is a technique for exploiting web applications that use client-supplied
data in SQL queries without stripping potentially harmful characters first. Despite being
remarkably simple to protect against, there is an astonishing number of production systems
connected to the Internet that are vulnerable to this type of attack. The objective of this paper
is to educate the professional security community on the techniques that can be used to take
advantage of a web application that is vulnerable to SQL injection, and to make clear the
correct mechanisms that should be put in place to protect against SQL injection and input
validation problems in general.
1.2. Background
Before reading this, you should have a basic understanding of how databases work and
how SQL is used to access them. I recommend reading eXtropia.com’s “Introduction to
Databases for Web Developers” at http://www.extropia.com/tutorials/sql/toc.html .
1.3. Character encoding
In most web browsers, punctuation characters and many other symbols will need to be
URL encoded before being used in a request in order to be interpreted properly. In this paper I
have used regular ASCII characters in the examples and screenshots in order to maintain
maximum readability. In practice, though, you will need to substitute %37 for percent sign,
%43 for plus sign, etc. in the HTTP request statement.
© 2002 SPI Dynamics, Inc. All Right Reserved. No reproduction or redistribution without written permission.
Page 3
707883851.002.png 707883851.003.png
2. Testing for vulnerability
2.1. Comprehensive testing
Thoroughly checking a web application for SQL injection vulnerability takes more
effort than one might guess. Sure, it's nice when you throw a single quote into the first
argument of a script and the server returns a nice blank, white screen with nothing but an
ODBC error on it, but such is not always the case. It is very easy to overlook a perfectly
vulnerable script if you don't pay attention to details.
Every parameter of every script on the server should always be checked. Developers
and development teams can be awfully inconsistent. The programmer who designed Script A
might have had nothing to do with the development of Script B, so where one might be
immune to SQL injection, the other might be ripe for abuse. In fact, the programmer who
worked on Function A in Script A might have nothing to do with Function B in Script A, so
while one parameter in Script A might be vulnerable, another might not. Even if a whole web
application is conceived, designed, coded and tested by one single, solitary programmer, there
might be only one vulnerable parameter in one script out of thousands of other parameters in
millions of other scripts, because for whatever reason, that developer forgot to sanitize the data
in that one place and that one place only. You never can be sure. Test everything.
2.2. Testing procedure
Replace the argument of each parameter with a single quote and an SQL keyword (" '
WHERE ", for example). Each parameter needs to be tested individually. Not only that, but
when testing each parameter, leave all of the other parameters unchanged, with valid data as
their arguments. It can be tempting to just delete all of the stuff that you're not working with in
order to make things look simpler, particularly with applications that have parameter lines that
go into many thousands of characters. Leaving out parameters or giving other parameters bad
arguments while you're testing another for SQL injection can break the application in other
ways that prevent you from determining whether or not SQL injection is possible. For
instance, let's say that this is a completely valid, unaltered parameter line:
ContactName=Maria%20Anders&CompanyName=Alfreds%20Futterkiste
And this parameter line gives you an ODBC error:
ContactName=Maria%20Anders&CompanyName='%20OR
Whereas checking with this line:
CompanyName='
Might just give you an error telling you that you that you need to specify a
ContactName value. This line:
© 2002 SPI Dynamics, Inc. All Right Reserved. No reproduction or redistribution without written permission.
Page 4
707883851.004.png 707883851.005.png
ContactName=BadContactName&CompanyName='
Might give you the same page as the request that didn't specify ContactName at all.
Or, it might give you the site’s default homepage. Or, perhaps when it couldn't find the
specified ContactName the application figured that there was no point in looking at
CompanyName , so it didn't even pass the argument of that parameter into an SQL statement at
all. Or, it might give you something completely different. So, when testing for SQL injection,
always use the full parameter line, giving every argument except the one that you are testing a
legitimate value.
2.3. Evaluating results
If you get a database server error message of some kind back, injection was definitely
successful. However, the database error messages aren't always obvious. Again, developers
do some strange things, so you should look in every possible place for evidence of successful
injection. The first thing you should do is search through the entire source of the returned page
for phrases like "ODBC", "SQL Server", "Syntax", etc. More details on the nature of the error
can be in hidden input, comments, etc. Check the headers. I have seen web applications on
production systems that give you an error message with absolutely no information in the body
of the HTTP response, but that have the database error message in a header. Many web
applications have these kinds of features built into them for debugging and QA purposes, and
then forget to remove or disable them before release.
Not only should you look on the immediately returned page, but in linked pages as
well. During a recent pen-test, I saw a web application that returned a generic error message
page in response to an SQL injection attack. Clicking on a stop sign image next to the error
that was linked to another page gave the full SQL Server error message.
Another thing to watch out for is a 302 page redirect. You may be whisked away from
the database error message page before you even get a chance to notice it.
Please note that SQL injection may be successful even if you do get an ODBC error
messages back. Lots of the time you get back a properly formatted, seemingly generic error
message page telling you that there was "an internal server error" or a "problem processing
your request." Some web applications are built so that in the event of an error of any kind, the
client is returned to the site’s main page. If you get a 500 Error page back, chances are that
injection is occurring. Many sites have a default 500 Internal Server Error page that claims
that the server is down for maintenance, or that politely asks the user to email their request to
their support staff. It can be possible to take advantage of these sites using stored procedure
techniques, which are discussed later.
© 2002 SPI Dynamics, Inc. All Right Reserved. No reproduction or redistribution without written permission.
Page 5
707883851.006.png 707883851.007.png

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin