Firefox/Features/Web Payments/Privacy & Security Considerations: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(add address privacy leak)
(minimum show time)
Line 1: Line 1:
Some things to keep in mind while working on Payment Request relating to privacy/security:
Some things to keep in mind while working on Payment Request relating to privacy/security:
* {{bug|1443735|avoid leaking the user's shipping address before payment}} (as much as possible) while still allowing shipping option calculations (both shipping methods and shipping availability)
* {{bug|1443735|avoid leaking the user's shipping address before payment}} (as much as possible) while still allowing shipping option calculations (both shipping methods and shipping availability)
** Implement a minimum amount of time to show the dialog in the event of a .show followed by an immediate .abort (if we leak an address on .show) to reduce abuse.
* navigations away from a page showing a Payment Request dialog should either be prevented or the dialog should abort.
* navigations away from a page showing a Payment Request dialog should either be prevented or the dialog should abort.
* attacks where the user is tricked into interacting with the Payment Request dialog (e.g. clickjacking)
* attacks where the user is tricked into interacting with the Payment Request dialog (e.g. clickjacking)

Revision as of 00:25, 13 March 2018

Some things to keep in mind while working on Payment Request relating to privacy/security:

  • avoid leaking the user's shipping address before payment (as much as possible) while still allowing shipping option calculations (both shipping methods and shipping availability)
    • Implement a minimum amount of time to show the dialog in the event of a .show followed by an immediate .abort (if we leak an address on .show) to reduce abuse.
  • navigations away from a page showing a Payment Request dialog should either be prevented or the dialog should abort.
  • attacks where the user is tricked into interacting with the Payment Request dialog (e.g. clickjacking)
    • The pay button should probably have a security delay
  • security state of the page e.g. HTTPS vs. HTTP, invalid certificate, etc.
    • Only allowed on secure contexts. Should we disable for cert overrides? What about for developers?
    • Most relevant for payment information
  • Private browsing mode
    • default to not saving new addresses
    • don't update storage metadata
    • don't leak the user's shipping address without clear understanding
    • don't remember the last used address for the site
  • Integrate with Clear Recent History / Sanitizer?
    • N/A for basic-card
  • Don't save the CVV anywhere (including form history)
  • Master password: Require entry before every use of the plaintext card number
  • Spoofing issues from showing page generated strings in a privileged dialog
    • e.g. we should constrain the amount of space that the untrusted strings can take on the screen and handle special characters e.g. whitespace and new lines carefully
  • Handle abusive pages repeatedly showing a payment request dialog (e.g. holding the user hostage until they pay).
    • The proposed design will allow the user to close the whole tab while the dialog is open
  • What happens if the dialog appears during DOM or UI fullscreen?
  • What happens if the dialog appears in different variants of popup windows? (consider window.open features)