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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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

Figure 2.2 Burp Suite Intercepting a POST Request<br />

Figure 2.2 shows Burp Suite intercepting a POST request <strong>and</strong> allowing the user to<br />

modify the fields. The request has been intercepted by the proxy <strong>and</strong> the user can make<br />

arbitrary changes to the content. Once finished the user should click the forward button<br />

<strong>and</strong> the modified request will be sent to the server.<br />

Later, in “Confirming <strong>SQL</strong> <strong>Injection</strong>,” we will discuss the kind of content that can be<br />

injected into the parameters to trigger <strong>SQL</strong> injection vulnerabilities.<br />

Other Injectable Data<br />

Most applications retrieve data from GET or POST parameters. However, other parts of the<br />

HTTP request might trigger <strong>SQL</strong> injection vulnerabilities.<br />

Cookies are a good example. Cookies are sent to the user’s browser <strong>and</strong> they are<br />

automatically sent back to the server in each request. Cookies are usually used for authentication,<br />

session control, <strong>and</strong> maintaining specific information about the user, such as preferences in the<br />

Web site. As explained before, you have full control of the content sent to the server <strong>and</strong> so<br />

you should consider cookies as a valid form of user data entry, <strong>and</strong> therefore, as being susceptible<br />

to injection.

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

Saved successfully!

Ooh no, something went wrong!