28.10.2014 Views

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SQL Injection Attacks and Defense - 2009

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

40 Chapter 2 • Testing for <strong>SQL</strong> <strong>Injection</strong><br />

As you can see, the Web server <strong>and</strong> the database server are separate entities. The Web server<br />

just creates an <strong>SQL</strong> query, parses the results, <strong>and</strong> displays the results to the user. The database<br />

server receives the query <strong>and</strong> returns the results to the Web server. This is very important for<br />

exploiting <strong>SQL</strong> injection vulnerabilities because if you can manipulate the <strong>SQL</strong> statement <strong>and</strong><br />

make the database server return arbitrary data (such as usernames <strong>and</strong> passwords from the<br />

Victim Inc. Web site) the Web server has no means to verify whether the data is legitimate.<br />

Database Errors<br />

In the previous section, you saw some <strong>SQL</strong> injection errors displayed as a result of<br />

parameter manipulation. Although the errors are displayed in the Web server response,<br />

the <strong>SQL</strong> injection happens at the database layer. Those examples showed how you can reach<br />

a database server via the Web application.<br />

It is very important that you familiarize yourself with the different database errors that<br />

you may get from the Web server when testing for <strong>SQL</strong> injection vulnerabilities. Figure 2.5<br />

shows how an <strong>SQL</strong> injection error happens <strong>and</strong> how the Web server deals with it.<br />

Figure 2.5 Information Flow during an <strong>SQL</strong> <strong>Injection</strong> Error<br />

As you can see in Figure 2.5, the following occurs during an <strong>SQL</strong> injection error:<br />

1. The user sends a request in an attempt to identify an <strong>SQL</strong> injection vulnerability.<br />

In this case, the user sends a value with a single quote appended to it.<br />

2. The Web server retrieves user data <strong>and</strong> sends an <strong>SQL</strong> query to the database server.<br />

In this example, you can see that the <strong>SQL</strong> statement created by the Web server<br />

includes the user input <strong>and</strong> forms a syntactically incorrect query due to the two<br />

terminating quotes.<br />

3. The database server receives the malformed <strong>SQL</strong> query <strong>and</strong> returns an error to the<br />

Web server.<br />

4. The Web server receives the error from the database <strong>and</strong> sends an HTML response<br />

to the user. In this case, it sent the error message, but it is entirely up to the<br />

application how it presents any errors in the contents of the HTML response.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!