I wish I was surprised. I bet the shipping is calculated via Javascript and people with Javascript turned off get free shipping too. Intro to CS courses don't think they have enough time to get into the details of what code runs where and who and what you can trust and what encryption really does and why "oh just use https" doesn't solve everything, but it's one of the most important topics that everyone exposed to a bit of programming should know and consider. If a rewrite proxy can give your customers free stuff, it's somehow at the same time both just unforgivable yet almost expected/par for the course. I wonder how many sql injection and cross site scripting holes are in the same site.
I hate when the top answers on stack exchange sites are suggestions to do something completely different (don't write your own web store). I wonder how that could be avoided. Should he have worded the question differently? Should there be separate upvotes for "answers question" and "useful information"?
On help groups, it has become common to address the XY problem: A user cannot solve problem X, but thinks that problem Y is equivalent and tries to solve that. The user can't solve Y either, and goes to ask for help on problem Y, without mentioning problem X.
Of course, this doesn't apply to this particular question, but I figured I'd explain why people do this.
With PHP you can create the headers at the top of the page, with python you can create a 'script' that sends custom headers to a server, thus you could tell the server that its a image via the headers but it could be something different ie a script... Any good developer will look out for this stuff though.
You can send custom HTTP headers from the browser with XMLHTTPRequest, commonly referred to as AJAX. Not totally sure if this is what the poster is referring to, but its possible.
Hmmm...is this a problem of someone who was hired to do the front and the backend? Why would freight and total price be calculated client-side, instead of the backend taking in quantity as input and then doing the calculation against the inventory db?
The card thing is really No Big Deal. It's actually a pretty smart integration with one shortcoming.
Whatever gateway they're using has some support for you maintaining control of the checkout experience while not actually receiving or transmitting card data--a great thing for PCI compliance. So the form is on an HTTPS page on the merchant's site, but instead of posting to the merchant's app, it posts directly to the gateway. The gateway communicates status with the merchant via a synchronous HTTP request or signed data in a redirect URL, and the merchant's software processes the transaction without ever seeing card data.
As the OP says, "they're using HTTPS"--yes, this makes all the difference. The only reason the info appears to be clear text to him is that he's using Tamper Data, a browser extension that lets you play with your own POST data before you send it over HTTP(S).
This is the Right Way to do it for a site that doesn't get some compelling advantage out of building the infrastructure necessary to be PCI compliant. Done this way, PCI compliance requires just the trivial SAQ A. The only problem with this is that either the gateway does not support (sadly, the most common case) or the developer did not implement signing the transaction details on the merchant side.
I meant not so big a deal as transmitting the card data in the clear, and not that hard to fix, and possibly not even indicative of developer incompetence if they knew about this issue (which may be a limitation of the gateway the merchant insisted they use) and apprised their client.
Yes, it's bad for people to be able to change the prices on what they're buying, and potentially it's a very big deal if there's no reasonably attentive humans involved anywhere else in your process. (If I got a $10,000 order, I'd double check that everything was golden in my gateway before I popped the cork on my champagne.)
The worst case for this is someone with a stolen credit card purchasing big ticket items for a small enough amount that it doesn't trip any alarms. You'd be a fool to do this with your own card.
Hmm, from what I gather the customer is able to reset the dollar amount. Something that can be caught for sure, but sounds like pretty bad design to me.
It's No Big Deal until someone orders $10,000 worth of merchandise, pays $1 for it, and it gets shipped to an empty house in a subdivision before someone notices.
Then it's a Really Big Fucking Deal Oh God How Will We Pay Rent.
I don't think this is what you meant by signing, but it seems the easy fix for this is to have the merchant server post the transaction details to the processor, get a purchase order number, and redirect the customer to that. Why do processors rely on the customer to provide the details?
[+] [-] pkteison|14 years ago|reply
Obligatory please-educate-yourself link: Open Web Application Security Project top 10 list: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...
[+] [-] nbpoole|14 years ago|reply
- http://checkout.google.com/support/sell/bin/answer.py?answer...
- https://payments.amazon.com/sdui/sdui/helpTab/Amazon-Simple-...
- http://letsearndollar.blogspot.com/2009/07/change-any-paypal...
[+] [-] mrspandex|14 years ago|reply
[+] [-] MostAwesomeDude|14 years ago|reply
Of course, this doesn't apply to this particular question, but I figured I'd explain why people do this.
[+] [-] tedunangst|14 years ago|reply
[+] [-] midnightmonster|14 years ago|reply
[+] [-] jivejones|14 years ago|reply
[+] [-] yahelc|14 years ago|reply
[+] [-] danso|14 years ago|reply
[+] [-] midnightmonster|14 years ago|reply
The card thing is really No Big Deal. It's actually a pretty smart integration with one shortcoming.
Whatever gateway they're using has some support for you maintaining control of the checkout experience while not actually receiving or transmitting card data--a great thing for PCI compliance. So the form is on an HTTPS page on the merchant's site, but instead of posting to the merchant's app, it posts directly to the gateway. The gateway communicates status with the merchant via a synchronous HTTP request or signed data in a redirect URL, and the merchant's software processes the transaction without ever seeing card data.
As the OP says, "they're using HTTPS"--yes, this makes all the difference. The only reason the info appears to be clear text to him is that he's using Tamper Data, a browser extension that lets you play with your own POST data before you send it over HTTP(S).
This is the Right Way to do it for a site that doesn't get some compelling advantage out of building the infrastructure necessary to be PCI compliant. Done this way, PCI compliance requires just the trivial SAQ A. The only problem with this is that either the gateway does not support (sadly, the most common case) or the developer did not implement signing the transaction details on the merchant side.
[+] [-] midnightmonster|14 years ago|reply
Yes, it's bad for people to be able to change the prices on what they're buying, and potentially it's a very big deal if there's no reasonably attentive humans involved anywhere else in your process. (If I got a $10,000 order, I'd double check that everything was golden in my gateway before I popped the cork on my champagne.)
The worst case for this is someone with a stolen credit card purchasing big ticket items for a small enough amount that it doesn't trip any alarms. You'd be a fool to do this with your own card.
[+] [-] djb_hackernews|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply
Then it's a Really Big Fucking Deal Oh God How Will We Pay Rent.
[+] [-] tedunangst|14 years ago|reply