Don't get ripped off!

[westmich]

I was recently amazed to learn that nearly a third of shopping cart software/programs have security holes. The security holes allow for hackers to alter prices.

According to the recent article by Laura Lorek, of Interactive Week, "Here's how it works: After choosing a product and receiving pricing information, a hacker can use a standard browser's "edit page" feature to show the hidden HTML code on the page. The thief then saves the page to his computer, alters the price information and then hits the "publish" key on the browser. In many cases, that page is then accepted by the shopping cart software - and that $999 watch becomes a $3 special."

To read the article in it's entirety, click here.

I can think of a couple approaches for fixing the problem, but that discussion is best left in specific technical forums.

[wdmny]

Anyone who has these holes are complete morons! How could you not realize this hole? If you check out almost all of the CGI scripts publicly available by Matt Wright, all have referer protection that only accepts from certain domains and IPs so that people can't use your stuff and screw with your system. Anyone selling software with these holes shouldn't be selling software.

[Hierophant]

Please don't call people morons. A lot of business people are not technically savvy and need to know about this kind of fraud so that they can ask those that are how to fix it.

[westmich]

Originally posted by Wes DeMoney
Anyone who has these holes are complete morons! How could you not realize this hole? If you check out almost all of the CGI scripts publicly available by Matt Wright, all have referer protection that only accepts from certain domains and IPs so that people can't use your stuff and screw with your system. Anyone selling software with these holes shouldn't be selling software.

I guess I'm an idiot. Although, I've never developed a commercial shopping cart, I have never even thought something this simple.

[wdmny]

ALL scripts don't need that protection, just those dealing with form processing. Otherwise, people screw with your stuff, and in the case of form mailers, use your mailer. Sorry about the moron thing.

[hmahonen]

And the referer checking (HTTP_REFERER) isn't 100% secure, since HTTP_RERERER is transmitted by browser and all it requires is a bit of hacking to make it transmit the url you want to in it.

Or you could always use bugs to do the same thing:
http://browserwatch.internet.com/new...-980302-7.html

I wouldn't rely only on referer checking.

[westmich]

Could you use session variables?

When clicks an item to add it to the shopping cart, the price could also be passed to a session variable. The following forms would rely on the session variable for price and not the precedding forms.

[Hierophant]

I would rely on SSL and not including the price in the form itself.

SSL pages are secure and not cacheable. You don't need them for the entire process just at the end when they submit their order for verification and billing.

In today's world of database driven and dynamically built sites, putting the price in the actual submitted form is bad practice. You can track products by productID or SKUs and retrieve necessary information from the database when it is needed.

To process any order correctly all your form should have is:
CustomerID (you should make an account before you get to the final stages).
Billing Info (credit card information or they can use the one on file).
Product(s) SKU and quantities.
Shipping Option(s).

From that information you can build an invoice, process it and ultimately ship the products..

[westmich]

So, if I am to understand you correctly: you might query the price from the database to show the customer, but ultimatley the price sent to the merchant account for processing would be taken directly from the database.