Closed Bug 1486879 Opened 3 years ago Closed 2 years ago

Handle infinite repetition of JS alerts

Categories

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

Unspecified
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mcomella, Assigned: amejiamarmol)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-dos, sec-low)

+++ 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.
See Also: → eviltraps
We currently do not implement alerts in Android Components. So I assume Firefox for Fire TV is not affected by this?
Flags: needinfo?(michael.l.comella)
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
Flags: needinfo?(michael.l.comella) → needinfo?(s.kaspari)
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.
Flags: needinfo?(s.kaspari)

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).

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?

Flags: needinfo?(s.kaspari)

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

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

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

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.

(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!

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

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.

Flags: needinfo?(s.kaspari) → needinfo?(amejiamarmol)

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

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.

Flags: needinfo?(amejiamarmol)

Now onJsConfirm and onJsPrompt are implemented on A-C.

Flags: needinfo?(michael.l.comella)

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!

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(michael.l.comella)
Resolution: --- → FIXED
Assignee: nobody → amejiamarmol
Group: firefox-core-security → core-security-release
You need to log in before you can comment on or make changes to this bug.