Comme c’est souvent le cas, une fonctionnalité créée pour plus de commodité peut être détournée de son but initial. Pour permettre aux utilisateurs de ne pas avoir à entrer les numéros de leur carte de crédit (notamment les 16 caractères, en plus des quatre pour la date et des trois ou quatre chiffres du numéro de vérification de carte CCV), l’API Payment Request permet aux sites Web d’extraire des numéros stockés dans les navigateurs.
Cependant, selon Lukasz Olejnik, chercheur en sécurité et en matière de protection de la vie privée, même sans une évaluation complète de la vie privée, il est facile de voir des vecteurs sérieux qui pourraient être utilisés pour détourner la fonctionnalité de son but initial.
« Il y a de fortes chances que les jours de sites de commerce électronique ayant des systèmes de paiement personnalisés, souvent inutiles, soient comptés. L’API Payment Request améliore non seulement la commodité, mais aussi la sécurité des paiements en ligne. Les sites Web auront plus facilement accès aux options de paiement. Les utilisateurs du Web pourront plus facilement éviter les phishings, les escroqueries et d’autres expériences désagréables », a-t-il reconnu.
L’API Web Payment fonctionne comme suit :
- le processus de paiement est lancé par le site ;
- le navigateur prend le contrôle, l’utilisateur peut fournir une méthode de paiement comme une carte de crédit, puis un numéro CVV, et c’est tout.
Tout en utilisant des messages d’affichage standard, intuitifs et compatibles avec le navigateur. L’API Payment Request est maintenant prise en charge par Chrome et Edge, et le sera bientôt dans Firefox et WebKit.
Les utilisateurs ont la possibilité d’ajouter une carte de crédit à un navigateur, il est donc simple de payer en utilisant une carte de crédit précédemment incluse. Pour faciliter à la fois la vie des développeurs Web, mais aussi celle des utilisateurs, la spécification comprend une méthode de vérification si l’utilisateur dispose d’une méthode de paiement enregistré. Cette méthode s’appelle canMakePayment et est l’objet central auquel s’est intéressé le chercheur.
« Pour protéger contre les abus, canMakePayment peut être exécuté par une origine (c.-à-d. un site Web) avec une méthode de paiement ciblé spécifique de temps en temps. Donc, un site Web peut vérifier si un navigateur a une carte Visa incluse – mais la vérification (immédiatement après) si la carte MasterCard est également prise en charge devrait être impossible. Ce mécanisme protège l’énumération des méthodes de paiement incluses dans un navigateur. Par exemple, c’est ainsi qu’il est implémenté dans Chrome. L’origine spécifique (c’est-à-dire le site Web) peut faire un tel test toutes les 30 minutes seulement, via un mécanisme de quota. Si un site Web tente de faire le test plus fréquemment, Chrome ne le permettra pas. Le mécanisme de quota rend les attaques d’énumération / empreintes numériques plus difficiles étant donné qu’elles vont nécessiter plus de temps.
« Cependant, un site Web pourrait simplement utiliser un tas d’iframes avec des scripts fonctionnant efficacement dans des origines différentes, ce qui signifie que le quota de 30 minutes est fonctionnellement non pertinent. De tels iframes (en utilisant le paramètre de “allowpaymentrequest” de l’empreinte numérique) effectueraient alors des tests supplémentaires sans quota. Par exemple, un iframe pourrait tester “visa”, un autre “mastercard”, etc. À la fin, les iframes communiquent les résultats du test au frame parent. En fin de compte, ce processus permettrait d’énumérer toutes les méthodes de paiement prises en charge par l’utilisateur. »
Pour étayer ses dires, il a mis sur pied une page Web qui permet de tester les méthodes de paiement enregistrées sur le navigateur Chrome. Il a expliqué qu’enregistrer au préalable une carte Visa est essentiel. Il a proposé d’utiliser la sienne avec les numéros 4916 6293 0528 7782 (CVV 933).
« Je l’ai testé sur Chrome, la version Desktop et la version Android. Dans cette démo, seules deux cartes sont testées : Visa et MasterCard. Ce n’est pas tout », a-t-il déclaré.
Le chercheur note également que l’API Payment Request, tel qu’elle est livrée dans Chrome, permet la détection lorsqu’un utilisateur est en mode Incognito. « C’est aussi simple que de tester deux méthodes de paiement différentes par le même site. Si je fais une demande canMakePayment pour “visa”, puis à nouveau pour “mastercard” (les deux demandes depuis le même site web), le second appel va entraîner une exception quand il ne sera pas en Incognito :
NotAllowedError: Not allowed to check whether can make payment”.
En revanche, en mode Incognito (dans cet exemple, je n’ai inclus qu’une Visa), nous avons :
mastercard card enabled? true
visa card enabled? true. »
En clair, l’API ne fonctionne pas bien avec le mode Incognito.
Il a déjà prévenu l’équipe Chrome.
