HTTP Security Headers: Guide
Autor: Diego Souza | Publicado: 2015-07-17T22:15:00-03:00

















O protocolo HTTP possui diversos Headers que podem aumentar consideravelmente a segurança de sua aplicação web e esses Headers podem ser muito úteis para prevenir alguns tipos de ataques.



A ideia deste artigo é mostrar todas as opções de Header HTTP que você pode utilizar para aumentar a segurança de sua aplicação e como você pode configurá-lo.



Confira abaixo:



Access-Control-Allow-Origin



Hoje é normal encontrarmos empresas que disponibilizam seus serviços através de APIs e que justificam o grande número de requisições com a origem de diversas fontes, mas diversas empresas não fornecem esse serviço e podem usar um Header HTTP chamado Access-Control-Allow-Origin que é parte integrante do Cross-Origin Resource Sharing (CORS). Este cabeçalho permite você definir quais endereços podem acessar os recursos do seu website.



Um exemplo de utilização seria:





Access-Control-Allow-Origin:&nbsp;http://labs.siteblindado.com




Onde seria permitido apenas o próprio site acessar os recursos. Você pode utilizar o Wildcard (*), onde permite que todos os sites acessem as informações, mas não é recomendado.



Maiores informações:

http://www.w3.org/TR/cors/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS





Content-Security-Policy



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.&nbsp;Veja 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





Mais informações:

http://content-security-policy.com/

https://en.wikipedia.org/wiki/Content_Security_Policy

https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy





X-Content-Type-Options



Este cabeçalho permite proteger sua aplicação contra um ataque específico chamado MIME-Type confusion ou também conhecido como MIME sniffing.



A utilização desse cabeçalho é muito simples e necessita apenas adicionar a opção “nosniff” no cabeçalho, como mostrado abaixo:





X-Content-Type-Options: nosniff







Strict-Transport-Security



HTTP Strict Transport Security (HSTS) traz diversas melhorias para o SSL, entre elas, forçar a utilização do HTTPS, impedindo que sites sejam acessados usando o protocolo HTTP ou que parte do código de um site que está usando HTTPS seja executada em servidores usando o HTTP.



Um exemplo de configuração no Apache onde coloca o website na lista STS por um ano e incluiria os subdomínios seria:





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





Mais informações:

http://imasters.com.br/infra/seguranca/hsts-meu-https-nao-esta-seguro/

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security





X-Frame-Options



O principal objetivo do X-Frame-Options é proteger contra os ataques de Clickjacking. Este cabeçalho permite que o proprietário do site decida quais sites estão autorizados a incluir conteúdo do seu site em outros locais.



A melhor opção é configurar como “SAMEORIGIN” que permite apenas os recursos que são parte da mesma origem acessar. Você também pode configurar como "DENY", que nega qualquer recurso (local ou remoto) de tentar incluir os recursos.



Um exemplo de utilização seria:





X-Frame-Options: SAMEORIGIN





O X-Frame-Options será substituído pela diretiva Frame-Options no Content Security Policy version 1.1 que está sendo desenvolvida.



Mais informações:

https://support.microsoft.com/en-us/kb/2694329

https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options





X-XSS-Protection



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.





Public-Key-Pins



A Public Key Pinning Extension for HTTP (HPKP) é um recurso que informa o navegador para associar uma chave pública de criptografia específica com um determinado servidor de web para prevenir ataques MiTM que utilizem certificados falsos.



O HPKP é baseado em uma técnica conhecida como Trust on First Use (TOFU). No primeiro acesso ao servidor web, informa o cliente através de um cabeçalho HTTP especial que as chaves públicas pertencem a ele, o cliente armazena esta informação por um determinado período de tempo. Quando o cliente visita o servidor novamente, ele espera um certificado que contém uma chave pública cuja impressão digital já é conhecido via HPKP. Se o servidor fornece uma chave pública desconhecida, o cliente irá apresentar um alerta para o usuário.



Um exemplo de configuração seria:





Public-Key-Pins: pin-sha256="&lt;sha256&gt;"; pin-sha256="&lt;sha256&gt;"; max-age= 5184000; includeSubDomains





Neste exemplo o primeiro pin, pin-sha256="&lt;sha256&gt;", faz o pin da chave pública utilizada no servidor de produção, o segundo faz o pin da chave backup. O max-age diz que o cliente deve armazenar a informação por dois meses, um tempo razoável especificado pelo IETF RFC e por último a opção includeSubdomains diz que o key pinning é válido para todos os subdomínios.



Mais informações:

https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning





Além desses headers, muitas aplicações definem um header customizado com um token para proteção contra o ataque de Cross-Site Request Forgery (CSRF), como esse tipo de token não segue um padrão, cada aplicação poderá definir o seu.



Essas opções mostradas anteriormente não podem ser consideradas como uma solução definitiva para deixar uma aplicação web segura, porém utilizando ela em conjunto com outras contramedidas, dependendo da sua necessidade, poderá aumentar consideravelmente a sua segurança online.



Fonte:http://goo.gl/qVN12h