Tuesday

E-Commerce

Implementation of a Shopping Cart Application

• Tweet
• Sharebar

• Tweet

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 conference management component, which keeps track of a customer’s shopping conference. Second, it is integrated with the product catalog application, which generates a show 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 conference. Fourth, it is integrated with back-end databases such as product inventory for involuntarily verifying and updating stock quantities, customer information for tracking customers’ buying preferences, and so on.

Figure 3-7. Shopping cart implementation – technology perspective

In view of the fact that the ahead of schedule 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 recommend itself. We look at such attacks in more detail in Chapter 10, everywhere poorly implemented shopping carts allow customers to hold 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 life passed back and forth. Quantity validation is an equally vital issue. What happens if a customer enters a negative quantity into the shopping cart? What happens if the customer enters a fractional quantity?

Conference Management

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

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 conference, 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 incorrect if shopping carts are poorly implemented by presenting some examples in this part. 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 do 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 frankly 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 font 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 hold. The product catalog application and the shopping cart application take care of this administer. Let’s now focus on the look into administer and how customers pay for their buys.

Finalizing the Order
Once a customer has finalized the selection of items she wishes to hold, the payment processing system captures the order details from the customer’s shopping cart. The system also questions 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 deduction cards are the most standard methods of payment in nearly 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 buys. 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 hold, and the like.

At the electronic storefront site, the payment processing system keeps a meticulous 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 must 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 say them of the admittance of shipment, with a tracking number for use with the delivery agency so that the customers can track their shipments themselves.