Robbing Acme Fashions, Inc.
Robbing Acme Fashions, Inc.
ACME Fashions, Inc., established itself as a clothing and apparel retailer operating through outlet stores in shopping malls across the country. A central warehouse supplied goods to its stores. Acme Fashions also sold its goods directly to customers through catalogs and orders taken over the telephone. In the early 1990s, Acme Fashions installed an Oracle database inventory management and shipment tracking system that enabled the company to expand considerably.
In the mid 1990s, as the Web gained popularity, Acme's vice president of marketing decided to post its catalog on its Web site at http://www.acme-fashions.com. The marketing team busily began writing HTML pages and soon converted the catalog to electronic form. A few months after putting up the Web site, the sales volume tripled. The marketing vice president went on to become Acme Fashions, Inc.'s CEO. The company had taken its first step toward becoming an electronic storefront.
Setting Up Acme's Electronic Storefront
In 1999, Acme Fashions, Inc., decided to open its doors to the world by hosting its business on the World Wide Web. Management wanted to debut the Web site in time to cash in on the 2000 holiday season. As the deadline rapidly approached, management decided to outsource development of its electronic storefront to a consulting company specializing in e-commerce software development.
The consultant and an in-house team worked day and night to open on November 1, 2000. They chose to integrate the existing Web-based catalog operation with a commercially available shopping cart system. They finally were able to tie up all the remaining loose ends and get the system up and running. The completed system is shown in Figure 10-4.
Figure 10-4. Acme Fashions, Inc.'s electronic storefront
However, as sales from the Web site picked up, so too did complaints. Most of the complaints were traced to the accounting department and the warehouse inventory department. The accounting department received frequent complaints of products being sold at lower than posted prices, when no discounts or promotions had been offered. Shipping clerks frequently were puzzled when they received orders to ship quantities in negative numbers. Under tremendous pressure because of the holiday season, all the complaints were attributed to unexplained glitches and were written off. When the total written off ran to almost $100,000 and after weeks of trying to isolate the source of the problem management called in a team of application security assessment experts.
Tracking Down the Problem
Acme's Web storefront www.acme-fashions.com had been implemented 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 Server Pages. The marketing team had used a FoxPro database to generate HTML pages automatically for the catalog. It was then converted to a Microsoft Access database and interfaced with ASP. A shopping cart application, ShopCart.exe, was set up on the Web server, and the ASP templates were designed to generate HTML with links to the shopping cart application. The shopping cart picked up the product information from the generated HTML. At the time, it seemed to be the easiest and fastest way of getting the electronic storefront up and running before the deadline.
ShopCart.exe had its own session management system, which relies on cookies and server-side session identifiers to maintain the shopping cart sessions. Because modification of ShopCart.exe wasn't possible, the task of validating proper inputs was pushed out to the JavaScript running on the customers' browsers.
The application security assessment team started looking at all possible entry and attack points. After examining the application and the way the Web site worked, the team uncovered some interesting security errors.
The Hidden Dangers of Hidden Fields
The security team found a major loophole in the way the shopping cart system was implemented. The only way to associate price with a product was via hidden tags within HTML pages. Figure 10-5 shows a page featuring shirts from the catalog at http://www.acme-fashions.com/.
Figure 10-5. Catalog page from www.acme-fashions.com
Each shirt had an associated form that accepted the quantity of shirts desired and a link to place them in the shopping cart. Looking at the HTML source code, shown in Figure 10-6, the team discovered that the vulnerability lay in the last few lines of the HTML code.
Figure 10-6. HTML source code of the catalog page
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">
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='/books/2/819/1/html/2/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 the input fields to the server, using a POST request. Note the three hidden fields on lines 2, 3, and 4 of the code. Their values were sent along with the POST request. The system was thus open to an application-level vulnerability, because a user could manipulate the value of a hidden field before submitting the form.
To understand this situation better, look at the exact HTTP request that 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 submitted in the POST request to /cgi-bin/shopcart.exe. That's the only way that ShopCart.exe learns the price of, for example, shirt number OS0015. The browser displays the response shown in Figure 10-7.
Figure 10-7. Shopping cart contents
If there was a way to send a POST request with a modified value in the Price field, the user could control the price of the shirt. The following POST request would get him that shirt for the low price of $0.99 instead of its original price of $89.99!
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: 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 the user's hard disk, edit the saved file, and make the changes in the HTML code. Figure 10-8 shows how the user saves the page.
Figure 10-8. Saving a local copy to the user's hard disk
The user first changes the value of the Price field in the line <INPUT type=hidden name="Price" value="89.99">. His second change is to fix the ACTION= 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 after it was modified to change the price to $0.99.
Figure 10-9. The shirts.html file being modified to change the price
Now if the user opens this modified file, shirts2.html, in the browser and submits a request to buy the shirt, he sees the window shown in Figure 10-10.
Figure 10-10. Results from tampering with the hidden field
Is this a great way of going bargain shopping or what? As incredible as it seems, this indeed was the problem that accounted for Acme Fashions, Inc.'s loss of revenue. After a thorough reconciliation of orders and transactions, the application security assessment team found that numerous "customers" were able to buy items for ridiculously low prices. We say "customers" facetiously because they most likely were hackers.
We alluded to the dangers of passing information in hidden fields in Chapter 7 where we showed how to go about quickly sifting through source code to locate hidden fields. Hacking applications using information passed back and forth via hidden fields is a trivial task. It involves no special skills other than using a browser and perhaps fumbling around with Unix's Visual Editor (vi) or Microsoft Windows' NotePad application. Yet the effect is quite devastating.
Bypassing Client-Side Validation
The next error spotted by the security testing team was the way inputs were validated before being passed to ShopCart.exe. Web applications consist of many scripts and interactive components, which interact primarily with the user via HTML forms on browsers. The interactive part of any component takes input from the HTML form and processes it on the server. HTML forms are generic when it comes to capturing data, 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 can enter a date such as 99/88/77 and the browser won't even care. The application has to have its own input validation mechanisms to filter out such erroneous inputs to ensure that the input complies with predetermined criteria for the application. Input validation for HTML forms can be done either on the server side with Perl, PHP, or ASP, among others, or on the client side, using scripting languages such as JavaScript or VBScript.
Using Search Engines to Look for Hidden FieldsYou can use any of the many Internet search engines to quickly check whether your Web site or application contains hidden fields. For example, Figure 10-11 shows how to use Google to determine whether hidden fields are used to pass price information within www.acme-fashions.com. Figure 10-11. A Google search
Because www.acme-fashions.com is a popular shopping site, Google has cataloged it. Figure 10-12 reveals the results of the search: all pages within the domain acme-fashions.com that contain the strings "type=hidden" and "name=price." Be sure to restrict the search to the chosen site; otherwise you may end up having to sift through thousands of results! Figure 10-12. Results of the Google search
|
Acme's development team recognized the need for such input validation, but because ShopCart.exe was a prepackaged application that couldn't be modified to incorporate input validation. Hence the team decided to move the burden of input validation to client-side scripts running on the browser itself. Someone even remarked, "Yes, this is a good idea since it will save the server's CPU usage. Let the work be performed by the client's browser instead."
The fact that any client-side mechanism could be altered by editing the HTML source code received by the browser was overlooked. The security testing team found several instances of client-side validation being used on www.acme-fashions.com. Figure 10-13 shows client-side input 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 invalid number.
Figure 10-13. Client-side validation, using JavaScript
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 the HTML 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 field qty. But, because the validation is done by a client-side script, it is easy to bypass. Simply disabling the execution of JavaScript by setting the browser preferences allows an attacker to bypass client-side validation! If we choose to disable JavaScript, as shown in Figure 10-14, we can enter whatever value we desire in the input fields.
Figure 10-14. Disabling JavaScript
Figure 10-14 shows the Disabling JavaScript in Netscape Now if a user were to send a quantity of " 3," the browser would issue the following POST request 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: 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 validation. Figure 10-15 shows the server's response.
Figure 10-15. Purchasing a negative number of shirts
The screenshot shows that the user has placed one order for 5 shirts at $54.99 each and another order for 3 shirts at $89.99 each. The total bill comes is $4.98. The ability to place orders for negative numbers to reduce the total amount of the bill would make shoppers quite happy! This flaw is what caused the shipping clerks at Acme to receive orders for negative numbers of items.
Acme Fashions, Inc.'s management concluded that client-side input validation is dangerous and should not be used. Who is to blame? The flaw lies with the way ShopCart.exe was designed in the first place. The onus of validating inputs should be on the ShopCart.exe application. But, because it had no input validation, the Web site development team was forced to resort to client-side validation.
Even today, many third-party commercial shopping cart systems lack proper input validation. Sometimes it is possible to place orders for fractional quantities. At other times it even is possible to insert meta-characters or arbitrarily long buffers and crash the server-side application.
EAN: 2147483647
Pages: 156