O que é o cabeçalho http "X-XSS-Protection"?

Então, eu tenho brincado com HTTP por diversão no telnet agora (ou seja, apenas digitando telnet google.com 80e colocando GETs e POSTs aleatórios com cabeçalhos diferentes e similares), mas me deparei com algo que o google.com transmite nos cabeçalhos que eu não sei

Eu estive pesquisando http://www.w3.org/Protocols/rfc2616/rfc2616.html e não encontrei nenhuma definição para esse cabeçalho http específico que o Google parece estar divulgando:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

Alguém sabe o que X-XSS-Protectioné?

X-XSS-Protection é um cabeçalho HTTP entendido pelo Internet Explorer 8 (e versões mais recentes). Esse cabeçalho permite que os domínios ativem e desativem o "Filtro XSS" do IE8, o que evita algumas categorias de ataques XSS. O IE8 tem o filtro ativado por padrão, mas os servidores podem ser desativados definindo

   X-XSS-Protection: 0

Consulte também http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header. aspx

• X-XSS-Protection: 1 : Forçar proteção XSS (útil se a proteção XSS foi desativada pelo usuário)

• X-XSS-Protection: 0 : Desativar proteção XSS

• O token mode=blockimpedirá que o navegador (navegadores IE8 + e Webkit) processe páginas (em vez de higienizar) se um possível ataque de reflexão XSS (= não persistente) for detectado.

/! \ Atenção, mode=blockcria uma vulnerabilidade no IE8 ( mais informações ).

Mais informações: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx e http://blog.veracode.com / 2014/03 / diretrizes para definição de cabeçalhos de segurança /

Esse cabeçalho de resposta pode ser usado para configurar a proteção reflexiva XSS incorporada de um agente de usuário. Atualmente, apenas o Internet Explorer, o Google Chrome e o Safari (WebKit) da Microsoft suportam esse cabeçalho.

O Internet Explorer 8 incluiu um novo recurso para ajudar a impedir ataques de script entre sites refletidos, conhecido como Filtro XSS . Esse filtro é executado por padrão nas zonas de segurança Internet, Confiável e Restrita. As páginas da zona da Intranet local podem optar pela proteção usando o mesmo cabeçalho.

Sobre o cabeçalho que você postou na sua pergunta,

O cabeçalho X-XSS-Protection: 1; mode=blockativa o filtro XSS. Em vez de higienizar a página, quando um ataque XSS é detectado, o navegador impede a renderização da página.

Em março de 2010, adicionamos ao IE8 suporte para um novo token no cabeçalho X-XSS-Protection, mode = block.

X-XSS-Protection: 1; mode=block

Quando esse token estiver presente, se um possível ataque de Reflexão XSS for detectado, o Internet Explorer impedirá a renderização da página. Em vez de tentar limpar a página para remover cirurgicamente o ataque XSS, o IE renderizará apenas “#”.

O Internet Explorer reconhece um possível ataque de script entre sites. Ele registra o evento e exibe uma mensagem apropriada para o usuário. O artigo do MSDN descreve como esse cabeçalho funciona.

Como esse filtro funciona no IE ,

Mais sobre este artigo, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

O filtro XSS opera como um componente do IE8 com visibilidade em todas as solicitações / respostas que fluem pelo navegador. Quando o filtro descobre o provável XSS em uma solicitação entre sites, ele identifica e neutraliza o ataque se for repetido na resposta do servidor. Os usuários não recebem perguntas que não conseguem responder - o IE simplesmente impede a execução do script malicioso.

Com o novo filtro XSS, os usuários do IE8 Beta 2 que encontrarem um ataque XSS do tipo 1 verão uma notificação como a seguinte:

Notificação de ataque do IE8 XSS

A página foi modificada e o ataque XSS está bloqueado.

Nesse caso, o filtro XSS identificou um ataque de script entre sites no URL. Ele neutralizou esse ataque quando o script identificado foi reproduzido novamente na página de resposta. Dessa maneira, o filtro é efetivo sem modificar uma solicitação inicial para o servidor ou bloquear uma resposta inteira.

O evento Filtro de script entre sites é registrado quando o Windows Internet Explorer 8 detecta e atenua um ataque de script entre sites (XSS). Os ataques de script entre sites ocorrem quando um site, geralmente malicioso, injeta (adiciona) código JavaScript em solicitações legítimas para outro site. A solicitação original geralmente é inocente, como um link para outra página ou um script CGI (Common Gateway Interface) que fornece um serviço comum (como um livro de visitas). O script injetado geralmente tenta acessar informações ou serviços privilegiados que o segundo site não pretende permitir. A resposta ou a solicitação geralmente reflete os resultados no site mal-intencionado. O filtro XSS, um recurso novo no Internet Explorer 8, detecta JavaScript em solicitações de URL e HTTP POST. Se o JavaScript for detectado, o filtro XSS pesquisa evidências de reflexão, informações que seriam retornadas ao site atacante se a solicitação atacante fosse submetida inalterada. Se a reflexão for detectada, o filtro XSS limpa a solicitação original para que o JavaScript adicional não possa ser executado. O filtro XSS registra essa ação como um evento de filtro de script entre sites. A imagem a seguir mostra um exemplo de site modificado para impedir um ataque de script entre sites.

Fonte: https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Os desenvolvedores da Web podem querer desativar o filtro para seu conteúdo. Eles podem fazer isso definindo um cabeçalho HTTP:

X-XSS-Protection: 0

Mais sobre cabeçalhos de segurança em,

• Diretrizes para definir cabeçalhos de segurança

• Cabeçalhos HTTP de segurança - X-XSS-PROTECTION

• MDN Docs X-XSS-Protection

Você pode ver nesta lista de cabeçalhos HTTP úteis .

Proteção X-XSS: esse cabeçalho ativa o filtro XSS (Cross-site scripting) incorporado nos navegadores da Web mais recentes. Geralmente, ele é ativado por padrão de qualquer maneira, portanto, a função desse cabeçalho é reativar o filtro para esse site específico, se ele foi desativado pelo usuário. Esse cabeçalho é suportado no IE 8+ e no Chrome (não sei quais versões). O filtro anti-XSS foi adicionado no Chrome 4. Não se sabe se essa versão honrou esse cabeçalho.

TL; DR: Todos os sites bem escritos (/ apps) precisam emitir cabeçalho X-XSS-Protection: 0e esquecer esse recurso. Se você deseja ter segurança extra que os melhores agentes do usuário podem fornecer, use um Content-Security-Policycabeçalho estrito .

Resposta longa:

O cabeçalho HTTP X-XSS-Protectioné uma das coisas que a Microsoft introduziu no Internet Explorer 8.0 (MSIE 8) que deveria melhorar a segurança de sites gravados incorretamente.

A idéia é aplicar algum tipo de heurística para tentar detectar o ataque XSS de reflexão e neutralizar automaticamente o ataque.

A parte problemática disso é "heurística" e "neutralização". A heurística causa falsos positivos e a castração não pode ser realizada com segurança, pois causa efeitos colaterais que podem ser usados ​​para implementar ataques XSS e ataques DoS em sites perfeitamente seguros.

A parte ruim é que, se um site não emitir o cabeçalho X-XSS-Protection, o navegador se comportará como se o cabeçalho X-XSS-Protection: 1tivesse sido emitido. A pior parte é que esse valor é o valor menos seguro de todos os valores possíveis para esse cabeçalho!

Para um determinado site seguro (ou seja, o site não possui vulnerabilidades XSS de reflexão), esse recurso "proteção XSS" permite os seguintes ataques:

X-XSS-Protection: 1permite ao invasor bloquear seletivamente partes do JavaScript e manter o restante dos scripts em execução. Isso é possível porque as heurísticas desse recurso são simplesmente "se o valor de qualquer parâmetro GET for encontrado na parte de script da origem da página, o script será modificado automaticamente de maneira dependente do agente do usuário". Na prática, o invasor pode, por exemplo, adicionar parâmetro disablexss=<script src="framebuster.js"e o navegador removerá automaticamente a string <script src="framebuster.js"da fonte real da página. Observe que o restante da página continua sendo executado e o invasor acabou de remover essa parte da segurança da página. Na prática, qualquer JS na origem da página pode ser modificado. Em alguns casos, uma página sem vulnerabilidade XSS com conteúdo refletido pode ser usada para executar o JavaScript selecionado na página devido à neutralizaçãotransformar incorretamente dados de texto sem formatação em código JavaScript executável .

X-XSS-Protection: 1; mode=blockpermite que o invasor vaze dados da fonte da página usando o comportamento da página como canal lateral. Por exemplo, se a página contiver código JavaScript ao longo das linhas de var csrf_secret="521231347843", o invasor simplesmente adiciona um parâmetro extra, por exemplo, leak=var%20csrf_secret="3e se a página NÃO estiver bloqueada, o 3primeiro dígito estava incorreto. O atacante tenta novamente, desta vez leak=var%20csrf_secret="5e o carregamento da página será abortado. Isso permite que o invasor saiba que é o primeiro dígito do segredo 5. O atacante continua adivinhando o próximo dígito.

No final, se o seu site estiver cheio de ataques de reflexão XSS, o uso do valor padrão de 1reduzirá um pouco a superfície de ataque. No entanto, se seu site é seguro e você não o emite X-XSS-Protection: 0, ele estará vulnerável a qualquer navegador que suporte esse recurso. Se você deseja um suporte profundo da defesa de navegadores contra vulnerabilidades XSS ainda desconhecidas em seu site, use um Content-Security-Policycabeçalho estrito . Isso não abre seu site para vulnerabilidades conhecidas.

Atualmente, esse recurso está ativado por padrão no MSIE, Safari e Google Chrome. Isso costumava ser ativado no Edge, mas a Microsoft já removeu esse recurso incorreto do Edge . O Mozilla Firefox nunca implementou isso.

Veja também:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https: // bugs.chromium.org/p/chromium/issues/detail?id=498982