
Domino's: Pizza and Payments - TheGuyWhoCodes
http://www.ifc0nfig.com/dominos-pizza-and-payments/
======
srtjstjsj
client-side payments is totally normal, when done right, unlike dominos's's
buggy version -- what usually happens is that the vendor sends you to a
payment processor, and you pay them, and the _payment processor sends a
verification token to the vendor_ , and the vendor delivers your product to
you.

Domino's skipped one critical step.

~~~
dperfect
> ... and the payment processor sends a verification token to the vendor

I would just add one more critical step: _the vendor actually verifies the
verification token_ rather than just checking that it exists (since the token
is often passed through the client, it can't be inherently trusted either).
This should involve either hitting the processor's server or verifying a
cryptographic signature, and verifying that the payment associated with the
token matches what the vendor expects.

~~~
mintplant
Why not have the payment processor notify the vendor's server directly? I
believe PayPal does this.

~~~
jdavis703
That's how it works most of the time, at least in my experience.

Card details are sent to the processor, a token comes back. You then send the
token along with any data relevant to the transaction (which items were
purchased, tax zones, coupon codes etc), you then verify on the server that
inventory exists etc, and then you send the token (which is only a short-lived
represention of the credit card number) and then verify the payment went
through, and then you go through the bussines process for delivering your
product(s).

Then, and only then do you give back a response saying the order has
processed, so the UI can alert the user.

~~~
ndboost
this is essentially how stripe's implementation works.

CLient side library handles the CC and token generation. Server side you use
that token to call stripes backend to process the payment.

------
Natsu
I'm waiting for Pizza Hut to show up next. I refuse to let them save my CC
number because their password policy basically ensures that you can't choose a
reasonable password.

And if the obvious, public part of the site is like that, I can only wonder
what hackers would find probing deeper.

~~~
junto
Which pizzahut country are you referring to out of interest? Is this US?

~~~
Natsu
The USA, specifically pizzahut.com prevents you from using any special
characters in your password.

You can see the message here:
[http://imgur.com/T8R6Fnr](http://imgur.com/T8R6Fnr)

I thought they used to also have limits on the maximum length, but thankfully
that doesn't seem to be there when I tested it just now.

------
swalsh
One of the things I love about stripe is it allows you to give them the raw
credit card details directly (never hits my servers/logs), and they give me
back a token. So I can still keep things server side, but I don't have raw
credit card information in my server logs/database.

~~~
jon-wood
That's exactly what Domino's provider (and anyone else worth using) allows,
they just didn't bother verifying the yoken.

------
lowtto
It's not that processing payment client-side is wrong, it's that the Dominos
app implement it wrongly, or DataCash simply doesn't provide any security
feature for protecting against http request data tampering, which I believe
the latter is not the case.

Most payment gateway have a security mechanism to ensure the response from
payment server have its integrity remain intact. Most of the time by hashing
some combination of responses value and shared secret key between merchant and
the payment server, and comparing if both marchant calculated value and
payment server hash matches. If it doesn't match, then it is safe to to throw
an error and prompt appropriate message to said attacker. When implemented as
such, the system are expected to immune to such attack as described by the
author.

The article is a perfect case study to showcase the consequences when the
developer decided to skip the security part. (yes it's entirely up to the web
master if they want this or not, the payment server won't care).

~~~
aj_n
> Most payment gateway have a security mechanism to ensure the response from
> payment server have its integrity remain intact.

I've definitely seen SSL pinning used to this effect. The simple solution to
Dominos' problems seems like a server-verifiable transaction token that coming
from DataCash (or whatever gateway service). I agree that client-side payment
processing isn't wrong -- in fact, it makes more sense than attempting PCI
compliance on their middleman server.

------
tdaltonc
My interest is certainly peaked about the 10% off coupons.

~~~
Normal_gaussian
Here in the UK there is _always_ a 50% off or better deal for mediums and
larges. If you can't find one on the page or from a quick Google ringing the
store will get it (only ever had to do this at a friend's in Liverpool)

~~~
megablast
Might be because pizzas are incredibly overpriced in the UK. Most places they
are cheap student food, for $5 you can get a meal. Not in the UK.

------
lifeisstillgood
Did the author get a bug bounty? If not, is it that companies who understand
tech the least also don't understand the value of such things?

~~~
franciscop
From the tone of it, it seems he is graceful that he didn't get into any legal
trouble. So I'd bet no, he didn't get any bounty.

~~~
iolothebard
£26 for Domino's. Sounds like he got bent over pretty hard. I can't imagine
spending ~$37 on fantastic pizza, much less Domino's.

------
nstj
Don't rely on client side data. Pin certificates in mobile apps.

~~~
Spivak
You're still trusting client side data. What's stopping a more advanced user
from replacing your pinned cert with theirs.

Don't do any payment processing client side. Your app should be a pretty
interface to the actual service running on your servers.

------
shakesbeard
How was he able to see the raw responses from the payment gateway? Do they use
HTTP instead of HTTPS to make these requests?

~~~
geocar
Because the messages were clear at some point on a machine he controlled.

This is what the article means by the payment processing being done on the
client: Some client-side code (JavaScript? A mobile app?) would receive the
message from the payment gateway, and send the success code to Dominos.

He may have used a debugger[1] to breakpoint the application where the
application has a cleartext version of the traffic, however he might have also
taken advantage of the fact that even if using HTTPS, if the programmer uses a
certificate store the user has access to (which they usually do), they can
install a custom root certificate and then use something like mitmproxy[1] or
charles[2] to decode the traffic.

What's needed to make this secure is to have a token provided by the payment
processing API that the server can verify but that the client cannot produce
(or tamper with)[4].

[1]: [https://securitycafe.ro/2015/01/28/intercepting-functions-
fr...](https://securitycafe.ro/2015/01/28/intercepting-functions-from-
statically-linked-libraries/)

[2]: [https://mitmproxy.org/](https://mitmproxy.org/)

[3]: [https://www.charlesproxy.com/](https://www.charlesproxy.com/)

[4]: [https://en.wikipedia.org/wiki/Hash-
based_message_authenticat...](https://en.wikipedia.org/wiki/Hash-
based_message_authentication_code)

------
bitmapbrother
Why doesn't Google do more to prevent Android apps from being decompiled,
inspected and recompiled into modified apps? Yes, there's source code
obfuscation, but that only slows down the amateurs.

~~~
DannyBee
Because it's not an arms race that can be won? And in most cases, it's a
complete waste of time to try?

