Common Security Vulnerabilities in e-commerce systems
by K. K. Mookhey, Security Focus

1. Introduction

Successful exploitation of these vulnerabilities can lead to a wide range of results. Information and path disclosure vulnerabilities will typically act as initial stages leading to further exploitation. SQL injection or price manipulation attacks could cripple the website, compromise confidentiality, and in worst cases cause the e-commerce business to shut down completely.

Wherever examples of such vulnerabilities are given in advisories published by Bugtraq, we have given the Bugtraq ID in square brackets. Details of the vulnerability may be viewed by navigating to http://www.securityfocus.com/bid/<bid_number> .

2. Vulnerabilities

2.1 Background

One of the main reasons for such vulnerabilities is the fact that web application developers are often not very well versed with secure programming techniques. As a result, security of the application is not necessarily one of the design goals. This is exacerbated by the rush to meet deadlines in the fast-moving e-commerce world. Even one day's delay in publishing a brand new feature on your website could allow a competitor to steal a march over you. We've typically found this in cases where e-commerce sites need to add functionality rapidly to deal with a sudden change in the business environment or simply to stay ahead of the competition. In such a scenario, the attitude is to get the functionality online; security can always be taken care of later. Another reason why security vulnerabilities appear is because of the inherent complexity in most online systems. Nowadays, users are placing very demanding requirements on their e-commerce providers, and this requires complex designs and programming logic.

In a number of cases, we've found that e-commerce sites tout their 128-bit SSL certificates as proof that their sites are well secured. The gullibility of customers to believe in this has reduced over the past few years, but even now there are thousands of web sites displaying Verisign or Thawte certificate icons as proof of their security.

The following sections look at common security vulnerabilities that have been discovered in shopping cart and online payment systems.

2.2 SQL Injection

SQL injection techniques differ depending on the type of database being used. For instance, SQL injection on an Oracle database is done primarily using the UNION keyword [ref 1] and is much more difficult than on the MS SQL Server, where multiple queries can be executed by separating them with the semi-colon [ref 2]. In its default configuration, MS SQL server runs with Local System privileges and has the 'xp_cmdshell' extended procedure, which allows execution of operating system commands.

The most publicized occurrences of this vulnerability were on the e-commerce sites of Guess.com [ref 3] and PetCo.com [ref 4]. A 20-year old programmer in Orange County, California, Jeremiah Jacks discovered that it was possible to ferret out highly sensitive data such as credit card numbers, transaction details, etc. from these and a number of other sites using specially crafted URLs containing SQL meta-characters.

SQL injection vulnerabilities have also been discovered in shopping cart software such as the VP-ASP Shopping Cart [bid 9967], IGeneric Free Shopping Cart [bid 9771], Web Merchant Services Storefront Shopping Cart [bid 9301], etc. Of these, the vulnerability in the Storefront Shopping Cart occurred in its login.asp page, and could potentially allow the attacker to execute malicious database queries, without needing to authenticate to the web site.

2.3 Price Manipulation

Figure 1: Achilles web proxy

The final payable price (currency=Rs&amount=879.00) can be manipulated by the attacker to a value of his choice. This information is eventually sent to the payment gateway with whom the online merchant has partnered. If the volume of transactions is very high, the price manipulation may go completely unnoticed, or may be discovered too late. Repeated attacks of this nature could potentially cripple the viability of the online merchant.

Similar vulnerabilities have also been found in third-party software such as in the 3D3 ShopFactory Shopping Cart [bid 6296], where price and item-related information was stored in client-side cookies, which could easily be manipulated by an attacker. Similarly, Smartwin Technology's CyberOffice Shopping Cart 2.0 could be attacked by downloading the order form locally, and resubmitting it to the target server with the hidden form fields modified to arbitrary values [bid 1733].

2.4 Buffer overflows

Figure 2: PHP timeout error

Using this error information it was possible to access the restricted 'admin' folder. From the structure of the web site and the visible hyperlinks there would have been no way to determine that there existed the 'admin' directory within the 'func' sub-directory below the main $DocumentRoot.

Multiple buffer overflows were also discovered in the PDGSoft Shopping Cart [bid 1256], which potentially allowed the attacker to execute code of his choice by over-writing the saved return address.

Error pages can serve as a valuable source for critical information. These errors can be induced in web applications that do not follow strict input validation principles. For instance, the application may expect numeric values and would fail when alphabets or punctuation characters are supplied to it. This is exactly what has happened in the case below. Here, the e-commerce website used numbers for its various pages. Users would navigate using a link such as http://www.vulnerablesite.com/jsp/Navigate.jsp?pageid=123. By manipulating the URL and supplying the value 'AA' for the pageid, the following error was induced:

Figure 3: Discovering information through navigation errors

If you observe carefully, the highlighted information reveals the Oracle Application Server version as Oracle 9iAS 9.0.3.0.0 as well as certain third-party components being used by the web application, such as Orion Application Server. It also reveals the path where other (possibly vulnerable) .jsp scripts exist - /scripts/menu.jsp .

2.5 Cross-site scripting

1. The lack of input and output validation being done by the web application
2. The trust placed by the end-user in a URL that carries the vulnerable web site's name.

The XSS attack requires a web form that takes in user input, processes it, and prints out the results on a web page, which also contains the user's original input. It is most commonly found in 'search' features, where the search logic will print out the results along with a line such as 'Results for <user_supplied_input>'. In this case, if the user input is printed out without being parsed, then an attacker can embed JavaScript by supplying it as part of the input. By crafting a URL, which contains this JavaScript, a victim can be social engineered into clicking on it, and the script executes on the victim's system. A typical XSS attack URL would look like this: http://www.vulnerablesite.com/cgi-bin/search.php?keywords=<script>alert("OK")<script>. In this case, when the victim clicks on this link, a message box with the text "OK" will open up on his system.

In most cases, the attacker would craft the URL in order to try and steal the user's cookie, which would probably contain the session ID and other sensitive information. The JavaScript could also be coded to redirect the user to the attacker's website where malicious code could be launched using ActiveX controls or by utilizing browser vulnerabilities such as those in Internet Explorer or Netscape Navigator.

However, the JavaScript can also be used to redirect the user to a site that looks similar to the original web site and requests the user to enter sensitive information such as his authentication details for that web site, or his credit card number or social security number. A related attack is shown below:

Figure 4: Phishing scam (Source: Article on SecurityFocus http://www.securityfocus.com/infocus/1745)

In this case, the attacker has opened up two windows on the victim's system. The one in the background is the original Citibank web site, whereas the pop up window in front of it requests for the user's debit card number, PIN, and card expiration date. On hitting the submit button, this information is sent to the attacker's server. Called a 'phishing' attack [ref 7], it was done by sending a spoofed email that claimed to originate from Citibank and asked users to verify their details. The link in the spoofed email looked something like this http://www.citibank.com:ac=piUq3027qcHw003nfuJ2@sd96V.pIsEm.NeT/3/?3X6CMW2I2uPOVQW Most users would not be aware that as per HTTP rules, this link would actually go to sd96v.pisem.net (highlighted above), and not www.citibank.com

Similar attacks can be carried out if the web application has scripts that redirect users to other parts of the site, or to other related sites. For instance, in one of our assignments, the web application had a script that was used to send the user to dynamically created parts of the web site: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=some_dynamic_value Due to the lack of security awareness of the web developers, they did not realize that an attacker could craft a URL such as http://www.vulnerablesite.com/cgi-bin/redirect.php?url=www.attackersite.com and send it to a victim. This URL can be trivially obfuscated by hex-encoding the part that follows 'url=' or by converting the attacker's IP address into hexadecimal, octal or double-word values. For instance if the attacker's IP address is 192.168.0.1, the URL could be crafted as follows: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=http://7934518627/ .

2.6 Remote command execution

In another case, Pacific Software's Carello Shopping Cart [bid 5192] had a vulnerable DLL that allowed the execution of remote commands due to directory traversal attacks that could be carried out using a specially crafted URL.

2.7 Weak Authentication and Authorization

Since HTTP is a stateless protocol, web applications commonly maintain state using session IDs or transaction IDs stored in a cookie on the user's system. Thus this session ID becomes the only way that the web application can determine the online identity of the user. If the session ID is stolen (say through XSS), or it can be predicted, then an attacker can take over a genuine user's online identity vis-à-vis the vulnerable web site. Where the algorithm used to generate the session ID is weak, it is trivial to write a Perl script to enumerate through the possible session ID space and break the application's authentication and authorization schemes.

This was illustrated in a paper by David Endler [ref 9], "Brute-Force Exploitation of Web Application Session IDs", where he explains how session IDs of sites like www.123greetings.com, www.register.com, and others could be trivially brute-forced. Similarly, in one such instance, we discovered that the order ID for the user's transactions was not generated randomly, and it was possible to access the orders placed by other users simply by writing a Perl script that enumerated all possible order IDs within a given range. The most pertinent point here is that although web application may have mechanisms to prevent a user from multiple password guessing attempts during authentication, they do not usually prevent a user from trying to brute-force sessions IDs by resubmitting the URLs as described in Endler's paper.

3. Countermeasures

Some excellent resources on secure coding are David Wheeler's book "Security Linux Programming HOWTO" [ref 10], Michael Howard's "Writing Secure Code", and John Viega's "Secure Programming Cookbook for C and C++". The Open Web Application Security Project's Guide [ref 11] is also a highly useful document on web application security issues.

4. Conclusion