Justin Clarke Lead Author and Technical Editor Rodrigo Marcos Alvarez Dave Hartley Joseph Hemler Alexander Kornbrust Haroon Meer Gary O’Leary-Steele Alberto Revelli Marco Slaviero Dafydd Stuttard

 
Testing for SQL Injection • Chapter 2
 
35
Figure 2.2 shows Burp Suite intercepting a 
POST
request and allowing the user to 
modify the fields. The request has been intercepted by the proxy and the user can make 
arbitrary changes to the content. Once finished the user should click the 
forward
button 
and the modified request will be sent to the server.
Later, in “Confirming SQL Injection,” we will discuss the kind of content that can be 
injected into the parameters to trigger SQL injection vulnerabilities.
Other Injectable Data
Most applications retrieve data from 
GET
or 
POST
parameters. However, other parts of the 
HTTP request might trigger SQL injection vulnerabilities.
Cookies are a good example. Cookies are sent to the user’s browser and they are 
automatically sent back to the server in each request. Cookies are usually used for authentication, 
session control, and maintaining specific information about the user, such as preferences in the 
Web site. As explained before, you have full control of the content sent to the server and so
you should consider cookies as a valid form of user data entry, and therefore, as being susceptible 
to injection.
Figure 2.2 
Burp Suite Intercepting a 
POST
Request

---

36
 
Chapter 2 • Testing for SQL Injection
Other examples of applications vulnerable to injection in other parts of the HTTP 
request include the Host, Referer, and User-Agent headers. The Host header field specifies the 
Internet host and port number of the resource being requested. The Referer field specifies
the resource from which the current request was obtained. The User-Agent header field 
determines the Web browser used by the user. Although these cases are uncommon, some 
network monitoring and Web trend applications use the Host, Referer, and User-Agent header 
values to create graphs, for example, and store them in databases. In such cases, it is worth testing 
those headers for potential injection vulnerabilities.
You can modify cookies and HTTP headers through proxy software in the same manner 
you saw earlier in this chapter.
Manipulating Parameters
We’ll start with a very simple example so that you can become familiar with SQL injection 
vulnerabilities.
Say you visit the Web site for Victim Inc., an e-commerce shop where you can buy all 
kinds of things. You can check the products online, sort them by price, show only a certain 
category of product, and so forth. When you browse different categories of products you 
notice that the URL looks like the following:
http://www.victim.com/showproducts.php?category=bikes
http://www.victim.com/showproducts.php?category=cars
http://www.victim.com/showproducts.php?category=boats
The showproducts.php page receives a parameter called 
category
. You don’t have to type 
anything, as the preceding links are presented on the Web site, so you just have to click them. 
The application at the server side is expecting known values and displays the products which 
belong to the given category.
Even without starting the process of testing you should already have a rough idea of
how the application may work. You can assert that the application is not static; it seems that 
depending on the value of the 
category
parameter the application will show different
products based on the result of a query to a back-end database.
You can now begin to manually change the values of the 
category
parameter to 
something the application does not expect. Your first attempt can be something such as the 
following:
http://www.victim.com/showproducts.php?category=attacker
In the preceding example, we sent a request to the server with a non-existent category 
name. The response from the server was as follows:
Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result
resource in /var/www/victim.com/showproducts.php on line 34

---