Por que os iframes são considerados perigosos e um risco de segurança?

124

Por que os iframes são considerados perigosos e um risco de segurança? Alguém pode descrever um exemplo de caso em que ele pode ser usado maliciosamente?

html  security  iframe 
— Daniel T.
fonte
5
Isso soa como um conto de mulheres velhas. A janela do seu navegador é basicamente apenas um grande iframe.
— Bill Criswell
1
Já foi solicitado no stackoverflow
— Samich 02/09
1
@Samich - Não, isso é sobre melhores práticas, e não especificamente questões de segurança (e o único problema de segurança que eu posso pensar surge de terceiros usando iframe)
— Quentin
Tanto a segurança quanto a prática recomendada não são consideradas, consulte: stackoverflow.com/questions/1081315/why-developers-hate-iframes Eles eram muito mais populares quando as pessoas projetadas com tabelas também dividem todos, mas eliminam a necessidade de iframes.
— RandomUs1r
Curiosamente, um artigo apareceu quase uma década depois, sugerindo que colocar qualquer coisa que contenha um formulário em um iframe, isolado de todo o seu javascript de terceiros, etc., seja possivelmente necessário para proteger a coleta de formulários. hackernoon.com/...
— GordonM

Respostas:

83

Assim que você estiver exibindo conteúdo de outro domínio, estará basicamente confiando nesse domínio para não exibir malware.

Não há nada errado com os iframes em si. Se você controla o conteúdo do iframe, eles são perfeitamente seguros.

— Diodeus - James MacFarlane
fonte
19
Assim que você cria um link para o conteúdo de outro domínio, etc etc ... não há nada se for específico para isso.
— Quentin
5
Um navegador implementado corretamente (também conhecido como User Agent) não permitirá que o conteúdo do iframe vaze para fora do iframe. Se o documento host (um que contém o <iframe>elemento) possui um estilo adequado e sugere que o iframe contém conteúdo não confiável, não há problema. Módulo vulnerabilidades reais no navegador, é claro. Em suma, um <iframe>é tão seguro quanto um <a href>.
— Mikko Rantalainen
2
Que tal um iframe oculto que pertence ao mesmo domínio? Isso é totalmente seguro?
— Ciaran Gallagher
2
Oculto <iframe>do mesmo domínio pode causar risco à segurança se o conteúdo dentro do iframe oculto puder ser modificado pelo invasor. Isso permitirá que o invasor estenda o ataque XSS dentro do oculto <iframe>para qualquer página do site que se refira ao referido <iframe>conteúdo. Consulte stackoverflow.com/a/9428051/334451 para obter detalhes.
— Mikko Rantalainen
Curiosamente, um iFrame pode realmente ser uma proteção útil contra o caso inverso. Se você tiver muitos scripts de terceiros em seu site, precisará isolar os formulários deles. Uma maneira sugerida de fazer isso era colocar o formulário em sua própria página mínima sem javascript de terceiros e exibi-lo em um iframe na página host. hackernoon.com/...
— GordonM
140

O IFRAMEelemento pode ser um risco de segurança se o site estiver incorporado em um IFRAMEsite hostil . Google "clickjacking" para mais detalhes. Observe que não importa se você usa <iframe>ou não. A única proteção real contra esse ataque é adicionar o cabeçalho HTTP X-Frame-Options: DENYe esperar que o navegador conheça seu trabalho.

Além do que, além do mais, elemento IFRAME pode ser um risco de segurança se alguma página do seu site contiver uma vulnerabilidade XSS que possa ser explorada . Nesse caso, o invasor pode expandir o ataque XSS para qualquer página do mesmo domínio que possa ser persuadida a carregar dentro de uma <iframe>página com vulnerabilidade XSS. Isso ocorre porque o conteúdo da mesma origem (mesmo domínio) tem permissão para acessar o DOM do conteúdo pai (praticamente executa JavaScript no documento "host"). Os únicos métodos de proteção reais desse ataque são adicionar o cabeçalho HTTP X-Frame-Options: DENYe / ou sempre codificar corretamente todos os dados enviados pelo usuário (ou seja, nunca ter uma vulnerabilidade XSS no seu site - é mais fácil falar do que fazer).

Esse é o lado técnico da questão. Além disso, há o problema da interface do usuário. Se você ensina seus usuários a confiar que a barra de URL não deve mudar quando eles clicam nos links (por exemplo, seu site usa um iframe grande com todo o conteúdo real), os usuários não notarão nada no futuro, nem no caso de segurança real vulnerabilidade. Por exemplo, você pode ter uma vulnerabilidade XSS no seu site que permite ao invasor carregar conteúdo de fontes hostis no seu iframe. Ninguém pode dizer a diferença porque a barra de URL ainda parece idêntica ao comportamento anterior (nunca muda) e o conteúdo "parece" válido, mesmo que seja de um domínio hostil solicitando credenciais de usuário.

Se alguém afirma que o uso de um <iframe>elemento em seu site é perigoso e causa um risco à segurança, ele não entende o que <iframe>faz ou fala sobre a possibilidade de <iframe>vulnerabilidades relacionadas nos navegadores. A segurança da <iframe src="...">tag é igual <img src="..."ou <a href="...">desde que não haja vulnerabilidades no navegador. E se houver uma vulnerabilidade adequada, pode ser possível acioná-la mesmo sem o uso <iframe>,<img> ou <a>elemento, por isso não vale a pena considerar para este problema.

No entanto, esteja avisado de que o conteúdo de <iframe>pode iniciar a navegação de nível superior por padrão . Ou seja, o conteúdo dentro do <iframe>está autorizado a abrir automaticamente um link no local da página atual (o novo local estará visível na barra de endereço). A única maneira de evitar isso é adicionar sandboxatributo sem valorallow-top-navigation . Por exemplo <iframe sandbox="allow-forms allow-scripts" ...>,. Infelizmente, o sandbox também desativa todos os plugins, sempre. Por exemplo, o conteúdo do YouTube não pode ser protegido por sandbox porque o Flash player ainda é necessário para exibir todo o conteúdo do YouTube. Nenhum navegador suporta o uso de plug-ins e a proibição da navegação de nível superior ao mesmo tempo.

Observe que X-Frame-Options: DENYtambém protege contra o desempenho do ataque ao canal lateral que pode ler a origem do conteúdo (também conhecido como " Pixel perfect Timing Attacks ").

— Mikko Rantalainen
fonte
Bom, mas não deve "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."ser reformulado na direção do documento (pai) que contém uma vulnerabilidade XSS ao documento (filho) no iframe?
— Shuzheng
@Shuzheng, a vulnerabilidade ocorre nos dois sentidos e, se você usar <iframe>em uma página, ela permitirá estender a vulnerabilidade a partir do conteúdo do iframe para hospedar o documento. A pergunta era sobre <iframe>ser perigoso e se o documento host tem vulnerabilidade XSS, você realmente não precisa do <iframe>elemento.
— Mikko Rantalainen
13

Estou assumindo o iFrame entre domínios, já que, presumivelmente, o risco seria menor se você o controlasse.

  • Clickjacking é um problema se o seu site for incluído como um iframe
  • Um iFrame comprometido pode exibir conteúdo malicioso (imagine o iFrame exibindo uma caixa de login em vez de um anúncio)
  • Um iframe incluído pode fazer determinadas chamadas JS como alerta e prompt, o que pode incomodar o usuário
  • Um iframe incluído pode redirecionar via location.href (imagine, imagine um quadro 3p redirecionando o cliente de bankofamerica.com para bankofamerica.fake.com)
  • O malware dentro do quadro 3p (java / flash / activeX) pode infectar o usuário
— Joe Zack
fonte
2

"Perigoso" e "Risco de segurança" não são as primeiras coisas que vêm à mente quando as pessoas mencionam iframes ... mas podem ser usadas em ataques de clickjacking .

— Quentin
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.