financial transaction form - need advice!

sneakyimp

hi all:

I really apologize for such a long post, but I'm anxious to make sure I keep this financial transaction secure.

i am working on a multi-page purchase form which will collect eCheck or credit card info to accept user payments. I am PARANOID about security here and could would like to get the complete lowdown on where my security vulnerabilities might lie and how i might shore them up. My site will collect the credit card number but will not store it in any database for future use. Questions are inline.

My form has 4 pages total. 3 of them have variations depending on what they buy and how they pay (Card or Echeck)

GENERAL INFO
Session handling...
I borrowed my session handling technique from phpBB. Session ID is stored in a cookie (if they are enabled) and passed via the URL by appending the SID to links within a page. Even if cookies are enabled, you typically see the SID in at least one URL for any given visit to the site. This is because when you visit the first page, the session ID has not yet been stored in the cookie and the codebase assumes that you'll need to propagate the SID via URL.
Certificate
I had my certificate issued to www.mydomain.com and when i visit https://mydomain.com, i get a warning that the cert doesn't match the site. when i go to https://www.mydomain.com, it works fine.

QUESTION 0:
Should I try to get my cert adjusted so that it refers to just mydomain.com? will that still work for www.mydomain.com?

QUESTION 1:
Given the way that I will handle sensitive data (see below) does this way of handling session ids and session data present any risk? I don't store any sensitive information in session at any time.

PAGE 1: WHAT TO BUY
This form determines what the user would like to purchase. There is no critical information gathered yet about this user. When the form gets submitted, their selection is stored in $_SESSION['some_var_name'] and the user gets forwarded to page 2.

QUESTION 2: Since no critical information is gathered on this page, is it fair to assume that it doesn't introduce any risk? If it does produce risk, how can I shore it up?

PAGE 2: ADDRESS INFO AND METHOD OF PAYMENT
This form is the same regardless of which selection the user is purchasing. It assumes that Page 1 has been completed so that we know what the user is purchasing. It gathers address information (which WILL be stored for each user) and asks the user to specify echeck or credit card. When the user submits this form, I may or may not save any information to the user table.

QUESTION 3: same as question 2 but for this form. I am guessing that this page does not introduce any significant risk.

PAGE 3: !!! CRITICAL PAYMENT INFORMATION !!!
This page is the one I'm really concerned about. This is where we ask the user to enter their credit card information. Obviously, I plan to make sure that this page (and the other 3 pages) are always served securely (HTTPS). When the user enters their information, this page will submit to itself so that errors can be reported easily. A submssion will result in the following actions
a) credit card information is validated...type must be valid, there must be 16 digits, the expiration date must be in the future.
b) if that checks out, a transaction is initiated to our payment gateway. I've written some code to handle this process that uses cURL to query the payment gateway and get a response. the response will determine which page gets displayed next.
c) the user will be forwarded to the appropriate page based on the gateway reponse.
The gateway interface has security features such as a timestamp and secret hash value, but i'm a bit concerned about where the credit card/echeck data might reside on our machine.

QUESTION 4: In the form on this page, do I need to specify HTTPS and the ENTIRE url in the action attribute or is it sufficient to use $_SERVER['PHP_SELF']? How can I ensure that HTTPS is used?

QUESTION 5: I expect to put the payment gateway code in a subroutine does this present any additional risk?

QUESTION 6: What kind of validation should I do on the critical information? Is there any kind of validation I can do to make sure abuse of this routine doesn't result in money being stolen from our merchant account?

QUESTION 7: Given that a form has been submitted to our server, will the credit card and/or echeck information live in memory or on disk anywhere where a hacker might somehow find it? I will NOT put this info in SESSION, I will NOT store it in a database, it will ONLY be used to initiate a CURL query and then it will be forgotten. Should I explicitly UNSET the values before my script ends?

QUESTION 8: when i do curl_init(), is specifying an HTTPS connection sufficient to ensure that the transaction is encrypted, or are there additional steps I should take to ensure a secure connection to the payment gateway?

QUESTION 9: Do echecks present any additional risk? i have yet to read the payment gateway guide regarding echecks but the form i see requires Bank Name, Account Holder, Routing Number, Account Number, and Check Number. I've heard of scams used by folks that involve echecks...don't recall what the specific risks are.

Any advice would be much appreciated.

kburger

I'm only going to tackle your first question.

>>>QUESTION 0:
Should I try to get my cert adjusted so that it refers to just mydomain.com? will that still work for www.mydomain.com?

No matter which one you use to write your certificate, either www.mydomain.com or mydomain.com, if a user accesses your site with the other one the browser is going to give a warning. There's nothing you can do about that. Obviously, you can redirect to the other one but by that point your server and the user's browswer have already communicated and the warning has been issued (depending upon the settings of the user's browser).

My advice would be to write your certificate as www.mydomain.com and don't worry about it. To answer your question -- yes, it will work but with a warning message. That's just the nature of SSL. There's nothing you can do about it.

Anybody else want to chime in and correct me?

sneakyimp

Thanks Kburger.

I suppose the other questions might be pretty complex. At the moment, I'm really concerned about eCheck fraud. I read some article that described a way that people can forge checks from your account once they've paid you with an echeck. I'm trying to track that down now.

sneakyimp

these links kind of relate to question 9:

this link suggests that someone armed with a bank routing number and account number can forge checks. given that i don't expect anyone to have out bank routing number or account number, I don't think this suggests any greater risk--most of these horror stories are ID 1O T errors:
http://www.msnbc.msn.com/id/7914159/page/2/

This page is more helpful in that it describes liability for echecks, but it doesn't really answer my question:
http://www.bankersonline.com/vendor_guru/pps/pps_op041105a.html

cyberlew15

Hiya I was just wondering if you could implement a worldpay or paypal gateway that way you do not need to worry about e-check fraud. Also I beleive that Worldpay do a payment portal system for an extra $100 per month which means that you could have their full worldpay API without the users exiting from your website. this would iron out any of your security worries scince you are not storing client financial information in a database.

sneakyimp

I have no plans to store financial data in a database. I wrote that in the post, but the post is really long so it's easy to miss.

Also, the client has already contracted with a reputable payment gateway. There's no need to store any financial data, but it does need to pass through my script and my script will contact their servers for transaction validation.

The more I think about it, the more I think that the transaction data never gets into the session data, so I'm beginning to think the session handling in no way jeopardizes the financial data because it never gets stored--in session or DB.

cyberlew15

sneakyimp wrote:
I have no plans to store financial data in a database. I wrote that in the post, but the post is really long so it's easy to miss.

Also, the client has already contracted with a reputable payment gateway. There's no need to store any financial data, but it does need to pass through my script and my script will contact their servers for transaction validation.

The more I think about it, the more I think that the transaction data never gets into the session data, so I'm beginning to think the session handling in no way jeopardizes the financial data because it never gets stored--in session or DB.

possibly you mis-read my post I acknowledged that you do not wish to store financial data

sneakyimp

yes i misread it. the gateway we are using has a pretty full-featured API that allows several different approaches. the one i plan to use means that the user will enter their cc/echeck info into OUR form (which will be served HTTPS) and processing will be done on the backend. the payment gateway company is quite reputable.

for QUESTION 1, i do not at any time store sensitive information in SESSION, database, or cookie. That encourages me to think that my session handling technique will have no bearing on the security of the site. Even if someone were to somehow get hold of the session id and come to the site quick enough to capitalize on it before the session expired, they would be unable to find sensitive data stored anywhere in a temporary session file, in SESSION var, database, etc. I might echo the user's credit card number back to them if there is an error, but this CC number would only exist in the _POST vars or in the ether between the user's client and the server. Since the page will be hosted HTTPS i don't think this presents any risk.

For questions 2 and 3, i'm guessing these pages present no risk whatsoever. they don't gather sensitive data, they don't propagate it.

For QUESTION 4, I'm still not certain what to do. I think that I will put code in the pages that gather the sensitive data which check to see if the protocol is HTTPS and, if not, will throw a fatal error if POST data is received. If not POST data is sent, the page will redirect to itself only with HTTPS to ensure that the user has a secure connection.

More as I make it up. It sure would be nice to have some really experienced input on this 🙁