Aumentando a segurança das aplicações com headers HTTP de segurança – Conviso
Home / Segurança de Aplicação / Aumentando a segurança das aplicações com headers HTTP de segurança
Aumentando a segurança das aplicações com headers HTTP de segurança
9 de março de 2015/ Conviso Application Security / Segurança de Aplicação / 0 comments
Neste blogpost iremos abordar a utilização de alguns headers HTTP que podem aumentar a segurança das aplicações web. Mesmo com a adoção da versão 2.0 do protocolo HTTP ganhando espaço, esses headers ainda serão utilizados. Vamos discutir um pouco sobre suas características e como implementá-los.
Quais são esses headers?
Os headers a seguir são inseridos em respostas a requisições http e podem implementar controles importantes a sua aplicação:
HTTP Strict-Transport-Security (HSTS)[1]: força o uso de SSL/TLS impossibilitando que a aplicação contenha conteúdo misto, ou seja, transmita conteúdo em HTTP. Também checa as características do certificado SSL evitando ataques Man in the Middle (MitM). Só pode ser habilitado em aplicações 100% HTTPS.
Content Security Policy (CSP)[2]: implementa políticas que validam a renderização da página e protegem contra ataques de injeção de conteúdo como Cross-Site Scripting (XSS). Deve-se estudar a aplicação de cada política configurada, para evitar que aplicações tenham seu funcionamento prejudicado. A principal característica que pode ocasionar a quebra é o bloqueio de javascript inline, situação onde o javascript é inserido na página com tag <script>.
X-Content-Type-Options[3]: evita que navegadores como Internet Explorer e Chrome interpretem o conteúdo da página (sniffing) e execute o dado como código/tag. Um exemplo básico é ao fazer o upload de um arquivo texto com um código javascript e o navegador ler o conteúdo que está no arquivo e executar, mesmo sendo apenas um texto e não parte do código.
X-XSS-Protection[4]: informa a navegadores mais modernos que deve ser aplicado os filtros anti-XSS. Navegadores como Internet Explorer e Chrome possuem ferramentas que procuram filtrar o conteúdo da página evitando que ataques de Cross-Site Scripting (XSS) afetem os usuários.
X-Frame-Options[5]: impossibilita que o navegador renderize conteúdo externo em objetos DOM como <frame>, <iframe> ou <object> e consequentemente protegendo a aplicação contra ataques de Clickjacking.
Nem todos os navegadores suportam a análise desses headers, porém isso não irá inviabilizar o seu uso. Se um navegador não suportar o header ele será simplesmente ignorado e a aplicação funcionará normalmente sem a checagem de segurança.
Apesar de ser possível habilitar via código, a melhor abordagem é implementada por configurações nos servidores de aplicação. Cada header possuí a sua política conforme os exemplos a seguir:
Políticas: max-age = o tempo, em segundos, que o navegador deve se lembrar que este site é apenas para ser acessado usando HTTPS; includeSubDomains = define se os subdomínios irão respeitar esse header; Preload que é uma especificação extra inserida pelo Google.
Exemplo: Strict-Transport-Security: max-age=16070400; includeSubDomains
Políticas: o CSP possui um número bem grande de políticas e deve ser estudado para implementar uma política adequada. O exemplo a seguir apresenta uma política básica.
Exemplo: Content-Security-Policy: default-src 'self'
Políticas: possui apenas uma política que é nosniff para informar que o browser não deve analisar o conteúdo.
Exemplo: X-Content-Type-Options: nosniff
Políticas: 1 = habilita a proteção; mode = define o bloqueio.
Exemplo: X-XSS-Protection: 1; mode=block
Políticas: DENY = não carrega nenhum objeto externo; SAMEORIGIN = carrega somente da mesma url; ALLOW-FROM = pode definir UMA url que pode carregar objetos externos.
Exemplo: X-Frame-Options: deny
É possível burlar esses headers?
Como a grande maioria dos recursos que adotamos, esses não são diferentes. Sim, existem possibilidades de se burlar a adoção desses headers em algumas condições. É importante adotar os headers e proteger a aplicação contra outros ataques que podem viabilizar esse bypass. Alguns ataques conhecidos até o momento:
HTTP Strict-Transport-Security (HSTS): com algumas técnicas e uma configuração inadequada do HSTS é possível alterar o time da máquina e fazer expirar a política do HSTS. Mais detalhes nesse paper da Black Hat.
Content Security Policy (CSP): com injeção de CRLF é possível explorar algumas implementações do navegador e burlar as políticas do CSP conforme podemos ver nesse blog post.
X-XSS-Protection: com injeção de header através de um ataque de HTTP Response Splitting é possível alterar o valor do header e desabilitar a proteção conforme podemos ver nesse blog post.
Como podemos ver os headers trazem importantes controles, mas é essencial que sua aplicação tenha as proteções adequadas além dessas configurações.