Link com target = "_ blank" e rel = "noopener noreferrer" ainda vulnerável?
Vejo pessoas recomendando que sempre que alguém usa target="_blank"em um link para abri-lo em uma janela diferente, eles deveriam colocar rel="noopener noreferrer". Eu me pergunto como isso me impede de usar Ferramentas para Desenvolvedores no Chrome, por exemplo, e remover o atributo rel. Em seguida, clicando no link ...
Essa é uma maneira fácil de ainda manter a vulnerabilidade?
Que tipo de proteção você acha que seria (ou não, neste caso) concedida?
Eu estava considerando extensões de navegador que podem manipular o DOM.
O Firefox 79 fará isso automaticamente (bem, noopenerpelo menos, mas como indicado abaixo, noreferreré redundante): hacks.mozilla.org/2020/07/firefox-79
Você pode estar entendendo mal a vulnerabilidade. Você pode ler mais sobre isso aqui: https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
Essencialmente, adicionar rel="noopener noreferrer"links protege os usuários do seu site contra o potencial de sequestro do navegador do site que você vinculou (via JS desonesto).
Você está perguntando sobre a remoção desse atributo por meio das Ferramentas de Desenvolvedor - isso apenas exporia você (a pessoa que adulterou o atributo) à vulnerabilidade.
— Jon Uleis
noopener noreferreré redundante, pois noreferrerinclui a funcionalidade de noopener. html.spec.whatwg.org/multipage/links.html#link-type-noreferrer
— mfluehr
se for redundante, por que o Visual Studio Code exige os dois?
— muhe
Os links com target="_blank"eles são vulneráveis a ter a página de referência sendo trocada em segundo plano enquanto a atenção do usuário é desviada pela guia recém-aberta. Isso é conhecido como tabnapping reverso :
A página de referência é armazenada em window.openere um site malicioso pode modificá-la por meio de:
window.opener.location = "https://phish.example.com";
Adicionar rel="noopener noreferrer"corrige esta vulnerabilidade em todos os principais navegadores.
Observe que você poderia teoricamente remover o rel lado do cliente por meio da manipulação ... mas por que você quer? Tudo o que você está fazendo é ficar deliberadamente vulnerável ao ataque.
Outros usuários que visitam o mesmo site (e não modificam seu próprio código do lado do cliente) ainda estariam seguros, pois o servidor ainda serviria o rel="noopener noreferrer". Sua remoção se aplica apenas a você.
— Idade Obsidiana
apenas vagar, qual benefício de rel = "noopener noreferrer" oferece ao meu aplicativo interno? Abre mesmo domínio interno, na mesma rede interna, há 0 chance de que esteja se referindo a algum site externo. E se ainda fosse benéfico, por que não adicioná-lo a todos os links em geral?
— Dainius
A tag âncora rel="noopener"ou os rel="noreferrer"atributos melhoram a segurança do site, mas algumas pessoas querem ignorá-los porque acham que afetarão a otimização do mecanismo de busca do site, mas isso é apenas um mito. Ele protege a confidencialidade do público do seu site e evita que sites externos espalhem códigos maliciosos.
— Kowsigan Atsayam
Seria bom se você pudesse citar alguma fonte para a declaração de "mito". Especialmente, para o noreferrerpapel.
Em relação ao relatório de auditorias de práticas recomendadas do Lighthouse :
Adicione rel="noopener"ou rel="noreferrer"a quaisquer links externos para melhorar o desempenho e evitar vulnerabilidades de segurança.
Em geral, ao usar target="_blank", sempre adicione rel="noopener"ou rel="noreferrer":
<a href="https://www.kaiostech.com/store/" target="_blank" rel="noreferrer">
rel="noopener"evita que a nova página acesse a window.openerpropriedade e garante que ela seja executada em um processo separado.
rel="noreferrer"tem o mesmo efeito, mas também impede que o Referercabeçalho seja enviado para a nova página.
Veja o documento oficial para mais informações.
Você pode adicionar os dois?
— abençoado em
Se o console do desenvolvedor estiver mostrando um aviso a respeito noopener noreferrer, certifique-se de adicionar ambos noopenere noreferrerem rel. o link deve ser algo como abaixo: