During the navigator.pay security review, the threat of a background app requesting a payment was raised. The concern is that the user might mistake the payment as being related to the currently active app, and might pay for something they didn't mean to buy. If nothing else, a background app being able to interrupt a foreground app with a modal dialog is a potential DoS scenario The risk is mitigated by: * an app should not be able to tell which app is in the foreground (I think?), which makes targeting an attack more difficult * The payment provider must clearly show who the payment is for, as part of their flow, so hopefully the user would realizes and not pay at this point. * In terms of DoS, maybe dialog for navigator.pay sits below the b2g attention_screen, which would mitigate this threat, since urgent apps use the attention_screen? Mitigating circumstances aside, I am not sure there is a valid use case for a non-foreground app from calling navigator.pay, so I am proposing that only the active app in B2G be allowed to successfully call navigator.pay. There wasn't consensus in the security meeting about this, or what to do with blocked requests (drop or queue till foreground, etc) so I took an action to raise it here for further discussion. Thoughts?

> * an app should not be able to tell which app is in the foreground (I think?), which makes targeting > an attack more difficult Any webpage can use the DOM visibility API to tell whether it's in the background. https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API

Huh, first I have heard of that API. So the app will know when it is background, but not necessarily which app is in foreground (which would help in tailoring some kind of fraudulent payment request)

> So the app will know when it is background, but not necessarily which app is in foreground Correct.

This patch checks that the nav.mozPay caller is a foreground app. It does so by requesting the UI to provide the origin of the foreground app and comparing it with the origin of the nav.mozPay caller. This also requires some changes on Gaia that will be send within a PR once this gets r+ (hopefully soon :))

Comment on attachment 662594 [details] [diff] [review] v1 Review of attachment 662594 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/payment/Payment.jsm @@ +76,5 @@ > this.paymentFailed("CREATE_PAYMENT_GLUE_FAILED"); > return; > } > > + // We check the that the caller app/tab is in the foreground. s/check the that/check that/ I'll change it on my next patch, with other review comments if needed. ::: dom/payment/interfaces/nsIPaymentUIGlue.idl @@ +21,2 @@ > // The 'paymentRequestsInfo' contains the payment request information > // for each JWT provided via navigator.mozPay call. Whitespace. Same as above, fixed on my next patch.

Comment on attachment 662594 [details] [diff] [review] v1 Review of attachment 662594 [details] [diff] [review]: ----------------------------------------------------------------- What you're doing here is very complex. An easier way to check if an app is in the background is to check if the docshell is active: Doing that in pay() let docShell = aWindow.QueryInterface(Ci.nsIInterfaceRequestor). getInterface(Ci.nsIWebNavigation). QueryInterface(Ci.nsIDocShell); if (docShell.isActive) {...} This means that should be able to not need gaia support, which is nice.

(In reply to Fabrice Desré [:fabrice] from comment #7) > > What you're doing here is very complex. An easier way to check if an app is > in the background is to check if the docshell is active: > > Doing that in pay() > let docShell = aWindow.QueryInterface(Ci.nsIInterfaceRequestor). > getInterface(Ci.nsIWebNavigation). > QueryInterface(Ci.nsIDocShell); > if (docShell.isActive) {...} > > This means that should be able to not need gaia support, which is nice. Great! Good to know. I'll change the patch asap. Thanks!

Review comments addressed. This patch checked for an active docshell to determine if the app is in the foreground, as Fabrice suggested.

I've tested the above patch with this test page. It contains a timer that triggers a navigator.mozPay request after 8 sec. To test it, you need to launch the application, click on the HOME button to hide the window application and wait for the navigator.mozPay call, which should log a message like "onerror received BACKGROUND_APP" in the jsconsole. Showing the window application again and clicking on the "Pay" button should trigger the payment request.

Testing is blocked on this - the trusted UI appears to be broken on 9/27 build. Gaia issues discovered through testing this: - https://github.com/mozilla-b2g/gaia/issues/5374 - https://github.com/mozilla-b2g/gaia/issues/5375 - https://github.com/mozilla-b2g/gaia/issues/5371

Hmm...I tried the test page here, although I don't think going to the browser directly on that page validates if this works or not. I'm hunting around for a good way to simulate a payment in the background on FF OS. Any ideas?

(In reply to Jason Smith [:jsmith] from comment #14) > Hmm...I tried the test page here, although I don't think going to the > browser directly on that page validates if this works or not. I'm hunting > around for a good way to simulate a payment in the background on FF OS. Any > ideas? Sorry, I should explained myself better. The attached test is intended to be used as an installed web app, not from the browser app.

To test this app you only need to add it to your Gaia apps folder, run |make install-gaia| and follow the instructions in comment 10