Como corrigir um Cross Site Scripting ?

Seguir

Problema:

 

O ataque de XSS permite a injeção de códigos JavaScript no navegador de outro usuário, e o atacante não tem como alvo diretamente sua vítima – ao invés disso, ele explora uma vulnerabilidade em um site que o alvo pode visitar com o objetivo de entregar o JavaScript malicioso para ele.

 

No navegador do alvo, esse JavaScript parece ser como parte integrante do site, o que torna o ataque efetivo e quase imperceptível para a vítima.

 

As consequências da exploração dessas falhas podem ser muito sérias, permitindo que um atacante roube as informações confidenciais contidas em um cookie, como os Sessions IDs, habilitar um Keylogging em seu servidor, realizar ataques de phishing mais elaborados, entre outras ações.

 

Basicamente, se o atacante consegue executar códigos JavaScript em seu website, a segurança do site e dos seus usuários pode ser comprometida.

 

Hoje temos três tipos de ataques XSS:

 

  1. Reflected XSS: Acontece quando o servidor reflete o que enviamos sem filtrar o que o usuário colocou, ou seja, ao enviar um determinado parâmetro, o servidor repete no código-fonte da página sem tratar o que foi inserido.

 

  1. Persistent XSS: Acontece quando o código malicioso, a ser injetado, não foi filtrado e está armazenado na página ou em algum componente da aplicação.

 

  1. Dom Based XSS: É o tipo mais difícil de ser encontrado entre os três, porque depende de uma das vulnerabilidades em algum dos componentes da página, sendo que o script faz alterações no HTML atual da página através da manipulação do DOM (Document Object Model). Recentemente, o tema TwentyFifteen, que é padrão nas instalações do WordPress, foi alvo desse tipo de vulnerabilidade e deixou milhões de sites vulneráveis.



Solução:

 

A melhor forma de corrigir os problemas de Cross Site Scripting é aplicando um conjunto de soluções. Essas soluções envolvem aplicação de filtros no código fonte da aplicação, seja através da criação ou utilização de bibliotecas com filtros existentes ou configurações de Headers e Cookies de proteção na aplicação, como mostrado abaixo:

Validação de dados - Encoding e Validation: A função do Encoding é filtrar os dados que o usuário irá inserir para que o navegador o interprete apenas como dado e não como código. Um exemplo clássico é a conversão em HTML, como “<“ e “>” em “&lt;” e “&gt;”. Além disso, quando falamos de Enconding, precisamos pensar tanto do lado do cliente quanto do lado do servidor. No lado do cliente, normalmente você utilizará códigos JavaScript para fazer a verificação, já do lado do servidor, provavelmente você utilizará algum framework que irá realizar essas tarefas. Somente a utilização do Encoding não é suficiente para bloquear os ataques de XSS, e ele não irá prevenir que o atacante insira algo como “&lt; script &gt;” e continue executando códigos – nesse caso, nós iremos utilizar o Validation. O objetivo do Validation é filtrar todas as entradas do usuário que podem ser maliciosas para a sua aplicação, e essa será a sua primeira linha de defesa conta os ataques XSS. Essa validação funciona melhor através da prevenção sobre os dados que possuem limites de valores. Um exemplo é uma variável “Int” (inteiro), que não precisa conter códigos HTML. Até mesmo os formulários POST podem conter scripts de XSS. Então, toda vez que você for usar alguma variável com algum valor no site, tente tratar contra o XSS.

 

Bibliotecas Anti-XSS: As bibliotecas Anti-XSS fornecem um conjunto de funções que irá facilitar o filtro dos dados para bloquear os ataques XSS. Algumas para .NET, PHP e Java:

 

 

Content Security Policy (CSP): O Content Security Policy é um cabeçalho HTTP que fornece uma whitelist de recursos confiáveis no qual o navegador poderá confiar. Um recurso pode ser um script, CSS, imagem ou outro tipo de arquivo que poderá ser indicado. Isso significa que mesmo se um atacante conseguir injetar um código XSS no seu site, o CSP poderá impedir a sua execução. Você poderá utilizar o Content Security Policy no Header como mostrado abaixo:

 

 

  • Content-Security-Policy: Sendo que o texto “policy” deverá seguir algumas diretivas. Veja abaixo um exemplo:

 

 

Content‑Security‑Policy:

 

script‑src 'self' scripts.seusite.com.br;

media‑src 'none';

img‑src *;

default‑src 'self' http://*.seusite.com.br

 

Nesse exemplo, os scripts podem ser carregados apenas do servidor atual e da URL scripts.seusite.com.br. Áudio e vídeo não podem ser carregados de nenhum local, imagens podem ser carregadas de qualquer host e qualquer outro recurso pode ser carregado apenas do servidor atual ou de todos os subdomínios em seusite.com.br.

 

O único problema atual do CSP é que a interpretação é diferente em alguns navegadores e por isso você terá que fazer um tratamento de qual Header enviar, como no caso do Safari, que você precisará usar o modelo abaixo:



 

  • X-WebKit-CSP: policy

 



Flag HttpOnly

 

O HttpOnly é uma flag adicional que pode ser incluída junto com a opção Set-Cookie. Quando o HttpOnly é usado, o JavaScript não será capaz de ler esse cookie protegido se acontecer a exploração do XSS do lado do cliente. Caso o navegador suporte essa opção, mesmo que a falha de XSS exista e o atacante consiga fazer uma vítima acessar o link que pode explorar a falha, o navegador não irá fornecer os dados do cookie para o atacante.

 

 

  • X-XSS-Protection no Header

 

 

Este cabeçalho pode ser utilizado para configurar uma proteção no navegador contra ataques XSS Reflected. Atualmente, apenas os navegadores Internet Explorer, Google Chrome e Safari (WebKit) o suportam.

 

Exemplo de Header:

X-XSS-Protection: 1; mode=block

 

Sendo que os parâmetros “1; mode=block” habilitam a proteção contra XSS e instruem o navegador a bloquear scripts que sejam inseridos pelos usuários.

 

 

  • ModSecurity

 

O módulo open source chamado ModSecurity possui diversas proteções para os principais ataques do OWASP. Este módulo está disponível para o Apache, IIS e Nginx e pode ser baixado no endereço abaixo:

Além dos exemplos mostrados acima, a utilização de um Web Application Firewall (WAF) irá ajudar a proteger suas aplicações em tempo real contra ataques não somente de XSS, mas muitas vezes também de SQL Injection, DDoS, entre outros.



Tem mais dúvidas? Envie uma solicitação

Comentários

Powered by Zendesk