[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