Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Tuesday 16 August 2011

Securing Full-Screen

Some Web apps would benefit from displaying full-screen, without any non-app content visible. Obvious examples are watching video and playing immersive games. A while ago I proposed a Web API to enable this, and Chris Pearce is making good progress implementing a version of it in Firefox. A slightly different version of it is in Safari now too.

Our biggest issue right now is how to make it secure. The perceived threat is a malicious page going full-screen and then displaying something that looks like the content of another site, say the user's bank, complete with false URL bar --- or the content of a native application or the operating system, for that matter.

There are a few things we can do to make it harder for a malicious application to go full-screen. We can ensure that full-screen requests are only honoured from scripts triggered by user input (mouse clicks and keystrokes), much like requests to open popup windows. We can make sure that when going full-screen, we display a clear message describing how to leave full-screen --- like Flash does, but hopefully better. Then if a malicious page goes full-screen when the user didn't want to, the user will probably exit full-screen immediately.

A harder case is when the user intentionally goes full-screen to watch a video or play a game, but the application later tries to abuse full-screen status by spoofing another page or application. Most spoofing attacks require user input that the browser can detect, so for full-screen video and other applications that don't require much input, we could show a real URL bar while the user is typing input, so the user knows the true domain. However, many applications (games) want to be full-screen while receiving the full range of user input. It's unclear how we could distinguish such applications from a spoofing attack. The risks here already exist to some extent, if an application can persuade users to manually go full-screen, for example by pressing F11 in Firefox.

This feature seems particularly challenging to design because browser security often depends on the assumption that the user can visually identify the domain of the current page at all times, and full-screen violates that by definition. (However, mobile browsers seem to violate that assumption by hiding browser UI most of the time; I wonder how browser security people feel about that.)

This problem would be a good one for security researchers to study and solve! I think the world would be a better place if security research focused more on constructive solutions to problems like this one :-). Anyway, feedback and ideas welcome from anyone, security researchers or not.

Comments

Josh Triplett
Why not do what video fullscreen does, and don't allow scripting to initiate fullscreen at all, in response to user input or otherwise? You'd get the equivalent of the old "press alt-enter if you want to play fullscreen".
Anonymous
F11 is all we need on the desktop. One extra button press to go full screen is not much to ask a user for. Only possible new feature/API could be a UI hint on how to get to the full screen mode, if a page needs that. Any automatic full screen mode is asking for trouble. The simplest problem I can see is people getting stuck in that mode and asking for help to get their "regular internet" back.
Robert
People are used to having in-page UI to trigger full-screen. Relying on browser UI doesn't even solve the problems; see paragraph 4 of my post. Do people have problems "getting stuck" with the fullscreen API Flash offers now?
Tommy McAnonymous
How about not going full-screen? Maybe full-ish-screen is a good compromise between as full-screen as possible while still allowing room for a bit of browser chrome for security. Given today's vast array of screen resolutions, it's not like developers could count on "full screen" meaning anything with regards to resolution anyway.
funtom
I'd suggest making obligation to specify resource URL at the time of calling full screen mode and display a message to the user once the URL changes.
Rob Sayre
I'm still wondering about the perceived threat. If a large percentage of users don't understand the difference between browser UI and web content, what's been made worse? I'd like to see a really good study on user awareness of browser trust boundaries. My guess is that awareness is close to 0%, but data would be awesome.
Anonymous
"I think the world would be a better place if security research focused more on constructive solutions to problems like this one" There's an assumption this isn't already the case. You'd be surprised. The thing is UI developer often choose to completely ignore the security implications of their work and in-house security teams often ignore suggestions regarding UIs as 'not a real bug' or 'subjective'. From my perspective as a security researcher, I don't waste my time anymore unless asked. "I'd like to see a really good study on user awareness of browser trust boundaries. My guess is that awareness is close to 0%, but data would be awesome." There are solid studies about but I can't go fishing them out during work hours unfortunately.. "How about not going full-screen? Maybe full-ish-screen is a good compromise between as full-screen as possible while still allowing room for a bit of browser chrome for security." One of my various use cases: HD TV in the front room. I want to watch the Formula One on BBC iPlayer using HTML5, rather than Flash. Can't because I can't full screen unless I want browser bar taking up valuable real-estate. --- At the risk of going somewhat application-layer gung-ho against this problem, couldn't you use the same regression testing suites that Firefox has to ensure the UI looks as intended to ensure that no-one is emulating that UI elsewhere on the page? Speed issues would be easily taken care of and there's little to no chance of a false positive. It would have to be part of a package solution though.
Anonymous
A more realistic solution might be to disable forms and scripting related to forms whilst the user is in the full screen. Is there a use case where anyone wants to use forms in full screen? A full-screen video game invariably uses its own UI. If it wants to use web forms then it should expect the other things that come with the web... like an address bar.
RemiB
like while playing a video on desktop app, while don't you show the url on mouse move ?
Moldován Eduárd
How about educating the user? Show him where he is, in a non obtrusive way, like a faded minimalist browser ui. And if he is tricked, then he is tricked on his own responsability. This o course might be a solution next to the ones mentioned by you.
Anonymous
How about asking for permission to go fullscreen? Like browsers already do for other features like geolocation.
Gerv
The goals "provide a web page with the ability to control the entire screen area" and "make sure the user can always see security indicators" are mutually exclusive. Which one do we loosen? I think, in fact, the "full page" spoof is going to be less common than you think. It's hard to make a web page which spoofs someone's desktop so they are not looking. Use Personas? You are pretty unspoofable? Any other desktop customization? The same. Flash has got away with the "press Esc to exit full screen" notice fading out for a while, and I haven't seen reports of full-screen flash spoofs in the wild. As long as people can always exit, I say we just do what they did. Gerv
Robert
funThomas: that doesn't solve anything. The problem is when a malicious app is full-screen, displaying its own content but making it look like some other app. Rob: that's a good question. rushyo: "There's an assumption this isn't already the case. You'd be surprised." I have read plenty of security literature, and I have security researcher friends (e.g. Dawn Song) who I talk to regularly, and security research is definitely still far more about attack than defense. OK, sometimes once you see the attack the defense is obvious, but for most interesting work that isn't so. Trying to make sure "no-one is emulating the browser UI" sounds really hard to me, in terms of coming up with the right perceptual metrics. Blocking from controls wouldn't help at all, they can be emulated with canvas and JS if necessary. RemiB: as I suggested in paragraph 4, that's OK for video but won't work for games. Moldován, Eduárd: those suggestions won't help much; I covered them in my post. Gerv: forcing people to use Personas might indeed help. It's an interesting idea, but might be too radical. Flash getting away with it counts for something, but we have to consider the possibility that attacks just haven't become popular yet for some reason, e.g. there are currently easier methods to achieve the same ends, or simply that they haven't become fashionable yet. Remember that we knew about CSS-based history sniffing for years before it suddenly became a hot issue. Patching in a fix late sucks.
Zack Weinberg
There's some evidence that UI spoofing attacks work even if you aren't fullscreen -- see for instance http://mayscript.com/blog/eric/browser-ui-spoofing-attack-revisited, where a fake pop-up dialog box tricks users into entering credentials. It's pretty easy to discover that the pop-up is a fake, but people don't bother. I think the long-term solution is BrowserID. You can't give your credentials away if you didn't have them to begin with.
Anonymous
i'm fine with going full window (like some browsers do video right now) then leaving it up to the user to press F11
Anonymous
"Blocking from controls wouldn't help at all, they can be emulated with canvas and JS if necessary." Doesn't mean there not an aid though. I don't think anyone's going to come up with a silver bullet (you've already established reasons why in your post - trust issues rarely have an explicit solution) but that doesn't mean you can't put down layers of difficulty. Malware writers ignore harder vectors if the ROI doesn't justify it. "Gerv: forcing people to use Personas might indeed help. It's an interesting idea, but might be too radical." Taking a cue from Visa/Mastercard could we have a unique message/icon somewhere on the UI? We could automatically assign one (something like a Gravatar) so it wouldn't require user interaction or a particular decision. The downsides are only a study would illuminate whether this is really effective and there'd need to be some measure of associated user education to maximise its utility. "security research is definitely still far more about attack than defense." I still maintain that depends on the side of the fence you're on and which books you read. Independent researchers have a tendency to deal in attack. This is because in-house security researchers tend to consider themselves 'the defenders' and don't accept nearly as much input on matters of defense. On the other hand inside every competent enterprise there's a security team that deals almost entirely in defense and very little in attack. Their literature deals very little with penetration testing and much more with handling modelling, analysis, policies, user education and defense in general.
Smylers
Another common scenario for wanting full-screen is displaying presentations (using HTML as an alternative to something like Powerpoint). These require complete full-screen with no chrome (it's very distracting when presenters have bits of chrome and so on around their slides), for the presenter to be able to use the mouse pointer to point to things, and for full keyboard input to be available (many presenters script various navigation shortcuts).
Ian Melven
Hi Robert, a good post, it's nice to see this being discussed publicly. I agree wholeheartedly about the focus on attacks rather than defense, this was discussed pretty widely at Blackhat this year. Personally, i like the idea of showing the URL bar if the fullscreened site navigates elsewhere. There are some edge cases here, and there's an objection the user could 'just miss it' but I think it's not a bad compromise. The points about spoofing being difficult because the user may have customized or non standard UI are valid, but there's so much fingerprinting possible by web content that I'm not sure how solid of a mitigation this is. As far as Flash goes, I believe many of the attacks around full screen mode involved clickjacking the Flash settings manager, which thankfully Firefox does not have to deal with :)
Smylers
Ian, it would not be acceptable for a presentation to show the URL bar every time the speaker switches to the next next slide.
Robert
Ian: if the page navigates elsewhere we will leave full-screen automatically. But that doesn't help with spoofing issues.
Juan Lang
Browser security people don't much like phone browsers: http://mu.cs.ucdavis.edu/~fhsu/papers/upsec08.pdf
Anonymous
What about restricting fullscreen to HTTP sessions? Most of the fullscreen takeover scenarios involve things like bank accounts and web shops, usually using HTTPS.
Robin Berjon
Assuming fullscreen can only be triggered by deliberate user action and said action immediately displays a message explaining how to exit full screen, given how difficult it is to credibly simulate a given user's UI I think it's overall fairly safe. Given the constraints I don't see how 100% security could be attained, but the cost of crafting an attack by these means compared with its odds of success seems highly prohibitive to me.
Robin Berjon
Hey by the way it just dawned on me that I'd forgotten to mention http://www.w3.org/TR/view-mode/ which may have some interest in helping to specifically style a full-screen context.
Josh Cogliati
This is kind of a side comment, but when I click on flash to make it full screen, I really just want it to be the full size of the tab I am browsing it in. Unfortunately the ui usually does not give that option. If there is a full screen api, it would be very nice if there was an option to never allow full screen to actually be the full screen. Also, "We can ensure that full-screen requests are only honoured from scripts triggered by user input (mouse clicks and keystrokes), much like requests to open popup windows. " in practice means that the web page waits until I click on the page trying to do something else (like click on a link) and instead it opens the popup window then.
Robert
Yeah but at least we can be very confident that you're looking at the screen and will be able to see the warning message we show.
Matt McMahon
Warning messages won't work; they'll just be ignored. I'd suggest a simple compromise: No matter what the page wants, no matter what preferences the user sets, what toolbar the user hides, or what plugins the user installs, the user should always be able to get their current location by moving their mouse to the top of the screen. If the browser is currently chrome-less (e.g., to play a movie) this would mean having the URL box slide down (like it does with Firefox's F11 full-screen currently). And yes, I think this should apply equally to full-screen flash (and other plugins) as it does to plain-old-html. No preference, plugin, or act of god should be allowed to disable this functionality. (Some day we may be able to figure out "installing web apps" and "pin as app-tab" well enough to avoid security issues, but that day hasn't yet arrived.)
Robert
It's not clear to me that "Press Esc to exit full-screen" will be ignored to the point that users don't know how to exit full-screen. Your suggestion about moving the mouse to the top of the screen would break some full-screen apps.
Andrew
I'd suggest: * Requiring the user to confirm full-screen mode. The dialog would describe how to get out of full-screen mode in a way that can't be blocked by the content, and how to tell that you are still in full screen mode. * A 1 pixel red border around full-screen content. The content is not quite fullscreen (it loses two pixels of width, and two of height), but is close enough. I hypothesise that this should be enough to stop savvy users from being caught by UI spoofing. Less savvy users are already fooled by non-full-screen UI spoofing, so the remaining problem is not really unique to fullscreen mode.
Anonymous
good movies and trustworthy video web links, Terrarium TV App PlayView, CinemaBox HD, PlayBox HD and also much more nice.