Jump to content

Archived

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

twigster

OSCOMMERCE ORDER HACK!!!

Recommended Posts

is it not possible to set a transaction code in a transaction table at the top of confirmation when confirm is selected and have checkout_process check for that entry and remove it if present and refuse execution if it is not ?

I'm pretty sure it is... I was actually pointed to an oscommerce made store that had a fix in it... when the hack was attempted it just wouldn't let it happen - I have to try to find the site again and maybe try contacting the owner to ask advice. It's probably something simple but it definately needs a fix


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
You need to re-read my previous post and note where and when to type checkout_process.php regardless of the payment module used

 

This is not the case, if you use HSBC secure e-payments and go directly to checkout_process.php you are sent to the HSBC site for payment details. Your order is not processed.

 

Neil Westlake

Share this post


Link to post
Share on other sites
I'm pretty sure it is... I was actually pointed to an oscommerce made store that had a fix in it... when the hack was attempted it just wouldn't let it happen - I have to try to find the site again and maybe try contacting the owner to ask advice. It's probably something simple but it definately needs a fix

 

I personally use this in the confirmation form:

 

echo tep_draw_hidden_field('confirm',1);

 

 

and this in checkout_process:

 

if (!$_POST['confirm']) {

tep_redirect(tep_href_link(FILENAME_CHECKOUT_CONFIRMATION, '', 'SSL'));

}

 

but that is purely for internal so that process is only executed via the confirm button and not url creative editing, when the form goes external that field will not work anymore.

So maybe do a check on fields which are in the back posting if the payment gateway.


Treasurer MFC

Share this post


Link to post
Share on other sites

Hi this hack doesn't work on HSBC stores as the hsbc module sends a code to HSBC and returns a different one if the checkout is a success, if not you return to the shopping cart.

 

Elegant, BUT no other payment gateway does this as it is not poss to send extra variables to the payment gate way and have them return a confirmation value. Hsbc allows for this.

 

I am amazed this has not been resolved years ago, flabbergasted that no-one has found a solution and amazed still further that we are all not bitching about it daily.

 

If I hadn't come here today to the forum for another issue I would be non the wiser!!!

 

I am hoping I will have this sorted today...

 

Ian

Share this post


Link to post
Share on other sites

Is it not possible to put the referrer into a if else clause? So if the user went direct to checkout_process.php they would be re-directed to another page.

 

Even if that meant adding an additional page before checkout_process.php, like order_processing.php so the referrer would have to come from there.

 

I don't have a live store yet so I am stabbing in the dark.

Share this post


Link to post
Share on other sites

Peter,

 

Not a bad idea but the call to checkout_process.php doesn't always originate from the same place.

 

Neil

Share this post


Link to post
Share on other sites
Is it not possible to put the referrer into a if else clause? So if the user went direct to checkout_process.php they would be re-directed to another page.

 

Even if that meant adding an additional page before checkout_process.php, like order_processing.php so the referrer would have to come from there.

 

I don't have a live store yet so I am stabbing in the dark.

 

referer cannot close this as it can be empty and if not, it can be anything.

It can only be closed via a post variable from checkout_confirmation (internal) or the gateway (external) back to checkout_process or via a reference number stored first, past to and returned by the gateway and verified by checkout_process.


Treasurer MFC

Share this post


Link to post
Share on other sites
referer cannot close this as it can be empty and if not, it can be anything.

It can only be closed via a post variable from checkout_confirmation (internal) or the gateway (external) back to checkout_process or via a reference number stored first, past to and returned by the gateway and verified by checkout_process.

 

Posting some extra variables won't do anything. It's very easy to check it at the php level. before headers are sent and redirect to the gateway (or module) at the beginning of the script. In other words like the create account or login scripts do. Just set a session var and checkit.

 

because things like

echo tep_draw_hidden_field('confirm',1);

 

are always visible with the form at the html level and can be manipulated.

 

I am amazed this has not been resolved years ago, flabbergasted that no-one has found a solution and amazed still further that we are all not bitching about it daily.

It's being discussed and several alternatives were provided if you check the forum.

Share this post


Link to post
Share on other sites
and can be manipulated

 

you are getting a little vague here.


Treasurer MFC

Share this post


Link to post
Share on other sites
you are getting a little vague here.

 

I agree a POSTed value is pretty much worthless. This can stop someone playing around, but will never stop someone who knows what they're doing.

 

There's nothing stopping me from looking at the HTML source of your shopping cart to determine what hidden variables I need to pass along. If someone is using a payment type that doesn't leave your site (COD) you can set session variables to verify they have followed the correct steps. This would be far more secure than POST variables, which your cart sends to a customer in plain text, and which they send back in plain text. A session variable is never seen by the customer, and so cannot be modified by him or her.

 

If someone is using an external payment processor, the best way is to have the transaction between you and the payment processor happen separately from what the customer is doing. Like Paypal IPN. An order is not confirmed for you until the payment processor notifies you.

 

A POST variable from the payment processor will help but that still allows someone to make one legitimate order to discover how to bypass your payment.


Contributions

 

Discount Coupon Codes

Donations

Share this post


Link to post
Share on other sites
I agree a POSTed value is pretty much worthless. This can stop someone playing around, but will never stop someone who knows what they're doing.

 

There's nothing stopping me from looking at the HTML source of your shopping cart to determine what hidden variables I need to pass along. If someone is using a payment type that doesn't leave your site (COD) you can set session variables to verify they have followed the correct steps. This would be far more secure than POST variables, which your cart sends to a customer in plain text, and which they send back in plain text. A session variable is never seen by the customer, and so cannot be modified by him or her.

 

If someone is using an external payment processor, the best way is to have the transaction between you and the payment processor happen separately from what the customer is doing. Like Paypal IPN. An order is not confirmed for you until the payment processor notifies you.

 

A POST variable from the payment processor will help but that still allows someone to make one legitimate order to discover how to bypass your payment.


Treasurer MFC

Share this post


Link to post
Share on other sites
I agree a POSTed value is pretty much worthless. This can stop someone playing around, but will never stop someone who knows what they're doing.

 

There's nothing stopping me from looking at the HTML source of your shopping cart to determine what hidden variables I need to pass along. If someone is using a payment type that doesn't leave your site (COD) you can set session variables to verify they have followed the correct steps. This would be far more secure than POST variables, which your cart sends to a customer in plain text, and which they send back in plain text. A session variable is never seen by the customer, and so cannot be modified by him or her.

 

If someone is using an external payment processor, the best way is to have the transaction between you and the payment processor happen separately from what the customer is doing. Like Paypal IPN. An order is not confirmed for you until the payment processor notifies you.

 

A POST variable from the payment processor will help but that still allows someone to make one legitimate order to discover how to bypass your payment.

 

You actually believe that someone ordering COD will try to mess with POST variables?


Treasurer MFC

Share this post


Link to post
Share on other sites

so here is where your hidden confirm variable will end up. (HTML generated)

 

			<td align="right" class="main">
<form name="checkout_confirmation" action="https://secure.paypal.com/cgi-bin/webscr" method="post"><input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="you@yourbusiness.com"><input type="hidden" name="item_name" value="osCommerce"><input type="hidden" name="amount" value="129.98"><input type="hidden" name="shipping" value="5.00"><input type="hidden" name="currency_code" value="USD"><input type="hidden" name="return" value="http://localhost/unnamed1/catalog/checkout_process.php?osCsid=l1tvgrqtjuv4cu979r8ibiidi5&osCsid=l1tvgrqtjuv4cu979r8ibiidi5"><input type="hidden" name="confirm" value="1"><input type="hidden" name="cancel_return" value="http://localhost/unnamed1/catalog/checkout_payment.php?osCsid=l1tvgrqtjuv4cu979r8ibiidi5"><input type="image" src="includes/languages/english/images/buttons/button_confirm_order.gif" border="0" alt="Confirm Order" title=" Confirm Order "></form>
		</td>

 

So I could simply change the secure.paypal.com to checkout_process in the action and skip the gateway. Or whatever payment method.

 

I was saying instead of having the gateway or payment method url with the form you have the checkout_confirmation.php again. But this time near the beginning of the script you process the action switch. So if it is a form submission request you insert the new record for the order sql table (you also register that as a session) and then you redirect to the form's destination url. On checkout process instead of creating a new order there you use the session variable to update the order to pending status.

 

You have to take care of some payment modules like authorizenet that check the return parameters. If the return parameters include an error you have to remove the order from the table. But that's an alternative that secures the cart and pre-records orders so no missing requests.

Share this post


Link to post
Share on other sites
so here is where your hidden confirm variable will end up. (HTML generated)

 

			<td align="right" class="main">
<form name="checkout_confirmation" action="https://secure.paypal.com/cgi-bin/webscr" method="post"><input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="you@yourbusiness.com"><input type="hidden" name="item_name" value="osCommerce"><input type="hidden" name="amount" value="129.98"><input type="hidden" name="shipping" value="5.00"><input type="hidden" name="currency_code" value="USD"><input type="hidden" name="return" value="http://localhost/unnamed1/catalog/checkout_process.php?osCsid=l1tvgrqtjuv4cu979r8ibiidi5&osCsid=l1tvgrqtjuv4cu979r8ibiidi5"><input type="hidden" name="confirm" value="1"><input type="hidden" name="cancel_return" value="http://localhost/unnamed1/catalog/checkout_payment.php?osCsid=l1tvgrqtjuv4cu979r8ibiidi5"><input type="image" src="includes/languages/english/images/buttons/button_confirm_order.gif" border="0" alt="Confirm Order" title=" Confirm Order "></form>
		</td>

 

So I could simply change the secure.paypal.com to checkout_process in the action and skip the gateway. Or whatever payment method.

 

I was saying instead of having the gateway or payment method url with the form you have the checkout_confirmation.php again. But this time near the beginning of the script you process the action switch. So if it is a form submission request you insert the new record for the order sql table (you also register that as a session) and then you redirect to the form's destination url. On checkout process instead of creating a new order there you use the session variable to update the order to pending status.

 

You have to take care of some payment modules like authorizenet that check the return parameters. If the return parameters include an error you have to remove the order from the table. But that's an alternative that secures the cart and pre-records orders so no missing requests.

 

that is a nice solution. For internal form posting over the top but for payment gateways nice.

 

why do you have osCsid=l1tvgrqtjuv4cu979r8ibiidi5 2 times in there ?


Treasurer MFC

Share this post


Link to post
Share on other sites
You actually believe that someone ordering COD will try to mess with POST variables?

 

The point I was trying to make is a little broader than that. COD is just the obvious example of a type of payment that doesn't leave your site. Security with POST variables is a mistake, since you're sending that information to an unknown entity, and trusting that the information that comes back hasn't been tampered with. That's the first rule in internet security: don't trust ANYTHING that is or can be changed or altered by the client. A session variable is more secure, since that value is never transferred to the client, and unless they know the code, they won't even know that there is such a value being stored.

 

The same cannot be said for POST variables. I can go to your checkout_shipping.php page, download it, change the POST url, change any hidden variables I want, run it in my browser off of my local machine, and your code will never know the difference.

 

I think it's a mistake to "secure" the checkout process with POST variables since they don't provide you any more security than making a fraudster take one extra step.


Contributions

 

Discount Coupon Codes

Donations

Share this post


Link to post
Share on other sites
I think it's a mistake to "secure" the checkout process with POST variables since they don't provide you any more security than making a fraudster take one extra step.

 

So true

Share this post


Link to post
Share on other sites
that is a nice solution. For internal form posting over the top but for payment gateways nice.

 

why do you have osCsid=l1tvgrqtjuv4cu979r8ibiidi5 2 times in there ?

 

probably my mistake, I posted the html and then just copied one of the fields and renamed it.

 

This is how I've setup my live store but it can be a nightmare to debug issues sometimes. I will have to add a switch to enable/disable this extra checking.

Share this post


Link to post
Share on other sites

Ok, it's nice for to see all the views and opinions but someone actually have a code that can be inserted somewhere to check the state of play?

 

Does anyone have any working example of some kind of fix?


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
probably my mistake, I posted the html and then just copied one of the fields and renamed it.

 

This is how I've setup my live store but it can be a nightmare to debug issues sometimes. I will have to add a switch to enable/disable this extra checking.

 

 

so your form goes back to the top of confirmation at all times.

but what code do you use to then post a request to the gateway without using a form ?


Treasurer MFC

Share this post


Link to post
Share on other sites

I tried the hack many times and each time the page just redirects back to checkout_payment.php. We accept check, money order, and paypal. I tried all of em... I am on a shared ssl so my url was a little different than what is posted here as an example.

 

Best to all,

Moon


"Woohoo, Just Havin Funnn!"

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.

Share this post


Link to post
Share on other sites
I tried the hack many times and each time the page just redirects back to checkout_payment.php. We accept check, money order, and paypal. I tried all of em... I am on a shared ssl so my url was a little different than what is posted here as an example.

 

Best to all,

Moon

 

 

STRIKE THAT... If you place the hack on the order_confirmation.php it works...In admin it shows the order by paypal. I checked paypal and nothing. Wow, this is crazy...

 

Best to all,

Moon


"Woohoo, Just Havin Funnn!"

Share this post


Link to post
Share on other sites

This is a serious issue - and needs to be fixed before it undermines Oscommerce full stop.


Regards,

Clive

Share this post


Link to post
Share on other sites

I just received a helpful email from someone proving this flaw to me on my new site. He offers a simple code fix based on preventing direct access of the file, based on using:

 

if (!$HTTP_SERVER_VARS['HTTP_REFERER'])

 

 

More instructions at http://www.westhost.co.uk/osc_freecontributions.php

 

 

Can people offer their opinions on whether this is a valid fix?

 

 

Cheers.

Share this post


Link to post
Share on other sites

×