Target blank ed i suoi pericoli

Quando si crea un link con target blank, bisogna sapere che ci sono dei pericoli.

Nella versione breve, se avete un link con target blank, ad esempio
<a href="https://google.it" target="_blank"  ----> aggiungete rel="noopener noreferrer ">


Per farla breve, se un target blank viene preso di mira, ad esempio il nostro sito miosito.it contiene un lin al sito2.com, e il sito com viene compromesso,
può essere possibile iniettare del codice javascript malevolo può inficiare la pagina di partenza(a grandi spanne). Ad esempio sostituendo contenuti presenti nella pagina, un link, contenuto x ogni volta che viene lanciato il link dalla pagina A alla pagina B, la pagina A è a rischio. (Se B viene infettato).

Riportiamo qui sotto la guida molto ben scritta da Mathias Bynens

https://mathiasbynens.github.io/rel-noopener/#hax

About rel=noopener

What problems does it solve?

You’re currently viewing index.html.

Imagine the following is user-generated content on your website:

Click me!!1 (same-origin)

Clicking the above link opens malicious.html in a new tab (using target=_blank). By itself, that’s not very exciting.

However, the malicious.html document in this new tab has a window.opener which points to the window of the HTML document you’re viewing right now, i.e. index.html.

This means that once the user clicks the link, malicious.html has full control over this document’s window object!

Note that this also works when index.html and malicious.html are on different origins — window.opener.location is accessible across origins! (Things like window.opener.document are not accessible cross-origin, though; and CORS does not apply here.) Here’s an example with a cross-origin link:

Click me!!1 (cross-origin)

In this proof of concept, malicious.html replaces the tab containing index.html with index.html#hax, which displays a hidden message. This is a relatively harmless example, but instead it could’ve redirected to a phishing page, designed to look like the real index.html, asking for login credentials. The user likely wouldn’t notice this, because the focus is on the malicious page in the new window while the redirect happens in the background. This attack could be made even more subtle by adding a delay before redirecting to the phishing page in the background (see tab nabbing).

TL;DR If window.opener is set, a page can trigger a navigation in the opener regardless of security origin.

Recommendations

To prevent pages from abusing window.opener, use rel=noopener. This ensures window.opener is null in Chrome 49 and Opera 36.

Click me!!1 (now with rel=noopener)

For older browsers, you could use rel=noreferrer which also disables the Referer HTTP header, or the following JavaScript work-around which potentially triggers the popup blocker:

var otherWindow = window.open();
otherWindow.opener = null;
otherWindow.location = url;

Click me!!1 (now with rel=noreferrer-based workaround)Click me!!1 (now with window.open()-based workaround)

Note that the JavaScript-based work-around fails in Safari. For Safari support, inject a hidden iframe that opens the new tab, and then immediately remove the iframe.

Don’t use target=_blank (or any other target that opens a new navigation context), especially for links in user-generated content, unless you have a good reason to.