I just discovered major security flaws in my web store(security.stackexchange.com)
security.stackexchange.com
I just discovered major security flaws in my web store
http://security.stackexchange.com/questions/5701/i-just-discovered-major-security-flaws-in-my-web-store
6 comments
This is a fairly common issue when people are integrating with third party payment providers:
- 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...
- 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...
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.
Of course, this doesn't apply to this particular question, but I figured I'd explain why people do this.
Mmmm... I think it's more than that. It's been my experience that questioners don't always ask the right question. For example, consider the (not entirely) hypothetical "How do I implement drop-down menus?" What the person typically needs is some sort of navigable interface for a web site--but that's not what they ask for.
How is the root question uncovered? By asking questions. (Why do you need it? How far along is the project?)
The best solution answers both what they asked and what they should have asked.
The reason people do this (as you say) is that they sometimes have enough experience to suggest a different path altogether.
How is the root question uncovered? By asking questions. (Why do you need it? How far along is the project?)
The best solution answers both what they asked and what they should have asked.
The reason people do this (as you say) is that they sometimes have enough experience to suggest a different path altogether.
Is HTTP header just a codeword for cookie? How does a website get the browser to send custom headers?
HTTP header is code for "POST data".
That makes sense. It was worth the negative karma to solve the mystery. :)
Oh god, thanks. I was confused about this new-fangled technique of using "HTTP headers" to pass pricing information...
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.
So how does the website get my browser to run a python script?
According to the article, this was supposed to work for normal users, not people hacking the server.
According to the article, this was supposed to work for normal users, not people hacking the server.
All I meant to say was that its easy to send custom headers to a server.
If you are using PHP:
http://php.net/manual/en/function.header.php
If you are using PHP:
http://php.net/manual/en/function.header.php
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.
ok, I didn't think a payment processor would be using a cross domain xmlhttprequest, but I don't know a lot about it.
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?
Ahhhhhh... Someone is wrong on the Internet!
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.
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.
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.
Then it's a Really Big Fucking Deal Oh God How Will We Pay Rent.
So admittedly I've only ever dealt with Paypal as a third party taking payment (as opposed to a few other systems where my server talked directly to the payment gateway).
One thing I noticed that the OP did not mention was whether or not the website's own 'transaction ID' was part of the transaction details being sent and / or whether or not the third party site returns a transaction ID themselves. At least with Paypal, the client makes the payment then they are returned to the original site with a 'receipt' transaction ID and it is then up to the original site to take that receipt number and do their own look up, back to Paypal, to ensure that the amount paid was actually the amount it wanted to be paid...
If that is happening with the OP's site, then I don't think there's anything stupid going on (or, at least, it's relatively simple to resolve).
One thing I noticed that the OP did not mention was whether or not the website's own 'transaction ID' was part of the transaction details being sent and / or whether or not the third party site returns a transaction ID themselves. At least with Paypal, the client makes the payment then they are returned to the original site with a 'receipt' transaction ID and it is then up to the original site to take that receipt number and do their own look up, back to Paypal, to ensure that the amount paid was actually the amount it wanted to be paid...
If that is happening with the OP's site, then I don't think there's anything stupid going on (or, at least, it's relatively simple to resolve).
I used a lot of systems. AFAIK, they all give some way for you to set your own transaction ID, and they all provide you with a gateway transaction ID, too. A good system will have a backend process to reconcile records based on one of these and would of course flag anything where the dollars don't match. This is the (inadequately explained) basis of my contention that the price editing is not a big deal. Of course, it could be a big deal if they botched a lot of other things, but by itself it doesn't mean there's an actual serious problem.
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?
Actual approaches I've seen:
* Trust the submitted data. Sadly, very popular. Of things I've seen lately, Authorize.Net's new Direct Post Method does this, as does the Prolific gateway.
* Have the merchant optionally crypto-sign all the interesting-to-manipulate parts and submit the signature along with. Braintree's old API worked this way, not sure about the current. USAePay does this, but they don't let you sign all the important fields.
* Stripe has your form submit to you, but they use JavaScript to submit the card details to them first and replace them in your form with a customer ID which you charge as you like.
* PayPal Express Checkout (but not any of their other checkout methods) uses the method you suggest. Although of course with them you leave the merchant's site to complete your payment. I suspect the reason it's not used more is that it requires the gateway to maintain some state that they wouldn't otherwise have to, and it involves an extra server round trip versus signing the submission.
* Trust the submitted data. Sadly, very popular. Of things I've seen lately, Authorize.Net's new Direct Post Method does this, as does the Prolific gateway.
* Have the merchant optionally crypto-sign all the interesting-to-manipulate parts and submit the signature along with. Braintree's old API worked this way, not sure about the current. USAePay does this, but they don't let you sign all the important fields.
* Stripe has your form submit to you, but they use JavaScript to submit the card details to them first and replace them in your form with a customer ID which you charge as you like.
* PayPal Express Checkout (but not any of their other checkout methods) uses the method you suggest. Although of course with them you leave the merchant's site to complete your payment. I suspect the reason it's not used more is that it requires the gateway to maintain some state that they wouldn't otherwise have to, and it involves an extra server round trip versus signing the submission.
Obligatory please-educate-yourself link: Open Web Application Security Project top 10 list: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Proje...