Discuss findings of security analysis

[crowgames]

Dear all!
I spent the last 6 months performing a formal security analysis of the current state of the Web Payment APIs as my Master's Thesis. You can find the report of the analysis attached to the issue.

Through that analysis 3 issues were observed.

1. An attack that resulted out of a faulty implementation of the retry mechanism in Chrome/an ambiguous definition of the retry mechanism in the specs.
2. A vulnerability that results out of the possibility to specify ambiguous information for a single payment method identifier in the methodData of a payment request. Especially since the spec does not imply what should happen in such a scenario (e.g. "last one wins" or "fails").
3. A proposal of how to change the payment update event to prevent privacy issues concerning sending data to the merchant before payment intent was expressed.

I hope that especially the second point could be tackled in the spec. I worry that potential future named payment methods or future developments in general could otherwise introduce major attack vectors.

Have a nice day and stay healthy!
a_formal_security_analysis_of_the_web_payment_apis.pdf

[marcoscaceres]

wow! thanks @crowgames! I'm super excited to read your thesis - thanks for spending time on this. We will do what we can do take your recommendations onboard. I see your thesis is ~80 pages, so might be help us speed things up if we break up the three things above into 3 separate issues.

Do you have time to be involved in those discussions? If you can summarize the problem AND your proposed solutions, we can then work a bit more rapidly with trying to fix things.

[ianbjacobs]

Wow also from me! Thank you so much for doing this @crowgames and for sharing it with the group. I look forward to reading the thesis and improving the specification.

In related news, the Chrome team embarked on a privacy threat analysis; your feedback on this is also very welcome:
https://w3c.github.io/webpayments/proposals/privacy-threat-model.html

I'll be sure to mention this to the Working Group during this week's calls.

Stay well,

Ian

[crowgames]

@marcoscaceres I did create the corresponding issues and will try my best to be as involved as possible. Due to a certain illness, chances are quite good.

@ianbjacobs Privacy is a huge aspect concerning the Web Payment APIs and I am very happy to see that it is actively being tackled! I will have a look at the document and get back to you concerning it.

Since there is no need for this issue being open, if the other three exist, I am closing it.

[cyberphone]

Personally I think the root of the problem actually is the combination of personal information with payments. These are separate issues. The shipping part of PaymentRequest addresses a limited set of real-world cases (ad-hoc shopping on the Web) and only saves a single click or two compared to HTML's autocomplete.

Other privacy discussions I have seen over the years seem to overlook the fact that a malicious PaymentHandler (aka payment application) can return whatever information it has access to. That is, a PaymentHandler must be trustworthy. For native PaymentHandlers this is accomplished though publishing in specific "app-stores" as well as through platform attestations. Since I'm not up-to-speed on ServiceWorker-based PaymentHandlers, I don't know what kind of attacks that are possible for such designs.