Closed Bug 776417 Opened 7 years ago Closed 7 years ago

Prevent navigator.mozPay from being fired from apps in the background (in B2G )

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: pauljt, Assigned: ferjm)

References

()

Details

(Whiteboard: [WebAPI:P2])

Attachments

(2 files, 3 obsolete files)

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?
Blocks: 764966
No longer blocks: 767818
Component: DOM → DOM: Device Interfaces
Component: DOM: Device Interfaces → DOM: Mozilla Extensions
> * 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.
Component: DOM: Mozilla Extensions → DOM: Apps
Assignee: nobody → ferjmoreno
Attached patch WIP (obsolete) — Splinter Review
Attachment #649784 - Flags: feedback?(fabrice)
Summary: Prevent navigator.pay from being fired from apps in the background (in B2G ) → Prevent navigator.mozPay from being fired from apps in the background (in B2G )
Blocks: 767818
Whiteboard: [WebAPI:P2]
Component: DOM: Apps → DOM: Mozilla Extensions
Attached patch v1 (obsolete) — Splinter Review
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 :))
Attachment #649784 - Attachment is obsolete: true
Attachment #649784 - Flags: feedback?(fabrice)
Attachment #662594 - Flags: review?(fabrice)
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.
Attachment #662594 - Flags: review?(fabrice) → review-
(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!
Attached patch v2Splinter Review
Review comments addressed. This patch checked for an active docshell to determine if the app is in the foreground, as Fabrice suggested.
Attachment #662594 - Attachment is obsolete: true
Attachment #662981 - Flags: review?(fabrice)
Attached file Test page (obsolete) —
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.
Attachment #662981 - Flags: review?(fabrice) → review+
Keywords: verifyme
QA Contact: jsmith
https://hg.mozilla.org/mozilla-central/rev/929786a618f4
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
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
Keywords: verifyme
Whiteboard: [WebAPI:P2] → [WebAPI:P2], [qa verification blocked]
Keywords: verifyme
Whiteboard: [WebAPI:P2], [qa verification blocked] → [WebAPI:P2]
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?
Flags: needinfo?(ferjmoreno)
(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.
Flags: needinfo?(ferjmoreno)
Attached file Test 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
Attachment #662985 - Attachment is obsolete: true
Keywords: verifyme
Whiteboard: [WebAPI:P2] → [WebAPI:P2][qa-]
Status: RESOLVED → VERIFIED
Whiteboard: [WebAPI:P2][qa-] → [WebAPI:P2]
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.