Tabnabbing relies on the tab mechanism, which is common in all modern browsers. Users visit Websites, but instead of navigating away from that Website when they want to consume the content of a different Website, they open a new tab and use that tab instead. The old site remains open in the old tab, and many tabs can accumulate over time in a user’s browser. A 2009 study of users’ browsing habits revealed that users have an average of 3.2 tabs open in their browsers. We expect that today, this number has increased, due to the sustained popularity of social networking sites and Web applications that constantly update a user’s page with new information. The latest features introduced by browsers attest to this popularity of multiple open tabs, since they give the user the ability to “pin” any given tab to the browser and treat it as a Web application.
The steps of a tabnabbing attack are the following:
- An attacker convinces the user to visit a Website under his control. This Website appears to be an innocuous site that is not trying to fool the user into giving up her credentials. What the attacker must do, is convince the user to keep this tab open, and browse to a different Website. This is easily achieved in a wide range of ways, for instance by providing an article that is both very interesting, but also too long to read in a single go, or some sort of free product that will be available in the near future. Directing the user away from the attacker’s site is straightforward by adding the target=”_blank” attribute to interesting hyperlinks so that new links automatically open in a new tab or window.
- The user keeps the attacker’s Website open and uses other tabs to surf the Internet.
The attacker realizes that his window is currently not in focus, and, after a possible delay of a few seconds in order to make sure that the user is busy consuming other content, changes the title, favicon and layout of the page to mimic the login screen of a Web application, for instance the user’s Web mail or social networking site. The attacker can choose a default Web application (like Gmail) under the assumption that most users have a Gmail account or can combine the tabnabbing attack with a history-revealing attack, and present the login of a Web application that he knows is visited in the past by the user.
- At some point in the future, the user recognizes a tab with a familiar favicon (e.g. GMail) and unwittingly opens the attacker-controlled tab. At this point, the user is no longer checking the URL of the Website, since it is a Website that she opened in the past and thus “trusted”. Given a convincing login screen, the user proceeds into typing her credentials in the given forms which are then transferred to the attacker, thus completing the tabnabbing attack.
The main difference between tabnabbing and traditional phishing attacks is that the fake login form is decoupled from the visit of the malicious Website. Thus, users who have been trained to spot phishing attacks by immediately checking the URL of the page they open may fall victim to this variant of phishing. This “delayed maliciousness” can also be used to evade detection by any automated honeyclients which may be autonomously searching for phishing pages based on various heuristics. If the honeyclient does not stay for long enough on the malicious page or does not trigger the window.onBlur event, then the actual phishing page will never be shown and the attacker can avoid detection.
OVERLY SPECIFIC DETECTION
An attacker needs to change three things in order to conduct a successful tabnabbing attack: the page’s title, the page’s favicon, and the page itself. Accordingly, currently known countermeasures depend on changes in these three properties or include even more specific tabnabbing characteristics. This overly specific detection gives the attacker more flexibility to avoid detection.
Chrome keeps all tabs visible but shrinks the space allotted to each Tab.
After a number of tabs, Firefox hides older tabs in order to make space for the new ones.
One example of such flexibility is carrying out a tabnabbing attack without changing the title of the tab, simply by taking advantage of the tabbing behavior within a browser. While conducting our research, we noticed that different browsers behave differently when a user has many open tabs in one window. Chrome starts resizing the label of each tab, in an effort to keep all tabs visible. Here, one can notice that most of the title of each tab is hidden while favicons remain visible. On the other hand, Firefox starts hiding tabs that the user can access by clicking on the left arrow. Moreover, Firefox preserves the title bar above the tabs, which Chrome dispenses in an effort to maximize the amount of space available for HTML. In the case of Chrome, assuming that a user has many tabs open, the attacker can avoid the title change altogether, since it will likely not be visible to the user anyway.
A successful tabnabbing attack depends on the user visiting a malicious page, shifting focus to a different tab, and returning at some point, after which the malicious page has changed its looks to resemble a popular application’s login form. In itself, a tabnabbing attack is extremely obvious to detect, since a convincing phishing page will differ from the previous content. Detection is however complicated by the tab being out of focus, and the user placing some trust in previously opened and visited tabs.
TabShots takes advantage of these obvious changes needed by a successful tabnabbing attack, by remembering what a tab looks like before it loses focus, and comparing that to what it looks like when it regains focus. Any changes that happened in the background will be detected, and communicated to the user by means of a colored overlay. This allows the user to decide for herself whether the changes are innocent (e.g. an incoming chat message) or malicious masquerading (e.g. a login form and GMail logo popping up).
TabShots is currently implemented as an add-on for Google Chrome, but could easily be ported to other browsers supporting an add-on system, provided they offer a reliable way to capture screenshots of tabs. In the following paragraphs, we discuss several implementation techniques and strategies for the major components of TabShots.
Capturing Tabs. TabShots records the favicon and captures screenshots of the currently focused tab at regular intervals, keeping track of the latest version. This latest snapshot will be the basis for comparison when a tab regains focus. Capturing a screenshot of a tab in Google Chrome is trivial since the browser offers an API call to capture the currently visible tab of a window. Capture data is stored as a data URL. Capturing snapshots of a tab at regular intervals is a deliberate design decision, allowing TabShots to handle changes that happen in a tab while it is in focus. These changes typically occur in highly dynamic applications, such as Facebook or Gmail, which often use AJAX techniques to dynamically update the contents of their pages. Ideally, a tab could be captured right before it loses focus, but since Google Chrome does not offer such an event, this feature cannot be implemented without a severe usability and performance penalty.
Comparing Tab Snapshots. When a tab regains focus, TabShots needs to compare the current snapshot data with the stored data and detect any differences. Favicons are compared by source, and the screenshots are compared visually. Each screenshot is divided in a raster of fixed-size tiles (e.g., 10×10 pixels). Each tile is compared to its counterpart in the stored snapshot data. If the tiles do not match exactly, the area covered by it is marked as changed. The rastering and comparison algorithms are implemented using the recently introduced HTML5 canvas element, which offers extensive image manipulation capabilities. One potential disadvantage of the screenshot analysis is the difficulty to detect a small change in a page that results in a visible shifting of contents (e.g. adding one message in front of a list). Such false positives may be addressed by a smarter comparison algorithm, that is able to detect movements within a screenshot.
Highlighting Differences. Once the differences for a focused tab are calculated, TabShots injects an overlay into the page. This overlay is completely transparent, except for the differences, which are shown in semi-transparent red. The overlay is positioned in the top left corner and covers the entire visible part of the site. Setting the CSS directive pointer-events: none ensures that the overlay does not cause any unwanted interactions, and allows mouse and keyboard events to “fall through” the overlay onto the original content. In order to detect a malicious page from actively trying to remove the overlay from the DOM, we implement a mutation event listener that is triggered when an element is removed. It then checks whether the overlay is still present and if not, immediately warns the user of this active malicious behavior.
Security Indicator. In addition to the overlay of the changes on the current page, TabShots also has a browser toolbar icon, indicating the current status of the site. The icon’s background color indicates how much of the site has changed, ranging from almost nothing (< 10%, shown as green), over moderate (< 40%, shown as yellow) to high (> 40%, shown as red). Clicking on the icon shows a miniature view of the current tab combined with the overlay of detected changes. Having a security indicator as part of the browser environment ensures that even if a malicious page somehow manipulates or removes the overlay, the user still has a trustworthy notification mechanism. The current notification mechanism is quite subtle but follows other commonly accepted and implemented notification mechanisms, such as displaying a padlock when using a secure connection. If desired, the notification mechanism can be easily extended to something more visible, such as the warnings given in case of an invalid SSL certificate.
ALTERNATIVE DESIGN DECISIONS
During the design and development of TabShots, we considered different paths and options, leading to the outcome described here. For completion, we want to discuss two topics that drove the design and workings of TabShots in a bit more detail.
Regularly Capturing Tabs. Currently, TabShots makes capture of a tab at regular intervals, so it can compare the capture taken when the user returns to a fairly recent capture from before. Ideally, we would make a capture when the user leaves, and capture when the user returns. Unfortunately, Chrome does not trigger an event when a user leaves a tab, only when a user focuses on a new tab. At the moment this event is received, the new tab is already displayed. To take a screenshot of the tab that was just left, TabShots has to switch it back into display, take a capture and switch back to the new tab. Unfortunately, this cannot be implemented without very briefly revealing this process visually to the user, with a degraded user experience as a consequence.