A importância da implementação dos headers nas aplicações Web
Recentemente, venho estudando cada vez mais sobre Docker, por conta da sua facilidade para a construção de containers para diversos serviços/aplicações.
Dessa maneira, resolvi buscar um exemplo de como criar um serviço em Node.js, por fazer parte da stack JavaScript que está sendo cada vez mais utilizada pelos desenvolvedores atualmente. Além da integração do Node.js ao NGINX (o qual pronuncia-se como Engine-X) por meio do Docker Compose — o qual serve para orquestrar os containers do Docker.
A escolha de estudo sobre o NGINX deu-se por conta do seu frequente uso como servidor Web — o qual responde as requisições HTTP feitas pelo cliente (Navegador Web) e principalmente, pelo seu uso como Proxy Reverso. Dessa maneira, isso traz diversos benefícios, como Load Balacing, e o que eu gostaria de focar nesse post: Segurança.
Acredito que esse tópico seja de total importância e por isso, a implementação dos Headers (cabeçalhos) de maneira correta no NGINX. Visto que diversas vezes, durante o Pentest, na fase de Information Gathering— coleta de informações, pode ser descoberta a exposição da versão de um serviço. Dessa forma, isso pode acarretar em uma brecha de vulnerabilidade, como a descoberta de uma versão de um servidor desatualizado. Então, um atacante poderia explorar essa informação que está sendo exposta.
Como também, caso determinados Headers não estivessem presentes dentro da aplicação, isso poderia ocasionar nas descobertas de outras falhas nas aplicações.
Além disso, em muitos testes de vulnerabilidade (Pentest), por mais que essas vulnerabilidades sejam consideradas de grau baixo, os desenvolvedores não entendem o motivo de sua implementação ou até mesmo, não sabem como implementar de forma correta no servidor. Portanto, acredito que esse texto possa informar melhor aos desenvolvedores, como também, aos profissionais de segurança de como orientar nessas melhores práticas.
Como exemplo desse estudo, utilizei como referência esse Post do Medium:
Além disso, eu também tenho disponibilizado no meu GitHub por conta das alterações que eu resolvi fazer para implementar de forma mais segura, o qual podem ser acessados aqui:
Portanto, segue abaixo parte do arquivo de configuração do NGINX modificado, com a adição dos Headers:
server {
location / {
add_header X-Frame-Options "SAMEORIGIN"
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
add_header Strict-Transport-Security "max-age=63072000" always;
server_tokens off;
proxy_pass_header Server;
}location = /favicon.ico { access_log off; log_not_found off;}
location = /robots.txt { access_log off; log_not_found off;}}
Irei demonstrar de forma prática, o uso de alguns desses cabeçalhos na aplicação feita em Node.js.
Na primeira imagem abaixo, podemos observar a aplicação rodando na porta 80.
Fica aqui como sugestão o uso de uma porta diferente, como boa prática. Não apenas para serviço Web, mas qualquer serviço que esteja rodando no servidor, para que se torne mais difícil para um atacante descobrir quais serviços que são rodados no servidor através de um port scanner como o Nmap. Recomenda-se a atualização dos serviços para a versão mais atual, como também, o uso de portas altas. No exemplo abaixo, pode ser visto o uso de uma porta diferente no arquivo do Docker Compose.😊
nginx: build: context: ./nginx ports: - "8080:80"
Além disso, podemos perceber as diferentes tecnologias estão sendo utilizadas e é possível observar a versão dessa tecnologia também.
Dessa forma, um atacante poderia buscar exploits referentes a essas tecnologias, como em repositórios do Github ou no site https://www.cvedetails.com/
Embora não exista vulnerabilidade para essa versão do NGINX, essa prática é bastante comum de ser realizada.
O plugin Wappalyser também é muito bom de ser utilizado, pois ajuda rapidamente a se encontrar as tecnologias que são utilizadas naquela aplicação.
Então, após a adição dos Headers comentados previamente, é possível observar que agora não é mais possível identificar a versão daquela tecnologia, conforme imagem abaixo.
Além disso, com a adição desses outros cabeçalhos, é possível evitar/mitigar outros tipos de vulnerabilidades fossem exploradas, caso essa aplicação fosse mais complexa e tivesse inputs de informações para o usuário interagir ou área de upload de arquivos, conforme observado na OWASP TOP 10.
- X-Content-Type-Options- Evita que navegadores interpretem o conteúdo da página e execute o dado como código. Um exemplo disso ocorre ao fazer o upload de um arquivo texto com um código javascript, o navegador ler o conteúdo que está no arquivo e executá-lo.
- X-Frame-Options- 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.
- X-XSS-Protection- Filtra o conteúdo da página, evitando ataques de Cross-Site Scripting (XSS).
- Strict-Transport-Security- Força o uso de SSL/TLS impossibilitando que se transmita conteúdo em HTTP. Também checa as características do certificado SSL evitando ataques Man in the Middle (MitM).
Referência: https://blog.convisoappsec.com/aumentando-a-seguranca-das-aplicacoes-com-headers-http-de-seguranca/
Uma outra observação interessante, é evitar que a página robots.txt seja acessada. Muitas vezes, pode conter informação de páginas que um atacante poderia tentar acessar, caso não permitisse que ela fosse indexada (na área de "Disallow").
Caso queiram testar:
location = /robots.txt { return 200 "User-agent: *\nDisallow: /\n"; }
Para isso, é necessário que se use essa configuração:
location = /robots.txt { access_log off; log_not_found off;}Assim, essa página não será acessada. No entanto, é necessário que seja criada uma página em html ou que se retire a versão mostrada na página abaixo.
Com esse comando:server_tokens off;
Assim, será possível obtermos aplicações mais seguras ❤️ .
