[TYPO3-commerce] *SECURITY ISSUE* possible Hack of paypal2ogone extension

Thibaut van de Mortel tibo at goutemesdisques.com
Sat Dec 15 19:31:08 CET 2007


Hi list,
well, you will have understood that in my previous message, the 
mentionned conditional call to the "insertOrderToDB" is actually 
breaking other payment methods. Of course it needs some 
"method_exists($paymentObj,"hasInsertedOrderToDB")" involved in the 
condition and then it's working ok without breaking anything.

If you have read all my previous post, you noticed that the big weak 
point of my solution is the cleaning process of unconfirmed orders. 
Well, after some testing I discovered an even worse problem :(

As I said, my solution doesn't call the stock handling as long as the 
payment isn't confirmed, which is logical. The problem is : this allows 
the customer to launch several identical orders in different browsers 
windows for example. And if he is crazy enough to validate each of those 
payments, then we could have a problem of stock. He could have ordered 
more than available stock, and we have now several valid orders, each 
with a valid token payment ID because they have been really paid. But we 
cannot honnor all orders because of stock : the hacker won again and we 
must refund him.

I know : the given example is totally 
ridiculous/pessimistic/paranoid/surreal.

But it's still makes me feel that my solution is not good at all.
I think I need a much more simpler solution than dealing with 
unconfirmed-junk records.

I now think that the key is simply NOT to allow the user to launch an 
order if there is ANY other unfinished order running from him. IF SO, he 
would be shown a form asking him to CANCEL the previous order first if 
he wants to start a new one. The form should also warn the customer to 
please NOT confirm any payment if he has a browser window waiting him to 
press any "confirm payment" button, because cancellation on merchant's 
site means delete order data from session (or database if I still wanna 
use database).

I know, we will again have the same problem if he cancels on merchant's 
site and still confirms on payment's site. But at least this time :
1) the database cannot be flooded by same account
2) we have warned him, so we can assume that A)he's totally stupid B)or 
he's a desperate hacker trying stupid things.

That's it.

hmmm... ok...  C) or he just likes to play innocently with several 
browser windows before confirming a payment, so he simply didn't see the 
warning but still cancelled order without having actually read it 
because he thought it was just another confirmation request despite the 
big red letters "WARNING"... shit happens, customers can be very 
"unlucky" O_o


I'm not an expert in security, all those potential problems scare me. I 
am a bit lost because I realize than having an external payment service 
leads to all those problems, but I still have no choice : I must 
integrate it for my project.

Argh this message is too long again. If anyone has an idea about all 
those problems regarding external payment, I'm desperatly interested. 
I'm also waiting for some news about the patch and about what you think 
of the trustability of session data.

[PS] you may think : hackers don't try to hack by confirming a payment, 
they rather try to fake a positive response of transaction.
I guess it's true, but what if they do?
Although I have no fear about a fake confirmation because the payment 
service I use (Ogone) can and is sending the confirmations in a 
"background" process (by "background" I mean : NOT via customer's 
browser but by a direct server call to a defined page on merchant's 
site). So all I have to do is - I guess - check the refferrer and parse 
the data from that call, that's all. I don't know how a hacker could 
possibly know which page to call and most of all : with which parameters 
and coming from payment's site... it's impossible, isn't it? So it 
doesn't scare me, the automatic redirection back to merchant's site from 
payment's site will NOT validate the order (even if it could), the 
background process from Ogone will.
[/PS]

Thank you for your support.

Regards,
Thibaut






More information about the TYPO3-project-commerce mailing list