Jump to content

Archived

This topic is now archived and is closed to further replies.

twigster

OSCOMMERCE ORDER HACK!!!

Recommended Posts

chooch - you're correct, that is exactly what happens - bollocks..

 

...that was a short lived fix :)

 

Dave what payment module are you using? I currently have Paypal & Secpay installed and both are working fine. In fact I've received over 20 orders since I implemented the change and only 1 rejected.

 

Neil

Share this post


Link to post
Share on other sites

In the new version of the Barclays EPDQ payment module (once you've got it working), although you are directed to checkout_success.php using this hack, no order emails are sent and the order status is still "Awaiting Card Transaction". These things are only updated when EPDQ posts back the order variables when a payment is either approved or declined. I suppose this will still be a problem for download stores though.

 

Trying it with PayPal IPN on my store just took me to PayPal for payment. You can do it with Cheque too, but the order status will still be "Awaiting Cheque" so not much point!

 

Just my 2p.

Share this post


Link to post
Share on other sites
Dave what payment module are you using? I currently have Paypal & Secpay installed and both are working fine. In fact I've received over 20 orders since I implemented the change and only 1 rejected.

 

Neil

Well that should tell you something !

 

Assuming it is very unlikely that the 1 rejected order was from someone trying this very specific hack that is basically only known to us lot using OSC then I would guess that you have blocked a genuine customer from your site.

 

I wouldn't want to turn away every 20th customer! Very bad PR and lost revenue.

 

Rich.

Share this post


Link to post
Share on other sites
Well that should tell you something !

 

Assuming it is very unlikely that the 1 rejected order was from someone trying this very specific hack that is basically only known to us lot using OSC then I would guess that you have blocked a genuine customer from your site.

 

I wouldn't want to turn away every 20th customer! Very bad PR and lost revenue.

 

Ah but that was before I added the Secpay fix. I will wait and see if anymore are rejected.

 

It's called working to find a solution.

Share this post


Link to post
Share on other sites
Ah but that was before I added the Secpay fix. I will wait and see if anymore are rejected.

 

It's called working to find a solution.

 

But this is looking in the wrong direction. Basing a solution on data that is COMPLETELY controlled by an unknown entity (the client or the browser) is not a good solution, and is like saying you can't get shot in the head because you're wearing a bullet proof vest. What happens when I change my referer header to match what you're checking for? What happens if my browser chooses not to send a referer in the header?

 

This solution protects you from my grandmother who doesn't know what an http referer is. It doesn't protect you from any real fraudster or hacker - the person that can do real damage.

 

This really is one of the worst solutions because not only does it not protect you, it also can prevent legitimate, paying customers from getting their products. Even using POST variables is a better solution because you're guaranteed any major browser will always correctly send those. There is nothing that requires browsers send http referer headers, nor is there anything that requires them to send a correct one. Also, firewalls and proxies and all those nifty little privacy-protection and anti-spam applications people sometimes have on their computer can strip out http referer headers.


Contributions

 

Discount Coupon Codes

Donations

Share this post


Link to post
Share on other sites
http://www.oscommerce.com/community/contributions,2280

 

Try this mod instead, it uses payment notification from nochex instead of browser redirect to confirm the payment similar to paypal IPN.

 

Ok then Peeps

 

Sorry for opening this big old can of worms.

 

I have successfully implemented the APC module listed above (Thanks Dave).

 

After messing with my servers configuration you need to have Curl installed with Mod ssl. It adds a feature into the admin tool that only lists payments that have been verified by the Nochex APC backend.

 

I know that PayPal use a similar solution and I'm sure that any other secure payment systems will have an SSL chacking facility for payments.

 

Good Luck

Twig

Share this post


Link to post
Share on other sites

Paypal

 

For the time being at least, I am using the Paypal module, so I know nothing about the other module issues. I have had plenty of experience with Paypal on other projects and in particular, the issues surrounding IPN (Instant Payment Notification).

 

If the Paypal module was written properly, it should pass a variable (the IPN) to Paypal which takes the format of a URL. This URL would then receive a POST request from the Paypal server once a transaction had been completed successfully. The POST information would send back to the shopping site a confirmation with the corresponding transaction or order ID; only once the IPN has been triggered in this way should an order be confirmed.

 

I cannot find reference to an IPN location within OSCommerce - perhaps, at least for the paypal module, this should be the place to look for a genuine and lasting fix.

Share this post


Link to post
Share on other sites
chooch - you're correct, that is exactly what happens - bollocks..

 

...that was a short lived fix :)

LOL! chin up dave, I'm sure we'll get there :-)


Upon receiving fixes and advice, too many people don't bother to post updates informing the forum of how it went. Until of course they need help again on other issues and they come running back!

 

Why receive the information you require in good faith for free, only to then have the attitude to ignore the people who gave it to you?

 

There's no harm in saying, 'Thanks, it worked'. On the contrary, it creates a better atmosphere.

 

CHOOCH

Share this post


Link to post
Share on other sites
so within the action switch in the checkout_confirmation.php I use something like

 

		  $form_action_url = $$payment->form_action_url;
	  header('Location: ' . $form_action_url . $$payment->process_button_string() );

 

To do the redirect. The form_action_url contains the parameters of the form while the process_button_string is set to the gateway specific parameters.

 

Then the payment module itself stores the gateway's parameters to the process. For instance with paypal instead of setting the $HTTP_POST_VARS array I do:

 

	 $process_button_string = '?cmd=_xclick' . 
						   '&business=' . rawurlencode(MODULE_PAYMENT_PAYPAL_ID) . 
						   '&item_name=' . rawurlencode(STORE_NAME) .
						   '&amount=' . rawurlencode(number_format(($order->info['total'] - $order->info['shipping_cost']) * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .
						   '&shipping=' . rawurlencode(number_format($order->info['shipping_cost'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .
						   '&currency_code=' . rawurlencode($my_currency) .
						   '&return=' . rawurlencode(tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL')) .
						   '&cancel_return=' . rawurlencode(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));

 

Now the reason for the form_action_url being also passed is because I process the payment module's extra fields on the confirmation page instead of the payment page. With those extra fields I mean for instance the cc details. Normally you have those fields in the checkout_payment.php but it is not practical if you use multiple cc gateways for instance. Instead what I do is give the customer the radio fields to select the gateway on checkout_payment.php and then on checkout_confirmation.php I extract the fields of the selected gateway. These are the fields used with the form_action_url variable.

 

Now this way I do not expose the cc details anywhere, if I have such a gateway available. Only the final form in transit to the gateway contains the payment details. Since the order is pre-recorded I check the order in checkout_process.php by basically doing a query to the database. If no match is found you redirect to the shopping cart or checkout_payment.php.

 

Also following this approach makes possible for your tip and tricks post - bypass shipping/payment, to bypass the payment and shipping pages with a single click. Because the cc fields are used in the final confirmation page. It is how I also utilize my express checkout.

 

You have given this a lot of thought.

what is your view on using code like the below to issue post/gets without forms in this context ?

would it serve anything or just be a variation not adding to a solution ?

 

function sendToHost($host,$method,$path,$data,$useragent=0,$secure=0)

{

// Supply a default method of GET if the one passed was empty

if (empty($method)) {

$method = 'GET';

}

$method = strtoupper($method);

if ($secure) {

$fp = fsockopen('ssl://'.$host, 443, $errno, $errstr, 30);

} else {

$fp = fsockopen($host, 80, $errno, $errstr, 30);

}

if ($method == 'GET') {

$path .= '?' . $data;

}

fputs($fp, "$method $path HTTP/1.1\r\n");

fputs($fp, "Host: $host\r\n");

fputs($fp,"Content-type: application/x-www-form- urlencoded\r\n");

fputs($fp, "Content-length: " . strlen($data) . "\r\n");

if ($useragent) {

fputs($fp, "User-Agent: MSIE\r\n");

}

fputs($fp, "Connection: close\r\n\r\n");

if ($method == 'POST') {

fputs($fp, $data);

}

 

while (!feof($fp)) {

$buf .= fgets($fp,128);

}

fclose($fp);

return $buf;

}


Treasurer MFC

Share this post


Link to post
Share on other sites

I remember seeing a similar example on php.net and I believe this should work. Basically you open the socket and you post the form with this function. As long as you pre-record the order in someway it should be ok. This is important, in case someone may change a parameter on the gateway end for instance. (or create a fake form and post it) By having the order id as a registered session you can verify whether the transaction was legitimate.

 

And you could even cross-reference with the order status or order amount in the extreme case a the order id is not enough.

Share this post


Link to post
Share on other sites

Neil,

 

I'm currently using epdq version 1.2.

 

I'm going have a crack again at the latest version which we've had some hiccups with until steve sorted it.

 

Cheers

 

Dave

Share this post


Link to post
Share on other sites
I have tested it and can confirm it works Neil. This is the code i have got.

 

The message you get it "A problem has occured whilst processing your payment, the store owner has been notified and should be in contact soon"

 

// load selected payment module

require(DIR_WS_CLASSES . 'payment.php');

$payment_modules = new payment($payment);

 

// load the selected shipping module

require(DIR_WS_CLASSES . 'shipping.php');

$shipping_modules = new shipping($shipping);

 

require(DIR_WS_CLASSES . 'order.php');

$order = new order;

 

//Stop direct access to this file - Added by Neil Westlake (Westhost.co.uk) sales@westhost.co.uk

if (!$HTTP_SERVER_VARS['HTTP_REFERER'] && substr($_ENV['HTTP_USER_AGENT'], 0, strpos($_ENV['HTTP_USER_AGENT'], '/')) != 'Java'){

 

// Send an email as a safe-guard against faliure

$email_message = 'This order failed at the final stage, maybe a checkout hack attempt. The customers name is ' . $order->customer['firstname'] . ' ' . $order->customer['lastname'] .'. There telephone number is ' . $order->customer['telephone'] . ' and email address is ' . $order->customer['email_address'];

tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, 'Order Rejection', $email_message, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);

 

// Redirect the user to the checkout payment page with an error

$error = 'A problem has occured whilst processing your payment, the store owner has been notified and should be in contact soon';

tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode($error), 'SSL'));

exit;

}

 

I have just gone through the code again and can conform i am still having problems with this fix. It appeared to work on a test server i setup however on the live site it would not except the call back from SECPay :( Has anyone else had progress with this problem?


Steve

Share this post


Link to post
Share on other sites

Sorry Steve I'm affraid this fix is dead in the water as it's not 100% guaranteed.

 

I'm still working on a bullet proof fix.

 

Neil

Share this post


Link to post
Share on other sites
It appears to work, it throws them back to order confimation and sends you an email with their disclosed details. It's better than nothing I suppose ;)

Sorry, No it doesn't work. It tells a genuine sale that there is a problem and doesn't process the order. :blush:

Share this post


Link to post
Share on other sites

Why not just write a flag into the session data when the payment has been completed and then check for this on the confirmation / completion page ?

 

This could be done generallly and very easily by the checkout_process bit that completes the payment transaction.

 

Rich.

Share this post


Link to post
Share on other sites
Why not just write a flag into the session data when the payment has been completed and then check for this on the confirmation / completion page ?

 

This works for payment types that do not lead to external sites. The problem is the process for external payment sites normally goes

 

checkout_confirmation -> external_site -> checkout_process

 

By manually typing checkout_process in the URL on the checkout_confirmation page, you skip the external site, but you haven't skipped any pages that can set session variables.

 

I agree if there is no external site involved in the process (from the client's point of view) session variables are absolutely the way to go.


Contributions

 

Discount Coupon Codes

Donations

Share this post


Link to post
Share on other sites
This works for payment types that do not lead to external sites. The problem is the process for external payment sites normally goes

 

checkout_confirmation -> external_site -> checkout_process

 

By manually typing checkout_process in the URL on the checkout_confirmation page, you skip the external site, but you haven't skipped any pages that can set session variables.

 

I agree if there is no external site involved in the process (from the client's point of view) session variables are absolutely the way to go.

 

it can work with external sites if your session binds to the order parameters in some way. And you can pre-record the order either by a contribution like logging orders or directly into the orders table. Upon return you check chek the session verifying the authenticity of the transaction. Because if the session is lost the checkout process will redirect you to the login page anyways.

Share this post


Link to post
Share on other sites

What about confirmation numbers? Can we get order confirmation numbers that will appear once payment is successful on the successpage? Isn't there a way to breadcrumb the route of a person's visit? I know that only has to do with navigation but maybe a code that creates a confirmation number only for visitors who are redirected. There should be a confirmation number or order tracking number that is automatically created once payment is received like for shipping purposes even. I'm sure one of the many genius programmers on here could come up with a script for that. The people on this forum are highly talented---unlike me, I am a total dummy when it comes to php and mysql.

Share this post


Link to post
Share on other sites
Has anyone had any luck with the fix westhost sent out?

 

Locate the following lines of code:

// load selected payment module

require(DIR_WS_CLASSES . 'payment.php');

$payment_modules = new payment($payment);

// load the selected shipping module

require(DIR_WS_CLASSES . 'shipping.php');

$shipping_modules = new shipping($shipping);

require(DIR_WS_CLASSES . 'order.php');

$order = new order;

and insert the following straight after:

//Stop direct access to this file - Added by Neil Westlake (Westhost.co.uk) sales@westhost.co.uk

if (!$HTTP_SERVER_VARS['HTTP_REFERER']){

// Send an email as a safe-guard against faliure

$email_message = 'This order failed at the final stage, maybe a checkout hack attempt. The customers name is ' . $order->customer['firstname'] . ' ' . $order->customer['lastname'] .'. There telephone number is ' . $order->customer['telephone'] . ' and email address is ' . $order->customer['email_address'];

tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, 'Order Rejection', $email_message, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);

// Redirect the user to the checkout payment page with an error

$error = 'A problem has occured whilst processing your payment, the store owner has been notified and should be in contact soon';

tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode($error), 'SSL'));

exit;

}

Now when a customer tries to go directly to the checkout_process.php file they will be immediately thrown back to the checkout payments page and you will be notified of there details.

If you have any problems implementing these changes, or experience problems please email support@westhost.co.uk

 

Now which page are you refering to and in which directory?

 

I just join this topic...

Share this post


Link to post
Share on other sites

Does the latest update address this security flaw, or is this still a problem?


Stuart

Share this post


Link to post
Share on other sites

I read a recommendation of setting a "process_step" at the end of each purchase step and verifying it at the beginning of the next. I haven't tried it yet. Does anyone know if this will work?


Just between us, remember there are only 10 kinds of people in the world; those who understand binary and those who don't!!

 

Remember, learning is a "do-it-yourself" experience; although, not necessarily a "do-it-BY-yourself" experience.

 

The quickest way to learn is to forget to BACKUP!

Share this post


Link to post
Share on other sites
I read a recommendation of setting a "process_step" at the end of each purchase step and verifying it at the beginning of the next. I haven't tried it yet. Does anyone know if this will work?

 

This thread discusses the use of that as a session variable. As a form variable, it's not very useful because it's VERY EASILY circumvented by anyone who can read and edit HTML code. It's further complicated when considering external payment processors like Paypal.


Contributions

 

Discount Coupon Codes

Donations

Share this post


Link to post
Share on other sites

everyone thinks paypal is safe but ive just been hacked with it so what can we do to stop this as something needs to be done or else i wont be using oscommerce as you can be hacked to easily

Share this post


Link to post
Share on other sites

I am quite sure the only right way to solve issues like this is using (ssl) certificates (like twigster already mentioned some posts back). All other checks and hacks are not 100% safe, and a waist of time, tmho :-)

 

The payment provider needs to support this certificate check of course, since only the provider can confirm if the payment really has been completed.

 

hth

 

edit:

everyone thinks paypal is safe
I am not a Paypal expert, but a s far as I know Paypal support those certificate checks. So if the module you are using use also supports (and uses) it, it should be safe.

Please do not PM me for support, I will not respond anyway.

Share this post


Link to post
Share on other sites

×