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 ;)
-Christian
our written thoughts are gifts to our future selves
Granted, people who run retail stores aren't supposed to be computer savvy, that's why they're supposed to hire people like us.
But instead they hire people like Joe Java who doesn't know a form from a transaction processing system.
Any retailer who uses the pricing info in the form instead of the SKU and an offering database is a luser of the highest water.
That's not an indication of a "bug" or a "glitch", it's malfeasant system design perpetrated by button-pushers pretending to be software engineers.
--Blair
"I gotta go see a website about a Lexus."
I'm shocked. You mean there are people writing commercial shopping cart systems without server side pricing checks? *ANYTHING* coming from the browser needs to be re-validated before being processed. This would certainly include pricing information. But all web based form input should be re-validated on the server side regardless of what sort of client side javascript form validation is in place. I've known this for years. Depending upon the application I'm writing and the environment in which it will be used, I sometimes cut corners and trust the client with my information. But for something dealing with real $$$ this sort of programming is inexcusable.
I'm supprised this hasn't been moderated to funny. Of couse I would think the courts would consider this more along the lines of switching the price tag which I have no clue of the legalities involved. Could someone who is a lawyer post so as to give us a clue how the courts look at price tag switching.
This is exactly the reason why we get stupid stats like 1/3 of shopping carts are vulnerable. I designed a shopping cart app that keeps the prices of each item and the quantity and the product number all in hidden fields. This is so we can do really quick calculations on the client side without having to hit up the database every single time we want to recalculate the totals etc. Then when they put the order through, the only thing that is kept is the product number and quantity, which is referenced in the database exactly once to finalize the sale. I got quite a few emails from people saying "You moron, you design insecure apps". I ignore these idiots, and ignore stupid articles like this one which was only created because Sanctum's sales aren't what they expected they'd be. FUD. Get used to it. Most shopping cart apps aren't actually insecure, I've looked at quite a few. They just appear to be to the untrained fool, and those people don't really matter much anyways. As usual, you slashdot morons should grow up and learn a thing or two before you shoot your mouths off. Jordan
Like everyone else is saying:
In Client/Server transactions: Never trust data from or judgements made by the client.
This includes The Client, your client - ther bods paying you to make their e-commerce site. Dont trust their specs, don't trust their existing system's specs, dont trust their decisions, and above all..
Dont trust 'The Check is in the Mail' when sending the final product.
Alex
The principles of secure design aren't new. The basic paper on the subject is Saltzer and Schroeder's paper from 1975.
heh, you forgot credit card number, too :-)
Doh!
Well shame on them for including the price as part of the form, instead of using a variable to reference the item in a database (NOT exposed of course). This is a bit like hand-writing prices on your product in grease pencil, then hiring a hydro-cephalic high-school student as your cashier. Sheesh... If half of the stories of this type are true, it makes one wonder how businesses survive at all...
It could be interesting if the vendor offers the same item to different people at different prices, as Amazon was doing for a while. Or if the vendor has different prices in different ads. Or the vendor advertises "We will meet any advertised price". It's then a reasonable strategy by the buyer to try lower prices to see what the seller will accept.
PUT doesn't put the form "back on the Web server." It submits it. These people are editing the hidden fields, then submitting it for processing. By blocking PUT that can't happen. Of course, blocking PUT is not helpful, in that the other method would be GET, which sticks the form info into the URL. To fix this "problem", one simply has to not rely on the user's browser to say what the prices are. I can't believe anyone would have developed an app like that, but apparently they have.
My bad, dude... sorry!
Sean
I imagine that that "somehow" would the same way it got it in the first place.
Or more realistically: somehow the item you bought happens to have no tag at all. And the cashier asks you "do you remember how much it was?". And instead of replying with the correct price, or "sorry, I dunno", you make up a slightly lower one. Don't laugh, there are supermarkets around here which often have those kinds of missing tag problems, and where the clerk first ask the customer before calling out for a "price check"...
Although this is very stupid on the store's part, I doubt though whether it would be legal to lie to the cashier: clearly, the cashier is not proposing a price negotiation, but rather attempting to save his and the customer's time.
Thats why whenever I get one of those textarea agreements, I delete the entire thing. Then I can honestly say I never agreed to any terms.
This doesn't mean that no one has ever been forced to abide by a contract to which they hadn't agreed, but that is not because it was a legal contract. It was because the written contract was better evidence than one party saying "He tricked me," but that is a practical matter, not the actual ideal of contrqact law. If there were perfect evidence the contract would not be enforcable.
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.
That's all dependant on the appearance (to the customer) of the person claiming to have 'agency'.
:) I should try placing orders from companies in those few states that have passed the UCITA. heheheh
It would (likely) be ruled by a judge that janitors don't ususally legally sell cars from the back of the lot, at night, and that the customer would know that. Thus they knew they weren't forming an agreement with the dealership.
But if the guy was dressed in a suit, had valid looking contracts, and gave you working keys, during business hours, you could safely assume he's an authorized salesman.
This establishes who gets blamed for theft. If the janitor sells you a car, you get nailed for buying stolen goods (and him for fraud, or theft, or such). If you buy from a fake salesman, he's guilty of the theft and the ownership of the auto is a little gray. If you buy from a clerk whose boss later says they didn't have authority, you own the car.
In the case of the software, the website (and implied back-end processing) is what accepts all contracts (on a site that doesn't just email the order to a person) and if it accepts a smaller payment and sends out a product, you can't argue that it didn't have permission. If an employee can sell a product, they can bargain for its sale. If they broke their contract with you by selling it for less than they were told, that's between you and them, the customer is blameless.
But, because this involves you telling the software what something cost, instead of a situation where you'd expect the ability to bargain, I'd say that it would be a crime of some sort.
Hey! Here's an idea... The UCITA is looking to make click-through licenses just as binding as a real paper contract, which you do have the right to modify and resubmit. If you live where the UCITA is in force, that computer program *IS* fully authorized to accept contracts in the name of its creator.
For the user to be able to do an "edit page" is one thing, that really can't be helped. But the "publish" function means that the server admin left an FTP port wide open. Who in there right mind allows unauthenticated ftp on a server that handles anything on the Internet, much less "aiee-commerce"?
And I don't deserve my brand new Ferrari to be stolen from a parkinglot after leaving it in Downtown Los Angeles for a couple of weeks unlocked and with the keys in the ignition?
"Deserve" from what perspective? Moral "everyone should be kind and peaceful towards their neighbors", no. Practical "take responsibility for the real consequences of your actions", yes. (But then, this is the point you were making, no?)
...people can't possibly get any dumber, they include the price of their products in a place it doesn't need to be, where it can be easily modified by users, and then they trust that price in their applications. And then they say that they've been 'hacked'.
Unless the rest of that sentence is "in the back of the head with a pickaxe, and that is why I can't grok the concept of looking the price up in my RDBMS instead of letting the user submit it," I beg to disagree.
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!"
I wonder what the real motivation was for Egghead's using the price checking system. Did they have prices changed in this way, or was it to prevent incompetant marking of prices?
A few years ago I had a friend who bought 5 digital cameras off Egghead for some amount between $4 and $5 each. It was just a price mismarking... he didn't hack thier website or anything. He was just looking for a camera and found a REALLY good deal! Of course he let his bank know about the purchase in case Egghead tried to come after him to get him to cough up $400-$500 for each camera instead... but they never did, and he kept (well, OK, he sold 4 of) the cameras. Was this an isolated incident? Perhaps Egghead was worried that they would slip up again?
There was recently a story about kids in Massachusetts sending fraudulently ordered goods to a house not used during the winter.
(As they say, don't do this at home kiddies.)
They got caught, not because of any online monitoring, or business complaint, but because of a suspicious neighbor who turned them in.
"It is a greater offense to steal men's labor, than their clothes"
This seems to be yet another instance of separating the wheat from the chaff (I dunno what the hell chaff is, but my grandma always talked about it, and I don't think she meant shredded aluminum) when it comes to e-commerce. The people who read the security bulletin and fixed the goddamn problem are FINE. These morons who plug the box into the CoLo facility and leave it at that deserve what they goddamn get. This is just a case of morons getting screwed. Chalk it up to a learning experience that only cost you a couple grand instead of your entire company, apply the patches and move the fsck on.
Sorry. I'm tired today and drank about 10 cups of coffee. And I'm all worked up about the DCMA for some reason. *sigh* Why do I hate?
Brant
Brant
Argle. Bargle.
why is this all of a sudden in the news? i (as im sure many of you) have done this for years
hehe, one time i tried it at gateway, got this loc'd out system for like $500, but the human in the process caught it
you know, i dont consider this stealing. i call it natural selection. WHY would you embed the price in the page? you know, i think you can afford mysql. i heard its cheap.
NEWS: cloning, genome, privacy, surveillance, and more!
NEWS: cloning, genome, privacy, surveillance, and more!
try everything2
If you need to change prices, either use product code versions or make a new product (wiget-20010307). If you require such functionality (frequenet price changes) in the first place, you need a more robust and sophisticated shopping cart anyways. It would include product versioning, and maybe even would alert a shopper a product in their cart is out of date, here is the new price, do you want to replace it or remove it. Really, if you're thinking so far ahead that price changes occur to you as a potential issue, you have it way more together than I do, and you're more than capable of building a shopping cart system that doesn't take the prices from a client form... but then again, that's _really_ allowing for price changes, eh? ;)
"Hot lesbian witches! It's fucking genius!"
When I read the article I thought the same thing. I don't write shopping carts for a living, but it seems to me like that would be the sort of thing that you would want to get out of your own database, and not pass around some other way. After all, it's fairly likely that you are going to know how much the items you are selling cost.
What amazes me is that someone almost certainly paid money for that shopping cart. And commercial software vendors wonder why Free Software is doing so well nowadays.
Price verification?!?! What price verification?
A shopping cart should never ever be verifying any prices. It _knows_ the prices, because they're stored in a database (SQL, dbm, flat file, common include file, whatever) and hence doesn't have to verify them. I could never understand how one could possibly design a shopping cart system that accepts product prices from a form... wouldn't this be much more work actually? You're displaying the price, plus you have to code in the hidden price tag, plus write code to process the price in the form handler... But you know what's in the cart, and you know its price (since you displayed it just a second ago), why on earth would you take the price again from a form! Why! Someone please tell me! Anyone thinking this is a good idea for _any_ reason simply has no business programming.
"Hot lesbian witches! It's fucking genius!"
Stop Yourself. You're right, a *good* shopping cart would do that -- but there are two small problems.
One) Few shopping carts, in my experience, meet the criteria of "good".
Two) Many Payment gateways offer a way to have secure transactions without the shop having to maintain a secure server of their own. Goes like this:
The buyer presses submit on a form that contains all their info (name, address, shopping cart contents, etc), except for their credit card number. This for posts, in fact, to the CCPG's secure server, where the card number is then entered and then the buyers posts that and is sent back to the merchant's cart.
I'm sure you can see that, using this scenario, you can't rely on the server to do the computation you describe. It's not the best way, granted, but it's a lot easier on the merchant. I'm sure you can see why that would be a problem, and why you should check the amount actually debited.
And yes, I realise that the article didn't specifically adress this scenario, but I feel that it should still be of intrest.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
You can modify agreements before returning them.
When you are offered a contract, you can cross out sections and write in your own before you sign it (you should initial and date your modifications, in case of multiple rounds of this). However, signing it doesn't form a contract, it forms a counteroffer. It doesn't become a contract unless the other guy signs it after you've returned it, modified and signed, or performs some other overt act indicating acceptance (such as saying nothing and fulfilling his side of the bargain).
This, to me, seems no different legally than handing $5 to the cashier when the register says $27; if the cashier takes it, puts the goods in a bag and hands them to you, they've agreed to your counteroffer and have no further claim against you. Furthermore, regardless of internal policy, the management and owner of the business have to live with it because the cashier acted within their role as an agent empowered to make sales (though they might fire his ass after the fact, or sue him to make up the difference); you've made your deal with the company as much as if its president agreed to the $5 price. Whoever's running the order and delivery system acts as an agent in a similar fashion, if they, through their software, accept such a deal, it's the company's tough luck for hiring an incompetent who negligently agrees to any counteroffer.
IANAL, IANYL, TINLA
---
Could you set the price to a negative number, amass lots of credit and use the money to finance a foolproof way of stopping spam that tells you how to make money?
Nope, that's POST. The PUT method is indeed used for Web publishing, and normally alters the page.
The method about which you are thinking is POST.
While I agree with the sentiment, I feel it important to point out that this vulnerability isn't just limited to NT based commerce sites. The strongest safe door won't do squat if you leave the damn thing open.
I am very small, utmostly microscopic.
There are laws that say that switching the price tags on merchandise to get a lower price is theft
The equivalent of wwitching the price tags would be cracking *their* server to change the price database. This is like shopping for a $1000 item and, when at the cash saying: "That was $500, right?". It the dealer accepts, you have bargained, not stolen.
Opus: the Swiss army knife of audio codec
Suppose you were going to do some work for me at the rate of $200 an hour. We drew up a contract, you read it and agreed to it. Just before you were going to sign it I switched it by sleight of hand so that you were actually signing a contract that said you'd get $7 an hour. Do you think you're now obligated to work for $7?
You may be required by law to sell a product at the advertised price, I don't know. But the point here is that the consumer put the "wrong" price on the product. If the merchant actually advertises a $3 laptop, that's one thing. But if the merchant advertises it as $1999 and the consumer tricks them into charging $3, then it's bait and switch on the part of the consumer.
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.
What did PT Barnum say about that sort of thing?....
Disclaimer: I work for uBid.com (shameless plug), a B2C auction site. I'm curious what auction types you think need client side validation.
I would like the plagurism of AlphaKinetic and Saalim Chowdhury exposed. My work, and the work of others, is the subject of a recent SlashDot article called "Electronic Pricetag Alteration", although we are not attributed. I published an article which was plagurized by Saalim Chowdhury and used as the subject of a press release. An article was subsequently published by TheTelegraph and mentioned by TheRegister. This article was cited by ZDNet, syndicated to Yahoo, then this article was cited by SlashDot.
I published an article called "Flaws In ECommerce Systems" in the Autumn issue of 2600 Magazine. This article is available at http://www.xirium.com/product/mtecs/doc/secure/ and http://www.basketlogic.com/doc/secure/ . This article:
On 25 Jan 2001, TheRegister reported an article in TheTelegraph which:
AlphaKinetic press releases 4 and 5:
All attempts to contact all parties have been ignored. This inaccuracy has now been extensively propagated during the last two days. The additional information that was unsubstantiated is now the subject of recent articles and the estimated proportion of vunerable sites has risen from 10%-20% to 40%.
There is circumstantial evidence that Saalim Chowdhury read my work in 2600 Magazine (the source of the information) and this can be verified by checking domain name registrations. 2600 has a pre-occupation with purchasing domains of the form *sucks.com then printing the "cease and desist" "nastygrams" from lawyers. AlphaKinetic (the source of the plagurism) is highly anomalous because they have registered alphakineticsucks.com themselves, although this problem only affects large companies.
This is essentially what Authorize.Net offers to their merchants. The response from the transaction contains an MD5 hash of the merchant's Login ID, the transaction ID, the amount of the transaction, and a shared secret (that only Authorize.Net and the merchant know).
This accomplishes a couple of things. First of all, it shows that the transaction really did go through the gateway, because of the shared secret, and second of all, it shows that the amount wasn't somehow changed AFTER authorization. This proves to the merchant that the amount that AuthNet says was charged is really the amount that's charged. Of course, it's up to the merchant to then check that amount and make sure it's the amount that was supposed to be charged for that transaction.
Since it's just MD5 with a shared secret, it's a lot easier for most developers to grok then figuring out certificates and stuff, while still achieving essentially the same thing.
-Aaron
Changing the price of an item sold on the web is very similar to going into a store and putting your own price sticker on an item, or putting a UPC sticker of a cheaper item on. Seems to me that some kind of law must cover it.
In Authorize.Net's defense, those pages aren't purporting to be complete examples of secure transaction processing. Those are just examples of the very basic ways that transactions can be sent to the gateway via form POST. That page doesn't discuss that type of security because that's not the place for it. Security is a complex idea that requires thinking through your entire order process. Those pages are just highlighting one small portion of the process.
Speaking only about Authorize.Net, the system isn't "insecure by design"; it's flexible by design, and that flexibility can be used to make the system as secure or insecure as is desired. Like all very powerful tools, if it's used by someone who has not the capability or desire to learn how to use the tool, disastrous results will occur.
Read the documentation online if you want to see all of the ways that transaction security is addressed (including such seemingly obvious statements as 'If you're going to let the client change the price, at least check things over before shipping product').
-Aaron
If someone goes into a store and paste a phony price tag on some merchandise, it is called fraud. I don't see how this is different, or how existing laws would protect someone doing a price-switch over the net.
Okay... Item one is $100, item 2 is $100, you put both in your cart and checkout. The server then confirms the price for item 1 is $100 and item 2 is $100 and you are charged $200 total. At no time does the server care what you (the client) says the price is. You return item #1 for a $100 refund.
Modify the local page all you want, all it tells the server is that they want item #1 and item #2, not how much item #1 and #2 costs.
Duh.
Remember a coworker did this at Blockbuster.
1. Buy Mortal Kombat 3 kart
2. Put your old Mortal Kombat 1 cart in MK3 box, reshrink box at work on lnuch break
3. Return for full refund
4. Imagine next customer's anger/confusion when he/she buys MK3 and gets your old MK1 cart
There's several variants to this trick, including putting broken version of same merchandise you have lyging around into box and returning for full refund to Best Buy. RedboxChiliPepper returned a modem, only instead of a modem in the box, it was crushed Pepsi cans.
Good to see e-commerce hasn't ruined the fun.
AFAIK it is theft. There are laws that say that switching the price tags on merchandise to get a lower price is theft. So even though the guy at the cash register tells you that the price is such and such, you're still guilty of theft if the price comes up that way because you manipulated their pricing system. Editing web based pricing information is basically the same thing, and I bet that any DA worth his salt could convince a judge to agree.
There's no point in questioning authority if you aren't going to listen to the answers.
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!
I suppose you could look at it the same way as an improperly-tagged product at a store (either you/someone else swapped the price tags, or the store screwed up). General idea seems to be that if the cashier doesn't notice, then it's the store's own fault. Of course, there's still the immoral aspect of it.
I'd consider this webpage abuse worse, though...at a brick and mortar store there's at least some real employee of the company who is going to see the product and the price before payment is accepted. Even the dumbest of Best Buy employees would probably notice a laptop ringing up for $3.
"That's Tron. He fights for the Users."
Sure, that was a slip-up on Egghead's part, but imagine it happening to them because of customers hacking the prices. No wonder Egghead.com has now made it to this list.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Yes, because you have modified the agreement the vendor showed to you.
I would say that I have modified the proposal that the vendor showed me. Then I submitted my altered proposal, and they accepted it, and only then did it become an agreement. Kind of like haggling with a really stupid person.
As you say, UPCs correspond to specific products, and the register looks up the price.
However, the analogy in the parent posting seems sound. You can go to a grocery store and switch the wrapper on a pound of CrapCo Farms chicken with a pound of Organic Hippie Chicken that costs three times as much, and the person at the register has no reasonable way of telling the difference. Is that legal? Of course not, it's theft, and infantile to think otherwise.
Likewise, the web site operator is engaging in the transaction on the good faith that you have accepted the terms as presented. Just because it's possible to present them other terms when they're not looking doesn't mean they have accepted them. It's not like playing tag, or serving someone with divorce papers.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Yeah. This would be serious if it weren't so funny.
I'm not a geek, I'm just a clever script.
This is the most informative thing I've read on this thread all day. I think you're exactly right. I was really struggling to imagine how else someone would even have come up with the idea to post prices back and forth between the client and server.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Oh yeah, I hadn't thought about that. You're probably right. Well, maybe more people will have their own SSL servers now that the RSA patent is over.
I'm still surprised that anyone would actually ship stuff that was ordered this way. I can picture someone now -- "hmmm.... I know we usually charge $800 for these, but this order just says $25. Well, I guess the computer knows better.... let's ship it!"
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
Right on... I mean I know one of the great virtues of a programmer is laziness, but this is just out of control. Would it not take less effort to work with a database instead of having the price verified?
...it's not illegal for the reason of changing the agreement.
It might be (and probably is) illegal for deliberately tricking the seller. ("Look, you advertised it at this price, you have to sell it to me for that.")
---
Not all stores do this. in fact not too long ago none of them did. The clerk relied on the sticker price. If you went in with your own stickers and changed the prices so that you could cheaply buy the stuff you can bet you'd be going to jail if you got caught.
You have, quite succinctly, justified the Microsoft business model. Bravo!
This isn't a vulnerability in anything... This is not even programmer error, just programmer complete idiocy. It's just common sense not to send pricing information in your POST data. That's just ignorant, you might as well put a field in there to change the price. It's the equivalent...
this e-scam is just the electronic version of switching price tags in a store--take the tag off the $2.00 item and stick it on the $40.00 item. That particular trick is illegal and is prosecuted. If not now, surely soon, e-switching of price tags will be e-llegal. this reality has been changed from its original form: it has been modified to fit your mind
Trying to retrofit security on to an existing application *never* works (for applications > trivial.) People who develop applications involving the transfer of money without thinking security, security, security from the very beginning should be working for Microsoft...
I believe that's what it was. I believe he brought them his "web receipt" showing how much the website said the total was, and told them that Egghead might try to demand additional charges to his credit card. Nothing ever happened like that... Egghead did contact him to ask him to return the items after he already had them in his possession. But they never tried to charge him extra.
From what was described in the article, it is an outright lack of common sense on the part of whoever wrote the application!
Even before learning what I know about web security, it was obvious to me that you don't put sensitive/important data in a hidden field of all places.
By the way, if I see a locked door on the side of the road, I don't have a penchant to go in and steal stuff, either.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
And I don't deserve my brand new Ferrari to be stolen from a parkinglot after leaving it in Downtown Los Angeles for a couple of weeks unlocked and with the keys in the ignition?
"Many Web sites are vulnerable to hackers because the task of auditing their applications and detecting hacking is time-consuming..."
/. has linked to it. Now every script kiddie on earth knows how to rip-off online vendors. Watch the patches fly out.
Not now that
Do you write code for web sites? It is REALLY not that hard to implement and is REALLY foolish not to. I wouldn't dream of writing this kind of code for someone else. What you say is correct, people shouldn't do this kind of stuff, but the fact is they will and it's somebody's job (in some cases mine) to make sure it doesn't happen.
Additionally, HTML does not keep state - meaning all data values in the cart must be passed somehow - usually either a cookie, a hidden form element, or in the query string(everything you see after the ?).
Compounding all this is that many dot-com sites were rushed to market. Speed was the ultimate requirement dot-com developers had, not security, not soundness of algorithms used. Yes its stupid, but add all this up and you have a lot of insecure websites. (Mine however only allows price input to the cart from values in the database itself and is additionally protected by an OpenBSD firewall :) )
No, Thursday's out. How about never - is never good for you?
An estimated one-third of all shopping cart applications at Internet retailing sites have software holes that make them vulnerable to the price switching scam said Peggy Weigle, chief executive of Sanctum, a security software company in Santa Clara, Calif.
Of course Peggy will sell you software to prevent this from happening.
This stat is also misleading. 1/3 of the number of sites might be vulnerable, but I doubt that 1/3 of all online purchases are vulnerable to this type of tampering. Joe Schmoe's T-Shirts may be vulnerable, but I doubt you can do this on Amazon.
BrianYour Source for Tech Humor
...when we had to switch the price tags by hand.
Oh my GNU. I can't beleive that there are morons that stores the prices client-side.
I am surprised that
1/ A lot of sites have goatsecx'ed shopping carts
2/ This have not been abused to death (ie: if you can get 25$ on a notebook, then you should buy a hundred of them).
I would first suspect employees of those dotcoms that hacked the databases for them or their friends. Like boo.com (Thanks to hole in the applications, employees were able to buy products in pounds, and pay in pesetas). Then I would suspect plain bugs (I once had the WebObject store.apple.com proposing me real nice prices, with a lot of 0$ options on high-end macs. I didn't bought them, but maybe I should have ?).
Btw, what are "pricing snafus resulting in a smorgasbord of bargains" ? Is this pig english thing already used at zdnet ?
Cheers,
--fred
1 reply beneath your current threshold.
This has nothing to do with the "web applications" in general, but only a stupid piece of software which counts on data at the client.
Any properly set up application uses the price information only to inform the customer; it does not re-ask the client to send the price information back. The only data the browser sends should be the session id; or the shopping basket id. All the inventory, cost, tax etc. is then calculated at the server side.
Donate free food to the hungry at The Hunger site.
As a Security Analyst, I did some Code review on ECommerce software. What happens is that usually the program consists of two 'main parts' : the products and the payment. On the product part, it contains the price, specs, etc. The vulnerability (?) consists how the first part 'communicates' with the second one. There is a lot of apps that use HIDDEN html tags, what is VERY wrong, and where a kid can change the price. If the 'payment part' has a price checking mechanism, this kind of fraud would be more difficult to reproduce. Its like a sales man giving a paper with the price to the buyer to pay at the cashier man. So, learn: In God we trust, the others we monitor.
gcc -o sig sig.c sig.c:4: #error NO SIG FOUND make: *** [sig] error 1
And that is why you never tell a manager that something is ready to go live untill you have more than enough security in place. It's a much easier sell to take security out in exchange for easier customer interface than to put it in after the site is live.
THIS SPACE FOR RENT
Three years ago I watched the CTO of a well-known e-commerce vendor describe this particular vulnerability: prices in hidden fields.
His company's shopping cart product didn't have this vulnerability. It was a big selling point for them. Really big. The salespeople would trot it out to create an Oh-shit-we-gotta-pay-these-pros-big-bucks moment in a prospect's mind. It worked. Well enough to close 6-figure sales.
You don't understand. The merchant has not choice in the matter. The way the credit card authorization works is exactly how the previous poster describes and there is NO way around it other than finding a company that actually has proper authorization. In places like the UK, this is impossible, in the US it's unlikely (if not impossible).
Burn Hollywood Burn
I can understand if organized religion leaves a bad taste in you mouth brother.
.sig is lumping you in with this somewhat.
Perhaps you could just abstain like the rest of us intelligent folk rather than burn the church. It goes along with the fact that you just can't kill dumb people.......you just ahve to smile at them and know that they'll take care of it.
Please note that perhaps you don't understand what you're really saying. There has been a rash of church burnings in the deep south, to my recollection most of them were the churches of blacks. Your
"Share your knowledge. It's a way to achieve immortality." -- Dalai Lama
Fraud is still fraud, even when the victim is stupid.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I don't think that's the explanation. Getting the prices from client-supplied data is a design flaw that must have been built in from the beginning. It has nothing to do with whether you've added error checking at the last minute, though omitting error checks can certainly cause plenty of problems too.
Once this is done, you are left with a bunch of small, dense, edible bits (the wheat), and a bunch of lighter, bigger, inedible bits (the chaff). The wheat is good, the chaff is useless.
The standard way of separating the wheat from the chaff was to throw both up into a breeze. The wheat would fall straight back down, the chaff would blow away.
"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)..."
Stop right there. I hope you can see why one would not want to design a system with this functionality. Perhaps it would be better to simply accept the user info, item number, and quanity instead - letting any price calculation be done on the server side - and submit THAT to the gateway.
Post de facto verification should be used as a last line of defense only.
I am very small, utmostly microscopic.
NO, No you don't. Nobody deserves to be robbed. People don't deserve to be killed in there homes just because a window is left open either.
Point in fact, we should all strive to make the world a place where we can leave are cars unlocked, our windows open at night, and are sites unprotected.
Will the world ever be that way? probably not, but if we strive for it, then maybe we can make are part of the world a little better.
If your question was "Is it wise to leave my Ferrari unlocked in an unsafe neighborhood?" Then No, no its not. Unfortunatly.
The Kruger Dunning explains most post on
Tough luck. Yeah, this is actually illegal but then again the companies actually selling this stuff on the web shouldn't go around bitching -- leaving your front door wide open and thinking "There's no one coming into my house because its illegal to steal stuff" is incredibly stupid.
Since when does a shopping cart program does have to be authoritative on prices? A shopping cart should send to the back-end just the item numbers, and any promotional code.
Next step, the back-end takes this information, and computes the actual order: to be sure to cover all legal bases, this order is given a serial number, the shopping cart shows the user a final recap with all the charges as determined by the back-end with a big I agree button at the bottom.
If the user agrees, the shopping cart then sends to the back-end just the serial number of the current order, which then gets processed.
Am I missing something ?
-- the cake is a lie
I don't think so. From the description, it sounds like the applications are trusting the prices submitted in forms, rather than always getting the prices from a database. People can send information to form-handling programs without using the forms the programmers intended. The easiest way is to save the form locally and alter it. It's not necessary to put the form back on the Web server.
Well they could have done a favor and posted some of the software in question, this way people who are using this software can make a switch.
This is why forums such as Security Focus exist. They shed light on security based products. Programmers however, should be held accountable for creating a boon of shoddily written programs without doing extensive research into security.
Publish!! Sounds to me like she means Microsoft Front Page. Again these concerns should be assessed by first: The programmers creating a slew of poorly written programs, second the administrators responsible for making sure their servers, and software is secure and all the permissions are set on files.
Studying a problem should be one of the steps but removing it should be the first.
Oh well we all get the point.
CIA vs. Jews
360 degrees of Karma
Now I've got your pesky pricing in my control...
No one. No one at all should use software that is as ridiculously written as the stuff in this article is. No one. The programmers have less brain wave activity than my grandmother. And she's been dead since 1987.
Of course they are GENIUSES compared to the idiot media who apparently think this is a common way of writing e-commerce apps!
Once again, the media takes something which had been a problem/concern - albeit slight - and creates a fiasco over it!!
and if I ever catch any of you using Sanctum, or even thinking of it I'll personally he-bitch man-slap you!
"If voting could really change things, it would be illegal. " - Revolution Books, NY
Nothing wrong with that. Let's say I had a desire to buy $1000 worth of nice Italian suits. I go try them on and ask that the store fax me an invoice. I take the invoice and change the prices so that these suits cost me $10. Now who's fault is it if the company honors these new prices?
Just like this company has the right to refuse the deal after I altered it, these websites have the right to refuse the altered prices. As others have pointed out, using some sort of "web shield" (web bandaid is more like it) is a joke. The only way to make sure is to only accept prices that come from your own database, and for Pete's sake, don't put that database machine on the public internet.
JET Program: see Japan, meet intere
In the real world, there are a small number of applications in large scale use, and the custom applications of the major retailers are... well, if 30 percent of them allow user-entered data, I've gotten unlucky...
This is a self-serving scare story.
I guess I really didn't mean they deserve it in the regard that we should all go out and rip them off, I meant that they shouldn't be crying about it if it has happened. If they are on the internet selling stuff then at least the minimum of precautions should be taken against getting ripped off. I am only saying that this is a known vulnerability and should be well-known to anyone using and especially writing shopping cart software. This type of vulnerability should not have happened in the first place.
Yup, nothing is gonna lower e-commerce fraud like telling everyone how to do it, and how easy it is.
/. ripple caused by this...
Hate to see the
and as someone mentioned below, why in God's name would an ecommerce server allow a user to publish a page to it? Unless of course the article writer has his wires crossed. It would make more sense to me that the page isnt uploaded to the server, its utilized from the hackers saved copy and only the shopping data is sent back. (shrug)
anyway.
As quoted from the linked article:
'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.'
RA7
-
"Consistency is the hobgoblin of small minds" - RWE
Others have rightly mentioned the flaw in trusting the client side to accurately report your own critical data back to you. This is the technical flaw, but not the root cause. This situation is a prime example of the business risk of employing an underqualified software development staff. (N.B. this could be direct employment, or "employment" via your purchasing department). A lead developer (or preferable, software architect) who analyzed and understood the problem domain (an online shop) separately from the machine (i.e. program) that implements the soltion, would not have exposed this obvious security risk.
Most people don't understand that HTTP is stateless and there are security considerations bundled with that.
I can't believe that the on-line sellers weren't aware of this! This was clearly mentioned in the book "Hacking Exposed". A blind monkey having a bad hair day could pull this off!
thank you. I know that. My shopping cart does this exactly, if you'll read the whole of my comment, you'll see that. I was just trying to explain why this is common.
No, Thursday's out. How about never - is never good for you?
Okay,
I can understand the use of allowing the user to update the data (for LOTS of reasons).
Fine HTML doesn't keep state (I won't argue about how to do this).
Why trust the prices that have been in the user's care? Why not simply discard all the description/pricing information, and just use catalog numbers and quantity from the shopping cart, and pull the rest from your own internal database, for the final bill (preperatory to paying?) Then, keep that information in a record number, and just pass the record number to the next step? Don't let the user play with the data once they come to the final checkout screen.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Go ahead, click it
Trolls throughout history:
Jonathan Swift
>I'm looking for a good Gyro place in the South >Bay area. If you know of one, please let me know. Falafel DriveIn (Bascom & 280) is decent, limited selection Yiasso (Chain) - OK food, more than one Angelos (Race & Alameda) Good to better Castle Greek Restaurant (N 1st near 237) - crowded at lunch everyday for a reason Falafel Hut (Ocean St(?), Santa Cruz) - high marks with everyone who's tried it
Actually, I wouldn't be too surprised if Compaq starts making keyboards with 'publish' keys to go along with the 'internet' and 'e-mail' and whatever other keys they're inventing.
When I was in school I took a couple law classes. That does not make me a lawyer. IANAL. Definitely am not a lawyer.
But what they always told us in the classes was that a price tag wasn't set in stone, it was merely an invitation to a potential buyer to make an offer. Sales prices are negotiated all the time, and not just on big-ticket items like houses and vehicles.
In that light, it seems to me that you could make a case for "Your honor, I wasn't hacking the system. I was merely making a counter-offer which his system accepted."
Still, it's pretty dodgy practice.
Without research, and just thinking off the top of my head, there is a legal concept in the contract world called: The Meeting of the Minds.
Both parties - the offeror, and the offeree, must be thinking along the same lines with regards to an offer, and a subsequent acceptance of that offer.
This is particularly true of the material (that is, essential) terms of the offer/acceptance. It would seem to me that if there is a discrepancy in price, whereby you are thinking you are offering $.01 for something and the other side is thinking it's selling it for $1000, then there's no meeting of the minds.
However, if this offer (that is, the offer to buy for $.01) is made in writing (and perhaps an html is arguably a writing), then you might be able to argue that the other side had an opportunity to read the terms since it's right under his nose. Therefore, the other side knew, or should have known, what it was getting into since it was in plain view and plain language and the contract should be enforced.
AC, that's just off the top of my head. I'll think about it more, and ask around. Let me tell you though, I hate to say this, but I have to disclaim anything I've said or written in this email as legal advice. You should NOT rely on this information.
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).
We do something similar - person fills out form, tell them how much they owe, click a button to pay.
However, we send an identifier to the CC verifaction company. They connect back to our machine with that info, pull out the price info and show that on the screen with the CC collection info. It connects back again once that is submitted to get the price again.
Even if the end user changed the info, it won't affect a thing.
It sounds to me like the stores are complaining because people aren't honest - like putting out your merchandise on the street with a box that says "Please put correct payment in here"
Duh.
A lot of e-commerce solutions work that way--the payment gateway is a CGI interface that requires a dollar amount as one of the parameters, and thus the reason for getting the price from the client. That is why the result page should look calculate the outstanding balance and not complete the purchase unless or until it is zero. FYI there is a solution that doesn't require submitting the price over CGI though...
I worked on an e-commerce site that used a Perl module as the interface to the payment gateway. The customer inputs didn't include price at all. A mod_perl handler (you could use a normal CGI script as well) recovered the price from a database based on SKUs and quantities and submitted it through the transaction object (then sent to the bank encrypted). That way, the payment interface is not directly linked to the customer via CGI. It isn't really much more work.
One thing that wasn't touched on in the feature article was encryption and security. I was a bit dismayed that some "canned" shopping cart solutions advertised that they were "secure" when they were not. The web page and CGI data was of course served up in https, but often credit card data was stored in CLEAR TEXT somewhere on the server, or sent IN THE CLEAR to the payment gateway. One "solution" I saw (geared towards smaller operations) involved collecting credit card info on a secure page, then E-MAILING IT IN THE CLEAR to the merchant to be keyed into their POS terminal manually! WTF is that?
Well, at least I'm comforted in the fact that the tech-stock-tanking will take out some of these losers--the past dot-com-mania fostered a "don't worry, be crappy" attitude. In this climate dot-coms now have to prove their viability and competence.
Yes, they do. They can do something like this: Customer -> Merchant -> CCAG. Yes, it's more work, but since the "Merchant" is always sitting between the CCAG and the Customer, they can verify the prices and such before the authorisation is sent to the CCAG. Basically, the merchant system abstracts the backend, whether it be the RDBMS or the CCAG.
It's just a matter of inexperienced/untalented developers taking on more responsibility than they can handle, and inexperienced/untalented management not seeing that this is the case.
--
That what I thought when I first read the article, but apparently it is fairly common for some mom and pop e-commerce sites to simple have a form that posts to someone else's SSL site.
You have probably seen sites like this. When the time comes to actually pay for the stuff the URLs are all at some other site. The information has got to get to the SSL site somehow, and apparently someone thought that "hidden" fields in a form would be a good idea, Yow!
The worst part is that someone almost certainly paid money for that!
I agree. I am the lead developer at my company where we too have our own application which includes the famous cart
All I can say is, DUH! The only thing our form lets you change is the quantity of product, and of course the handy delete button. The items in the cart are referenced by their rowid, because they are stored in our database, with their prices fixed. Adding items to the cart is done by part number only, and all other info is taken from the catalog database at that point. Of course we take precautions to validate that the rows you're modifying also belong to YOUR cart, and not someone else's.
Anybody who puts the prices in as part of any form does not deserve to be programming secure applications. This is a mistake which is in my view unforgivable and I would immediately discipline my staff if I ever caught something as stupid as this in our code.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Every time I deal with executive management, the same thought runs through my mind...
I can see the fnords!
What I am saying and others alluded to this is that if one expects others to behave in a certain way (be dishonest, etc), yet they do nothing to curtail such behavior or even promote it, then one gets what they deserve.
I do not trust people I do not know, so I don't trust them. Comon didn't everyone's parents tell them not to talke/accept things from strangers? That phrase is there for a reason...
Btw, I'm also trapped in a Microsoft job, please help me get out!
"You create your own web site with a form in it and have your customers submit that form directly to our SSL server! We handle everything"
This paradigm is intended to decouple payment processing from the rest of the website. There really isn't any incentive to "muck with the details".
Except, of course if you want to avoid this bug...
That depends on how the prices are labeled. If they use UPC symbols you may be right; it's their responsability to have the right data in their computer when they look up the price. But swapping the stick on price lables that used to be so common and are still used in some places is a different matter. Swapping those is as easy as pie, and it's unreasonable to expect the company to be able to tell when they've been swapped. Switching price tags is theft by deceit, and so is changing the price that their web page sends to you. The whole thing about this being "negotiating" is a crock of shit; negotiation requires a meeting of minds, and you can't have a meeting of the minds with a computer.
There's no point in questioning authority if you aren't going to listen to the answers.
I too would suspect friends of employees. Not that they are bad people or anything, but I've seen more varieties of friend-assisted price-changing scams in the meatspace retail than online variations. Of course, that's because there are only two ways to enable this online; one is backdooring, and the other is to be a clueless idiot loozer programmer.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
It's such utter bullshit that it gives real developers a bad name. I mean of course I'm not going to accept data from the client, unless it's What and How many. It's so utterly obvious.
First, it was stupid business models. Now it's idiotic software. No wonder there was a DotCom implosion. (Not that we didn't see it coming or anything... it's just so frustrating)
-- kwashiorkor --
Leaps in Logic
should not be confused with
-- kwashiorkor --
Leaps in Logic
should not be confused with
Jumping to Conclusions.
True, but you handed the modified agreemnent back to them, and they still honored it. Doesn't that show their agreement?
In a similar vein, I've sometimes wondered about all those sites that use <textbox> tags to frame their user agreements. The data in the text box is usually modifiable by the client, so if I go into the box and alter the agreement before I hit the submit button, why shouldn't my modification be enforceable? If they don't like it, they should reject my change, no?
tetrad
Allow client systems to pass client-domain data but never entrust server-domain data to the client.
The problem is state control. HTTP is stateless, so the short-cut is to store the server-issued data on the client (either in hidden input fields, the URL, or something similar). Usually those who fall for this error don't realize that you can connect to a httpd port with telnet...
Work around this by, one example, using a server-supplied transaction id to provide context for the server. This id can be stored on the client and used to re-establish application context. The threat of someone iterating through ids is low -- and can be thwarted (timeout, IP matching, client authentication, etc).
If you are allowing clients to maintain data integrity, you have none.
-- @rjamestaylor on Ello
Yep, that's generally how it works, but there's no need to send the PRICE of the things in the shopping cart as user-submitted data. Instead, you send things like product ID and quantity, and the software looks up the price from the database, which (on any sane system) is out-of-reach from Joe User.
If an online merchant is going to do something as stupid as this, they might as well save the shopping cart development costs and just put up a page with a blank check for the user to fill out, print, and cash.
Sean
If you cause a change in the price that the server sends you, then yes, it is illegal. But I feel that the retailer also has a responsibility, as blindly accepting any data from the client without checking its own internal database is just plain stupid!
AC comments get piped to
And i don't mean slashdot, i mean the idiots that wrote the story in the first place.
ANYONE who has ever written a shopping cart type app, or has used a canned one (a la site server or commerce server) knows that you only pass along the item's identifier (usually a number or string). this ID is then used ON THE SERVER SIDE to retrieve pricing info from the product tables.
I haven't seen a shopping cart app out there, EVER, that uses pricing as a variable in the html code, and i doubt the writers of the story have either.
and just trying to say this is the same problem that the united airlines site had is just plain lieing.
so now that slamming the tech sector is hip, are they all just gonna start making shit up?
sorry, but this really upsets me.
There are two kinds of people in the world: Those with good memory.
Whoever wrote these shopping cart applications should be taken out and shot. It is disgraceful.
Mod up the parent, this class of vulnerability is very old news and has indeed been corrected in all but the lamest of shopping carts.
Maybe next we can see an article on the new "format string" type of vulnerabilities?
maru
And too many bad managers. They just don't design it right (if they even did a real design at all) and of course it trusts everything the browser sends back. Shame shame shame!
now we need to go OSS in diesel cars
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.
Read to the end of my comment. I know you are only supposed to pass the ProductID and Quantity in form/hidden field/querystring values. Thank you for the lesson, but I've been doing this for years. All I was trying to do is explain why this is common. You had a lot of inexperienced developers being rushed, and they made some stupid mistakes.
No, Thursday's out. How about never - is never good for you?
You don't need to upload a page to their site. You just need to make an HTML page with a form that submits to their server.
This is really such an obvious problem, I can't believe that anyone would be stupid enough to code their application to accept a clients version of the price. I wonder if most of these problems are caused by one or two widely used but badly designed programs?
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
"For traditional shops this should be all that necessary to prevent this."
Of course. How many shops these days ring up the price from what's written on the product? They scan the barcode and pull the price out of their database. Swapping bar codes is tricky to get away with expecially if the bar code is part of the packaging - an exception is the shops that have to have their own bar code stickers on everything.
--
Consultancy: If you're not part of the solution, there's money to be made in prolonging the problem
I work in an auto parts store. We have 2 kinds of oil filters: $2.49 and $9.99. If you switched the products so the $9.99 filter is in the $2.49 box, you pay $2.49 for a $9.99 filter. Not quite. You paid $2.49 for the privilege of shoplifting a $9.99 filter. Still illegal, and if I catch you, you go to jail.
"fortunately we're not selling anything"
/. to change their karma.
Yeah, people only hack
--
Sheesh, evil *and* a jerk. -- Jade
Thanks for the pointer; it looks like the paper you referenced is the one at http://www.cs.virginia.edu/~evans/cs551/saltzer/ "The Protection of Information in Computer Systems". Interesting paper.
Once again, stupid people give everyone else in their easily classifiable sub-group (geeks) a bad name. For Stallman's sake...
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
Or at least a bunch of people's sigs.
---
AYBABTU (0wned)
it would depend on if the person you are dealing with has the authority to deal. If you go to a car lot and give the janitor $100 to druive off a $10000 car, it is theft because the janitor does not have the authority to give the car at that price. usually a salesman does not have the authority to go lower than a certain point either. usually I would think online vendors can claim that their software does not ahve any authority to accept altered prices. which would make submitting altered prices fraud. but then, IANAL.
Be ot or bot ne ot, taht is the nestquoi.
If an agent sells you something for a price lower than they are authorized to do you're in the clear. The agent, however, is responsable. So they get to sue their software, not you.
Cheers,
Rick Kirkland
In a physical store, if the staff is too busy too notice, is it legal to shoplift? I don't think so.
Life is like a web application. Sometime you need cookies just to get by.
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!
There's a simple term for the situation where one party in a contract is deliberately trying to cheat the other party by misrepresenting what the contract is about: the word is fraud. Contracts build on fraudulent representations are almost never enforcible by law.
If somebody gets $10,000 worth of equipment for $10 by price-changing the order form, all the company has to do to justify legal action is demonstrate to the court that the purchaser deliberately intended to defraud the company. Editing the html to change the hidden price fields is a pretty clear intent.
-mazor
At first glance, the answer would seem to be "obviously." But is it?
.. namely, that you are going to buy Item X and pay Price Y for it. Moreover, the vendor agrees to sell you Item X for Price Y. If that agreement, as shown to you, says that the vendor will sell you the shiny new laptop for $3, are you violating any actual, existing laws?
Think about it; when you're at the "checkout screen" of an arbitrary online vendor, and you click the "Submit Order" button, you are essentially formally agreeing to a set of terms
Certainly this is immoral, but I don't see how it can be (currently) illegal.
Just because you leave your car running in a bad neighborhood with the title taped to the rear view mirror and the doors open doesn't make you not a complete freaking idiot.
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 ...
First, take into account average computer literacy. Internet use has exploded, and not all the of the people online fuly understand what the hell they are doing. Mom and Pop buying something online arent goign to go check the source code for the page they are looking at. They are going to put there CC number in and click okay. This can be said of most people buying something online. Even the geekiest sysadmin probably won't view source when he uses on online shopping cart. Additionally, the script kiddie hax0r type probably doesnt even know what a hidden form field is.
So what we have here, is a problem that could potentially effect a huge number of people, but they dont know it. Its hiding in plain sight, if you will.
----
One of us needs to stick ones' head in a bucket of ice water.
- Hobbes
Maybe not you, maybe not me, but somebody is going to take advantage of this. And just like shoplifting, it is the real shoppers that are affected. Those that got $25 tickets to Paris are being subsidized to some degree by the rest of the airline's customers.
I find this really irresponsible of these companies, but the airline thing sounds like a different problem. Sounds like they had a bug in their software that forgot to include the fare for the ticket.
JET Program: see Japan, meet intere
Given the recent Columbine rehash over in California, I expect statistically an "It's for the children" argument would draw some support from some of the paranoids still bewitched by the event.
Course I don't have any "It's for the children" arguments to support cracking for stealing purposes, nor to support any other cause.
"It's for the children" should be banned as an argument.
Now for something completely on topic:
To the guy on a certain mailing list who can't see the light about security needs, don't ever sell anything online, you'll be sorry. That's a warning not a threat.
The message on the other side of this sig is false.
Why should you need to? Well, it's clearly necessary.
Sometimes, you're stuck without a choice. Perhaps you're writing a client/server database application that needs to be cheap -- you use Access, and leave date stamps in the hands of clients. I suspect that the biggest problems in the article's example come from the people who manage to get a shopping cart script or two running on their shared server. If the cart is database agnostic, it needs to know what the price is *somehow*, right?
If you have a dedicated server and a database that generates those prices in the catalog, you're just plain lazy. The programmer ought to be shot.
I registered my hate for Jon Katz
The really scarry bit is that out of all these messages, we only got complaints from *2* AOL users. If you are using formail.pl, tighten your security now.
--
Slashdot monitor for your Mozilla sidebar or Active Desktop.
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.
Sure, this article is clearly just promotion for Sanctum's products. Yes, it's the familiar voice of clueless marketroids.
But what makes you immediately assume that the product is worthless and that techs just like you who have developed it must be dumb? Why do you label them as "so-called security"? Have you even bothered to open their web site?
I am not affiliated with sanctum, but they actually have a very nice product. From their documentation it looks like AppShield is a proxy that takes the stateless http protocol and puts a stateful inspection layer on top of it, checking for manipulation of forms, cookies, field sizes, etc.
It's easy to blame sloppy web programmers but the fact remains that the demand far exceeds the supply of qualified programmers. And even good web programmers are sometimes required to use buggy packages developed by others. In the real world of deadlines and underqualified personnel there is definitely room for a product like this. You are more than welcome to develop an open source equivalent.
-
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
I could use some right now.
Je t'aime Stéphanie
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
NT. I just love it when they post the crack in plan sight like that...Idiots! Idiots Pinky!
LFS. Have you built your system today?
That is what CowboyNeal said in recent interview. This is why I never share a password for sensitive sites and non sensitives like this. I might use the same password for slashdot that I use for some forum somewhere, but my email accounts are going to be different. My cyberstore accounts will use a different password. I really dont care if someone steals my slashdot ID. It is only used to share a bit of info and have a customized front page. If you somehow manage to post as me on some forum then big deal. It is a big deal if you managed to log into buy.com and use my credit card info because I was stupid. (I really don't know what buy.com's credit card policies are, nor do I care as I don't shop there. It was just an easy example.)
Just a Tuna in the Sea of Life
Sorry, but I just went to several web sites that I buy from and tried this. It worked on EVERY ONE of them. I called the told them about the bug and asked them to cancel the order. One of the sites I tried is a MAJOR retailer.
I don't see any legal difference between the two hacks. There is a huge moral difference. In my case I was being fired to force me to give up minority ownership of the company. In the other case people are stealing from the stupid.
Hmmm... is it actually immoral to steal from the stupid?
I know how to prevent it - block PUT method access in your httpd.conf file. BIG DEAL.
..
.. ;-)
Yeah, it's not easy to fix, but how many "webmasters" out there are that competent? If it's not a checkbox option in FP2K, a lot of them don't think to look at it
I have to say I have seen few things easier to set up than Apache's httpd.conf, so it doesn't hurt to go take a look at the file. Oh, you're not using Apache, you're using IIS? Maybe this article *was* for you after all
73 de N5VB (ex-KD5BIV) AR SK
Just remember that behind every evil corporation is some webmaster trying to make ends meet. Maybe he didn't have the time to write decent, error free, hack free code. I say, if you're going to hack, hack your own software and hardware on your own box. Don't break other people's work, no matter how easy it may seem.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Good point, but these are not the sort of people who should be developing web applications for e-commerce sites. Anyone who puts them to work doing so deserves everything they get.
This vulnerability has been around for a while. The linked article is from October of last year and I remember seeing this at least a year ago. If this is still happening it is nobody's fault except the vendor that sells the shopping cart software. It is unbelievable that this is still happening.
My reaction was: how retarded!
Isn't it easy to do a lookup in your database to see if the prices match what's being bought, and put some integrity constraints into the system?
I sure would if it was my money on the line!
---
In a hundred-mile march,
This is really just poor software design. This is simply evidence of what many have indicated is a problem in the area of web design in general.
Just because Joe Schmo is a good graphics designer, or knows how to use front page, does not qualify him or her to start designing software... it should be obvious to any professional software designer to verify the data from the web form against what is in the database.
In fact, many good shopping cart packages do just this... I suspect that after being burned once, smart e-businesses will either redesign their software, or hopefully learn that even web based software should be designed by a professional programmer, not some hack who just happens to understand PERL's syntax...
-- If at first you do succeed, try to hide your astonishment. -- Harry F. Banks
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.)