A presença de vulnerabilidades no filtro XSS do Internet Explorer 8 foi descoberta primeiramente em novembro de 2009. Nesse meio tempo a Microsoft já havia lançado duas atualizações para tentar corrigir o problema: a MS10-002 em janeiro de 2010, e a MS10-028 em março deste ano, que já consegue corrigir algumas dessas vulnerabilidades. Uma nova atualização já está sendo planejada para ser liberada em junho deste ano, para corrigir as vulnerabilidades relacionadas a tag SCRIPT, que foi descrita na semana passada, na conferência Black Hat Europe.
Mas mesmo com toda essa discussão sobre o problema, David Ross da Microsoft, ainda continua a insistir que os navegadores devem ter a funcionalidade de filtragem para XSS. Ele sinceramente acredita que a existência de proteção contra ataques XSS padrão, na maioria dos casos, supera o risco potencial de bugs.
Enquanto o popular plugin NoScript, usado na maioria dos navegadores Firefox instalados, sempre pede a interação do usuário para saber se bloqueia ou os scripts encontrados nas páginas Web durante a navegação feita pelo usuário, os filtros de respostas do servidor para bloqueio XSS do Internet Explorer 8, atua de forma completamente diferente. Ao invés de efetuar solicitações ao usuário, para cada código malicioso encontrado, ele os altera. E essa "funcionalidade" pode muito bem ser explorada por atacantes para modificar as respostas do servidor, e assim, conseguir injetar o código que bem entender.
É claro que para isso, o atacante precisa ter algum nível de controle do conteúdo das páginas visitadas pelos usuários, como o obtido nos sites de redes sociais, fóruns e wikis. E o exemplo citado na conferência Black Hat foi ninguém menos que a maior de todas as redes sociais do mundo - o Facebook.
O próprio Google e seus serviços também são afetados. Mas a gigante da Internet tem uma "arma" à favor dos usuários que utilizam o navegador Internet Explorer com esse sistema de bloqueio. Ele envia um cabeçalho X-XSS-Protection: 0, para desabilitar esse recurso. Mas desde a última atualização feita no Internet Explorer 8 em março deste ano, o bloqueio já suporta o cabeçalho X-XSS-Protection: 1; mode=block. Isso informa ao navegador para, ai invés de modificar as respostas do servidor, em caso de dúvida, o mesmo deve efetuar o bloqueio de todo o conteúdo proveniente do site suspeito.
O Google Chrome 4 também possui um bloqueador XSS experimental conhecido como XSS Auditor. para funcionar, o mesmo verifica antes se há algum código JavaScript retornando ao gerar uma página Web vulnerável que esteja incluído na requisição. Caso se confirme, o sistema poderá estar vivenciando um caso clássico de ataque XSS reflexivo envolvendo um link manipulado. mas não se preocupe pois o navegador irá bloqueara execução do script. O WebKit, motor principal do navegador Chrome, também suporta cabeçalhos XSS. Porém o modo de bloqueio ainda não está implementado, mas agendado para inclusão em uma futura versão do Chrome.
Se você é usuário do navegador Internet Explorer, poderia começar a pensar em migrar para o Firefox, e poder utilizar a extensão NoScritp. Lembre-se que "o seguro morreu de velho". Não tem porque ficar preso a um navegador que não está se preocupando muito com a sua segurança. Lembre-se que a maioria dos vetores de ataques na Inter5net são efetuados através de falhas encontradas em ferramentas da Microsoft, seja seu navegador, ou até mesmo seu sistema operacional. E você? Qual navegador utiliza em seu dia-a-dia, e quais suas táticas para garantir sua segurança na Internet? Deixe seus comentários abaixo.
Links de Interesse:
- Microsoft to fix further vulnerabilities in IE 8 XSS filter