Exportar (0) Imprimir
Expandir Tudo
Web
Expandir Minimizar

HTML5 - Como proteger seu site com área restrita HTML5

Dariusz Parys

Microsoft Technical Evangelist

Março 2013

Os aplicativos Web de hoje reúnem uma combinação de experiências novas em uma única. Pense em widgets do Twitter mostrando os tweets mais recentes sobre um produto. Ou em comentários do Facebook discutindo um artigo. Ou até mesmo simplesmente em páginas Web integradas através de um elemento IFRAME. Essas experiências podem aumentar violações de segurança em seu site.

Não se apavore... há um recém-chegado para ajudá-lo: A área restrita HTML5. Mas, antes de falar disso, vamos revisar rapidamente os problemas do elemento IFRAME.

Uma caixa preta

Embutir conteúdo com um IFRAME é como anunciar publicamente uma festa no Facebook. Você acha que conhece todos os convidados, mas, na verdade, não faz ideia de quem passou a informação adiante e quem vai aparecer.

O mesmo vale para conteúdo de enquadramento. Você sabe a que está se referindo, mas não nem imagina como o site evoluirá no futuro. Conteúdo ou funcionalidade (ou ambos) podem mudar a qualquer momento. Sem você saber... e sem a sua aprovação.

Preocupações de segurança no uso do iframe

Navegadores tratam páginas que usam IFRAME exatamente como qualquer outra página da Web. Formulários podem ser usados para recuperar informações de usuários, scripts podem ser executados, a página pode navegar dentro da janela do navegador e plug-ins de navegador podem ser executados. E, exatamente como os "penetras" da festa que saem do controle, você não tem controle sobre o que o conteúdo hospedado fará.

Existe um mecanismo em vigor por padrão que impede alguns tipos de ataques: a política entre domínios.

Hospedagem de conteúdo de outro domínio

Se conteúdo hospedado vem de outro domínio, a política entre domínios entra em vigor e proíbe que o conteúdo "externo" acesse o modelo de objeto do documento do pai.

Dn163524.D858E42DF86C44DC18F57673575F37F6(pt-br,MSDN.10).png

Assim, a página embutida não é capaz de ler, por exemplo, cookies ou o armazenamento local do navegador do domínio hospedado. Mas ainda restam riscos.

Conteúdo hospedado ainda pode renavegar no nível superior. Ao exibir conteúdo que o usuário esperaria, o site pode tentar "pescar" (através de phishing) informações confidenciais do usuário. Ou, usando um formulário de estilo semelhante, tentar capturar informações do usuário de maneira mal-intencionada.

É por isso que, mesmo com a política entre domínios em vigor, ainda há sérios riscos de segurança.

Hospedagem de conteúdo do mesmo domínio

Dn163524.note(pt-br,MSDN.10).gifNote:
O caso da hospedagem de conteúdo do mesmo domínio é ainda pior.

Quando o conteúdo vem do mesmo domínio, não há restrições de segurança em vigor. Conteúdo embutido pode acessar o DOM completo do navegador carregado e manipular tudo.

De certa forma, faz sentido que conteúdo no mesmo domínio deveria ser seguro. O risco, aqui, tem origens em conteúdo gerado por usuário que é hospedado no IFRAME.

Dn163524.EF3C18B9CD3557715FE4DBA6704D63AB(pt-br,MSDN.10).png

Uma abordagem de área restrita

Essas preocupações com segurança válidas não foram tratadas adequadamente por uma entidade de padrões por um longo tempo. Sem um padrão claro do W3C, era essencial proteger-se de alguma forma o host do conteúdo enquadrado.  Por exemplo, a Microsoft forneceu uma implementação patenteada da segurança do IFRAME no Internet Explorer 8. Outros também a apanharam e discutiram como a base para seus navegadores.  Mas padrões amadureceram muito desde o IE8.

Navegadores modernos, inclusive o Chrome, Firefox e o IE10 Platform Preview se baseiam no atributo de área restrita de IFrame do W3C

Aqui está o que criaremos hoje com a área restrita. 

Dn163524.EDEB601AC17FF45505ADF7CD94C4A16A(pt-br,MSDN.10).png

Vamos começar aplicando a área restrita. Simplesmente a adicione como um atributo vazio no elemento IFRAME:

É isso!

Agora, o conteúdo do IFRAME na área restrita é hospedado no navegador com as seguintes restrições:

Plug-ins são desabilitados. Nenhum tipo de plug-in ActiveX, Flash ou Silverlight será executado.

Formulários são desabilitados. O conteúdo hospedado não tem permissão fazer postback de formulários a nenhum destino.

Scripts são desabilitados. O JavaScript é desabilitado e não é executado.

Links para outros contextos de navegação são desabilitados. Uma marca de âncora visando níveis de navegador diferentes não será executada.

Tratamento de origem única. Todo o conteúdo é tratado segundo uma origem única. O conteúdo não consegue atravessar o DOM ou ler informações de cookies.

Isso significa que mesmo conteúdo vindo do mesmo domínio é tratado com a política entre domínios, já que cada conteúdo do IFRAME será visto como tendo origem única.

Dn163524.3DC3DE34552224596537B9DBF73EADEC(pt-br,MSDN.10).png

Conteúdo embutido tem permissão apenas para exibir informações Nenhuma outra ação que poderia comprometer o site hospedeiro ou tirar vantagem da confiança dos usuários pode ser executada dentro do IFRAME.

Verificação do atributo sandbox

Sabemos que um IFRAME é um portão aberto. Sabemos que o atributo sandbox bloqueia a segurança de conteúdo hospedado. A decisão é clara: Use elementos IFRAME somente com o atributo sandbox!

Você pode confirmar que o navegador suporta o atributo sandbox do IFRAME com uma verificação simples em JavaScript:

Se for suportado, simplesmente use o atributo sandbox. Caso contrário, tente embutir o conteúdo através de outras maneiras ou encoraje o usuário com uma mensagem de que ele deveria atualizar para um navegador moderno.

Personalização da área restrita

Há casos em que você precisará de algum nível de personalização das restrições, o que é absolutamente possível.

Vários valores de atributo relaxam a política de área restrita padrão:

allow-forms

Se quiser habilitar o postback de formulários dentro do elemento IFRAME, você simplesmente especifica o valor allow-forms para o atributo sandbox.

Se esse valor estiver presente, a página embutida tem permissão para fazer postback usando um envio de formulário dentro do quadro.

allow-scripts

O JavaScript é uma linguagem poderosa e usado frequentemente para se terem interações dinâmicas no lado do cliente sem o reenvio de informações ao servidor. Mas esse poder também acarreta riscos quando se hospedam páginas da Web externas. Portanto, você deve considerar cuidadosamente se quer mesmo habilitar JavaScript em cenários de IFRAME – especialmente quando o conteúdo vem de uma fonte desconhecida.

A habilitação do JavaScript é feita através do valor allow-scripts.

allow-same-origin

Por padrão, uma página de IFRAME do mesmo domínio tem a possibilidade de acessar o modelo de objeto do documento do pai.

Com o atributo sandbox em vigor, a página será tratada como não sendo da mesma origem. Essa página não tem acesso aos recursos, mesmo quando vier do mesmo domínio.

Para reabilitar o tratamento de mesma origem em um cenário de área restrita, você tem de especificar o atributo allow-same-origin.

O valor em si não é muito útil, já que você precisa de algumas capacidades de script para usá-lo.

Por exemplo, se quiser acessar o armazenamento local do domínio atual assim:

…você também precisa do valor allow-scripts:

Agora o acesso funciona!

Mas considere-se avisado: Permitir múltiplos scripts na mesma área restrita pode levar a vulnerabilidades de segurança.  Por exemplo, seu conteúdo hospedado pode manipular os atributos da área restrita e remover outras restrições.

allow-top-navigation

Quando você usa o atributo sandbox, âncoras visando outros contextos de navegador são ignoradas e não executadas por padrão. Isso protege o site que hospeda o conteúdo do IFRAME contra substituição pelo conteúdo hospedado.

Por exemplo, esse link não seria executado na área restrita padrão, já que o destino substituiria a página da Web completa:

Relaxar essa política é recomendado apenas se você confiar no conteúdo que hospeda.

ms-allow-popups

Às vezes é útil permitir que conteúdo embutido abra novas janelas pop-up. Um exemplo perfeito é um serviço de mapeamento como o Bing Maps.

Quando se embute o Bing Maps, funcionalidade adicional como itinerários ou detalhes de destino podem ser pesquisados em janelas pop-up. Mas, como a área restrita proíbe isso, existe uma configuração no Internet Explorer 10 que habilita pop-ups sem comprometer a área restrita.

O código a seguir mostra como configurar ms-allow-popups.

Quando esse valor é definido, sites embutidos podem exibir informações em uma janela nova.

Reúna tudo

Você pode combinar diversos valores de atributos em uma única área restrita. Por exemplo, se quiser habilitar postback de formulários, navegação de nível superior e JavaScript, basta especificar.

Também é bom saber que a área restrita se comporta corretamente quando usada em situações hierárquicas, usando vários IFRAMES aninhados com diferentes valores do atributo sandbox. A área restrita de nível superior sempre domina hierarquia abaixo.

Ponha a mãos à obra!

Você pode praticar com a área restrita HTML nesta demonstração. E pode baixar uma cópia desta demonstração de Github. Para habilitar a demonstração de postback, simplesmente abra a pasta do projeto em WebMatrix e inicie o projeto dali.

Em seguida, baixe um navegador moderno (como o Internet Explorer 10 Platform Preview) e familiarize-se com a área restrita lendo o Guia do desenvolvedor do IE. Esse único atributo é um grande passo para uma Web mais segura... e navegadores modernos estão finalmente prontos para conteúdo embutido em área restrita.

Sobre o autor

Dariusz Parys é um evangelista desenvolvedor na Microsoft Germany, fazendo desenvolvimento da Web com um foco forte em tecnologias futuras. Atualmente escreve muito sobre JavaScript e HTML5. Você pode entrar em contato com Dariusz através de seu blog kouder.net

Mostrar:
© 2015 Microsoft