This article is the first in a series of posts on Web application security issues. This article will discuss the possibility of exploiting an injection vulnerability on pages without text fields and the use of the WebScarab tool to carry out such an attack.
Exploiting the Injection Flaw vulner ability is a common cause of Web application intrusions. Application security issues related to the injection of invalid data into pages with test fields are common (especially cross site scripting, XSS attacks). However, the possibility of exploiting the injection vulnerability on pages without text fields is no longer so obvious.
Injection Flaw
Let's consider a simple functionality of an application supporting an online store, used to show the status of placed orders. An example of such an application is shown in Figure 1.
As can be assumed, the information obtained from the user, related to the selection of the shipment status of interest, is used to parameterize the SQL query to the database. With high probability, it can be assumed that the SQL query used will be similar to a query in the following form:
SELECT id, goods, address FROM orders WHERE customer_id = ... and status = ....
If it is assumed that the application programmer glued the query manually and did not provide validation of the supplied data, it is easy to guess what text you need to put in the query to get information about all orders.
Consider the situation when, instead of the expected status identifier, a fragment of a SQL query of the form is substituted:
4 or 1=1
In such a case, the condition in the query will always be true, resulting in a search for all records from the table.
Since the application sends user data using the GET method, we can observe all the parameters in the sent URL. It is enough to paste a crafted piece of data in the appropriate place and the whole URL is sent again. In Figure 2 you can observe the result of executing such a malicious request using a regular browser.
As expected, the result of this query revealed the entire contents of the table. In this case, all the addressees to whom the store sent packages were learned. However, if this was a banking system and the "hole" functionality concerned one-time codes - the addresses to which they were sent would be revealed. If there were email addresses in the array, learning about them could be used to send SPAM or phishing messages. Such an attack would be all the more dangerous because it involved the organization's actual customers.
In the example discussed above, the application used the GET method for communication, so the attack could even be carried out using a browser. However, the use of the POST method, although it hides some information from the ordinary user and allows encryption of transmitted data in the case of HTTPS, is not security (see the security by obscurity paradigm). In such a case, the WebScarab tool can be helpful. WebScarab is a special kind of proxy server. Every request passing through it is intercepted and can be modified at will. This program is often used for security testing of web applications.
How to carry out an attack using WebScarab
The first step is to set the proxy in the browser you are using to the address used by WebScarab (by default it listens on port 8008). The next step is to enter the page whose possible vulnerabilities we want to check. When the query is called, it will be intercepted and presented to the user. At this point you can make any modifications to the headers and also to the data sent via the POST method. An example of such modification with a well-known fragment of an SQL query is presented in Figure 3.
As expected, after confirming the change made in WebScarab, access to all the data in the table is obtained.
Summary
How can you protect yourself from this type of attack
-
Do not glue queries manually, instead use special functions or objects for this purpose (but it is not always possible, such as XPath query). For example, in JDBC we have a PreparedStatement tospose:
. . . PreparedStatement ps; c = ds.getConnection(); ps = c.prepareStatement("SELECT id, merchandise, address FROM orders WHERE customer_id = ? and status = ?"); ps.setString(1, customer_id); ps.setString(2, status); ps.execute(); . . . -
Do not trust any data sent from the customer, always perform validation or at least the data escaping process
. . . try { Integer val = null; val = val.parseInt(request.getParameter("status")); if (val <= 0 || val > 4) throw new NumberValidationException(); //own exception class . . . } catch(NumberFormatException ex) { out.println("Parameter problem, try once again"); } catch(NumberValidationException ex) { out.println("Parameter problem, try once again"); } catch(...) ....
