Authentication of merchant domain and details

[mimi89999]

Hello,

I was reading the spec and I don't really understand how the merchant domain or payment details are authenticated. How do you prevent such a scenario:

1. A user visits secure-legit-trusted-store.com, adds a $1000 laptop to their cart and initiates a payment
2. secure-legit-trusted-store.com backend visits buy-crypto-online.com and initiates a payment for $1000
3. secure-legit-trusted-store.com relays the request from buy-crypto-online.com, but changes details to The best laptop
4. User confirms the payment
5. secure-legit-trusted-store.com relays the response to buy-crypto-online.com

[stephenmcgruer]

Hi @mimi89999 . I'm afraid I don't really follow your described attack scenario.

What does it mean in step 3 for secure-legit-trusted-store.com to "relay the request" from buy-crypto-online.com ?

In general, it sounds like in your attack that secure-legit-trusted-store.com is committing payments fraud, by taking $1000 from the user (with the user's permission!) but not giving them their goods (the laptop) and instead keeping the money (or here, spending it on crypto). That is a form of payments fraud that exists in the world, and there are many mitigations across the payments ecosystem to stop it, mostly outside of the scope of Payment Request.

[mimi89999]

is committing payments fraud, by taking $1000 from the user (with the user's permission!) but not giving them their goods (the laptop)

Not exactly. In my case secure-legit-trusted-store.com is not registered with any payment processor and does not receive any money. They merely relay the request from buy-crypto-online.com and buy-crypto-online.com receives directly money from the user. However the product form buy-crypto-online.com will be sent to the fraudster not to the user who made the payment.

[stephenmcgruer]

Thanks. I think my question still stands - what does it mean within the context of the Payment Request API to "relay the request" to you?

[ianbjacobs]

@mimi89999,

If I understand the scenario, the fraud you describe would be possible with or without using payment request. Is that correct? Or are you indicating that payment request introduces a new attack surface?

[mimi89999]

The difference is that now the total and list of items are displayed on the website and they should be trusted not more than any other content on the website. With payment requests that information could be displayed in some browser UI or banking web app and I fear that it might be difficult for users to evaluate how much they should trust that information that will be displayed there.

[cyberphone]

If we stick to trust in the payment process, the user-signed transaction request should preferably include the domain name of the merchant. Since this part could be collected by the browser during SPC invocation, it is not possible to fake. This makes relaying (or stealing) authorizations much less useful, here assuming that verifiers check this parameter as well as claimed receive account etc.

[mimi89999]

This makes relaying (or stealing) authorizations much less useful, here assuming that verifiers check this parameter as well as claimed receive account etc.

In that case it might vary greatly between payment processors. IIRC the spec doesn't say that the payment method provider should verify that.

[stephenmcgruer]

If we stick to trust in the payment process, the user-signed transaction request should preferably include the domain name of the merchant. Since this part could be collected by the browser during SPC invocation, it is not possible to fake. This makes relaying (or stealing) authorizations much less useful, here assuming that verifiers check this parameter as well as claimed receive account etc.

Fwiw, this issue was filed against Payment Request in general, and not SPC (https://github.com/w3c/secure-payment-confirmation) specifically. @mimi89999 if you are thinking of SPC specifically please let me know, but otherwise I'm assuming general Payment Request.