Industry Observations-Technical Insight

“HREF with Target” Weakness

Some questions have been popping up about the browser behavior around links in new tabs.  Specifically, the page opened in the new tab can cause the original tab to navigate away, possibly leading to a fake login window or other spoof.

 

Target=_blank: Not Too Bad

Every year or two we get questions about a funny little gotcha in browser behavior related to links that open in new tabs. (Side note, the behavior is the same for “target=_blank” and “target=foobar”) The short version is that the page you open in a new tab can usually force the original page to navigate away to any specified URL.  This happens in the background and could be used to do something sneaky.  But is it really all that bad?  I don’t think so.

 

The Exploit

The best exploit is to make a spoofed version of the original site’s login page, so the next time the victim returns to the original tab, they just put in their credentials without noticing that they are no longer on the right domain.

For example:  Say you (the victim) are on fakesocialsite.com, and you click a link to an article about cat personalities.  A new tab opens up with catpersonalities.com.  While you are reading, your original tab navigates to fakedsocialsite.com/login.  When you close your tabby tab, you are greeted with page that looks totally legitimate saying you need to log back in.  Maybe it even has the little green lock.  You don’t notice the slightly wrong domain name, so you send your username and password to a bad person, and that’s not good.

 

Why Does this Work?

Short answer, the living HTML spec says it should work that way.  https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-context

There are legitimate flows for this, such as opening a new tab to pay with PayPal, then the PayPal tab could tell the original page that the transaction is done by navigating to a “complete” URL.  However in modern application design we would probably do that with backend communication between the services and just make the original page reactive to state changes from the server.  But anyways, the spec says you should be allowed to do it that way.

 

Can an Attacker Do Anything Worse?

It doesn’t look like it.  If the new tab is in the same origin, then JavaScript running in that new tab has access to the whole original tab, which is bad.  Then again this assumes an attacker has JavaScript running somewhere in your domain, in which case they don’t really need this to get what they want.

If the tab is on a different domain, then this is all they can do.  In fact, unless you are on a really old browser, the only practical thing they can do is navigate that page away.  They can’t even read the current value of the location.  The attacker has write access to your location, but not read access.  See this screenshot from Chrome, if you don’t believe me:

href blank

 

Why Isn’t This So Bad?

It still sounds like a nice little attack, right?  Most people will fall for this if your domain name and spoofed site are good enough.  But the reason I don’t consider this a huge deal is because I don’t expect you’d have much more success with this than with a straightforward spoof attack.

For example:  Say you (the victim) are on fakesocialsite.com and click that link to read about cat personalities.  Now imagine that it just immediately redirects to fakedsocialsite.com/login where you are greeted with a page that says “you have been logged out, please log in to continue.”  Most people will fall for that as well.

 

What Should I do?

I will admit that using this trick makes a spoofing attack a little more effective.  So, as a developer, it’s a good practice to always add “rel=noopener” to links that open in new tabs, unless you actually intend to let the destination navigate your original tab.  This previously didn’t work in Firefox, but in March they added it in Firefox 52. This severs the link between form the new tab to the one that opened it.  It also has some performance benefits.

Do this:

<a href="http://localhost/hack.html" target="foobar" rel="noopener">Link</a>

 

Note on IE and Edge

Some are saying IE and Edge don’t support this rel=noopener, which is true.  However, in my testing neither currently allow the new tab to relocate the original tab unless they are on the same domain.  So it’s not really needed.

 

Conclusion

Due to all the questions we get, here at WhiteHat we’ll be opening informational level findings for this issue when we see links that open in new tabs.  But I wouldn’t make it your top priority, most of you have bigger fish to fry in your Sentinel results already.

 

Sources:

https://html.spec.whatwg.org/multipage/browsers.html

https://developer.mozilla.org/en-US/Firefox/Releases/52

https://www.jitbit.com/alexblog/256-targetblank—the-most-underestimated-vulnerability-ever/

https://developers.google.com/web/tools/lighthouse/audits/noopener

https://jakearchibald.com/2016/performance-benefits-of-rel-noopener/