Iago Santos Oliveira

Analista de Segurança – Resh Strike Team

Durante a comunicação entre uma aplicação num servidor web e o navegador do cliente, são trocadas mensagens que trafegam pela Internet. Estas mensagens são chamadas genericamente de “pacotes” e estes pacotes da aplicação contém, em seu início, determinados marcadores que são chamados de “headers” ou, mais formalmente, campos de cabeçalho do protocolo HTTP [1]. 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 bem simples de ser feita, ainda é muito comum encontrarmos grandes aplicações que não possuem os headers HTTP implementados corretamente. Ou os possuem implementados, mas configurados de forma errada. Vale lembrar que mesmo com o aumento do uso da versão 2.0 do protocolo HTTP, esses headers ainda serão bastante utilizados.

COMO CONFIGURAR OS HEADERS?

Todos os headers que iremos mencionar aqui podem ser definidos de duas maneiras: diretamente no servidor web ou pela aplicação. Portanto você precisará consultar a documentação adequada para o seu caso. O mais recomendável é que estes headers sejam configurados pelo servidor web, por exemplo nas configurações Apache, Nginx, Microsoft IIS ou equivalente.

MAS AFINAL, QUAIS SÃO ESSES HEADERS?

Os headers tratados aqui são aqueles inseridos na resposta das requisições HTTP, e ajudarão a prevenir alguns ataques em sua aplicação. 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 com isso 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 garantir que esteja tudo certo. Com a utilização desse header os ataques do tipo Man in the Middle [4] são evitados. Entretanto este header só pode ser implementado se 100% da aplicação estiver utilizando 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]. 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