]
] A Case Study on the Current State of E-Commerce Security
] [http://hackunix.org/~derekm/e-commerce_security-2.0.txt]
] by Derek P. Moore
] April 8, 2002
]
This afternoon I decided to undertake a quick case study on the
current state of security in relation to online shopping cart solutions. I
powered up Google and searched the known digital universe for shopping cart
software, studying the systems I found and their design principles as I went
along.
My search revealed a prime target for my test: a flexible--although
seriously insecure--shopping cart design method, in which each shopper's web
browser would control many elements of the product details when placing
orders. In order that the software could accommodate things such as temporary
changes in product details, many of the variables relating to the products
{c,w}ould be sent to, and controlled by, the user's browser--via data in the
HTML sent from the merchant's web server down to the customer's computer, and
HTTP GET or POST encoded data then sent from the customer back up to the
merchant.
Among these browser-controlled details are: product's name, price,
catalog number, and quantity; order's shipping and tax charges; and customer's
name, address, contact information, and payment method (credit card
information). When shoppers browse products, these details are stored and
manipulated on the shopper's computer. When the customer "checks out" using
this shopping cart, the customer's computer feeds this information to the
server for order processing.
Essentially, the merchant is providing an API (via HTTP GET/POST [URLs
and HTML forms]) by which customers can dynamically, on the client-side,
generate and submit order requests to the merchant's electronic storefront.
Perhaps unintentionally, this offers shoppers the electronic equivalent of
going to a store, picking something up, and saying, "I'd like to purchase this
for this much."
I wondered how exploitable these types of carts were with respect to
the human factor involved in order verification and processing. As is allowed
by this method of interaction with the customer, one can certainly send any
arbitrary data one wishes when submitting order requests--however, at some
point along the line, all orders must be verified and processed by human
beings. This is the point at which the data sent by the customer to the
merchant in the order request must make sense, and be approved and accepted.
I wondered what types of order requests the humans working for these
virtual merchants might approve. If the process of order verification,
approval, and processing was atomized enough (i.e., if the merchant was big
enough, fragmented enough, and departmentalized enough), would a web-based
"offer" to buy their products at my price get through the bureaucracy? How
successful could you be in saying, "I'd like to purchase this widget for 50%
it's suggested retail price"?
I resolved I'd find someone to put to the test. Being a technologist
at heart, I sought out an online computer merchant utilizing such a vulnerable
style of e-commerce solution as has been discussed. One was discovered in
no time at all--a merchant operating out of Canada.
I browsed through their catalog of products, wondering what I might
like to order. I ended up deciding I'd see if I could order a Wacom tablet.
Computer graphics has been a hobby of mine every since I got involved in
computers, and I've always desired to one day possess one of Wacom's fine
pressure-sensitive computer drawing pen tablets. But Wacom's products that
are actually worth owning have always been just slightly out of my price
range. Perhaps not anymore with my new bargaining tool that is poorly
implemented e-commerce solutions.
I opted to purchase a higher-grade Wacom Intuos2 tablet, a fine
product indeed. This product ran for about CAD$725.00, which is a fair market
price. In terms of the importance of my hobby in relationship to my current
financial situation, such a coveted piece of equipment must still be deemed
out of my price range. While CAD$725.00 might be too heavy for my wallet,
CAD$125.00 certainly isn't.
I got a hold of the documentation for the software this particular
merchant was running, and I whipped up a few URLs and HTML forms that would
submit my order request for the purchase of a Wacom Intuos2 9x12 USB tablet at
the price of about CAD$125.00. Submission of the order request went off
without a hitch.
As of this evening, I've received contact from a living representative
of this merchant. My order has been approved and accepted, and it will go out
in the mail tomorrow morning. In their words, "Your special order ... has
been sent to you via Canada Post and your payment processed. Thank you for
your business." *smile*
In the end, I have successfully managed to purchase a USD$475.00 order
of computer equipment for about USD$100.00. Not too shabby. And people have
said that the negotiation and bargaining power of individuals is nil.
With the transaction completed and legal (I don't see how this can
constitute computer fraud, as a human ultimately reviews and approves my order
request, and as I did nothing more than place an order request via the
merchant's open and published order request placement API), I shall enjoy my
new toy.
June 10, 2002, Addendum:
I received the graphics tablet mid-April via U.S. Postal Service. My
order was handled personally by several humans at the Canadian supplier, they
actually had to type my credit card number into a machine by hand and someone
wrote "web order" on the signature line of the credit card machine's receipt.
There were also some hand-written corrections on the invoice I received.
All in all, I've enjoyed playing around with my tablet--it's quite useful--and
I've even managed to put it to some legitimate use. On top of that, I've yet
to hear anything at all from the merchant. However, the invoice states, "All
sales are final." That's fine by me.
And my legal council had this to say: "From first year contracts law
all law students know (or should know) that a catalog does not constitute an
offer but is rather a solicitation for bids, in other words, offers, from
prospective buyers. A buyer, in response to the bid price suggested by the
catalog may in fact offer the merchant that price for the goods advertised in
the catalog; on the other hand, a buyer may make an offer at a lower or higher
price (usually lower). It is up to the merchant to accept the offer, usually
by shipping the goods and depositing the tendered funds in his account, or to
refuse the offer, either by asking for more money or by refusing the tender of
funds or returning the payment instrument to the offeror. In your case, the
correspondence you had the next morning with the representative seems to mark
the point at which the merchant accepted your offer. ... Contracts for the
sale of goods appear to be made when the representative contacts prospective
customers..."
GLOSSARY (in order of appearance)
---------------------------------
Google - a popular Internet search engine, .
HTML - H(yper)t(ext) M(arkup) L(anguage), the language in which web documents
are written.
HTTP - H(yper)t(ext) T(ransfer) P(rotocol), the protocol by which web
documents--and the data associated with them--are transferred between
web browsers (clients) and web servers.
GET - a method of HTTP utilizing URLs.
POST - a method of HTTP utilizing HTML forms.
API - A(pplication) P(rogramming) I(nterface), the interface (or calling
conventions) by which applications access resources--or other
applications--that process data, retrieve data, or perform calculations.
URL - U(niform) R(esource) L(ocator), i.e. a web address, e.g.
.
Wacom Intuos2 9x12 -
CAD - Canadian dollars.
USD - United States dollars.