By: Ben Toews
TL;DR: preventDefault can be bad
In playing with the preventDefault method on JavaScript events, it occured to me that one can easily hijack events that should get passed through to the browser. The example that I will be discussing here is the ctrl+f or ⌘+f combination. This ubiquitous key combination results in a search box of some type being displayed to the user. With browser and OS key bindings, there is a user expectation of continuity. We are conditioned as users to expect that pressing these key combinations will have a certain effect. The interruption of this continuity can have security implications.
In the example hosted here, a list of information that a user might be tempted to search through is presented. JavaScript on the page hijacks the ctrl+f and ⌘+f combinations, presenting a search box that is nearly identical to the browser search box users would see running Google Chrome on OSX. While normally, JavaScript wouldn’t have access to the contents of the search box, the fake search box is obviously accessible to the malicious site.
Fake Browser Search Bar
Real Browser Search Bar (Google Chrome on OSX)
The ability of a malicious site to interrupt the expected continuity of user interaction with a web browser constitutes a breach of user trust on the part of the web browser. Because the user trusts that this key combination will trigger a browser event, they will trust the search bar presented by the site and interact with it as they would with the browser. Other key combinations could be similarly attacked. For example, ctrl+s/⌘+s or ctrl+o/⌘+o could be hijacked and could display a fake dialog claiming that the user’s password is required for file-system access. Specific attack scenarios aside, it is problematic to have ambiguity about the boundaries between browser and web app. More generally, a lower trust component should not have the ability to affect the behavior of a higher trust component.
This page in probably won’t be convincing for users of different operating systems or browsers, but with a bit more effort, the script could detect browser and OS and display an appropriate search box. It could also easily emulate other browser behavior like highlighting entered text or scrolling around the page.
What is the solution, though? There are a few solutions that come to mind:
- Place the browser search box in a part of the browser that could not be confused with website content.
- Warn the user when a site attempts to call
preventDefaulton an event that is registered as a browser key binding.
I raised this issue to the Chrome team and it was labeled as a low-priority issue. I’m not sure that I disagree with that analysis, but I do think that this is an issue that should be considered.
This is a great trick!
Very simple and in same time interesting case!
Sigh…. Nice to see another way that your information can be leaked
& to mke it a high priority issue.. have it show up in the “wild”
[...] More technical details about the exploits are here and here. [...]
[...] More technical details about the exploits are here and here. [...]
[...] hebben nu ook aangetoond dat de zoekfunctie in browsers gekaapt kan worden zodat een hacker gegevens kan bemachtigen via een eigen boxje die met CTRL F wordt opgeroepen, [...]
Indeed a simple but effective tric.
I wonder, if you’d do this with the Chrome Extension manager, how many people would be tricked in installing a malicious addon?
Could this be used to hijack the browser menu commands as well? In your example CTRL+F brings up the “fake” search box, but choosing the “Find” command from the menu in Chrome does not.
No. Ctrl-F is a keyboard-shortcut to trigger the “Find” functionality normally started by clicking on the menu item, where as clicking on the menu item das not trigger the “Ctrl-F” keyboard event on the website.
The website can capture “Ctrl-F” because it can capture keyboard events, and then can prevent that that same keyboard event is passed on to the browser application itself – it’s that last step, the prevention of the passing-on, that gives authority to the input box opened by the javascript, because the browser-provided input field doesn’t appear at all.
[...] A to najważniejszy fragment kodu źródłowego tego ataku: [...]
Good idea, if you read the Browser information, you can fake any browser.
When I think about it, can a webside read your Firefox “Persona”? If not, everyone who is using a Persona in Firefox, will notice the difference of colours and background.
One good thing: Does not work with noscript active
[...] im letzten Monat hatte das Sicherheitsblog Neophasis darauf hingewiesen, dass man mit der DOM-Methode preventDefault() den Benutzern recht einfach ihre [...]
[...] security researchers have blogged about the issue here and [...]
[...] A to najważniejszy fragment kodu źródłowego tego ataku: [...]
[...] funktionieren würde, haben zwei dokumentierte Versuche aus den letzten Wochen gezeigt. Auf dem Neophasis Security Blog wurde zunächst über die Möglichkeit des “Browser Event Hijacking” berichtet, der [...]
[...] Η μέθοδος hacking που χρησιμοποιείται δεν είναι καινούρια, αλλά γνωρίζει ιδιαίτερη έξαρση, μετά από δημοσίευση της στο Internet. http://labs.neohapsis.com/2012/11/14/browser-event-hijacking/ [...]
[...] Browser Event Hijacking (2, 3) [...]
[...] Browser Event Hijacking (2, 3) [...]
[...] Browser Event Hijacking (2, 3) [...]
[...] Bypassing (1) 13. Bruteforcing/Abusing search functions with no-rate checks to collect data 14. Browser Event Hijacking (2, 3) 15. Bypassing Flash’s local-with-filesystem Sandbox Process oversight. Due to the [...]
Excellent little trick, thanks.
[...] [...]
[...] 14. Browser Event Hijacking (2, 3) [...]