Forum Moderators: buckworks
I believe PCI compliance will be coming very soon, so is it worth writing your own custom cart?
I really want to write my own custom cart (for many reasons I don't want to get into), but my one big concern I have is being compliant.
I know commercial carts pay big bucks to get the compliance certificate.
All my carts are custom, as are my checkout processes.
Most of the PCI stuff has to do with the host server. What OS, along with what version of SSH, FTP, what remote accesses their are, webdav and remote desktop stuff.
It is here already! Trust me, I fight month after month with this with my merchant provider.
As Demaestro stated, PCI is more about the server/network/processes and less about the software. Yes, the software need to meet the standards, but that is a very small part.
A PCI compliance is usually just a questionaire, but they don't look at the software level.
Why are these commercial carts saying they pay 40K/year to be certified, and other carts are not?
but they don't look at the software level.
For services that use Security Metrics, it **does** look at the software level from an external point of view. S.M. passes potential malicious XSS, SQL injection, and other queries to the site, and if the data is not filtered properly, adds to the risk score.
Sometimes it's an internal server software, not your cart. For example, some versions of PHP contain security holes and if found, this will add to the risk score. You fix it by upgrading to the suggested version of PHP.
**Most** of the scripting risks are managed by properly filtering input. The upshot of this is it makes your programs more secure, you learn to properly filter input, and this can't be anything but a good thing.
Why are these commercial carts saying they pay 40K/year to be certified, and other carts are not?
Don't know the direct answer to that, but I do know that sites that actually store credit card info are required to be PCI compliant on a higher level. The questionnaire is used to determine what level of PCI compliance you are required to meet as a vendor.
I'm beginning to think Security Metrics is not "perfect" and is giving some false positives based on unrelated non-security issues. Here's an example [webmasterworld.com], the basic question asked there is still unanswered.
Even so, it's helped my clients to have more secure environments and made me a better programmer, at least, a little. :-)
I may be wrong, or this may be just in Canada, but....
Isn't it the case you only need PCI cert if you are storing the credit cards on one of your servers?
If you don't store or record the CC numbers are you required to have a PCI cert? I thought no but could be wrong.
I just checked with my gateway and they only want me to have one if I store numbers, they don't require it otherwise, and they are very strict.
I am just wondering if there is some other body that is requiring it of me.
dreamer -> there are third party services that do code review. Applications and Websites that use those code reviews are usually in a position of high trust.
For example, banks and some poker/gambling sites have code audits. These are expensive though. Most e-comm vulnerabilities come in the form of sql injections and cross scripting stuff which can be checked using brute force methods, so getting a full code review isn't required.
There are various levels of PCI compliance. The lack of storing CC data does not relieve you from being PCI compliant. Simply the act of taking cc info and transmitting it requires PCI.
The only way to NOT need PCI is if you use a proxy payment provider (ie paypal, google, etc) where the customer leaves your site to complete payment.
Also, it is not the gateway that requires PCI, it stems initially from Visa/MC and is required by your merchant provider.
just wondering who requires this if you process CC numbers?
The credit card companies require the gateway to require PCI compliance of their web site clients. So if your gateway hasn't required this of you yet, they will . . . eventually. Not sure if this is just U.S. only or not.
EDIT: what ssgumby said . . .
I just finished a gateway for a client about 3 months ago and it says specifically we only need PCI cert if we store the numbers ourselves. It may have even changed since then.
Our only requirement was an SSL.
I will be watching for a change though.
Gateway = authorize.net (they do not require me to be PCI compliant)
Merchant Provider = First Data (they DO require me to be PCI compliant).
Also, the wording is quite tricky. When I first read this I thought too that as long as I did not store the number then I was safe. After a full analysis, it is simply if I store "credit card data". Credit Card Data is defined as ANY info on the credit card. (ie. First, Last, CC#, Expire Date). Of course I store first/last and this in and of itself forces PCI compliance.
I would consider that customer information, even part of the shipping information, but if no other card data is there not sure how they could consider just the names as such.
I too would consider it customer info, but my provider anyway sees it differently.
Trust me, I have been working on PCI and fighting with FD since Jan 1 2009 to get this all worked out. My cart scans fine, the questionairre and specific level is what is hard to pinpoint. They have me at the second to the highest which is nuts in my opinion.
But you know what they say, to be in security you have to be paranoid. And paranoid people often don't make decisions based on reasonable logic.
Q: What is defined as ‘cardholder data’?
A: Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security number, etc. All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data.
I agree, it seems totally nuts!
It really isn't that big of a pain.
Putting on my programmer hat for a second and playing devil's advocate.... I wonder to myself technically what the difference is between doing a POST from my SSL'd page to the payment gateway, and the POST coming from the processor's page itself?
Especially if I am not storing any of that form data on my server. As long as the SSL cert has good encryption, what difference does it make which page POSTs the data?
I am not saying PCI isn't a good thing to have in either case, I just wonder what the difference is technically when you host the form yourself from when you don't, that would cause them to say that if you host the form you need to be PCI compliant?
Both scenarios POST form data from an SSL'd page to the same place and both scenarios end with the processor POSTing back the results of the transaction to the website's server.
If you are starting out you might want to use something like Paypal that processes the card off site. If you are established, go for it but don't plan on storing full credit card numbers or expiration dates.
That isn't the case though. I am not sure you understand the how transmission of data occurs.
Again, I am not storing the form data so hacking my site wouldn't yield anything. The form is filled out client side so the only way to intercept the data is at time of POST.
If a proper SSL encryption is applied to the POSTed data, then I don't see the difference in which page POST's it. It still gets transmitted from the user's computer to the gateway regardless of who hosts the page.
Again don't get me wrong, I am not suggesting that we shouldn't have it.
I just don't see the difference between hosting a form yourself or having them host the form.
If anything I think it is less secure to send the user to the host page because then they don't require an SSL and the site may transmit order details and shipping info which could be intercepted, not CC info, but some other customer and order info.
Keep in mind that quite a number of very popular open source solutions actually use the API integration with payment gateways - making PCI compliance a requirement for their users.
In regards to $600 PCI compliance - no one can provide PCI compliance for $600. This is why:
PCI defines a number of regulations and procedures you have to comply with.
These require you to not only set up your firewalls, servers and databases in a certain way - they also define how you connect to your servers, who has what kind of access, how you deal with passwords, what kind of intrusion control and logging processes you use, how long you store logs, how access to the data enter you host in is secured, how you encrypt credit card details (if you store them) and many other procedures which you have to implement.
The $600 option can only deal with the server side setup - and in most cases they will not even set up intrusion control and PCI compliant logging - they simply make sure the server passes an external PCI scanning test. The onus of complying with many procedures is on you.
Most people who store or transfer credit cards believe they are okay, if they sign up with a company scanning their server for PCI compliance. This however is only one small part of PCI compliance.
PCI compliance is a huge pain in the proverbial - and unfortunately it is made a lot more difficult by people who don't read the rules or who choose to interpret the rules in certain ways rather than the way they are written down (usually so they can charge you more for becoming compliant).
A whole industry has developed around this, from special intrusion detection software to logging software and companies verifying your compliance.
Software for PCI compliance can quickly add up to more than $20,000 in yearly license fees, depending on the number of servers your system uses. Prices are absolutely horrendous. Although this isn't required at all. There are a number of open source solutions you can use to meet compliance, such as Ossec and Snort (but you need to know how to set them up and you have to use multiple servers). You can also host servers on Amazon EC2 cloud, so long as you don't require Level 1 PCI compliancy (more than 6 million transactions per year).
Really your best option is to go to the PCI website [pcisecuritystandards.org...] and download the questionnaire applicable to you and you customers. Just read it - that will give you the clearest understanding of what you are getting yourself into.
:)
I don't see the difference in which page POST's it.
Take a scenario. You've bought the best 256 bit encryption cert you can buy, high user trust, whatever. Let's say it's perfect.
Your server has failed a PCI compliance scan due to some security flaw, whatever it is, doesn't matter - let's say it's an old PHP version with a flaw.
Some hacker has made use of that flaw and can access your data in some way, or maybe has even rooted your box without your knowing it.
User submits data. Hacker logs all data submitted.
So even though your cert encrypts the data, the server decrypts it on receipt. When it's received, hacker is sniffing/storing it, after decryption.
This is the difference, although it's a simplistic scenario, it demonstrates you are responsible for the environment you create.
