[FX.php List] [ OFF ] Getting to PCI compliance
dale.bengston at gmail.com
Thu May 19 14:16:36 MDT 2011
Getting back to your original question... using a regex to strip characters could alter the data being submitted by users. This might not work if your regex is stripping, say, characters people are allowed (even encouraged) to use in passwords. To defend against SQL injection and cross-site scripting, you need to properly encode user input so that characters used in scripts and queries are seen as part of text strings and not processed as part of the query to "hijack" what you're trying to do.
To echo GGT, you *are* filtering your users' input, aren't you?
On May 18, 2011, at 4:52 PM, Bob Patin wrote:
> I've read a lot on their site too, and I'm no closer to what I need to fix than I was...
>> Back to reality...I boiled down the options to three:
>> 1) Store credit cards locally at the company and deal with each aspect of security.
>> 2) Store credit cards on the cloud. Recent hacks to SONY and others made me drop that option.
>> 3) Use Authorize.net's CIM integration method which completely removes all credit card data from client hands.
> I've been doing authNet integrations for years, but there are actually THREE ways to do card integrations: the first is what you described, where you leave your site, use their card-input page and then it returns the result to you. IMO, this method stinks, because you're stuck with their ugly input form, you leave your own site and have to return (which sends up an alert to users and is disconcerting), and you have much less control over how your app functions.
> The 2nd, and (IMO) preferred, is to build a custom integration which passes the card #, exp. date, fee, and other variables to authNet, where they process the card and return the results. In other words, you gather the card info in a form, use a processing page to send the data up to authNet; they process it, and send back a transID if it succeeds, an error msg. if it fails.
> The 3rd method would be to use a plugin like Plastic to run cards; this means you're probably storing client card #s in a database, and they need to be encrypted.
> My client isn't using authNet any longer; they're using another company, a very large gateway, but I think this whole PCI issue came up when they were still with authNet. Because of the fines involved, they've directed me to see about becoming 100% compliant.
> I never store a card # or any other card-related data; most gateways, including authNet, don't explicitly require CVV. I pass the card info directly to authnet, they process it, return a transID to me. I don't store card numbers in session variables or anywhere else.
> However, that doesn't get me any closer to what I need to do; the problem here isn't with card numbers, which aren't being stored. The problem is with cross-site scripting, and that's what I believe that I need to prevent. If I understand their docs correctly, I need to filter certain characters (the only 2 I'm certain of are the left and right carets). Once I do that, I think my part of compliance is done...
> SO... I'm hoping I can find someone who's already written this regex expression and could show me what they used...
> One last thought: I'm a huge authNet fan; I've probably written carts or other payment apps with a dozen different gateways, but authNet's is by far the easiest to implement. The gateway this client uses is compatible with the authNet method, so it was easy to migrate the existing web apps (there are 3) to their new gateway earlier this year.
> But if anyone's needing an authNet account, I have a great person up in the NW who sets them up for me; she's fast, efficient, and great to work with.
> Bob Patin
> Longterm Solutions
> bob at longtermsolutions.com
> iChat: bobpatin
> FileMaker 9, 10 & 11 Certified Developer
> Member of FileMaker Business Alliance and FileMaker TechNet
> Expert FileMaker Consulting
> FileMaker Hosting for all versions of FileMaker
> PHP • Full email services • Free DNS hosting • Colocation • Consulting:
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FX.php_List