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 ;)
No they don't deserve it. Just because a vulnerability exists doesn't mean us, the good Slashdot hackers, should take advantage of it. The only people who should utilize this vulnerability are the people who are fixing it and criminals.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
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!
Having a good teacher helps a lot. You probably explained to them the way a web browser communicates with the server. Not everyone in web dev understands that, even though it is the basic foundation, which is why these problems pop up. If you look at some of the web dev forums you'll see people asking why their static/global variables aren't preserved between invocations of their code, not understanding the stateless nature of http connections.
So people often do stupid things like this, not knowing any better. Then they notice (either of their own discovery, advice from a peer, or the hard way) that they can save the web page to their local disk and edit the price and submit the altered form. So they "fix" the problem by implementing a referrer check! Then they try the save-and-edit thing and it doesn't work, and figure they're secure, not understanding the way HTTP actually works.
It's sad, really. I hope you can produce a few more cluefull ones and raise the average out there.
Trusting data passed by hidden form variables is probably just the tip of the iceburg, though... I suspect there are a lot of database-driven sites that insert user-supplied data into SQL query strings without proper validation, allowing remote users to execute arbitrary SQL. It's like the shell metacharacter thing all over again. I've even encountered a page that did the input validation on the client side in javascript (I had js disabled so I discovered the problem entirely by accident).
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.
No offense to our competitors at the company referenced, but ISS issued an advisory on this over a year ago. Read it here:
Form Tampering Vulnerabilities in Several Web-Based Shopping Cart Applications--Tim Farley, ISS
How /. could afford to buy the Slashdot Cruiser!
If you love God, burn a church!
Ewige Blumenkraft!
For traditional shops this should be all that necessary to prevent this. But I do see problems for certain types of auctions.
Then of course, servers can be hacked, but that is a different problem ...
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.
Geek> Okay, the site is progressing nicely. We're almost ready to roll out, all we have to do is pay our contractor for another two hours of work to add in the price verifi...
Suit> What? Another hour?! But we're paying her almost $70 an hour! That's $140 for something we can go live without, right?
Geek> Well, theoretically, but...
Suit> Do it! Wait until the CEO hears that I'm taking proactive steps to save money on our mission-critical project!
I've sat in enough meetings that went like this to have no problem picturing an exchange of this nature.
----
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.)