While this is sufficient for the protection of a user who has installed our browser add-on, we deem it desirable to also protect users who are using different browsers or have not installed TabShots. This can be achieved through an optional server-side component which can aggregate information sent by individual browsers and, after validation, add the reported URLs in a blacklist. This server-side component would be the logical next step, to transition from the protection of a selected number of users (those with TabShots installed) to more global protection, similar to Google’s SafeBrowsing list of malicious sites which is currently utilized by many modern browsers.
In the stand-alone version of TabShots, once a user realizes that she is being targetted by a tabnabbing attack, she is instructed to simply navigate away from the malicious site without entering any private information. With a server-side component in place, the user can mark the current page as a “tabnabbing attack” through the UI of our add-on. Once this happens, TabShots transfers to a server-side, data aggregator the following information:
- The URL of the current page
- The image of the page before the user switched tabs
- The image of the page after the user switched tabs
The server-side aggregator has the responsibility of receiving reports from multiple users, filtering-out false reports, and then adding the true positives on a blacklist. Filtering is necessary to stop attackers who wish to harm the reputation of the TabShots blacklist, by submitting legitimate sites that would then be automatically blocked. Our server-side service operates as follows: For every previously unreported URL received by a user with TabShots installed, our service spawns an instrumented browser that visits the reported URL and captures a screenshot. Assuming that the current page is indeed performing tabnabbing, the malicious scripts will try to get information about their “visibility” through the window.onBlur event. Since our browsers are instrumented, we can trigger a window.onBlur event without requiring the actual presence of extra tabs. In the same way, any callbacks that the script registers using the setTimeout method, are immediately triggered, i.e., the malicious code is tricked into performing the tabnabbing attack, without the need of waiting. Once the callbacks are executed, our system takes another snapshot of the resulting page. The set of screenshots captured by the user is then compared with the set that was captured by our system. To account for changes in the pages due to advertisements and other legitimately-dynamic content, the screenshots are accepted if either the server-generated set is an identical copy of the user-generated one, or if they match over a certain configurable threshold (i.e. everything matches except certain dynamic areas).
Once the above process is complete, the URLs recognized as true positives are then sent to a human analyst who will verify that the resulting page is indeed a phishing page. A human analyst is necessary since our system cannot reason towards the maliciousness or legitimacy of the final changed page. Note, that human-assisted phishing verification is currently one of the most successful approaches, e.g., PhishTank, and its results are more trustworthy than any automated phishing-detection solution. The URLs that are marked as “tabnabbing”, can then be added to a blacklist that browsers can subscribe to. The users who report URLs that either never reach a human analyst (because the server-side screenshots did not match the user-provided ones), or reached a human analyst and were classified as “non-phishing” are logged, so that if they are found to consistently submit false positives, our system may adapt to ignore their future submissions.
Submitting screenshots to a third-party service might be considered privacy-sensitive, so we take care to address these issues accordingly. Therefore, TabShots only submits a screenshot after explicit user approval. Additionally, the screenshot submission is only triggered after the user flagged a tabnabbing attack, so it is very likely that the captured site is malicious of nature, and does not contain any sensitive information.
While tabnabbing is a relatively new phishing technique, attackers have been trying to convince users to voluntarily give up their credentials for at least the last 17 years. Several studies have been conducted, trying to identify why users fall victim to phishing attacks and various solutions have been suggested, such as the use of per-site “page-skinning”, security toolbars, images, trusted password windows, use of past-activity knowledge, and automatic analysis of the content within a page. Unfortunately, the problem is hard to address in a completely automatic way, and thus, the current deployed anti-phishing mechanisms in popular browsers are all blacklist-based. The blacklists themselves are either generated automatically by automated crawlers, searching for phishing pages on the Web or our crowdsourced.
Tabnabbing attacks are a type of phishing attack where the attacker exploits the trust a user places in previously opened browser tabs, by making the malicious tab look like a legitimate login form of a known Web application. This happens when the user is looking at another tab in the browser, making it very hard to detect and very easy to fall victim to. Currently available countermeasures typically depend on several specific characteristics of a tabnabbing attack and are easily bypassed or circumvented. Our countermeasure, TabShots, is the first to do a full visual comparison, detecting any changes in an out-of-focus page and highlighting them, aiding the user in the decision whether to trust this page or not. Our evaluation shows that TabShots protects users against potential tabnabbing attacks, with a minimal performance impact. Furthermore, an experimental evaluation using Alexa’s top 1,000 sites shows that 78% of these sites fall within the safe threshold of less than 5% changes in subsequent snapshots. This means that TabShots is fully compatible with these sites, and has very little impact on another 19%.