lorenw — 2013-02-05T13:10:57-05:00 — #1
First off, this goes against everything I know about PCI compliance.
I am working with Intuit's guest pay form. I get the form from Intuit's website with cURL, the form has some session ID's or something.
The form itself uses jQuery and as soon as it is submitted jQuery writes the credit card number to a cookie in your browser.
I need to replicate that with php to set the cookie with the credit card number and the use cURL to access Intuit's tolenizer URL.
I can only think of two things to make this secure,
1) make the cookie file name a long obscure non pronounceable name.
The site will be https.
Does anyone have any other ideas for security?
michael_morris1 — 2013-02-05T13:31:37-05:00 — #2
Find another way.
PCI compliance failure can kill a company. You can lose the ability to use credit card transactions for months and face fines in the millions of dollars.
lorenw — 2013-02-05T16:05:55-05:00 — #3
@Michael Morris (or anyone), is my suspicion correct that Intuit is in violation of PCI compliance?
Its right there in the live HTTP headers that show the raw credit card number being set in a cookie,
Here is a copy of the headers, sdsa_cc is the actual credit card number, I changed the numbers obviously but there it is.
GET /sdsa?sysid=ipn&num=0 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept-Encoding: gzip, deflate
Cookie: sdsa_cc=43516548214553296; s_vi=[CS]v1|285DE584231D1BCF-6000015874203E18[CE]; wa_cpm=h%20%5Bref%5D; mbox=check#true#1358434279|session#1358434218696-401004#1358436079; s_cc=true; c_28=h%20%5Bref%5D; ursvar=h%20%5Bref%5D; s_sq=intuitpaynetwork%3D%2526pid%253Dpaynow%25252Fguestpay%252520%25257Cspi%25253Aipn%25253Aapp%2526pidt%253D1%2526oid%253Dfunctiononclick(event)%25257BpaymentMethodChanged(this.value)%25253B%25257D%2526oidt%253D2%2526ot%253DRADIO
I have a copy locally of their credit_card_fields.js and can make it alert my credit card number.
kylewolfe — 2013-02-05T16:20:53-05:00 — #4
It's being sent over https, just as anyone who would type their card into a web browser, so I don't see why this would be a violation, but you need to watch how yo handle the card on your end.
cpradio — 2013-02-05T16:40:47-05:00 — #5
It is likely in violation because they are storing it in plain text in a cookie. You are to keep the card number secure at ALL times. That means encrypted in any storage mechanism you use, that mechanism shouldn't be easy to circumvent either, in which case, this one seems to be.
Intuit is walking a fine line on this one, and I'm terribly disappointed in what they have done, I thought they were better than this.
kylewolfe — 2013-02-05T16:56:18-05:00 — #6
Doh, cookie. Didn't see that
lorenw — 2013-02-06T17:32:23-05:00 — #7
Thank you for the input, My jaw dropped when I saw my credit card number in my cookie.
The problem is that I need to replicate this behavior using cURL.
I spoke with a couple of the tech people at Intuit and this was their response.
It is true that the card # is set in cookies, but is also cleared as soon as we receive a response from PCI token server. That's the advised approach to tokenize credit cards.
The Server will try to delete the cookie by setting expiration date to the past. It will work only if you create the cookie under ".intuit.com" domain, so you might need to use that domain if want to rely on server's logic.
In any case, I would strongly recommend to do your own cleaning job as soon as you received a token or an error from the server. The first thing that you need to do is to clean the cookie. Actually, consider this as a requirement, because this is what I've seen in other apps.
Basically if something goes wrong, you're credit card number will sit on a cookie.
And if you do use Intuit, it's up to you to make sure your cookies are cleaned.
Kinda makes me nervous.
cpradio — 2013-02-06T18:59:08-05:00 — #8
Me too, especially since they are aware of it... :shifty:
Apart from what you have mentioned, I think you are on the track that you may need to utilize. Unfortunately, I think you will have to use their cookie name and their domain (which I'm not sure that is possible, as it breaks cross-domain, but I digress, maybe with curl it would be fine with a cookie container). Just be sure to wipe out that cookie container once you are done.
felgall — 2013-02-06T20:31:29-05:00 — #9
Storing the credit card number on any computer with an internet connection is a breach. Since cookies only work on the internet that means that cookies cannot be used to hold credit card numbers - no matter how they might be encrypted.
The way that it ought to be done is to use a token that identifies the owner of a given credit card and pass that through the system. Once it is passed to the computer that only accepts information from the internet and which ic blocked from sending anything to the internet the token can then be looked up to obtain the credit card number.
lorenw — 2013-02-06T23:36:33-05:00 — #10
I am amazed and disappointed that a company like Intuit uses jQuery to set the cookie in your browser with the raw card number. I loaded the payment page and turned off the wifi. Then submitted the form and there was my card in the cookie. This was not well thought out for sure.
Bottom line is that if you use Intuit to make a payment, it is up to you to delete your cookies or there is the possibility that you could be compromised (by their own words, but they just don't tell you).
michael_morris1 — 2013-02-07T08:43:16-05:00 — #11
My advice is to forward this conversation with Inuit along to the proper authorities. A company as large as Intuit should be able to pay a huge fine.
felgall — 2013-02-07T13:38:20-05:00 — #12
While waiting for Intuit to fix this major security hole I suggest you completely disable cookies for their site.
lemon_juice — 2013-02-07T13:39:10-05:00 — #13
Good idea! It's incredible that a company can choose to store card numbers in cookies, be aware of it and think it is okay! Next time I'll be making an online payment I'll do it in a separate browser or another profile, and clear all cookies after the payment - just in case another reputable company comes up with such ingenious engineering...