As shown in Figure 3-7, proper implementation of the shopping cart application requires integration of several different electronic business components. First, it is integrated with a session management component, which keeps track of a customer’s shopping session. Second, it is integrated with the product catalog application, which generates a display of products sold by the storefront and allows the customer to browse the products; the customer can select a product from the catalog and place it in the shopping cart. Third, it is integrated with—acts as an input to—the payment gateway, which comes into play at the end of the shopping session. Fourth, it is integrated with back-end databases such as product inventory for automatically verifying and updating stock quantities, customer information for tracking customers’ buying preferences, and so on.

Figure 3-7. Shopping cart implementation - technology perspective

Since the early days of electronic retail shopping, many types of shopping carts have been introduced. Some shopping carts were made publicly available along with the source code, whereas some were sold as commercial third-party applications. Of the plethora of shopping carts, many failed because of improper implementation, which eventually led to security vulnerabilities.

Product Catalog

The product catalog typically consists of a product code, a product description, pricing, and other information. When a customer selects a product from the catalog, she places it in her shopping cart. Weak integration of the product catalog and the shopping cart leads to security vulnerabilities.

For example, if the customer can find a way to manipulate the price while selecting a product, a major error will occur. We look at such attacks in more detail in Chapter 10, where poorly implemented shopping carts allow customers to purchase products at reduced prices.

A well-implemented shopping cart application interfaces with the back-end product information database. Then parameters such as prices are derived from the database instead of relying on HTML form fields being passed back and forth. Quantity validation is an equally important issue. What happens if a customer enters a negative quantity into the shopping cart? What happens if the customer enters a fractional quantity?

Session Management

Another important aspect of shopping cart implementation is the session management mechanism. Each customer has to have a separate shopping cart while making purchases from the electronic store. Like regular storefronts, an electronic storefront probably caters to many customers at the same time. A poor session management mechanism may cause customers’ shopping carts to get mixed up, which may lead to disastrous results, especially if one customer ends up paying for another customer’s purchases. To manage customer shopping activities, a well-designed server-side session management system is essential. A poorly designed session management system can lead to session hijacking or information leakage.

Database Interfacing

The database interface between the shopping cart application and back-end databases is a focus for attacks. If it isn’t implemented properly, an attacker can inject malicious SQL queries to the database and cause a security breach. An attacker may also modify intermediate tables that store other users’ shopping sessions and selections.

Integration with the Payment Gateway

At the end of the shopping session, all selected items in the shopping cart and the corresponding bill are passed to the invoice generation and payment processing page of the electronic store application. Weak integration in this area can lead to the tampering of prices or entering of illegal quantities before the information is passed to the payment gateway.

Examples of Poorly Implemented Shopping Carts

We illustrate briefly what can go wrong if shopping carts are poorly implemented by presenting some examples in this section. More complete coverage of the vulnerabilities illustrated here are presented in later chapters and in Chapter 10, in particular.

Carello Shopping Cart
The Carello shopping cart (http://www.carelloweb.com) running on Windows NT has a flaw that allows remote command execution over HTTP. This shopping cart has a component called Carello.dll that interacts with the client. An attacker can inject commands by using malformed URLs that lead to remote command execution on the Web server.

For example, the following URL can execute the dir command on the server:

http://target/scripts/Carello/Carello.dll?CARELLOCODE=SITE2&VBEXE=C:\..\winnt\system32\cmd.exe%20/c%20dir

A full description is available at http://securitytracker.com/alerts/2001/May/1001526.html.

DCShop Shopping Cart
The DCShop shopping cart (http://www.dcscripts.com/dcforum/dcshop/44.html) stores temporary order information in clear text in a temporary file called orders.txt. This file is in DCShop’s Order subdirectory and can be retrieved directly via HTTP by any user. The orders.txt file contains all the data related to customers’ recent orders, including names, shipping addresses, billing addresses, e-mail addresses, and credit card data. The attack can be performed simply by issuing the following URL:

http://target/cgi-bin/DCShop/Orders/orders.txt

A full description is available at http://securitytracker.com/alerts/2001/Jun/1001777.html.

Hassan Consulting’s Shopping Cart
Hassan Consulting’s shopping cart (http://www.irata.com/products.html) allows arbitrary command execution on the server. The shopping cart runs on Unix and is written in Perl. The script, shop.pl, doesn’t filter out characters such as “;” and “|,” which allow remote users to inject commands on the server via the URL. URL exploitation occurs as follows:

http://target/cgi-local/shop.pl/SID=947626980.19094/page=;ls|

A full description is available at http://securitytracker.com/alerts/2001/Sep/1002379.html.

Cart32 and Several Other Shopping Carts
Some shopping carts have hidden form fields within the html source code that contain product information such as price, weight, quantity, and identification. An attacker can save the Web page of a particular item to his computer and edit the html source, allowing him to alter the parameters of the product, including the price of the product.

A full description is available at http://online.securityfocus.com/bid/1237.

Processing Payments

So far, we’ve looked at how a customer goes about browsing the electronic storefront and selecting items for purchase. The product catalog application and the shopping cart application take care of this process. Let’s now focus on the checkout process and how customers pay for their purchases.

Finalizing the Order
Once a customer has finalized the selection of items she wishes to purchase, the payment processing system captures the order details from the customer’s shopping cart. The system also asks for extra information to complete the order, such as shipping address, mode of shipment, method of payment, and so on. At this point, the customer is given the option of revising the order if necessary.

Method of Payment
Customers have several options for making payment. Credit cards and debit cards are the most popular methods of payment in almost all retail shopping, be it physical or electronic. All electronic payment processing systems can handle payment by credit card and check.

Verification and Fraud Protection
Payment processing systems communicate with the payment gateway to verify the authenticity of the customer’s method of payment for the purchases. In the case of credit cards, the payment gateway validates credit card numbers and expiration dates, verifies ownership, and determines whether the credit balance covers the amount of the purchase, and the like.

At the electronic storefront site, the payment processing system keeps a detailed log of all transactions so that they can be reconciled when payments are settled with the financial institution. Maintaining transaction logs is mandatory in most cases, and they should also be closely guarded. An attacker’s gaining access to the transaction log database would pose a huge security risk involving customers’ identities and payment instruments, which could then be used in fraudulent schemes.

Order Fulfillment and Receipt Generation
Once the payment is processed successfully, the payment system application in the electronic storefront confirms the order acceptance and generates a receipt for the customer. Nowadays, such applications have the ability to e-mail receipts to customers and notify them of the initiation of shipment, with a tracking number for use with the delivery agency so that the customers can track their shipments themselves.