Bugzilla

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

bug 1681103 comment 3 and following describes a separate issue that I'm moving to this bug.

testcase: attachment 9194803 [details]
result: attachment 9194804 [details]

There seem to be two failures to follow the [specified behavior](https://html.spec.whatwg.org/multipage/history.html#shared-history-push/replace-state-steps):
1. relative URL is resolved wrt to baseURI (minor, annoying)
2. there is no same-origin check (horrifyingly insecure)

I don't have a Firefox Lite to experiment with so I don't know if the same-origin check is always skipped or if it's only skipped in the case of relative URLs, but either way this POC demonstrates exactly why that restriction is in the standard!

I'm surprised either of these would be performed by the FF Lite browser front-end. I would have expected `replaceState` and `pushState` would be executed by the underlying platform WebView and the security checks should be at that level.

Irvan: what device do you have and android version? Does the default browser, or other WebView-based browsers have the same problem on your device? In bug 1581103 comment 0 you say the original problem doesn't reproduce in other browsers so it's likely you already tried this, but I'm very surprised at the thought of rolling our own `replaceState()` implementation.


It is possible to spoof Firefox Lite full address bar with secure padlock, by typing or pasting URL on website with empty response body (https://www.google.com/csi) or closed port (https://www.google.com:82) to the address bar. 

While Firefox Lite loads the content, the target website URL stays on the address bar, so we can spoof current content using unbeforeunload event.

## Browser tested:
Firefox Lite 2.5.2 (20647)
WebView version: 86.0.4240.198 (released on Nov 11th,  2020)

## Steps to Reproduce:
1. Visit attached testcase.html
2. Tap "Copy URL"
3. Tap on the address bar
4. Tap "Open Copied Link"
5. Address bar show: https://www.google.com/csi?response_type=auth&client_id=...
6. Spoofed content show: Sign in to continue to Google Drive

## Mitigation:
Currently I can't reproduce this on another WebView browser:
- [FOSS Browser](https://github.com/scoute-dich/browser) on [Google Play](https://play.google.com/store/apps/details?id=de.baumann.browser1&hl=in&gl=US)
- Yandex Browser Lite

They do mitigate this spoof vulnerability by only displaying website on the address bar when it successfully loaded.

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

bug 1681103 comment 3 and following describes a separate issue that I'm moving to this bug.

testcase: attachment 9194803 [details]
result: attachment 9194804 [details]

There seem to be two failures to follow the [specified behavior](https://html.spec.whatwg.org/multipage/history.html#shared-history-push/replace-state-steps):
1. relative URL is resolved wrt to baseURI (minor, annoying)
2. there is no same-origin check (horrifyingly insecure)

I don't have a Firefox Lite to experiment with so I don't know if the same-origin check is always skipped or if it's only skipped in the case of relative URLs, but either way this POC demonstrates exactly why that restriction is in the standard!

I'm surprised either of these would be performed by the FF Lite browser front-end. I would have expected `replaceState` and `pushState` would be executed by the underlying platform WebView and the security checks should be at that level.

Irvan: what device do you have and android version? Does the default browser, or other WebView-based browsers have the same problem on your device? In bug 1581103 comment 0 you say the original problem doesn't reproduce in other browsers so it's likely you already tried this, but I'm very surprised at the thought of rolling our own `replaceState()` implementation.