CHAPTER 10 E-Shoplifting

CHAPTER 10

E-ShopliftingE-Shoplifting

The broadest and most prevalent error requires the most disinterested virtue to sustain it.

Henry David Thoreau (1817–1862)

IntroductionIN the beginning, computer systems were installed to manage back-endoperations and support employees in their daily tasks. As technologyevolved and systems became cheaper to deploy, businesses started usingcomputers more and more in the management of their operations. Bythe early 1990s, computers and computer networks had become theinformation backbone of most enterprises, hosting a myriad of applica-tions that even handled complex business logic.

As Internet availability and use increased, information dissemi-nation via the Web became very popular. It allowed small and medium-sized businesses to present information about them and their productsfor the whole world to see. No longer were storefronts restricted by geo-graphic limitations. Numerous catalog stores such as Sears and Macy’sstarted putting out their catalogs and brochures in electronic form. Bythe late 1990s, almost every major consumer-based U.S. company hada Web site that featured its goods and services.

Moreover, as Web applications gained momentum, merchants realizedthat they could reduce reliance on physical storefronts and let customersplace orders and pay for them directly over the Internet. Thus was born theelectronic storefront was born. Computer networks and applications werenow mature enough to handle monetary transactions efficiently andreliably.

The technological revolution of the past decade made a significantimpact on the way business is done. Terms such as e-commerce, e-business, B2B (Business-to-Business), and B2C (Business-to-Consumer)started appearing in the business media and in product literature.Business trends and practices changed drastically. And the moving forcebehind this change was the technology shift, including the Internet.The Internet served as a binding force between entities hosting businesslogic and customers. It expanded the scope and reach of business andthus companies began to shift their short-term and long-term strategiesto adapt and remain competitive.

Vendors such as IBM, BEA, Netscape, Sun, and Microsoft startedcoming up with different technological building blocks, which sup-ported key business strategies. As a result, business owners and managersbegan making widespread use of these technologies and started doingbusiness over the Internet. As these new electronic businesses openedtheir windows to a global audience, they started catching the attentionof evildoers. What could be more profitable than trying to break into

2 7 62 7 6 E - S h o p l i f t i n gE - S h o p l i f t i n g

systems that make significant profits off the labors of others? (Or sothe mentality goes.) The Information Superhighway now was ready forhighway robbery. In this chapter we describe tricks used by Internetrobbers to steal from electronic storefronts when no one is looking. Wedub this crime “e-shoplifting.”

Building an Electronic StoreAN electronic business is a synthesis of two elements: business logicand technology. Robust business logic and technology can spell successfor any electronic business, whereas weaknesses in these elements typi-cally leads to disaster. The strengths and weaknesses of business logic arevast and varied, and consequently, beyond the scope of this book.Hence we focus on the technological elements of an electronic business.

Figure 10-1 and 10-2 show how a business evolves from a brick-and-mortar entity to an electronic entity.

The traditional interface between a company and its customers is thestorefront. Customers walk into a store and look around for items they areinterested in buying. As they walk around, they select the items they wantto buy. Once they are satisfied with the items that they’ve selected, orwhen it dawns on them that they may not have enough money to pay forany more, they go to the checkout counter and pay for the items.

An electronic storefront functions the same way. It comprises a storefront-end, a shopping cart, and a checkout station.

The Store Front-EndThe store front-end displays products, allows a customer to learn moreabout the products if they so desire, and provides pricing informationfor the products. Technologies used in the store front-end are mainlyaimed at smooth navigation and information dissemination. HTML ordynamically generated HTML is mainly used here.

The Shopping CartThe purpose of the shopping cart is to maintain an ongoing session withcustomers and allow them to select and collect items that they’re inter-ested in purchasing before they have to pay for them. Technologies

Building an Electronic Store 277

involved in this component revolve around session management, statetracking, and interfacing with front-end navigation. Shopping cart pro-gramming is usually done with scripting technologies such as Perl, PHP,or ASP, or by using readily available components—either in the form ofprecompiled binaries or object-oriented components, such as Java classes.

The Checkout StationThe checkout station connects the store with a bank or a credit cardprocessor, such as Verisign or Cybercash. To handle transactions, thesecompanies provide payment gateway systems that enable the appli-cation to exchange the buyer’s monetary instruments for the services orproducts requested. The checkout station also ensures that an order fordelivery of the purchased items is placed with the clearinghouse orinventory management system and that the shipment is initiated. Everycompleted transaction updates the quantities of items in the storefront.

The DatabaseKeeping records during the various stages of product purchasing ishandled by a database. It tracks inventory, order details, financial trans-actions, customer information, and the like.


Figure 10-1 Elements of a traditional business

Clearinghouse

SuppliersCompany

Store

Customer

Marketing

FinancialInstitution

TransactionProcessing

Putting It All TogetherFigure 10-3 shows how the various elements come together to form anelectronic storefront.

Evolution of Electronic StorefrontsLE T ’ S take a look at how electronic storefronts evolved with respectto technologies and the businesses adopting those technologies. Theearly Web storefronts were designed by using scripting languages suchas Perl, running on a Web server, and interacting with flat files insteadof databases. The systems were heterogeneous; that is, each componentwas distinct and separate. As Web technologies matured, vendors suchas Microsoft and Sun Microsystems came up with homogeneous e-commerce framework technologies and other vendors joined the race.Web storefront technologies began to feature multilayered applicationsinvolving middleware and middle-tier binary components such as ISAPIfilters and Java beans.

Integration with databases allowed applications to migrate fromflat files to relational databases (RDBMS), such as MS-SQL server, Oracle,and MySQL. Similarly, for storefronts, technologies such as Dynamic

Evolution of Electronic Storefronts 279

Figure 10-2 Elements of an electronic business

Customer

Store

Clearinghouse

WebMarketing

FinancialInstitution Transaction

Processing Company

SuppliersInternet

HTML (DHTML) and Flash started gaining popularity, because theymade the shopping experience both visually appealing and pleasant.However, each stage of evolution brought new vulnerabilities and newdimensions of attack. Incidents of robberies from electronic storefrontsrose dramatically, and stealing information and money on the Webbecame intolerable, desperately needing technical attention.

Where do hackers find loopholes in e-business systems? Whenever abusiness decides to establish or upgrade an electronic presence, thingsdon’t happen all at once. At one stage or another, different technologiesare integrated with existing systems. Businesses thrive on evolution, notsoftware. Mixing and matching various technologies over a period oftime leaves opportunities for vulnerabilities to creep in.

The root causes of vulnerabilities plaguing electronic storefronts are:

• Poor input validation

• Improper use of cookies

• Poor session or state tracking


Figure 10-3 Building blocks of an electronic storefront

PaymentGateway

Middle-LayerComponents

Database

Customer

Shopping CartSystem

Store Front-End

SessionManagement

System

• Assumptions that HTML and client-side scripting cannot be tam-pered with.

• Improper database integration

• Security loopholes in third-party products

We focus on these issues throughout the remainder of this chapter byfollowing the experiences of a company that decided to place itsbusiness on the Web.

Robbing Acme Fashions, Inc.AC M E Fashions, Inc., established itself as a clothing and apparelretailer operating through outlet stores in shopping malls across thecountry. A central warehouse supplied goods to its stores. AcmeFashions also sold its goods directly to customers through catalogs andorders taken over the telephone. In the early 1990s, Acme Fashionsinstalled an Oracle database inventory management and shipmenttracking system that enabled the company to expand considerably.

In the mid 1990s, as the Web gained popularity, Acme’s vice pres-ident of marketing decided to post its catalog on its Web site at http://www.acme-fashions.com. The marketing team busily began writingHTML pages and soon converted the catalog to electronic form. A fewmonths after putting up the Web site, the sales volume tripled. Themarketing vice president went on to become Acme Fashions, Inc.’s CEO.The company had taken its first step toward becoming an electronicstorefront.

Setting Up Acme’s Electronic StorefrontIn 1999, Acme Fashions, Inc., decided to open its doors to the world byhosting its business on the World Wide Web. Management wanted todebut the Web site in time to cash in on the 2000 holiday season. As thedeadline rapidly approached, management decided to outsource devel-opment of its electronic storefront to a consulting company specializingin e-commerce software development.

The consultant and an in-house team worked day and night toopen on November 1, 2000. They chose to integrate the existing Web-based catalog operation with a commercially available shopping cart

Robbing Acme Fashions, Inc. 281

system. They finally were able to tie up all the remaining loose endsand get the system up and running. The completed system is shownin Figure 10-4.

However, as sales from the Web site picked up, so too did com-plaints. Most of the complaints were traced to the accountingdepartment and the warehouse inventory department. The accountingdepartment received frequent complaints of products being sold atlower than posted prices, when no discounts or promotions had beenoffered. Shipping clerks frequently were puzzled when they receivedorders to ship quantities in negative numbers. Under tremendouspressure because of the holiday season, all the complaints wereattributed to unexplained glitches and were written off. When the totalwritten off ran to almost $100,000—and after weeks of trying to isolatethe source of the problem—management called in a team of applicationsecurity assessment experts.

Tracking Down the ProblemAcme’s Web storefront—www.acme-fashions.com—had been imple-mented with the following technologies:

Operating system Microsoft Windows NT 4.0

Web server Microsoft Internet Information Server (IIS) 4.0

Online catalog Template and Active Server Pages (ASP)

Back-end database Microsoft Access 2.0

ShoppingCart Shopcart.exe

The HTML catalog was written by using templates and Active ServerPages. The marketing team had used a FoxPro database to generateHTML pages automatically for the catalog. It was then converted to aMicrosoft Access database and interfaced with ASP. A shopping cartapplication, ShopCart.exe, was set up on the Web server, and the ASPtemplates were designed to generate HTML with links to the shoppingcart application. The shopping cart picked up the product informationfrom the generated HTML. At the time, it seemed to be the easiest andfastest way of getting the electronic storefront up and running beforethe deadline.


ShopCart.exe had its own session management system, which relieson cookies and server-side session identifiers to maintain the shoppingcart sessions. Because modification of ShopCart.exe wasn’t possible,the task of validating proper inputs was pushed out to the JavaScriptrunning on the customers’ browsers.

The application security assessment team started looking at all pos-sible entry and attack points. After examining the application and theway the Web site worked, the team uncovered some interesting securityerrors.

The Hidden Dangers of Hidden FieldsThe security team found a major loophole in the way the shoppingcart system was implemented. The only way to associate price with aproduct was via hidden tags within HTML pages. Figure 10-5 shows apage featuring shirts from the catalog at http://www.acme-fashions.com/.


Figure 10-4 Acme Fashions, Inc.’s electronic storefront

PaymentGateway(Verisign)


(Binaries, ASP,ShopCart.exe)

InventoryDatabase(Oracle)

Customer

CatalogDatabase

(MS-Access)

Store Front-End(ASP, HTML, JavaScript)

Shopping CartSystem

SessionManagement

(Cookies)

Each shirt had an associated form that accepted the quantity ofshirts desired and a link to place them in the shopping cart. Looking atthe HTML source code, shown in Figure 10-6, the team discovered thatthe vulnerability lay in the last few lines of the HTML code.

The following source code had been used to invoke ShopCart.exe:

01: <form method=post action="/cgi-bin/shopcart.exe/MYSTORE-AddItem">

02: <input type=hidden name="PartNo" value="OS0015">

03: <input type=hidden name="Item" value="Acme Shirts">


Figure 10-5 Catalog page from www.acme-fashions.com

04: <input type=hidden name="Price" value="89.99">

05: Quantity: <input type=text name=qty value="1" size=3

06: onChange="validate(this);">

07: <input type=image src='buy00000.gif' name='buy' border='0' alt='Add To

08: Cart' width="61" height="17">

09: </form>

When the user clicked the Buy button, the browser submitted all theinput fields to the server, using a POST request. Note the three hidden


Figure 10-6 HTML source code of the catalog page

fields on lines 2, 3, and 4 of the code. Their values were sent along withthe POST request. The system was thus open to an application-levelvulnerability, because a user could manipulate the value of a hiddenfield before submitting the form.

To understand this situation better, look at the exact HTTP requestthat goes from the browser to the server:

POST /cgi-bin/shopcart.exe/MYSTORE-AddItem HTTP/1.0

Referer: http://www.acme-fashions.com/shirtcatalog/shirts2.asp

Connection: Keep-Alive

User-Agent: Mozilla/4.76 [en] (Windows NT 5.0; U)

Host: www.acme-fashions.com

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Encoding: gzip Accept-Language: en

Accept-Charset: iso-8859-1,*,utf-8

Cookie: ASPSESSIONIDQQGQQKIG=ONEHLGJCCDFHBDHCPKGANANH; shopcartstore=3009912

Content-type: application/x-www-form-urlencoded

Content-length: 65

PartNo=OS0015&Item=Acme+Shirts&Price=89.99&qty=1&buy.x=16&buy.y=5

The values of the hidden fields PartNo, Item, and Price are submittedin the POST request to /cgi-bin/shopcart.exe. That’s the only way thatShopCart.exe learns the price of, for example, shirt number OS0015. Thebrowser displays the response shown in Figure 10-7.

If there was a way to send a POST request with a modified value inthe Price field, the user could control the price of the shirt. The followingPOST request would get him that shirt for the low price of $0.99 insteadof its original price of $89.99!












Content-length: 64

PartNo=OS0015&Item=Acme+Shirts&Price=0.99&qty=1&buy.x=16&buy.y=5

An easy way of manipulating the price is to save the catalog page,shirts2.asp, viewed in the browser as a local copy, shirts2.html, to theuser’s hard disk, edit the saved file, and make the changes in the HTMLcode. Figure 10-8 shows how the user saves the page.


Figure 10-7 Shopping cart contents

The user first changes the value of the Price field in the line <INPUTtype=hidden name=”Price” value=”89.99”>. His second change is to fix theACTION= link in the <FORM> tag so that it points to http://www.acme-fashions.com/cgi-bin/shopcart.exe. Figure 10-9 shows shirts2.html afterit was modified to change the price to $0.99.

Now if the user opens this modified file, shirts2.html, in the browserand submits a request to buy the shirt, he sees the window shown inFigure 10-10.


Figure 10-8 Saving a local copy to the user’s hard disk


Is this a great way of going bargain shopping or what? As incredibleas it seems, this indeed was the problem that accounted for AcmeFashions, Inc.’s loss of revenue. After a thorough reconciliation of ordersand transactions, the application security assessment team found thatnumerous “customers” were able to buy items for ridiculously lowprices. We say “customers” facetiously because they most likely werehackers.

We alluded to the dangers of passing information in hidden fields inChapter 7 where we showed how to go about quickly sifting throughsource code to locate hidden fields. Hacking applications using infor-mation passed back and forth via hidden fields is a trivial task. Itinvolves no special skills other than using a browser and perhaps fum-bling around with Unix’s Visual Editor (vi) or Microsoft Windows’NotePad application. Yet the effect is quite devastating.

Figure 10-9 The shirts.html file being modified to change the price


Figure 10-10 Results from tampering with the hidden field

Bypassing Client-Side ValidationThe next error spotted by the security testing team was the way inputswere validated before being passed to ShopCart.exe. Web applicationsconsist of many scripts and interactive components, which interactprimarily with the user via HTML forms on browsers. The interactivepart of any component takes input from the HTML form and processes


Using Search Engines to Look for Hidden FieldsYou can use any of the many Internet search engines to quickly check whether your Web siteor application contains hidden fields. For example, Figure 10-11 shows how to use Googleto determine whether hidden fields are used to pass price information within www.acme-fashions.com.

Because www.acme-fashions.com is a popular shopping site, Google has cataloged it. Figure10-12 reveals the results of the search: all pages within the domain acme-fashions.comthat contain the strings “type=hidden” and “name=price.” Be sure to restrict the search to thechosen site; otherwise you may end up having to sift through thousands of results!

Figure 10-11 A Google search

it on the server. HTML forms are generic when it comes to capturingdata, and there is no way to ensure validation of data within such forms.For example, if an HTML form is designed to accept a date, a user canenter a date such as 99/88/77 and the browser won’t even care. Theapplication has to have its own input validation mechanisms to filterout such erroneous inputs to ensure that the input complies with pre-determined criteria for the application. Input validation for HTML formscan be done either on the server side with Perl, PHP, or ASP, amongothers, or on the client side, using scripting languages such as JavaScriptor VBScript.


Figure 10-12 Results of the Google search

Acme’s development team recognized the need for such input vali-dation, but because ShopCart.exe was a prepackaged application thatcouldn’t be modified to incorporate input validation. Hence the teamdecided to move the burden of input validation to client-side scriptsrunning on the browser itself. Someone even remarked, “Yes, this is agood idea since it will save the server’s CPU usage. Let the work be per-formed by the client’s browser instead.”

The fact that any client-side mechanism could be altered by editingthe HTML source code received by the browser was overlooked. Thesecurity testing team found several instances of client-side validationbeing used on www.acme-fashions.com. Figure 10-13 shows client-sideinput validation in action on Acme’s system. A user tries to buy “–5”shirts and an alert pops up stating that the user has entered an invalidnumber.

The JavaScript code that validates the input is shown in Figure 10-13. For the sake of clarity, the following is the code separated from theHTML elements:

<script>

function validate(e) {

if(isNaN(e.value) || e.value <= 0) {

alert("Please enter a valid number");

e.value = 1;

e.focus();

return false;

}

else {

return true;

}

}

</script>

:

:

<input type=text name=qty value="1" size=3 onChange="validate(this);">

This code ensures that only positive numbers are allowed in the fieldqty. But, because the validation is done by a client-side script, it is easyto bypass. Simply disabling the execution of JavaScript by setting thebrowser preferences allows an attacker to bypass client-side validation! Ifwe choose to disable JavaScript, as shown in Figure 10-14, we can enterwhatever value we desire in the input fields.


Figure 10-14 shows the Disabling JavaScript in Netscape Now if auser were to send a quantity of “–3,” the browser would issue the fol-lowing POST request to the server:






Figure 10-13 Client-side validation, using JavaScript







Content-length: 63

PartNo=OS0015&Item=Acme+Shirts&Price=-3&qty=1&buy.x=16&buy.y=5

Note how this HTTP request completely bypasses client-side vali-dation. Figure 10-15 shows the server’s response.

The screenshot shows that the user has placed one order for 5 shirtsat $54.99 each and another order for –3 shirts at $89.99 each. The totalbill comes is $4.98. The ability to place orders for negative numbers toreduce the total amount of the bill would make shoppers quite happy!This flaw is what caused the shipping clerks at Acme to receive orders fornegative numbers of items.


Figure 10-14 Disabling JavaScript

Acme Fashions, Inc.’s management concluded that client-side inputvalidation is dangerous and should not be used. Who is to blame? Theflaw lies with the way ShopCart.exe was designed in the first place. Theonus of validating inputs should be on the ShopCart.exe application.But, because it had no input validation, the Web site development teamwas forced to resort to client-side validation.

Even today, many third-party commercial shopping cart systems lackproper input validation. Sometimes it is possible to place orders for frac-tional quantities. At other times it even is possible to insert meta-characters or arbitrarily long buffers and crash the server-side application.


Figure 10-15 Purchasing a negative number of shirts

Overhauling www.acme-fashions.comAFTER the application security assessment team presented its findings,Acme’s management decided to make radical changes in the company’s e-business application, it hired a new team to look at the existing system andrewrite the code as necessary. The older commercial shopping cart system,ShopCart.exe, didn’t allow product and pricing information to be stored ina database, so the team decided to develop its own shopping cart system.At the same time, it also decided to move the servers from Windows NT4.0to the newly released Windows 2000 platform, running IIS 5.0 andActivePerl. This time, the developers used a modified version of a shoppingcart written in Perl, which was freely available on the Internet.

All client-side validation routines and improperly used hidden fieldswere removed. Care was taken to ensure that all the other mistakes madepreviously were not repeated. The new system went online August 1,2001.

Facing a New Problem with the Overhauled SystemOn September 15 Acme’s accounting department received a call from acredit card agency that was trying to trace the sources of credit cardfraud. It so happened that most of the customers of the credit cardagency who reported incidents of fraud had made purchases on AcmeFashions, Inc.’s Web site between August 1 and September 1. The creditcard agency was convinced that the customer credit card informationhad somehow been stolen from Acme.

Acme’s management already had faced and solved problemsinvolving customers’ tampering with prices during the precedingholiday season shopping. As if that weren’t enough, now they had todeal with possible credit card theft. Management called in yet anothertop-notch computer forensics team to help evaluate the situation.

The team discovered that, in all the Web server logs for the month ofAugust, there wasn’t a single entry for August 29. This gap led the teamto believe that a hacker must have wiped out the file C:\WINNT\System32\LogFiles\W3SVC1\ex20010829.log, which would have con-tained log data for that date. The file size had been reduced to 0 bytes, sothe hacker must have had some way of getting administrative control ofthe server in order to wipe out the IIS Web server’s logs.

Because there was no log data to go by, the team could only spec-ulate on the possible cause of the attack. A thorough investigation of the

Overhauling www.acme-fashions.com 297

system’s hard drive showed that a file called “purchases.mdb” waspresent in two directories:

C:\>dir purchases.mdb /s

Volume in drive C is ACMEFASHION

Volume Serial Number is 48CD-A4A0

Directory of C:\ACMEDATA

08/29/2001 08:13p 2,624,136 purchases.mdb

1 File(s) 2,624,136 bytes

Directory of C:\Inetpub\wwwroot

08/29/2001 11:33p 2,624,136 purchases.mdb


Total Files Listed:


0 Dir(s) 111,312,896 bytes free

How did purchases.mdb end up getting copied from C:\ACMEDATAto the C:\Inetpub\wwwroot directory? The system administrator at AcmeFashions confirmed that purchases.mdb was used to hold customer orderinformation, which included the customer’s name, shipping address,billing address, items bought, and the credit card used to pay for theitems. The application designers assured management that the databasefiles lay outside the Web server’s document root (C:\inetpub\wwwroot).The forensics team therefore concluded that, because a copy of pur-chases.mdb was created at 11:33 P.M. on August 29, 2001, fraud hadoccurred and it was the work of a hacker. The hacker must have copiedthe file from C:\ACMEDATA to C:\Inetpub\wwwroot and downloaded itwith a browser by making a request to http://www.acme-fashions.com/purchases.mdb. Most likely, the hacker forgot to delete the copiedfile from the C:\Inetpub\wwwroot directory after downloading it.

Remote Command ExecutionThe fact that files were copied from one location to another and thatthe Web server logs were deleted suggested that the hacker had a meansof executing commands on www.acme-fashions.com and had “super-


user” or “administrator” privileges. After thoroughly evaluating the oper-ating system security and lockdown procedures, the team concluded thatthe vulnerability was most likely an error in the Web application code.The problem was narrowed down to lack of proper input validationwithin the shopping cart code itself. Figure 10-16 shows how theshopping cart interacts with various elements of the Web application.

The shopping cart is driven by a central Perl script, mywebcart.cgi. Allclient-side sessions are tracked and managed by mywebcart.cgi. Theshopping cart pulls product information from the products.mdb databaseand interfaces with a checkout station module that handles the cus-tomer payments, which are stored in purchases.mdb.

Figure 10-17 shows a page generated by mywebcart.cgi. Note the waythat the URL is composed, especially keep in mind the ideas presentedin Chapter 3 concerning poorly implemented shopping carts.

Overhauling www.acme-fashions.com 299

Figure 10-16 Components of the new www.acme-fashions.com

PaymentGateway(Verisign)


(Binaries, ASP,ShopCart.exe)

Customer

CatalogDatabase

(MS-Access)

Store Front-End(ASP, HTML, JavaScript)

Shopping CartSystem

SessionManagement

(Cookies)InventoryDatabase(Oracle)

CatalogDatabase

(MS-Access)

CustomerDatabase

(MS-Access)

The URL is:

http://www.acme-fashions.com/cgi-

bin/mywebcart.cgi?cust=0873&nextpage=shirts3.html&cid=03417

The most interesting elements of this URL are the parameters passedto it, along with their values. Note that the parameter nextpage is passeda value of “shirts3.html.“ In the Perl code of mwebcart.cgi, the followingline is responsible for the vulnerability:


Figure 10-17 Page generated by mywebcart.cgi

$file = "c:\inetpub\wwwroot\catalog_templates\" . $input{'nextpage'};

open(FILE, $file) || die "Cannot open $file\n";

The fate of mywebcart.cgi is sealed. The parameter nextpage is passedto the Perl’s open() function without any input validation. As discussedin Chapter 3, an attacker can insert the pipe symbol “|” at the end of thevalue assigned to nextpage and cause the open() function to execute arbi-trary commands.

The following request would cause mywebcart.cgi to execute the “dirc:\” command on www.acme-fashions.com:

http://www.acme-fashions.com/cgi-

bin/mywebcart.cgi?cust=0873&nextpage=;dir+c:\|&cid=03417

Figure 10-18 displays the results in the browser window.At this point, we can assume that the hacker must have performed

a full directory listing, using the “dir c:\ /s” command. From the results,he noticed the presence of the file purchases.mdb in the C:\ACMEDATAdirectory. Next, he copied it to c:\inetpub\wwwroot and then down-loaded it, using http://www.acme-fashions.com/purchases.mdb. Figures10-19 and 10-20 show how the file was copied and eventually down-loaded.

This demonstration by the forensics team exposed a serious securitybreach in mywebcart.cgi. Even today, many publicly and commerciallyavailable shopping carts are rife with such vulnerabilities.

Postmortem and FurtherCountermeasures

AC M E Fashions, Inc., suffered tremendous losses of time and moneybecause of three critical mistakes over a period of time. All these mis-takes were attributed to the lack of input validation and trust in theintegrity of data received from the Web browser. Let’s review these short-comings again.

The first flaw was caused by the improper use of hidden fields.Crucial information such as product ID and price were passed viahidden fields in HTML forms. Recall that, once the HTML response issent by the Web server to the Web browser, the server loses all control

Postmortem and Further Countermeasures 301

over the data sent. HTTP is essentially stateless, and the server can makeno assumptions about whether the data returned is intact or has beentampered with. Hidden fields can be manipulated on the client side andsent back to the Web server. If the server doesn’t have any way to val-idate the information coming in via hidden fields, clients can tamperwith data and bypass controls enforced by the system. To protectsystems from such attacks on data integrity, Web site developers should


Shopping Carts with Remote CommandExecutionMany commercially available shopping carts suffer from a lack of input validation in param-eters passed via the URL or hidden fields. That lack allows Meta-characters to be inserted toachieve remote command execution. Here are some headlines taken from various securityinformation portals regarding vulnerabilities in shopping carts:

• September 6, 2001—ShopPlus Cart Commerce System Lets Remote Users ExecuteArbitrary Shell Commands

• September 8, 2001—Hassan Consulting Shopping Cart Allows Remote Users to ExecuteShell Commands on the Server

• September 19, 2001—Webdiscount.net’s eshop Commerce System Lets Remote UsersExecute Arbitrary Commands on the System and Gain Shell Access

• October 20, 2001—Mountain Network Systems WebCart Lets Remote Users ExecuteArbitrary Commands on the Web Server

All these shopping carts fail when the pipe character is inserted in one of the URL param-eters. The exploit URLs for these carts are:

http://targethost/scripts/shopplus.cgi?dn=domainname.com&cartid=%CARTID%&file=;c

at%20/etc/passwd|

http://targethost/cgi-local/shop.pl/SID=947626980.19094/page=;uname+-a|

http://targethost/cgi-bin/eshop.pl?seite=;ls|

http://targethost/cgi-

bin/webcart/webcart.cgi?CONFIG=mountain&CHANGE=YES&NEXTPAGE=;ls|&CODE=PHOLD

As a result, all these shopping carts end up passing unchecked parameter contents to Perl’sopen() function for opening a file.


avoid passing information via hidden fields. Instead, such informationshould be maintained in a database on the server, and the informationshould be pulled out from the database when needed.

The second obvious mistake was using client-side scripts to performinput validation. Code developers are always tempted to use JavaScriptor VBScript to have code executed on the client side and remove theburden from the server. However, client-side scripts are as fragile ashidden fields when it comes to the lack of tamper resistance. Client-sidescripts only are to be used for smooth navigation or adding extra inter-activity and presentability to the Web page. An attacker can easily

Figure 10-18 Executing arbitrary commands with mywebcart.cgi


bypass or modify client-side scripts and circumvent any checks enforcedby them. As in the Acme case, attackers can inject negative quantitieswith ease, bypassing any restriction imposed by the embeddedJavaScript. Similarly, some Web-based storefront systems perform arith-metic operations on the client side, such as computing the totalquantity and price of an order within the fill-out form itself. To the cus-tomer, it is a nice feature when they can see prices updated on thebrowser without submitting the values to the server and waiting for aresponse. However, this technique must be avoided at all costs and theapplication must be designed in such way that all important valida-

Figure 10-19 Copying purchases.mdb to c:\inetpub\wwwroot


tions and computations are executed and verified on the server side sothat attackers cannot manipulate the data. The golden rule is: “Thoushalt not trust data coming from the client.”

The final vulnerability was caused by the lack of input sanitizationin mywebcart.cgi. Whenever data is passed by fields in HTML forms tocritical functions such as open(), care must be taken to remove any com-bination of symbols or meta-characters. Two main input validationsmust be performed: one for the length of the data received (to avoidbuffer overflow attacks) and the second for meta-characters. In this case,Acme has to insert an input sanitization to filter meta-characters such as

Figure 10-20 Downloading purchases.mdb

“&,” “%,” “$,” “|,” and “<.” For a nearly complete list of input saniti-zation routines in all the major Web languages used today, reviewChapter 1.

Additional security issues relating to e-commerce shopping systems,in general, include information retrieval from temporary files on theserver, poor encryption mechanisms, file system directory exposure,privilege escalation, customer information disclosure, alteration ofproducts, alteration of orders, and denial of services. All offer vulnera-bilities to attack and are present in many e-commerce application imple-mentations.

SummaryE- B U S I N E S S applications attract hackers that can manipulate moneyflowing through business channels. It becomes the responsibility ofevery CIO, systems administrator, and applications developer to protectcritical corporate and customer information and assets from malicioushackers. A single loophole in the application can prove disastrous, andin moments an electronic storefront can be cleaned out by robbers onthe information superhighway. Not only does the business lose money,but it also loses its hard-earned reputation. Whether the flaws lie withpoorly written third-party applications or were left behind by adeveloper team, the company loses business. Shore up your Web appli-cations and make security priority one before you start writing your firstline of code.


Documents

CHAPTER 10 E-Shoplifting