A princípio, durante a comunicação entre uma aplicação no servidor web e o navegador do cliente, o servidor e o cliente trocam mensagens que trafegam pela internet. Chamamos genericamente de “pacotes” as mensagens trocadas, e cada pacote da aplicação contém, em seu início, marcadores chamados de “headers” ou campos de cabeçalho do protocolo HTTP [1]. Desse modo, estes campos definem como vai acontecer uma operação de comunicação web. Nesse post iremos falar sobre como melhorar a segurança das suas aplicações implementando alguns ajustes nos headers HTTP.

ISSO É SUFICIENTE?

Obviamente que somente a implementação dos headers HTTP não tornam uma aplicação segura. Entretanto, quando implementados de forma correta, melhoram consideravelmente a proteção das aplicações contra alguns tipos de ataques.

Apesar de ser uma configuração simples, grandes aplicações ainda frequentemente não implementam corretamente os headers HTTP; portanto, encontramos muitas dessas falhas. Ou os possuem implementados, mas configurados de forma errada. Ademais, vale lembrar que mesmo com o aumento do uso da versão 2.0 do protocolo HTTP, os desenvolvedores ainda utilizarão bastante esses headers HTTP.

COMO CONFIGURAR OS HEADERS?

Pode-se definir todos os headers que mencionaremos aqui de duas maneiras: diretamente no servidor web ou pela aplicação. Por conseguinte, você precisará consultar a documentação adequada para o seu caso. Recomendamos que você configure esses headers diretamente no servidor web, por exemplo nas configurações do Apache, Nginx, Microsoft IIS ou equivalente.

MAS AFINAL, QUAIS SÃO ESSES HEADERS?

Inserir os headers HTTPna resposta das requisições HTTP ajudará a prevenir alguns ataques em sua aplicação. Além disso, explicaremos um pouco sobre cada header, e falaremos também sobre a política de cada um. Por fim, daremos um exemplo de uso.

1. Header X-XSS-Protection:

Este header serve para informar aos navegadores mais modernos que eles devem aplicar filtros contra ataques Cross Site Scripting ou XSS [2]. Navegadores em suas versões mais novas, tais como Google Chrome e Internet Explorer, já possuem ferramentas que procuram filtrar o conteúdo de uma página, evitando assim que ataques Cross Site Scripting (XSS) ocorram.

Exemplo:
X-XSS-Protection: 1; mode=block;

2. Header X-Content-Type-Options:

Este header serve para evitar que navegadores interpretem o conteúdo da página e como resultado evita a execução de possíveis códigos maliciosos. Um bom exemplo para ilustrar o uso desse header é quando fazemos o upload de um arquivo de texto contendo um código javascript, e o navegador interpreta e executa o código mesmo sendo apenas um arquivo de texto.

Exemplo:
X-Content-Type-Options: nosniff;

3. Header HTTP Strict-Transport-Security

Este header serve para obrigar a aplicação a utilizar o protocolo de comunicação segura SSL/TLS [3]. Isso não permite que a aplicação possua conteúdo misto, ou seja, as páginas da aplicação não transmitirão ou consumirão recursos de páginas que utilizem o protocolo HTTP sem criptografia. Este header também obriga uma verificação do certificado SSL/TLS, para assim garantir que esteja tudo certo. A utilização desse header evita ataques do tipo Man in the Middle [4]. Então, você só pode implementar este header se 100% da aplicação utilizar SSL/TLS.

Exemplo:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload;

Uma observação importante sobre a opção preload: para que ela funcione adequadamente é necessário informar previamente o endereço do seu domínio num formulário fornecido pelo mecanismo de busca Google. Ao receber esta informação, o Google, insere seu domínio em uma lista de domínios que devem ser carregados apenas se estiverem utilizando o protocolo HTTPS. Essa lista por fim, é compartilhada entre os navegadores Google Chrome, Mozilla Firefox e Safari. Na referência [5] você encontra tanto o formulário quanto as configurações corretas que o header precisa ter para que o domínio entre na lista.

4. Header X-Frame-Options:

Este header impede que o navegador exiba determinados tipos de conteúdos com base em elementos definidos Modelo de Objeto de Documentos (DOM – Document Object Model) [6]. Ou seja, ao não permitir a renderização de determinados conteúdos externos nós protegemos a aplicação contra ataques de Clickjacking [7].

Exemplo: 
X-Frame-Options: deny;

5. Header Content Security Policy (CSP):

Este header implementa políticas que servem para validar a renderização da página e proteger contra ataques de injeção de conteúdo, tais como o Cross Site Scripting (XSS) [2].  Este header possui muitas políticas [8] que devem ser estudadas individualmente para que não ocorra nenhum problema na aplicação.

Exemplo: 
Content-Security-Policy: default-src 'self' http://example.com;  connect-src: 'none';

OBSERVAÇÃO FINAL:

Alguns navegadores mais exóticos não suportam os headers citados aqui. Porém isso não causará nenhum problema para a aplicação, ou seja, caso o navegador não tenha suporte a um determinado header, ele apenas irá ignorar o header e aplicação continuará seu funcionamento normal.

REFERÊNCIAS:

[1] HTTP headers – https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

[2] Cross-site scripting – https://pt.wikipedia.org/wiki/Cross-site_scripting

[3] Transport Layer Security (TLS) – https://pt.wikipedia.org/wiki/Transport_Layer_Security

[4] Ataque man-in-the-middle – https://pt.wikipedia.org/wiki/Ataque_man-in-the-middle

[5] HTTP Strict Transport Security (HSTS) preload list – https://hstspreload.org/

[6] Modelo de Objeto de Documentos

[7] Clickjacking – https://owasp.org/www-community/attacks/Clickjacking

[8]  Content-Security-Policy

Iago Santos Oliveira

Analista de Segurança – Resh Strike Team