Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet

Electronic Pricetag Alteration 210

Posted by CmdrTaco from the it-took-folks-that-long-to-figure-this-out? dept.
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 ;)
This discussion has been archived. No new comments can be posted.

Electronic Pricetag Alteration More

Electronic Pricetag Alteration

Comments Filter:
  • No ... that's not PR for Sanctum or anything ... naaawwww ... couldn't be. Companies don't advertise with news articles ... not at all.

    -Christian

  • 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.

  • Re:Try this link... (Score:1)

    by Anonymous Coward
    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
  • This is unrealistic. The error was committed at the design phase. The system shouldn't even ask the client what the price should be, and therefore shouldn't have to check whether or not the client modified the price. The only things the shopping cart should put in the form at all are: item numbers, quantity of items, identity of the buyer, possibly an order number (picking this using a cryptographically strong random number generator is a plus). That is all the client has the authority to change.

    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 :-)
  • 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.
  • It's not necessary to put the form back on the Web server.

    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
  • If the cart is database agnostic, it needs to know what the price is *somehow*, right?

    I imagine that that "somehow" would the same way it got it in the first place.

  • > The clerk/whoever says "$100", pointing to their sticker. *IN PLAIN VIEW*, you pull out a sticker that says "$50" and carefully affix it to the item and say "How about that?"

    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.
  • A contract is a description of an agreement. If I switched papers then that paper does not descibe our agreement. There is no "Meeting of the minds."

    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.

  • Re:Then they deserve it (Score:4)

    by Fervent ( 178271 ) on Tuesday March 06, 2001 @10:00AM (#380876)
    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.
  • That's all dependant on the appearance (to the customer) of the person claiming to have 'agency'.

    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. :) I should try placing orders from companies in those few states that have passed the UCITA. heheheh
  • 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?
    • Yes, because you have modified the agreement the vendor showed to you.
  • 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?)

  • Just when you think... (Score:1)

    by Anonymous Coward
    ...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.

  • Well, DUH! (Score:5)

    by schon ( 31600 ) on Tuesday March 06, 2001 @10:01AM (#380882)
    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?

  • I suspect that the police could probably prosecute this, but it would take a while to catch up.

    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.

  • 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
  • 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! [silicongod.com]
  • try everything2 [everything2.org]
  • 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? ;)

  • 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.

  • 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...

    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.


  • 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.


    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.

  • 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
    ---
  • 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.

  • If you dont control it, dont trust it... (Score:5)

    by segfaultcoredump ( 226031 ) on Tuesday March 06, 2001 @09:47AM (#380899)
    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.
  • Disclaimer: I work for uBid.com (shameless plug), a B2C auction site. I'm curious what auction types you think need client side validation.
  • 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.

  • 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.

  • Hey, I can't find it! (Score:5)

    by glindsey ( 73730 ) on Tuesday March 06, 2001 @10:03AM (#380910)
    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.

  • Back on September 24, 2000, Egghead.com advertised a 256MB stick of Crucial SDRAM for $35. HardOCP got the scoop on this [hardocp.com] (just keep searching for Egghead on that page). The price was wrong (it was supposed to be $350, not $35), but many people had already placed orders for it and had received confirmation messages. Two days later, Egghead announced that they were cancelling all orders for that item. Unfortunately for Egghead, a few of the orders were actually shipped out the door.

    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 [fuckedcompany.com].

  • 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.

  • Not in the least. When you go to the store and get an item, it has a UPC on it. That UPC has a number that corresponds to a record in a pricing database. That record has name and price (among other things). When the cashier scans it, he/she views (or is supposed to view) the display to make sure the name matches what they just scanned. If it doesn't, they should cry foul (though for the machine by default, I would think). What you seem to imply is that the UPC is a number directly representing the price. This is totally incorrect, and would lead to a lot of UPC switching in stores.

    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.

  • Some of us actually do leave our doors wide open. And noone comes in, because they are decent.

    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.

  • "Many Web sites are vulnerable to hackers because the task of auditing their applications and detecting hacking is time-consuming..."

    Not now that /. has linked to it. Now every script kiddie on earth knows how to rip-off online vendors. Watch the patches fly out.
  • All shopping carts that I have ever seen specifically allow the user to update data. They almost universally allow you to change the quantities and to add and remove items to a cart. This involves an update to the database usually(exceptions being a file-based cart or a cart stored entirely in memory).

    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 [page1book.com] however only allows price input to the cart from values in the database itself and is additionally protected by an OpenBSD firewall :) )

  • ...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
  • 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.
  • One anecdotal data point....
    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.

  • Fraud is still fraud, even when the victim is stupid.
    ---
  • 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.
  • 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 ?

  • I know how to prevent it - block PUT method access in your httpd.conf file.

    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.

  • 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.
  • 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.
  • 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.

  • Anybody who is relying on client-side storage is asking for trouble. Basically, storing information in this way is little more than a suggestion to the client. Sort of like the server saying "here is what the price is, now send back what you think the price is!". This is useful for things like non-crucial state information, but use it for much else and youre asking for trouble.

    Most people don't understand that HTTP is stateless and there are security considerations bundled with that.

  • 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.

  • Re:Argh. (Score:4)

    by Admiral Burrito ( 11807 ) on Tuesday March 06, 2001 @12:46PM (#380973)

    On a side note, I teach people to write web applications. My students are generally not programmers to begin with. When we were writing shopping carts, not a single one of my students stored pricing on the client side.

    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.
  • Yup.

    I set up slash for a simple intranet at work. Naturally, some people forgot their passwords. No problem, right? Just clear out the encrypted field and let the user create a new one. Using KMySQL, I brought up the table and, to my horror, the passwords were not encrypted. The passwords for everyone in my company were staring at me.

    Sigh...
  • 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.

  • 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).

    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.
  • The real problem is that a number of CC Processing companies are offering the following service:

    "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.

  • 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.
  • All shopping carts that I have ever seen specifically allow the user to update data. They almost universally allow you to change the quantities and to add and remove items to a cart. This involves an update to the database blah blah blah...

    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

  • 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.

  • 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!

  • Silly Merchants.. (Score:5)

    by Xunker ( 6905 ) on Tuesday March 06, 2001 @10:15AM (#380997) Homepage Journal
    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).
  • 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.
  • Hey isn't that bait and switch? I thought by law you had to sell it at the advertised price, regardless of the fact you put the wrong price on it.
  • 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?

  • 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...

    Actually, it's possible to use those systems and still avoid this bug: When the storefront presents the final 'submit' page to the customer, a hidden field (which will be posted to the CC processing company's server) should be included. This field should contain all of the order's pertinent data (price, etc), encrypted with the storefront's private key. When the CC processor gets the submit request from the user, they use the storefront's public key to decrypt the contents of this hidden field and compare the values it contains with those on the form submitted by the user to ensure that no monkeying has taken place.

  • Sometimes - but not all sites offer the same price to all customers.

    Ummm... If you can figure out what price to put into the form, you can figure it out again after they tell you how much they want.

    If the preexisting process is based on a paper quote, it may take non-zero work to avoid embedding any quotation information in the quotation into browser session state (cookies/URL fields/whatever).

    I agree that if someone is taking a paper quote and trying to then order it online (expecting the quoted price) you've got a real problem. This is, however, a business issue, not a software one. I'd suggest that this process would have to require the eMerchant manually verify the price against the quote before filling the order.

    As to tracking the session, the only safe way to do this is server-side. Anything else can be compromised by someone with a clue. Any cart software worth using will track everything about the session on the server side giving the browser a unique session Id to follow along with.

    The only variables that should be left up to the client are what item(s) they want, the QTY they want, how they're paying, and where it's going. Everything else should be calculated and stored server-side.

    --

  • 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 [iss.net]

    --Tim Farley, ISS

  • I'm guessing they probably also have the vulnerability to change the item description, which might be even worse. Think about it. If someone allows you to change the description on the web site, you could link to their page, with a specially coded URL that adds "Bag of Crap" to their cart for $5. Or you could add a "B1 Bomber" for $10. This would be even better than setting prices, and there's probably some vulnerable software packages. Noone bothers to check input these days. Where do these programmers come from?

  • Now we know... (Score:3)

    by the real jeezus ( 246969 ) on Tuesday March 06, 2001 @09:51AM (#381018)
    How /. could afford to buy the Slashdot Cruiser!


    If you love God, burn a church!

  • Is this illegal? (Score:2)

    by Anonymous Coward
    At first glance, the answer would seem to be "obviously." But is it?

    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 .. 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?

    Certainly this is immoral, but I don't see how it can be (currently) illegal.

  • Do not trust the client side! (Score:3)

    by (void*) ( 113680 ) on Tuesday March 06, 2001 @09:52AM (#381023)
    Shopping cart servers should not trust anything on the client side beyond the identity of the shopper and what items it purchased. The computation of price, shipping and tax should be all done on the server, and the results presented to the consumer for him or her to endorse and finalize the purchase.

    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 ...

  • 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.
  • 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.

    Which doesn't do the merchant any good if they're still assuming that the shopper gave them the correct price when they hit "Buy". Of course, any intelligent software designer would never have trusted the user with the price in the first place-- it would have have been grabbed out of the DB and totalled by the server just before passing it to the credit card authorizer.

  • Forged information from the client can also used to turn most web->email feedback forms into spamming gateways. We were recently stung when some jerk used a peice of software that lied about it's referer and hijaaked one of our feedback forms. He used it to send a porn spam to 33,000 AOL addresses.

    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.
    --

  • Yes, because you have modified the agreement the vendor showed to you.

    I don't know. You did not generate the agreement, the vendor did. And you made changes to the pricing before the agreement was generated or entered into by the vendor. Like in the real world, I call up a vendor who is advertising, say Xeon CPUs for $40 each. I tell the sales drone I'd like four, but I'm only willing to pay $30 each. The sales drone agrees to the price, and it is entered onto the sale order. When the sales drones boss takes a look at it, and says '$30?? It's $40, or nothing. Change the price.' he is pretty much screwed. He must either honour the price or face a lawsuit for the difference when he invoices me for $40 each.

    Now in this situation, the vendor is leaving the offer price open to the consumer, and not double checking before it is slapped on the semi-binding sale agreement. It's the vendors problem, not yours. You should never enter into any agreement you haven't read, nor are reasonably guaranteed to know the contents of. Same rule applies, technology or no.

  • Why merchants do this (Score:5)

    by dachshund ( 300733 ) on Tuesday March 06, 2001 @10:33AM (#381035)
    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."

    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.

    -
  • 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.

    If you're doing it the cheap & easy way, by having your shopping cart software POST to the authorize.net (or whoever) gateway, and then getting the status back as a redirection from the user, you're *still* screwed, even if you check the return code. Anything that goes through a redirection on the user's side can be altered by the user.

    Speaking of authorize.net, take a look at this page [authorizenet.com]; it includes an example of HTML code used to link to their service, and *of course*, it has the price changing flaw. Even funnier, if you run their Test Drive [authorizenet.com], you get not one, but TWO occasions to save the form to a local HTML file, edit the price value, submit it back, and their system is very happy to take your order at the price you've given.

    So, in short, if 30% of e-commerce sites out there have this problem (as the yahoo article claims), it's not just because of bad programming on the site's side, but also because of gateway services offering and advertising services that are insecure by design. I really wonder if a site that has lost money because of this couldn't sue them for it.

  • Patent violation here (Score:5)

    by Skyshadow ( 508 ) on Tuesday March 06, 2001 @09:52AM (#381039) Homepage
    Hey, isn't this a violation of Priceline's "Name Your Own Price" business model patent?

    ----

  • yep, it can be done in theory. in practice, most web developpers are way to clueless to put public key crypto in their webserver backends. even initiating a client SSL connection from the merchant's webserver is documented as "hard, not recommended for most users" by the gateways that offer this kind of secure options, imagine doing raw crypto by encrypting things with a key and sending them....

    btw, encrypting things with your public key amounts to a digital signature, so why not do that instead? send the data, and include a signature with it.

  • Does slashdot really store passwords in plain text? I know it has our browsers store passwords in plain text cookies (which is arguably worse).

    --

  • I agree. Reminds me of the time that one of our e-clients at my last company e-mailed us a list of ALL their clients' credit card numbers, home addresses, and SSN's ... in PLAIN TEXT. I now shudder whenever I buy something online...

    I also shudder when I think of how Slashdot stores passwords in plain text :>
  • 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.
  • OK, and we should do this because?... Just because we can hack some crappy source code doesn't mean we should take advantage of it.

    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.

  • Re:Richard M. Stallman! (Score:4)

    by Skyshadow ( 508 ) on Tuesday March 06, 2001 @09:58AM (#381063) Homepage
    I'd be really shocked if the people writing the web site were ultimately responsible for this. Instead, I see this sort of conversation:

    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.

    ----

  • 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...

  • Argh. (Score:5)

    by BJH ( 11355 ) on Tuesday March 06, 2001 @09:59AM (#381069)
    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.)

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close