Os ataques de Cross-Site-Scripting (XSS) têm se tornado frequentes e afetam milhares de aplicações web. Temos acompanhado essa evolução principalmente no CMS open source WordPress e seus plugins, cujas falhas, que afetam milhões de instalações, têm sido divulgadas nos últimos dias por pesquisadores.

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 – 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 imperceptível para a vítima.

Podemos considerar um JavaScript como sendo malicioso quando ele consegue acessar informações confidenciais dos usuários, como os cookies ou quando são enviadas 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 três 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: É 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.

As consequências da exploração dessas falhas podem ser muito sérias e permitirem que um atacante roube as informações confidenciais que podem conter 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.

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 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.

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:

• Microsoft AntiXSS Library
• HTML Purifier
• Java Encoder

3 – Utilize o 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: 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

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 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.

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) 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.

As vulnerabilidades de cross-site scripting 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 do cliente quanto do lado do servidor.

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.