TL; DR: Todos os sites bem escritos (/ apps) precisam emitir cabeçalho X-XSS-Protection: 0
e esquecer esse recurso. Se você deseja ter segurança extra que os melhores agentes do usuário podem fornecer, use um Content-Security-Policy
cabeç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: 1
tivesse 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: 1
permite 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=block
permite 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="3
e se a página NÃO estiver bloqueada, o 3
primeiro dígito estava incorreto. O atacante tenta novamente, desta vez leak=var%20csrf_secret="5
e 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 1
reduzirá 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-Policy
cabeç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