Tab Check

What is "Tab Check"?

Tab Check is a free online developer tool for checking whether a website is leaking URL data (domain, path and query) via the HTTP "Referer" header to other sites it links to and if a website's way of opening new windows or tabs (via window.open() calls or HTML anchor tags with the target="_blank" attribute) makes it vulnerable to the target="_blank" / window.opener attack.

What is the HTTP "Referer" header and what does it do?

It's a small piece of data sent by your browser as part of an HTTP request that tells the website you're visiting the page or domain you came from. So if you clicked on a link on Website1.test that leads to Website2.test, Website2.test is going to know that you came from Website1.test (in most cases; both the website and browser can be configured to send more or less data than that). This data may be used by a website to adjust the content it serves, however, it's usually just used for website analytics or to gather information about users.

What data can websites leak via the HTTP "Referer" header?

Depending on how the website, HTML document or individual anchor tag is set up, the header can leak:

• Nothing. The website you visit via an HTML link won't be able to tell whether you came from another website or just typed the URL into the browser yourself.
• Just the domain (e.g. https://google.com). While this isn't usually a big deal, it may be one if you're very privacy conscious or if the website you came from itself is sensitive information (e.g. websites that provide adult entertainment content, are related to a specific medical issue, etc.).
• The domain and path (e.g. https://google.com/path/to/specific/page/). If a path contains sensitive information (e.g. page on an embarassing medical issue) or if the website has lackluster security (e.g. usage of secret URLs without page-level access controls), revealing said path may allow a malicious website owner to acquire confidential information or even gain access to certain restricted functionality.
• The domain, path and query (e.g. https://google.com/path/to/page/?secret_value=42). While most query variables don't contain secret information (e.g. page=5 or theme=dark) some do contain data that may be sensitive (e.g. email addresses) or that may be used for certain attacks (e.g. the token used to protect against CSRF attacks).

What is the target="_blank" / window.opener vulnerability?

When a web page is opened in a new tab, certain browsers by default allow the newly opened page partial access to the window.opener object for the tab that opened it. With this access, the newly opened page can secretly redirect the user to a (seemingly) identical phishing page (by setting the window.opener.location property to a malicious URL). Here's a step-by-step breakdown of the attack:

1. User goes to GoodWebsite.test in browser tab no. 1.
2. User clicks a link on GoodWebsite.test that opens MaliciousWebsite.test in a new tab (browser tab no. 2).
3. User's browser automatically switches to the newly opened tab (browser tab no. 2).
4. While the user is distracted by the switch and is looking at the content in MaliciousWebsite.test, MaliciousWebsite.test secretly redirects browser tab no. 1 to GoodWebsiteLookalike.test that shows a "You've been logged out" message and a login screen that looks like it's from GoodWebsite.test.
5. User switches back to browser tab no. 1 and notices the new page.
6. User thinks he's still on GoodWebsite.test and types in his userame and password (not noticing the different URL in his browser's address bar).
7. GoodWebsiteLookalike.test uses the username and password to hijack the user's GoodWebsite.test account.

By default, this vulnerability is present in both <a> tags with the target="_blank" attribute set and in window.open() function calls. Obviously, the vulnerability is only relevant if the tag or function call is used to open pages on external websites.

How do I fix the target="_blank" / window.opener vulnerability?

If you're a website owner, there several different ways of mitigating this vulnerability:

• For <a> tags with the target="_blank" attribute. Set the rel="noopener" attribute. If you've already added the rel="noreferrer" attribute, you can use both by separating them with a space (rel="noopener noreferrer").
  • If you're unable to modify <a> tags, don't fret - according to MDN Web Docs, newer versions of the most popular browsers automatically assume noopener for HTML links with the target="_blank" attribute. This assumption doesn't seem to apply to window.open() calls at the time of writing.
• For window.open() function calls. Add noopener to the window features parameter (e.g. window.open("https://ExternalWebsite.test", "_blank", "noopener")). If you want to use the noreferrer window feature as well, just separate the features with a comma (window.open("https://ExternalWebsite.test", "_blank", "noopener,noreferrer"))
  • If you need to support older browsers or to know whether the window.open() call was blocked by a popup blocker (e.g. to ask the user to allow popups), simply open an empty window / tab, set the opener to null and then set the window's / tab's location to the intended web address (e.g. let win = window.open(); if (win != null) { win.opener = null; win.location = "https://website.test";}).

Not a web developer and don't know how to set these things up? No worries, I offer software development services on a freelance basis. If you're interested, click here to get in touch.

Where can I read more about this stuff?

The MDN Web Docs is a great developer resource for anything web related, be it info on browser support of different HTML, JavaScript and CSS features or detailed documentation of the aforementioned features. Here are the MDN Web Docs pages I used for sourcing (and double checking / verifying for the info I already knew) the information on how certain browser features work:

• Referrer-Policy
• Window.open()
• <a>: The Anchor element

While writing all of this, I at first wanted to just quote a bunch of excerpts (with proper attribution of course) from the site but decided against it due to how verbose and detailed it is (which may be a bit too much for someone who's just starting out in web development or who just wants a quick summary). As such, my own tl;dr on these topics excludes a lot of asterisks, nuance and leaves out a lot of supplementary info. So if you want a really in-depth overview on how the web works (or just dislike my writing style), be sure to check out the MDN Web Docs.