Slashdot Mirror
Electronic Pricetag Alteration
s3hel writes "As if things weren't already hard enough, online retailers are experiencing yet another e-rip-off:
electronic price tag alteration.
This is kind of neat, set your own price for that new laptop! " Basically it points out a very simple vulnerability in web applications.
It's nothing surprising at all, people do this sort of stuff to Slashdot
all the time -- fortunately we're not selling anything ;)
As someone who's designed websites (and shopping carts), the only thing I have to say is that it serves the company right..
This isn't anything like "price tag switching" - this is more like "not having price tags at all, and having the cashier ask the customer how much the sign said."
I mean come on, if you're stupid enough to send a price to the customer, and trust that he or she will send it back unmodifed, you deserve exactly what you get.
First rule of client/server computer security: you can't trust the client.
Perhaps next time one of these "30% of all online retailers" will hire someone who actually knows what they're doing, instead of Mr. "I know frontpage!"
Ok, rule number 1 of system security: If you don't control it, don't trust it until after you have verified it.
This vulnerability has been known for a long time and has been corrected in all but the lamest of shopping cart applications. It just makes sense that if you trust the client to report the cost of something to you that you are going to get burned.
The article says the hackers are hitting the "publish" key, but I've looked all over my keyboard and I don't see anything like that!
Okay, I must speak out here.
My day job is at a Credit Card Authorization Gateway -- we handle the debiting of the customers credit card -- so I feel I know a thingor two about how this system functions.
The process happens generally like: the the 'buy' button is pressed by the shopper, the shopping cart passes a few things to the transaction gateway (among them the price), the gateway debits the card in question, and returns a status code to the shopping cart saying either that the transacttion was sucessful, or that is wasn't (AVS fail, Insufficient funds, etc).
The problem here is that people are editing pages so that the wrong value is being passed to the payment gateway -- the gateway doesn't know dick about the product in question, all it knows to debit the amount of money it was asked to debit. So even if it's the wrong amount, all the gateway knows is if the debiting succeeded or failed, and doesn't know how much the item costs.
The thing here is that any payment gateway worth it's salt (Like Authorize.net or iTransact.com) will return, along with a status code about the transaction, a field containing the amount the buyers card was debited for, so they can then compare it to their records and see of the correct price was paid.
So, simply, the problem here is lazy merchants and (sadly) lazy programmers. With only a few lines of code this problem could be COMPLETELY aliviated(sp).
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Generally this sort of design-by-idiocy approach is the result of merchants using those "build your own store" systems. In these cases, a hosting service provides the shopping cart and credit card authorization, and you can build your site just to point into it. Since there's obviously no database shared between you and the shopping cart system, passing prices (in the clear or some munged form) is necessary. Then you take your chances. Hopefully if you're too cheap to build a real site, you're not selling anything too expensive. Hopefully.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
Sorry, but this looks like nothing more than a bit of self-promotion by the so-called "security" firm Sanctum. C'mon, if forty percent of all Internet retailers were vulnerable to this, wouldn't someone have noticed it before? Interesting how the article also includes a description of Sanctum's products that - surprise, surprise! - can apparently prevent this sort of abuse. I know how to prevent it - block PUT method access in your httpd.conf file. BIG DEAL.
(And I'm not going to even start on the way the Sanctum guy basically calls the people who got the cheap fares from United thieves.)