Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Fake orders from www.shieldtrust.com


Scubaroo

Recommended Posts

not sure about that cloaking, renaming is of course possible.

 

With your setup, I'd try the VVC ...

banktransfer is no issue, payflowlink can take a parameter to return as can paypal ...

at what point you will deploy the vvc? On the checkout confirmation page? Because the field will be visible through the form if you're planning to pass it to the gateway. So you already register a vvc session and then you display the form which has some vvc variable binded. Again they can copy it and pass it with a fake form.

Link to comment
Share on other sites

  • Replies 62
  • Created
  • Last Reply
at what point you will deploy the vvc? On the checkout confirmation page? Because the field will be visible through the form if you're planning to pass it to the gateway. So you already register a vvc session and then you display the form which has some vvc variable binded. Again they can copy it and pass it with a fake form.

 

yeah I have not tried it, but thought the spot right above the submit button could do it.

:-)

Monika

 

addicted to writing code ... can't get enough of databases either, LOL!

 

my toolbox: Textpad - Compare and Merge - phpMyAdmin - WS_FTP - Photoshop - How to search the forum

 

Interactive Media Award July 2007 ~ category E-Commerce

my advice on the forum is for free, PMs where you send me work are considered consultation which I charge for ...

Link to comment
Share on other sites

yeah I have not tried it, but thought the spot right above the submit button could do it.

well unfortunately anything that is posted from the global arrays can be manipulated. The approach I have and at least you cannot fool the cart on the osc end is by altering the entire checkout process. I had to deploy sessions at the beginning of the checkout process to monitor the steps the customer takes to reach the confirmation page. I also had to change all the payment modules in use so all fields are posted once in the final confirmation with the form itself calling the checkout_confirmation.php not the gateway or jumping to checkout_process.php. Then at that point I validate all arguments and then redirect to the gateway or to the payment/shipping page with an error.

 

Despite all this you can still create a form and post it directly to the gateway with all kinds of false info. From my end I can surely tell if the customer used the checkout procedure or not as all orders are pre-recorded and so the checkout_process.php will always abort if something is wrong. However if there is no protocol in place between the store and the gateway to avoid injections you will always have to go and confirm with the gateways cpanel.

 

For the internal payment modules same thing. Once the final submit button is pressed I validate all fields and set the appropriate sessions values in order to get through the checkout_process.php But all my forms are posted internally to the store scripts for validation. When using forms that call the external gateways becomes very easy to manipulate.

Link to comment
Share on other sites

IMO your wasting your time trying to come up with a global way of securing the payment modules without a lot of re-working of the checkout process.

 

If you want to fix this problem look at the payment modules themselves and fix it on a per module basis.

Link to comment
Share on other sites

  • 1 year later...

is this checkout_process.php bug now fixed??? i tryed jack's code, but it does not seem to work.

 

When i confirm my order, go to paypal, click on go back in my browser, then en in URL manualy www.myurl.com/checkout_process.php, it still makes fake orders !!!

 

I don't understand that there is still nog fix for this, we are already in 2007 you know.

 

 

Hop someone can give me a proper solution.

 

Thanks

Link to comment
Share on other sites

  • 2 weeks later...

I was reading the topic and I am like ... WOW

 

This is scary. I am thinking that ONCE I finish trying to install the oscommerce software that I am going to implement safe guards procedures for my customers. Safeguards as in .... two step payment processing.

 

Step I

All new customers will set up an account along with email ISP address verification/confirmation.

We have a call center where we randomly call new accounts

 

Step II

We will send customers via fax | email a 48 hour invoice with an approval signature to finalize orders.

 

Reading the topic .... now I know this is how we will handle this issue.

 

This is a serious bug ... hopefully it has been resolved.

 

We are developers and it is important to be biz owners as well.

 

~ Peaches ~ *

Link to comment
Share on other sites

I am only familiar with authorize.net payment module, but the default OSC codes should not allow someone to reach checkout_process.php without going to checkout_confirmation.php as the payment session variable would not have been set. Therefore, if one is experiencing the problem in this thread then you should pay closer attention to the payment module that you are using. Perhaps your payment module doesn't have the feature to detect "bounced checks," so in that case it really isn't a bug but rather a case of limited capabilities.

 

Further, as OSC is really only an online ordering system so it should not decide when an order can be shipped within the business process. I recommend my clients to use their AR in their accounting system to decide when it is okay to ship an order. For instance, they only ship an order after its invoice has been closed (full payment posted).

 

Lastly, calling suspicious customers is always a good idea (or better yet calling VISA International and etc.) as this is when most fraudulence orders with valid credit card numbers and AVS match were caught.

 

Tim

Link to comment
Share on other sites

I am only familiar with authorize.net payment module, but the default OSC codes should not allow someone to reach checkout_process.php without going to checkout_confirmation.php as the payment session variable would not have been set. Therefore, if one is experiencing the problem in this thread then you should pay closer attention to the payment module that you are using. Perhaps your payment module doesn't have the feature to detect "bounced checks," so in that case it really isn't a bug but rather a case of limited capabilities.
You've missed the point. The problem is in the code. Try it yourself. The problem is present with authorize.net too.

 

Jack

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

Perhaps I did...we also have CCGV installed but for sure when it was the "stock" (default OSC + default contributions) checkout process authorize.net didn't encounter this problem for us (it was heavily tested). The checkout process that we use now is so far apart from the "stock" version so it probably doesn't make a good comparison case anymore. We probably spent at least a good ole 1.5 month to do a code walk through and reworked the checkout process with CCGV (that was the winner).

 

Well, I was hoping that my comments would be of useful.

 

Tim

 

 

You've missed the point. The problem is in the code. Try it yourself. The problem is present with authorize.net too.

 

Jack

Link to comment
Share on other sites

Did you try placing an order and using the trick posted here? If yours does not fail, it may help others to post your code to see why yours works.

 

Jack

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

Yes, that has been tested. The original codes that we used was from the stock OSC + CCGV + authorize.net contributions so one should be able to download them and review why the checkout process didn't encounter the error as posted in the thread. However, I suspect that those who are experiencing this issue also offer more than just authorize.net as the checkout method.

 

Per my comment earlier again the checkout_process.php should not allow an order to go through without first reaching checkout_confirmation.php and the bug is more than likely within a payment module.

 

Best of luck...

 

Tim

 

Did you try placing an order and using the trick posted here? If yours does not fail, it may help others to post your code to see why yours works.

 

Jack

Link to comment
Share on other sites

Can't make any promise but if you would send me your production copies of the checkout_shipping.php, checkout_payment.php, checkout_confirmation.php and checkout_process.php (probably need more than these four, the payment and order and authorize.net and ot_gv and ot_coupon classes could eventually be useful too). I would take a look at them in my spare time and perhaps it is something simple without requiring testing...Tim

 

I guess you are lucky then. I use those contributions and it fails on mine and on any shop I've ever tested it on.

 

Jack

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...