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 ;)
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.
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.
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.
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!"
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"
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.
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.
Opus: the Swiss army knife of audio codec
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.
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
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.
"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
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?
...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.
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
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.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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
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.
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
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.
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Go ahead, click it
Trolls throughout history:
Jonathan Swift
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.
"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.
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.
There are two kinds of people in the world: Those with good memory.
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!
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
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?
Engineering and the Ultimate
How /. could afford to buy the Slashdot Cruiser!
If you love God, burn a church!
Ewige Blumenkraft!
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.
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.
JET Program: see Japan, meet intere
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.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
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.
Geek> Okay, the site is progressing nicely. We're almost ready to roll out, all we have to do is pay our contractor for another two hours of work to add in the price verifi...
Suit> What? Another hour?! But we're paying her almost $70 an hour! That's $140 for something we can go live without, right?
Geek> Well, theoretically, but...
Suit> Do it! Wait until the CEO hears that I'm taking proactive steps to save money on our mission-critical project!
I've sat in enough meetings that went like this to have no problem picturing an exchange of this nature.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.)