Closed Bug 836610 Opened 12 years ago Closed 7 years ago

Content can permanently DoS the URL bar

Categories

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Browser
Platform:
x86_64
Linux
Type:
defect

Tracking

(blocking-b2g:-, b2g18+)

Status:
RESOLVED INCOMPLETE
Project Flags:
blocking-b2g -
Tracking Flags:
Tracking Status
b2g18 + ---

People

(Reporter: cjones, Unassigned)

References

Details

(Keywords: sec-moderate, Whiteboard: [UX-P?] c=browser u=user [sprintready])

This is another symptom of bug 835152. Content can do something exceptionally simple, like - create a <body> that's scrollable (taller than viewport) - register onscroll listener - do nothing until a scroll event says window.top is greater than 20 or so pixels - register touchstart listener on document and always evt.preventDefault() the touchstart event This will prevent the URL bar from ever being shown again. This can obviously be used for clickjacking attacks too. Josh, how do you feel about adding a button to the browser's bottom bar that brings the URL bar into view? Kind of like tapping the window title bar on MobileSafari, but slightly kludgier. Not just a usability issue, but also a potential security issue.
Flags: needinfo?(jcarpenter)
(I remembered this issue when playing with http://lab.hakim.se/reveal-js, which unintentionally DoS's itself.)
Chris, I don't get the clickjacking attack possibility. Could you elaborate ? Otherwise I fully agree with this.
> Chris, I don't get the clickjacking attack possibility. Page DOS'es the URL bar, shows its own URL bar, simulates the browser.
Ok right, thanks Justin :) I was seeing that we still get the bottom bar so at least a website couldn't fake another application, but I missed this.
Per bug #835152, we know that our current header implementation is a bit clunky in practice, and we want to improve on it. I do not recommend we add a "show header" footer button, as it does not provide enough end-user benefit to bless with such prime UI positioning. We could instead look at doing away with the current auto-hide behavior and instead implement a wrapper-style fullscreen mode, but I'm skeptical that most users would discover that functionality. This needs deeper UX investigation. Unless we determine the security issues are really blockers (I am not qualified to judge), I'd like to add this to our future features tracking docs and revisit later (1.1 or after).
Flags: needinfo?(jcarpenter)
Josh, if this happens, the only way to make the browser work again is to 1. reboot the phone, or 2. close the browser app by long-tapping on the home button. I contend that many users won't know about (2) and will resort to (1). Not like (2) is particularly good. I'm totally cool with doing something other than adding a button to the bottom bar, but I think we'll look really bad if sites can trivially DoS the "Firefox OS" browser in v1.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > Josh, how do you feel about adding a button to the browser's bottom bar that > brings the URL bar into view? Kind of like tapping the window title bar on > MobileSafari, but slightly kludgier. Are there any alternate proposals for how to fix? UX changes aren't really appropriate for v1.0.0 at this point.
> Are there any alternate proposals for how to fix? It's not clear to me that there's a simple way to fix this without changing the way the user interacts with the browser. Basically that would require Gecko to somehow keep track of where we /should have/ scrolled to, if the page hadn't mucked with the scroll height. If however the requirement is not to add any new /UI elements/ (which I recognize is not the same as "not changing UX"), I have a proposal: Instapaper on my Android phone hides its "chrome" when you double-tap on the screen. That's the only way to hide the chrome. It's not particularly discoverable, but presumably if you do it once, you'll know how to get the chrome back.
The problem with double-tap is that it's ambiguous with zooming. How can the user get the UI back once it hides? I agree that new UX at this point sucks, my to be clear my proposal is - clone the "back" icon ("<") - rotate it 90 degrees clockwise ("^") - put it in between "back" and "star" [ < ^ * ] No new strings or deep interactions to worry about.
> The problem with double-tap is that it's ambiguous with zooming. Ah, good point. I rescind my proposal, unless someone has an alternative, non-hokey gesture. (Two-fingered double-tap? :-p)
Let's get a security rating here and also a nomination for uplift when there's a solution implemented that can be evaluated for risk.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Whiteboard: [UX-P?]
Out of interest, how does Fennec deal with this?
Flags: needinfo?(chrislord.net)
Whiteboard: [UX-P?] → [UX-P?] c=browser u=user
(In reply to Ben Francis [:benfrancis] from comment #12) > Out of interest, how does Fennec deal with this? The toolbar visibility in fennec isn't based off of scroll position, so in a worst-case scenario, the only thing the page can do is make it visible when it wasn't previously visible by shrinking itself. The toolbar can always be scrolled onto the screen, we don't only show it at the top of the page. We have a separate 'margin' area and we intercept our calls to scrollBy and scroll this area before then scrolling the page (if there's any excess). This margin area offsets page rendering at the compositor level, so the page knows nothing about it. It's possible that a page could preventDefault on touch events and prevent the bar from reappearing, but in this scenario, a user can press back and the toolbar will reappear.
Flags: needinfo?(chrislord.net)
Blocks: b2g-dynamic-toolbar
Priority: -- → P1
(In reply to lsblakk@mozilla.com [:lsblakk] from comment #11) > Let's get a security rating here and also a nomination for uplift when > there's a solution implemented that can be evaluated for risk. If this was a permanent way to hide the URL bar, then that sounds serious - assuming that it is plausible for a web page to imitate the browser app, it could present any content in place of an expected URL, and then phish users etc. My feeling is that this is at least sec-moderate - I am not sure how difficult would be to plausibly spoof the browser app. FWIW http://lab.hakim.se/reveal-js doesn't DoS the 1.0.1. I need to do more testing to see if its still possible to reproduce this bug.
Keywords: sec-moderate
Dynamic toolbar work on b2g has begun now, so marking this as sprint ready. This should be fixed when bug 860812 is fixed.
Whiteboard: [UX-P?] c=browser u=user → [UX-P?] c=browser u=user [sprintready]
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/55560666
FirefoxOS is no longer under active development.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.