Basic-credit security issue

[RomanKaliupin]

Hello,

Was found an issue in security.
The case:

1. User installed https://evil.com/ Payment App which has payment instrument basic-credit (like in bobpay).
2. User opened website with Payment Request which support basic-credit payment methods.
3. User is able to select https://evil.com/ payment app and enter sensitive data which can be stolen since evil.com support basic-credit instrument.

Was also found that you planned to implement a solution which will help in troubleshooting of this bug: w3c/payment-request#815 but it still in To-Do list.

Is it possible to somehow fix this security issue?

Best,
Roman.

[rsolomakhin]

The easiest way to avoid this issue is to avoid using basic-card. There is no allow-list for this payment method.

[RomanKaliupin]

hi @rsolomakhin,

It is a good idea, but the problem is, that we want to give user possibilities to pay with credit card.
So, we have only two options:

1. Leave in payment request just Google pay (for ex), in order to use JIT approach
2. Create a Payment App which will allow paying with credit card.

Disadvantages of first approach are understandable - we will be able to use just Google Pay, but no other Payment Apps as Samsung, or Apple Pay, or custom Payment Apps.
With the second approach is not so clear how to retrieve credit cards which is stored in Google Chrome for ex.

Questions:

1. Is there any way to allow usage of JIT approach not for case when we have only one Payment App but for case when we have more than one?
2. Is it possible to extract saved Chrome credit cards in custom Payment App?

Best,
Roman.

[ianbjacobs]

Hi all,

I wanted to mention some other aspects of mitigation:

• Chrome uses the safe browsing [1] database to help the user avoid installing potentially harmful Web-based payment apps.
• Payment apps (including Web-based) installed "on the fly" require a user gesture before installation.

If we can improve security further, that would be great. I welcome suggestions here.

Ian

[1] https://safebrowsing.google.com/

[RomanKaliupin]

Hi @ianbjacobs ,

Chrome uses the safe browsing [1] database to help the user avoid installing potentially harmful Web-based payment apps.

It is a good that Chrome uses the safe browsing. But even taking in consideration this point we can't proceed with basic-credit implementation, since the user still can install such evil Payment App even without even knowing about it (the topic of the website can be different).

For now the most important that it is not possible to have Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request. You first need to pay with each of these methods using JIT approach, but it is not a user-friendly approach.

The security issue may happen only in case of build in payment (like basic-card). Since in a response from Payment Request we have just methodName which is equal basic-card. It will be equal basic-cardwithout any info about payment domain...

My main questions are:

1. How we can use Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request? If it is not possible, could you please add this functionality? It will be really useful. Note: it isn't possible if we try to pay in new clean Google Chrome (without any transaction in google pay\samsung pay\etc.).
2. How we can avoid an issue with basic-card ? The main goal here is to keep basic-card default functionality in Payment Request and do not have insecurity case which was described above.
3. If we can't cover the second question, is it possible somehow to retrieve user saved Credit Cards? We will need it, in order to create a custom Payment Web App for basic-card.

Thank you for your answers,
Roman.

[rsolomakhin]

For now the most important that it is not possible to have Google Pay, Samsung Pay and Apple Pay in the same time in Payment Request.

This is a valid feature request in general.

If we're talking about particulars of Google Pay, Samsung Pay, and Apple Pay, however, then their support matrix makes supporting all of them easier. Here's a quick sketch:

	Chrome on Samsung phone	Samsung Internet browser on Samsung phone	Chrome on non-Samsung Android phone	Chrome on iOS phone	Chrome desktop	Safari
GPay	Android app works if manually installed	Not integrated	Android app works and is sometimes pre-installed	Works through pay.js script and popups, not PaymentRequest	Works through service worker payment handler and PaymentRequest	Works through pay.js script and popups, not PaymentRequest
Samsung Pay	Android app works	Android app works	Android app works if pre-installed	Not supported	Not supported	Not supported
Apple Pay	Not supported	Not supported	Not supported	Not supported	Not supported	Built-in and works with PaymentRequest

If you use exclusively PaymentRequest API and include all three supported payment methods in you request, then you would presented with a choice of apps only in the first two columns (Chrome on Samsung phone and Chrome on non-Samsung Android phone), only if the user has pre-installed the extra app. In the rest of the cases, the user is likely to not see any app chooser. Instead, the user will launch the available payment app directly.

Does that help to understand today's landscape a little better?

[RomanKaliupin]

hI @rsolomakhin ,

Hm.. yeah, it makes sense. Thanks.
But anyway, what about combination custom Payment Web App + Google Pay on Chrome desktop? Google Pay will appear only if from user Chrome Browser was made at lease one successful transaction to https://google.com/pay. In the other case you must have only Google Pay in Payment Request in order to trigger JIT approach.

Do we have there workaround?

Best,
Roman.

[rsolomakhin]

There is no workaround for that issue that I can think of at this moment.

[RomanKaliupin]

Hi @rsolomakhin ,

Alright. Is it possible to cover this case in a future version? This case seems to be common.
What about retrieving of credit card /saved billing address information from Chrome within custom Payment Web App? Is it possible?

Best,
Roman.

[rsolomakhin]

Is it possible to cover this case in a future version?

Yes, that seems like the most natural approach, so that's what browsers should be doing, ideally.

What about retrieving of credit card /saved billing address information from Chrome within custom Payment Web App? Is it possible?

That can be done by utilizing autofill on your page. That is, show a <form><input type="text" name="cc" id="cc" autocomplete="cc-number"></form> in your payment handler. Then browsers should give the user the ability to autofill their cards into the payment handler.

[RomanKaliupin]

Hi @rsolomakhin

That is, show a

in your payment handler.

Autocomplete doesn't work in the payment handler.
I tried with the next code (this code works if you try to open it as a normal html page in a browser):
<html><head></head><body><form method="post" id="usrForm"><label for="frmNameA">Name</label><input name="name" id="frmNameA" placeholder="Full name" required="" autocomplete="name"></form></body></html>

What configs I should add in order to use Chrome autocomplete in Payment Handler?

Best,
Roman.

[rsolomakhin]

Good find! Looks like that's a known bug reported here: https://crbug.com/855144. Sorry about leading you down the wrong path.

[RomanKaliupin]

Could you please let me know when it will be, approximately, fixed ?

[rsolomakhin]

We do not have immediate plans for this to be fixed.