Credit card security problem

zoobie

I'm using a single purchase button on my site. The problem is, when you view the souce code, you can see the "thankyou.php" page. Because the user comes back from credit card processing and clicks a button on this page, anyone can bypass the credit card processing (in this case Paypal), type mysite.com/me/thankyou.php in the address bar and click on the button.

I don't want to ask the user for their email, send a username/password, and have them come back. I just want to secure my thankyou.php page somehow without using javascript.

Unfortunately, $_SERVER['HTTP_REFERER'] doesn't work in this case. Neither does another directory.

I've been at this for a long time and still don't know how to do it.

Suggestions/solutions?

Thanks :p

stuartc1

Whats so special about the thankyou page ?
Do you not send a verification email to the users anyway ?, if so you could add the link there.

MrAlaska

I assume the button is a submit button and thankyou.php processes the form elements before displaying the thank you message. I would split up the page with an if/else. First have an 'if' statement that checks for the elements required and process the form, then an 'else' statement that includes the form submission page if the elements are not present.

I guess I am confused exactly where they are seeing the name of thankyou.php. Is it part of the URL so PayPal knows where to return them to? In that case, setting a temporary cookie might be an option. Or another option would be to send them to an intermediate PHP page instead of directly to PayPal, and let that page send them to PayPal with the proper information.

zoobie

Yes...The button's code contains the thankyou.php URL so Paypal knows where to send them after processing. What's so special about the thankyou.php page is that it contains a final button they click.

How would the intermediate page work without javascript?

Thanks :rolleyes:

MrAlaska

Originally posted by zoobie How would the intermediate page work without javascript?[/B]

The intermediate page would be a small PHP page that prints out nothing. You would send them to that page instead of PayPal, then it would collect the same variables you are sending to PayPal, then build the URL and redirect them to PayPal using the header() function.

That would take care of hiding the final URL from the source of your purchase page, but security is still compromised if people are able to do something from a page they shouldn't be at.

On another note, you are aware of PayPal issues? I understand why people need to offer them at times, but after I suffered a PayPal burn I found the site http://paypalsucks.com and feel obligated to spread the word.

zoobie

Ok..So, how do I collect the button vars in the blank page? I know about the header("Location: URL") bit...

An example would be great.

Thanks

MrAlaska

The button sending the page to PayPal is in a form (I presume)

It is difficult to be specific without actuall knowing the names of your variables that you are passing to PayPal, but the URL would be built something like this:

$URL="http://paypal.com?return=thankyou.php&product=$product&cust=$cust";

The version of PHP I am working on will automatically turn form inputs into variables. From what I have seen in threads here, there seems to be a newer way to collect form inputs and explicitly assign them to $variable names. Someone else will hafta address that aspect.

EDIT: Now that I think about it, though, they will still be able to go directly to your thankyou page without filling in the forms at PayPal. Even if you send them there on a POST, PayPal probaly puts the redirect into a field the users can view on the source from there. You still need to explicitly protect your thankyou page.

Does PayPal return a confirmation or something when they return the user?

zoobie

--Does PayPal return a confirmation or something when they return the user?--

Yep...They send them an email with confirmation of purchase.

Then, they just send them to the thankyou.php page per my button request...

Like I said...This is a complex question that has gone unanswered for weeks.

Thanks

jdesilva

still struggling with this problem zoobie? 🙂

just curious, why didn't the HTTP_REFERER idea not work? What if u did that and use sessions as well?

MrAlaska

I meant if PayPal returned them to your site with any way to identify the user and a way to determine if they submitted the proper information at PayPal.

Your challenge seems to be one of maintaining state. You can maintain state as far as identifying the user with a cookie or sessions, but you need some way to determine if they passed the credit check at PayPal. Then on your thankyou page you would then be able to check against whatever PayPal returned and have the page parse accordingly. It is tricky enough on one server, but the problems magnify when you have two servers involved.

This can't be a new problem, it would seem it would be a common problem and something that should be documented somewhere in the instructions for using PayPal as a vendor.

Sorry I can't be more help, I haven't dealt with third party CC validation... yet...

You MIGHT be able to find more help at the http://webhostingtalk.com/ forums, there are a lot of people who chat there that have dealt with third party vendors quite a bit.

zoobie

JdS - Yep...Still struggling. Nobody knows why the $_SERVER['HTTP_REFERER'] doesn't work and I'm already using sessions to hold the data while they return from Paypal. I went to the DevShed forum and they got all mad at me for stumping them. I guess I humbled them.

MrAlaska - --This can't be a new problem, it would seem it would be a common problem and something that should be documented somewhere in the instructions for using PayPal as a vendor. --

Yep...They recommend using IPN (Instant Payment Notification) which sends the buyer an email with username and password to return to my site. Problem is, I don't want to use this method.

Someone mentioned using $_POST['button']; but I have no idea how this would work since nobody likes to use examples...

tasistro

zoobie:

I had the same exact problem in our site. If I understand you well, you have a page with the payment data which is submited to Paypal. Then Paypal redirects the user back to the thank you page where he is supposed to press the submit button and finish off the sale. Right? The thankyou page gets the return values from the bank. Right? The ones you need to log.

We had a similar system which was prone to cracking due to file edits and a great deal of repost which resulted in double charges. The solution was to use CURL or curl lib under php. We post our data server to server via curl to the "Paypal" page and obviously get the return values from the bank via CURL (not the client) . All the process is done in the backstage and the user does not intervene.

Saludos
Gerardo

mattuu

I was looking over this. I haven't done anything where people buy something via paypal and get bounced back, so I haven't faced this. It isn't really "safe" to rely on the safety of a secret url in any event. Someone could buy one item, then return to buy several more and bypass paypal each time after. The only way to rely on them having paid via paypal is if paypal tells you somehow. If I were paypal, I'd make it so you could submit a pair of hashes to them first, and then direct people to them with one of the hashes given to the user. When they paid, paypal would send them back to you with the second hash, and to them it would be transparent, but it would be paypal's way of confirming them.

That said, I'd bet paypal does no such thing 🙂 Even a Location: header is insufficient, btw, since that can be intercepted as easily as the source can. In places where I've had people taking paypal, they have to 'approve' an order before whatever it is is shipped.

I'd be happy to help more, but you'll have to provide more details on the process.

MrAlaska

If that were the only solution offered by PayPal, you just may be stuck with writing a thankyou page that instructs them to sit tight and wait for the email, which is not the most elegant solution. I have never heard of CURL mentioned in the other post, but that sounds like an alternative way to talk to PayPal while maintaining state with the user.

I am not familiar with working with HTTP_REFERER, but it is possible the problem is also related to PayPal. Their validation URLs might be of a dynamic nature, possibly even using different domains. Even if they have a static URL that sends the user back, I would still be leary of trusting information that is out of my control.

Using $_post[button] would still do nothing to verify the user has jumped through all the proper hoops at PayPal.

zoobie

tasistro - Just about...I looked at cURL...It's built-in to PHP versions 4.01 and higher. Problem is, I have no idea what it is or how it would work in my situation.

dannys

cURL isn't compiled into PHP by default - you must add --with-curl=/path/to/curl when you compile PHP.

However, PHP4.3.0 will allow fopen() to open ssl connections too, negating the need for curl entirely. The downside is that you need OpenSSL compiled into PHP - which, again, isn't compiled in by default - though the openssl installation is much more likely to exist on the server than a curl installation (from what i've seen anyway).

Just don't expect to be able to use either of these methods on every server.

zoobie

So, how do I get cURL to perform what I want?

Need examples...:rolleyes:

mattuu

Curl let's you connect to another page and send and receive whatever you like, basically. Here's a piece of code showing curl at work:


            $ch = curl_init(); // init cURL handle -- your php must be compiled --with-curl[=DIR]
            curl_setopt($ch, CURLOPT_POST, 1); // we are posting data
            curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); // follow redirects
            //$opt = 2; settype($opt, "integer");
            //curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, $opt); //match SSL cert vs hostname
            curl_setopt($ch, CURLOPT_URL, "https://secure.iongate.com/iongate.asp");
            curl_setopt($ch, CURLOPT_USERPWD, $globaldata["iongatelogin"] . ":" . $globaldata["iongatepwd"]);
            curl_setopt($ch, CURLOPT_POSTFIELDS, $poststring);

            curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)");

            ob_start(); // turn on output buffering, because we don't want the results
                        // going to a user browser
            if (!curl_exec($ch)) {
                    global $response;
                    $response = ob_get_contents();
                    error_log($response);
                    ob_end_clean();
                    print curl_error($ch);
                    error_log("transcation->ccpay: curl_exec() returned error");
                    return 0;
            }
            $response = ob_get_contents();
            error_log($response);
            ob_end_clean();
            curl_close($ch);

That's actually a bit of code connecting to a credit card processor to authorize a payment. The $poststring variable is already set at the start of that block -- it read stuff like ccnum=1234123412341234&ordernumber=100, etc. When this block of code is done, everything their web server put out in response is in the $response string.

zoobie

I don't think this this is gonna work. First of all, I don't have SSL for the user to feel secure. Secondly, submitting to Paypal via my server and "remote control" would require quite a bit of work.

What I've decided to try is to, indeed, have an intermediate page after the Paypal button page which registers a session variable then proceeds to Paypal. This way, should he come to the Paypal button and try to shortcut to thankyou.php via the sourcew code, he gets validated for his session variable and if missing, redirected elsewhere.

A few problems with this...How do I disable going back once the session variable is registered via the intermediate page to the Paypal button page then shortcutting to thankyou.php?

Thanks :p

tasistro

Ok, I don't have curl compiled into php or ssl for that matter. I do have curl accesible through the command line so I do something like this:

$postparams="creditcard=2345232623452&amount=34&...etc....";

$targeturl = '%path to curl%/curl -u %myusername%:%mypassword% -d "'.$postparams.'" [url]https://%my[/url] page page here%';

$output = $targeturl;

Basically I ask the user for all the cc info and generate a string called postparams. Postparams holds all the info that would have otherwise been posted by the user on our infamous paypage. Targeturl is then built. Targeturl is actually a command line instruction to run curl with a login which our account requires for payment processes, the parameters to be sent to the paypage via post method (the previously mentioned $postparams) and finally the url (aka, our infamous pay page).

$output then equals the return values of executing the command $targeturl by use of back tics. $output is parsed for the return values which would have otherwise been sent to the thankyou page.

This is kind of makeshift since most of it was done around two years ago and all the fancy ssl things in php and file() where not there yet. It was easier and less impacting to our operation to use the command line that recompile php to include new modules. Obviously if you can do it all through php so much the better.

Hope it helps.

BTW this method is great for locking the user from multiple posts.

1)Their data is sent to you through a form. And you can write it to a session or dbase.
2)You confirm their intention to accept the charges through another page and an accept button (this step can actually be skipped depending on your policies).
3)Once your user accepts 1 or 2 you set a flag indicating that the user accepted the charge and then init the curl process. With that flag set the user can reload the page and resubmit as many times as he wants. You just ignore it until you get a response from the bank.
4)Most important the user submits the payment form to you and not the bank so you know if they actually accepted the charge. Besides altering the page the user could claim that he pressed the button, but you can't be sure yourself. Did the bank time out on the process, is it down, is their DNS out... etc. With this curl process you know exactly what is going on.

Saludos
Gerardo