5 formas para prevenir os ataques XSS


Os ataques de Cross-Site-Scripting (XSS) tem se tornado frequente e afeta milhares de aplicações web. Temos acompanhado essa evolução principalmente no CMS open-source Wordpress e seus plugins, que nos últimos dias os pesquisadores estão divulgando diversas falhas que afetam milhões de instalações.

O ataque de XSS permite a injeção de códigos JavaScript no navegador de outro usuário, o atacante não tem como alvo diretamente sua vítima, em vez 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, o JavaScript malicioso parece ser como parte integrante do site o que torna o ataque efetivo e quase não é percebido pela vítima.

Podemos considerar um JavaScript como sendo malicioso quando ele consegue acessar informações confidenciais dos usuários como os cookies ou quando é enviado requisições HTTP contendo scripts maliciosos que podem usar o XMLHttpRequest. Claro que estes são apenas alguns exemplos, mesmo porque os ataques de XSS permitem uma série de combinações no ataque.

Para entender um pouco melhor, hoje temos 3 tipos de ataques XSS:

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.

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.

Dom Based XSS: Este é o tipo mais difícil de ser encontrado entre os três porque depende de uma 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.

As consequências da exploração dessas falhas podem ser muito sérias e permitem que um atacante roube as informações confidenciais que pode conter em um cookie, como os Sessions IDs, habilite um Keylogging em seu servidor, realize ataques de phishing mais elaborados entre outros. Basicamente se o atacante consegue executar códigos JavaScript em seu website, a segurança do seu website e dos seus usuários podem ser comprometidas.

Métodos de prevenção

1 - Encoding e Validation
A função do Encoding é filtrar os dados que o usuário irá inserir para que o navegador interprete ele apena como dado e não como código, um exemplo clássico é a conversão em HTML como “<“ e “>” em “<” e “>”

Além disso, quando falamos de Enconding precisamos pensar tanto do lado cliente-side como do lado server-side, do lado do cliente-side normalmente você utilizará códigos JavaScript para fazer a verificação, já do lado do server-side 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 “< script >” e continue executando códigos, neste 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 este 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) 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.

2 - Use 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. Abaixo vou citar algumas que conheço para .NET, PHP e Java:

HTML Purifier: http://htmlpurifier.org/

3 - Utilize o Content Security Policy (CSP)
O Content Security Policy é um cabeçalho HTTP que fornece uma whitelist de recursos confiáveis que o navegador poderá confiar. Um recurso pode ser um script, CSS, Imagem ou algum outro tipo de arquivo que poderá ser indicado. Isto 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: policy
Sendo que o texto “policy” deverá seguir algumas diretivas, veja abaixo um exemplo:

ContentSecurityPolicy:
    script
src 'self' scripts.seusite.com.br;
    media
src 'none';
    img
src *;
    default
src 'self' http://*.seusite.com.br

Neste 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


4 – Usando a 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 este cookie protegido se acontecer a exploração do XSS do lado do cliente. Caso o navegador suporte esta 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.

5 – 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) suportam este cabeçalho.

Exemplo de Header:
X-XSS-Protection: 1; mode=block
Sendo que que os parâmetros “1; mode=block” habilita a proteção contra XSS e instrui o navegador a bloquear scripts que sejam inseridos pelos usuários.

As vulnerabilidades de cross-site scriting são uma das mais comuns em websites e lojas virtuais e também é uma das mais difíceis de se fazer a correção, procure sempre verificar os dados que são passados pelos usuários tanto do lado cliente-side como do server-side.

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.


EmoticonEmoticon