1486879 - Handle infinite repetition of JS alerts

Status: RESOLVED FIXED

(Firefox for FireTV Graveyard :: Security: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

+++ This bug was initially created as a clone of Bug #1486666 +++

We don't currently provide special handling for JS' `alert', 'confirm', or 'prompt' (are those all of them?) so a malicious site can run:
```js
for (var i = 0; i < 1000; i++) { alert('lol'); }
```

And prevent the user from using the browser.

Possible solutions:
- Block them all (they aren't used *that* often anymore for legitimate purposes)
- Give the user an option to prevent pop-ups after the site has displayed some number, like desktop

See bug 1486666 for same issue for Focus.

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

We currently do not implement alerts in Android Components. So I assume Firefox for Fire TV is not affected by this?

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Firefox for Fire TV is affected: the prompt APIs need to be explicitly disabled to prevent it from being launched. See [1].

Sebastian, unlike WebView, I think Android Components should default to disabling this functionality for security reasons.

[1]: https://github.com/mozilla-mobile/firefox-echo-show/blob/1695912b0bb7116f2c96ccfbfa7fb4dd428f6d6d/app/src/amazonWebview/java/org/mozilla/focus/webview/FirefoxWebView.kt#L185

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

Oh, I see. I'll bump the AC ticket back into triage. Now that we have implemented the prompt API and now that we handle this case for GeckoView we can look at doing the same for WebView.

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

AC now exposes prompt requests in Session.promptRequest (as Consumable<PromptRequest>).

Requests of type PromptRequest.Alert come with a hasShownManyDialogs flag that can be used to stop showing dialogs if the website/code abuses this feature.

The feature-prompts component comes with implementations for every PromptRequest (prompts, pickers, ..). In this component we show a checkbox in the alert that a user can check if they do not want to receive any more alerts from that page (like desktop).

Comment 5

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

To clarify, does Android components now, by default, disable prompts?

If so, all we need to do to fix this bug on Fire TV is upgrade to the latest version? Which version would that be?

Comment 6

[Arturo Mejia [:amejia]]

As Sebastian mentioned above by default, we're not providing any implementation. In case you want to be notified of any prompt request you can do it by subscribing on Session.onPromptRequested or checking the actual request in Session.promptRequest (as Consumable<PromptRequest>).

As a separate component we offer feature-prompts that provide an implementation for all prompt requests.

Alert implementation is in A-C version 0.38.0 and above. Here you can take a look at a demo for PromptRequest.Alert(JavaScript alert) and the PR that included it

Comment 7

[Arturo Mejia [:amejia]]

To fix the bug you just have preferably to update to the latest version of components 0.39.0 and use feature-prompts

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

As I mention in comment 2, if you don't provide any prompts implementation on the vanilla WebView APIs, the system provides its own prompts implementation, i.e. it is enabled by default. To disable it, the developer needs to take explicit action.

As Sebastian mentioned above by default, we're not providing any implementation.

With that context, ^ seems ambiguous (and my question in comment 5 might be as well).

To be explicit and remove ambiguity, what is the absolute behavior in components for WebView and GeckoView? imo, ideally it should be:

• App does not implement prompt callbacks: prompts do not appear
• App implements prompt callbacks: the app handles the requests
• App implements prompt callbacks with feature-prompts: the components prompts implementation handles the requests

Comment 9

[Arturo Mejia [:amejia]]

Got you!
Thanks for the clarification.

onJsAlert is behaving in the way you describe above, and case you want to take a look, you can do it here.
We haven't provided a full implementation for all prompts on WebView, at the moment, we have implemented just onJsAlert and onShowFileChooser.

Comment 10

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Arturo Mejia from comment #9)

onJsAlert is behaving in the way you describe above, and case you want to take a look, you can do it here.

The first line is:

val session = session ?: return super.onJsAlert(view, url, message, result)

This means if session is null, we're not blocking the default behavior to show a prompt. This will need to be addressed before this bug can be closed.

We haven't provided a full implementation for all prompts on WebView, at the moment, we have implemented just onJsAlert and onShowFileChooser.

Additionally, onJsConfirm and onJsPrompt will need to be implemented before this bug can be closed.

Thanks for getting the work started here!

Comment 11

[Arturo Mejia [:amejia]]

Thanks Mike, I created this PR for addressing the issue above.

Comment 12

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I don't understand what the default onJsAlert code is currently doing 1: Arturo, can you explain?

Also, when onJsConfirm and onJsPrompt receive implementations, will they receive a similar implementation?

I want to see if we can close this issue (i.e. prompts are disabled) by upgrading to 0.41 and ensure that new implementations won't break this behavior.

Comment 13

[Arturo Mejia [:amejia]]

I don't understand what the default onJsAlert code is currently doing 1: Arturo, can you explain?

Sure, when we have a session, we are creating a PromptRequest.Alert

• If the App uses feature-prompts an dialog will be shown.
• If the App doesn't use feature-prompts a dialog will NOT be shown, but a PromptRequest.Alert will be stored in Session.promptRequest.
• If we don't have a session, a dialog will NOT be shown neither a PromptRequest.Alert will be stored in Session.promptRequest.

Also, the function is updating the state about detecting if many dialogs have been shown in a short amount of time.

Also, when onJsConfirm and onJsPrompt receive implementations, will they receive a similar implementation?

Yes, they are going to share the same logic for detecting when many dialogs have been shown in a short amount of time. I just filed a PR for adding the implementation for confirm dialogs in Gecko, I will try to add the implantations for onJsConfirm and onJsPrompt on SystemEngineView this week, these are the issues on A-C repo onJsConfirm and onJsPrompt with those you can follow the progress.

Comment 14

[Arturo Mejia [:amejia]]

Now onJsConfirm and onJsPrompt are implemented on A-C.

Comment 15

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Okay, it sounds like we can close this issue after upgrading to 0.41, which we did in https://github.com/mozilla-mobile/firefox-tv/issues/1767.

Thanks Arturo!