The Security Risk That Is Actually the Humble Link on Your Webpage
When opening a new tab on your web browser, you could be putting personal data at risk. Click here to learn more about how to take the necessary precautions.
Join the DZone community and get the full member experience.Join For Free
When you open a link using
target, for example, in a new tab (
target="_blank"), the browser may set the
window.opener of the new tab to be the original window. This is not done universally but Firefox and Chrome both do it. This means that the new tab can now access information from the original window/tab.
If it is on the same domain, then that is a lot, including cookies and content. If it is on a different domain, then the same origin policy will protect that information, though some things are still available.
These attack vectors are targeted and don’t represent a major risk. But, at the same time, the cost of doing this is less than the risk. So, I recommend taking the necessary precautions.
It is not uncommon for a single domain to have pieces built by multiple teams, especially as web components get better adoption. A vulnerability in any team contributing to the content now has the potential to impact all teams.
For example, https://badsite.com/login.html is built by team A and has a simple login to the backend. https://badsite.com/products.html is built by team B and is a public site that lists products. If the login had a link to products that opened in a new tab, then all JS in products can manipulate the login page. For example, by silently injecting code, this sends the login details to the attacker. This example is also a good reason to embrace the sub-resource integrity, especially if you are using a CDN for JS, CSS, etc.
It is also possible to use the document.domain to get increased access to super domains; though things like cookies are still not accessible since the change will have been detected.
In this scenario, the data is really locked down. There are two possible attack vectors here:
The location of the parent window/tab can be changed. This could allow an attacker to redirect the original window/tab to a page, which has a vulnerability in it or in a targeted attack. It could open to a page that looks the same.
For example, you open a link from your bank's website to a third party. That third party has a piece of JS (either intentional or unintentional, for example, a compromised CDN resource) that checks the location, which is your bank, and changes it to a phishing site. You go back to the tab, expecting it to be your bank, and log in, compromising your credentials.
postmessage is an API that allows pages to communicate with each other, even across different domains. If the
postmessage has been used on the parent, it could contain a vulnerability that allows a new page to gain additional privileges.
To fix this problem, add the
rel="noopener noreferrer" to your links to prevent
window.opener from being set, unless you trust the property you to which are linking.
Published at DZone with permission of Robert Maclean, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.