canmove, Confirmed users
1,220
edits
Firefox/Features/Web Payments/Privacy & Security Considerations: Difference between revisions
Firefox/Features/Web Payments/Privacy & Security Considerations (view source)
Revision as of 02:07, 17 August 2018
, 17 August 2018→User Interaction
(corrected links) |
Ptheriault (talk | contribs) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 34: | Line 34: | ||
=== How Data is Secured on Device === | === How Data is Secured on Device === | ||
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key | For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key (see {{bug|1463865|Bug 1463865}}); in the initial release this method will be used to protect credit card information, and in future releases might be used to protect other kinds of data as well. | ||
== Interaction with Merchant Website ("Data in Motion") == | == Interaction with Merchant Website ("Data in Motion") == | ||
| Line 42: | Line 42: | ||
== Information Leakage == | == Information Leakage == | ||
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc. | |||
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks. | |||
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site: | |||
* Although a merchant website could gather the user's | * Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost. | ||
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}). | |||
== Device Fingerprinting == | == Device Fingerprinting == | ||
| Line 64: | Line 66: | ||
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses). | * Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses). | ||
== | == Data Validation == | ||
As part of the W3C Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include: | |||
* [https://www.w3.org/TR/payment-request/#dom-paymentitem-label PaymentItem labels] (e.g., products in a shopping cart) | |||
* The [https://tools.ietf.org/html/rfc6454 web origin] of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.) | |||
* [https://www.w3.org/TR/payment-request/#dom-paymentdetailsupdate-error Error strings], especially the generic error message | |||
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc. | |||
* | == User Interaction == | ||
User must provide explicit consent granting card data: | |||
* UX design should include explicit confirmation from the user (such as CVV confirmation before the pay button is enabled). | |||
* We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g. clickjacking, UI redress attacks) | |||
It must be clear to the user which page initiated the payment: | |||
* Navigation away from a page showing a Payment Request dialog either should be prevented or the dialog should abort. | |||
* If we plan to show origin information in Payment dialog (as per current UX spec, but not implemented yet) this needs to avoid all URL spoofing/truncation attacks. | |||
Web pages must not be able to interfere with the Payment Request dialog: | |||
* Prevent overlaying content on top of the dialog, or forcing part of the dialog off screen | |||
* Ensure that any string originating from content are sanitized for display | |||
Prevent web pages from coercing the user into payment: | |||
* An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open. | |||
== Process Separation and Sandboxing == | |||
To help mitigate against [https://wiki.mozilla.org/Security/Sandbox sandbox] violations, cross-site scripting attacks, and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles sensitive user information such as credit card numbers (see {{bug|1460425|Bug 1460425}}), thus helping to prevent a compromised web content process from reading this data. | |||
== Open Issues == | == Open Issues == | ||
* What happens if the dialog appears during DOM or UI fullscreen? | * What happens if the dialog appears during DOM or UI fullscreen? | ||
* What happens if the dialog appears in different variants of popup windows | * What happens if the dialog appears in different variants of popup windows (e.g. consider window.open features)? | ||
* It would be helpful to include diagrams of the UI workflow and protocol state machines. | |||
* It would be helpful to describe the process model or point to documentation on another page. | |||
* We need to add a more detailed discussion of fingerprinting attacks. | |||
== Privacy and Security Roadmap == | == Privacy and Security Roadmap == | ||
| Line 95: | Line 108: | ||
Future features will likely include: | Future features will likely include: | ||
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card | * Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card information is not sent from the browser to the merchant; instead, the browser sends a payment authorization token. | ||
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal. | * Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal. | ||
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation). | * Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation as in [[Project_Fission|Project Fission]]). | ||