Web applications access databases for many purposes. One common goal is to access information and present it to the user. In such cases, an attacker might be able to modify the SQL statement and display arbitrary information from the database into the HTTP response received from the web server.
However, there are other cases where it is not possible to display any information from the database, but that doesn’t necessarily mean the code can’t be vulnerable to SQL injection. This means the discovery and exploitation of the vulnerability is going to be slightly different. Consider the following example.
Victim Inc. allows its users to log on to its Web site via an authentication form located at
http://www.victim.com/authenticate.aspx. The authentication form requests a username and a password from the user. If you enter any random username and password the result page shows an “Invalid username or password” message. This is something that you would expect. However, if you enter a username value of user’ or ‘1’=’1 the error shown in Figure 2.8 is displayed.
Figure 2.8 Blind SQL Injection Example—Always True
Figure 2.8 shows a flaw in the authentication system of Victim Inc. The application shows different error messages when it receives a valid username, and moreover, the username field seems vulnerable to SQL injection.
When you find this kind of situation it can be useful to verify by injecting an always false condition, as shown in Figure 2.9, and checking that the returned value is different.
Figure 2.9 Blind SQL Injection Example—Always False
After the always false test you can confirm that the Username field is vulnerable to SQL injection. However, the Password field is not vulnerable and you cannot bypass the authentication form.
This form doesn’t show any data from the database. The only two things we know are: • The form displays “Invalid password” when the Username condition is true.
• The form displays “Invalid username or password” when the Username condition is false. This is called blind SQL injection. Chapter 5 is fully dedicated to blind SQL injection attacks and covers the topic in detail, however we will discuss the basics in this section.
Blind SQL injection is a type of SQL injection vulnerability where the attacker can manipulate a SQL statement and the application returns different values for true and false conditions. However, the attacker cannot retrieve the results of the query.
Exploitation of blind SQL injection vulnerabilities needs to be automated, as it is time- consuming and involves sending many requests to the Web server. Chapter 5 discusses the exploitation process in detail.
Blind SQL injection is a very common vulnerability, although sometimes it can be very subtle and might remain undetected to inexperienced eyes. Take a look at the next example so that you can better understand this issue.
Victim Inc. hosts a Web page on its site, called showproduct.php. The page receives a parameter called id, which uniquely identifies each product in the Web site. A visitor can request pages as follows:
http://www.victim.com/showproduct.php?id=1 http://www.victim.com/showproduct.php?id=2 http://www.victim.com/showproduct.php?id=3 http://www.victim.com/showproduct.php?id=4
Each request will show the details of the specific product requested as expected. There is nothing wrong with this implementation so far. Moreover, Victim Inc. has paid some attention to protecting its Web site and doesn’t display any database errors to the user.
During testing of the Web site you discover that the application by default shows the first product in the event of a potential error. All of the following requests showed the first product (www.victim.com/showproduct.php?id=1):
http://www.victim.com/showproduct.php?id=attacker http://www.victim.com/showproduct.php?id=attacker’ http://www.victim.com/showproduct.php?id=
http://www.victim.com/showproduct.php?id=999999999(non existent product) http://www.victim.com/showproduct.php?id=-1
So far, it seems that Victim Inc. really took security into account in implementing this software. However, if we keep testing we can see that the following requests return the product with id=2:
http://www.victim.com/showproduct.php?id=3-1 http://www.victim.com/showproduct.php?id=4-2
http://www.victim.com/showproduct.php?id=5-3
The preceding URLs indicate that the parameter is passed to the SQL statement and it is executed in the following manner:
SELECT ∗ FROM products WHERE idproduct=3-1
The database computes the subtraction and returns the product whose idproduct=2.
You can also perform this test with additions; however, you need to be aware that the Internet Engineering Task Force (IETF), in its RFC 2396 (Uniform Resource Identifiers (URI): Generic Syntax), states that the plus sign (+) is a reserved word for URIs and needs to be encoded. The plus sign URL encoding is represented by %2B.
The representation of an example of the attack trying to show the product whose idproduct=6 would be any of the following URLs:
http://www.victim.com/showproduct.php?id=1%2B5(decodes to id=1+5) http://www.victim.com/showproduct.php?id=2%2B4(decodes to id=2+4) http://www.victim.com/showproduct.php?id=3%2B3(decodes to id=3+3)
Continuing the inference process, we can now insert conditions after the id value, creating true and false results:
http://www.victim.com/showproduct.php?id=2 or 1=1 -- returns the first product
http://www.victim.com/showproduct.php?id=2 or 1=2 -- returns the second product
In the first request, the Web server returns the product whose idproduct=1, whereas in the second request it returns the product whose idproduct=2.
In the first statement, or 1=1 makes the database return every product. The database detects this as an anomaly and shows the first product.
In the second statement, or 1=2 makes no difference in the result, and therefore the flow of execution continues without change.
You might have realized that there are some variations of the attack, based on the same principles. For example, we could have opted for using the AND logical operator, instead of OR. In that case:
http://www.victim.com/showproduct.php?id=2 and 1=1 -- returns the second product
http://www.victim.com/showproduct.php?id=2 and 1=2 -- returns the first product
As you can see, the attack is almost identical, except that now the true condition returns the second product and the false condition returns the first product.
The important thing to note is that we are in a situation where we can manipulate a SQL query but we cannot get data from it. Additionally, the Web server sends a different response depending on the condition that we send. We can therefore confirm the existence of blind SQL injection and start automating the exploitation.