Implementação de cabeçalhos de segurança HTTP (Hypertext Transfer Protocol Headers) em seus serviços Web, para reduzir o risco de ataques contra as aplicações hospedadas nos seus servidores
Prevenção de Clickjacking
Em um ataque de clickjacking (sequestro de cliques), um invasor engana o usuário para que ele interaja com um site confiável de forma falsa.
Normalmente, o invasor cria um site falso que incorpora o site confiável do usuário dentro de um elemento <iframe>. O site do invasor oculta o <iframe> e alinha alguns elementos falsos para que apareçam no mesmo lugar que os elementos do site confiável que realizam ações sensíveis.
Quando o usuário tenta interagir com o site confiável, ele está inadvertidamente interagindo com os elementos do site falso e pode ser induzido a realizar ações que não pretendia.
Solução
A diretiva frame-ancestors do CSP (Content Security Policy - Política de Segurança de Conteúdo) e o cabeçalho X-Frame-Options controlam como seu site pode ser incorporado a um <iframe> em outro site.
X-Frame-Options oferece um controle menos preciso, mas é compatível com o conjunto de navegadores mais antigos.
add_header X-Frame-Options "SAMEORIGIN" always;
Content-Security-Policy: frame-ancestors é preferível, pois fornece um controle mais mais detalhado e preciso sobre as configurações sobre a incorporação de sites. No entanto, não é compatível com o IE11 e versões anteriores ao Chromium do Edge, Safari 9.1 (desktop) e Safari 9.2 (iOS).
add_header Content-Security-Policy "frame-ancestors 'self'";
Verificação do tipo MIME
O cabeçalho X-Content-Type-Options informa aos navegadores para não carregarem scripts e folhas de estilo, a menos que o servidor indique o tipo MIME correto.
Sem a verificação adequada do tipo MIME, os navegadores podem detectar incorretamente arquivos que não sejam scripts e folhas de estilo como scripts ou folhas de estilo. Esse erro permite que arquivos potencialmente maliciosos sejam carregados por meio de elementos <script> e <link> como parte de ataques de Cross-site scripting (XSS).
Solução
Todos os sites devem definir o cabeçalho X-Content-Type-Options com o valor nosniff e definir os tipos MIME apropriados para os arquivos que servem (por exemplo, por meio do cabeçalho Content-Type).
Exemplo
add_header X-Content-Type-Options "nosniff" always;
Implementação do HTTP Strict Transport Security
Para evitar ataques de manipulador intermediário (man-in-the-middle - MiTM), os navegadores devem se conectar a sites apenas via HTTPS.
Solução
HTTP Strict Transport Security (HSTS) é um cabeçalho HTTP que notifica os navegadores para se conectarem a um determinado site somente via HTTPS, mesmo que o esquema originalmente especificado tenha sido HTTP. Navegadores com HSTS definido para um determinado site atualizarão automaticamente todas as solicitações para HTTPS para esse site. O HSTS também instrui os navegadores a tratarem erros de TLS e relacionados a certificados de forma mais rigorosa, desabilitando a capacidade de ignorar a página de erro de certificado.
Strict-Transport-Security suporta as seguintes diretivas:
- max-age
Define a duração, em segundos, em que os navegadores redirecionarão para HTTPS.
Defina um valor de max-age de pelo menos seis meses (15768000). Períodos mais longos, como dois anos (63072000), são recomendados. Após definir esse valor, o site deve continuar a oferecer suporte a HTTPS até que o tempo de expiração seja atingido.
- includeSubDomains (Opcional)
Se possível, defina includeSubDomains para melhorar a segurança em todos os subdomínios. Testes cuidadosos são necessários ao definir essa diretiva, pois ela pode desabilitar sites em subdomínios que ainda não tenham HTTPS habilitado.
- preload (Opcional)
Especifica se o site deve ser pré-carregado. A inclusão desta diretiva significa que seu site pode ser incluído na lista de pré-carregamento do HSTS.
Se possível, defina preload para possibilitar a inclusão do seu site na lista de pré-carregamento do HSTS. Para adicioná-lo à lista, visite https://hstspreload.org/ e insira a URL do seu site no formulário no topo da página, corrigindo quaisquer problemas mencionados. Os navegadores da web realizarão atualizações de HTTPS em sites pré-carregados antes de receber o cabeçalho Strict-Transport-Security inicial. Isso evita ataques de downgrade no primeiro uso e é recomendado para todos os sites de alto risco. Observe que a inclusão na lista de pré-carregamento do HSTS também exige que includeSubDomains seja definido e que max-age seja definido como, no mínimo, 1 ano (31536000).
Juntamente com Strict-Transport-Security, você também deve definir a diretiva upgrade-insecure-requests na sua Content-Security-Policy. Isso instrui os navegadores a tratarem todas as URLs inseguras de um site (aquelas servidas por HTTP) como se tivessem sido servidas por HTTPS. upgrade-insecure-requests destina-se a sites com um grande número de URLs legadas inseguras que precisam ser reescritas.
Exemplo
add_header Strict-Transport-Security "max-age=63072000";
add_header Strict-Transport-Security "max-age=63072000"; includeSubDomains; preload;
Configuração da política de referência
O cabeçalho Referrer-Policy fornece controle refinado sobre como e quando os navegadores transmitem o cabeçalho Referrer.
Quando um usuário acessa um site por meio de um hiperlink ou quando um site carrega um recurso externo, os navegadores informam o site de destino sobre a origem das solicitações por meio do cabeçalho HTTP Referrer (sic). Embora isso possa ser útil para diversos fins, também pode representar um risco à privacidade dos usuários.
Solução
Use Referrer-Policy para limitar as informações disponíveis no cabeçalho Referer ou para impedir que o cabeçalho Referrer seja enviado completamente.
As diretivas mais úteis disponíveis para Referrer-Policy estão listadas abaixo, em ordem decrescente de rigor. Escolha a mais rigorosa que ainda permita que seu site funcione corretamente:
- no-referrer: Nunca envie o cabeçalho Referrer.
- same-origin: Envie o cabeçalho Referrer, mas apenas em solicitações de mesma origem.
- strict-origin: Envie o cabeçalho Referrer para todas as origens, mas inclua apenas a URL sem o caminho (por exemplo, https://example.com/).
- strict-origin-when-cross-origin: Envie o cabeçalho Referrer completo em solicitações de mesma origem e apenas a URL sem o caminho em solicitações de origem cruzada. Este é o valor padrão.
Exemplo
add_header Referrer-Policy "strict-origin-when-cross-origin";
CSP (Content Security Policy)
O Content-Security-Policy fornece controle detalhado sobre o código que pode ser carregado em um site e o que ele tem permissão para fazer. É um recurso que ajuda a prevenir ou minimizar o risco de certos tipos de ameaças à segurança. Ela consiste em uma série de instruções de um site para um navegador, que o instruem a impor restrições às ações que o código que compõe o site tem permissão para fazer.
O principal caso de uso da CSP é controlar quais recursos, em particular os recursos JavaScript, um documento pode carregar. Isso é usado principalmente como defesa contra ataques de script entre sites (XSS), nos quais um invasor consegue injetar código malicioso no site da vítima.
Solução
Um CSP deve ser entregue ao navegador no cabeçalho de resposta Content-Security-Policy. Ele deve ser definido em todas as respostas a todas as solicitações, não apenas no documento principal.
A política é especificada como uma série de diretivas, separadas por ponto e vírgula. Cada diretiva controla um aspecto diferente da política de segurança. Cada diretiva tem um nome, seguido por um espaço, seguido por um valor. Diretivas diferentes podem ter sintaxes diferentes.
Por exemplo, considere o seguinte CSP:
Content-Security-Policy: default-src 'self'; img-src 'self' ifsp.edu.br
A primeira diretiva, default-src, instrui o navegador a carregar apenas recursos da mesma origem do documento, a menos que outras diretivas mais específicas definam uma política diferente para outros tipos de recursos. A segunda, img-src, instrui o navegador a carregar imagens da mesma origem ou que sejam fornecidas por ifsp.edu.br.
Referência de Diretivas do CSP
default-src
A diretiva default-src define a política padrão para a busca de recursos como JavaScript, Imagens, CSS, Fontes, solicitações AJAX, Frames e Mídia HTML5. Nem todas as diretivas retornam para default-src. Consulte a Referência da Lista de Fontes para obter os valores possíveis.
default-src 'self' cdn.example.com;
script-src
Define fontes válidas de JavaScript.
script-src 'self' js.example.com;
style-src
Define fontes válidas de folhas de estilo ou CSS.
style-src 'self' css.example.com;
img-src
Define fontes válidas de imagens.
img-src 'self' img.example.com;
connect-src
Aplica-se a XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> ou EventSource. Se não for permitido, o navegador emula um código de status HTTP 400.
connect-src 'self';
font-src
Define fontes válidas de recursos de fonte (carregados via @font-face).
font-src font.example.com;
object-src
Define fontes válidas de plugins, por exemplo, <object>, <embed> ou <applet>.
object-src 'self';
media-src
Define fontes válidas de áudio e vídeo, por exemplo, elementos HTML5 <audio> e <video>.
media-src media.example.com;
frame-src
Define fontes válidas para carregamento de frames. No CSP Nível 2, frame-src foi descontinuado em favor da diretiva child-src. O CSP Nível 3 possui frame-src não obsoleto e continuará a adiar para child-src se não estiver presente.
frame-src 'self';
sandbox
Ativa um sandbox para o recurso solicitado, semelhante ao atributo sandbox do iframe. O sandbox aplica uma política de mesma origem, impede pop-ups, plugins e a execução de scripts é bloqueada. Você pode manter o valor do sandbox vazio para manter todas as restrições em vigor ou adicionar sinalizadores: allow-forms allow-same-origin allow-scripts allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox e allow-top-navigation
sandbox allow-forms allow-scripts;
report-uri
Instrui o navegador a enviar relatórios de falhas de política para este URI. Você também pode usar Content-Security-Policy-Report-Only como o nome do cabeçalho HTTP para instruir o navegador a enviar apenas relatórios (não bloqueia nada). Esta diretiva foi descontinuada no CSP Nível 3 em favor da diretiva report-to.
report-uri /some-report-uri;
child-src
Define fontes válidas para web workers e contextos de navegação aninhados carregados usando elementos como <frame> e <iframe>
child-src 'self'
form-action
Define fontes válidas que podem ser usadas como uma ação HTML <form>.
form-action 'self';
frame-ancestors
Define fontes válidas para incorporar o recurso usando <frame> <iframe> <object> <embed> <applet>. Definir esta diretiva como 'none' deve ser aproximadamente equivalente a X-Frame-Options: DENY
frame-ancestors 'none';
plugin-types
Define tipos MIME válidos para plugins invocados via <object> e <embed>. Para carregar um <applet>, você deve especificar application/x-java-applet.
plugin-types application/pdf;
base-uri
Define um conjunto de URLs permitidas que podem ser usadas no atributo src de uma tag base HTML.
base-uri 'self';
report-to
Define um nome de grupo de relatórios definido por um cabeçalho de resposta HTTP Report-To. Consulte a API de Relatórios para obter mais informações.
report-to groupName;
worker-src
Restringe as URLs que podem ser carregadas como Worker, SharedWorker ou ServiceWorker.
worker-src 'none';
manifest-src
Restringe as URLs para as quais os manifestos do aplicativo podem ser carregados.
manifest-src 'none';
prefetch-src
Define fontes válidas para pré-busca e pré-renderização de solicitações, por exemplo, por meio da tag link com rel="prefetch" ou rel="prerender":
prefetch-src 'none'
navigate-to example.com
Exemplos de Políticas de Segurança de Conteúdo
Aqui estão alguns cenários comuns para políticas de segurança de conteúdo:
Permitir tudo, mas apenas da mesma origem:
add_header default-src 'self';
Permitir somente scripts da mesma origem:
add_header script-src 'self';
Permitir Google Analytics, Google AJAX CDN e Mesma Origem:
add_header script-src 'self' www.google-analytics.com ajax.googleapis.com;
Política Inicial
Implemente um CSP rigoroso e comece a identificar os recursos que não estão sendo carregados como resultado da política, tomando medidas para contornar esses problemas.
Esta política permite imagens, scripts, AJAX, ações de formulário e CSS da mesma origem e não permite o carregamento de outros recursos (por exemplo, objeto, quadro, mídia, etc.). É um bom ponto de partida para muitos sites.
add_header default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self'
Mensagens de Erro do CSP
No Chrome, quando ocorre uma Violação de Script da Política de Segurança de Conteúdo, você recebe uma mensagem como esta nas Ferramentas do Desenvolvedor do Chrome:
Refused to load the script 'script-uri' because it violates the following Content Security Policy directive: "your CSP directive".
No Firefox, você pode ver mensagens como esta nas Ferramentas do Desenvolvedor Web:
Content Security Policy: A violation occurred for a report-only CSP policy ("An attempt to execute inline scripts has been blocked"). The behavior was allowed, and a CSP report was sent.
Configuração do NGinx
Deve ser adicionado dentro do bloco server {}.
server {
...
add_header Content-Security-Policy "default-src 'self';";
...
}
Você também pode acrescentar always ao final para garantir que o nginx envie o cabeçalho independentemente do código de resposta.
X-Frame-Options;
X-Content-Type-Options;
Referrer-Policy.
Content Security Policy – CSP e;
No comments to display
No comments to display