A Content Security Policy (CSP) é um recurso de segurança implementado em navegadores da Web para proteger sites e aplicativos da Web contra vários tipos de ataques, como cross-site scripting (XSS) e ataques de injeção de dados. A CSP controla e limita as origens de diferentes tipos de conteúdo que podem ser carregados ou executados em uma página da Web. Esses tipos de conteúdo incluem:
- Scripts
- Folhas de estilo
- Imagens
Nesta postagem, primeiro daremos uma olhada em como o CSP funciona. Veremos que um uso mais eficaz e dinâmico da CSP inclui alguns cálculos que precisam ser feitos no servidor. No entanto, é possível mover essa computação para a borda, reduzindo a latência e garantindo uma experiência ideal para o usuário final. Também exploraremos como essa solução de computação de borda pode funcionar.
Você está pronto para mergulhar de cabeça? Vamos começar entendendo como o CSP funciona.
Como a CSP funciona
Normalmente, um CSP é definido no lado do servidor adicionando um Content-Security-Policy em sua resposta HTTP. Ele é enviado pelo servidor da Web a um usuário que solicita uma página da Web. Esse cabeçalho especifica as regras que o navegador deve seguir ao carregar e executar o conteúdo da página.
Exemplos de configuração do Content-Security-Policy cabeçalho
Digamos que você esteja trabalhando com o Express em Node.js. Você definiria o cabeçalho do CSP desta forma:
const express = require('express'); |
Se você estivesse usando o Python com o Flask, o código seria semelhante a este:
app = Flask(__name__) |
Trabalhar com diretivas
Cada cabeçalho CSP pode ter várias diretivas, e cada diretiva pode ter valores apropriados para o tipo de configuração fornecida. Essas diretivas definem as regras de segurança para vários tipos de recursos. Por exemplo, a diretiva script-src especifica as fontes permitidas para as folhas de estilo.
Considere o seguinte cabeçalho de CSP:
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline'; |
No cabeçalho acima, vemos três diretivas, cada uma com seus respectivos valores.
- O
default-srcdefinida como'self'especifica que, por padrão, todo o conteúdo deve ser carregado da mesma origem que a própria página. - O
script-srcpermite que os scripts sejam carregados a partir da mesma origem ('self') e a fonte externa especificada (https://static.example.com). - O
style-srcpermite que as folhas de estilo sejam carregadas a partir da mesma origem e também permite estilos em linha.
A lista de diretivas disponíveis é, na verdade, bastante exaustiva. Ela pode ser encontrada aqui. As diretivas incluem:
font-src: Fontes para fontes carregadas usando@font-faceframe-src: Fontes para contextos de navegação aninhados carregados em elementos como<frame>e<iframe>img-src: Fontes de imagens e favicons
Vinculação do CSP ao HTML
Depois que o cabeçalho CSP é definido no servidor, o navegador aplica essas regras ao carregar recursos na página da Web.
Na fonte HTML, os desenvolvedores podem adicionar elementos (como scripts ou folhas de estilo) em linha ou fazendo referência a recursos (da mesma origem ou de outra). O navegador verificará o cabeçalho do CSP para garantir que esses recursos estejam em conformidade com as regras definidas. Se um recurso não for permitido pelo CSP, o navegador bloqueará sua inclusão e execução.
Único em cada solicitação
Devido à forma como os cabeçalhos do CSP são definidos, eles normalmente são consistentes em todas as solicitações de uma determinada página da Web. Os detalhes e as diretrizes de cada solicitação de uma única página serão os mesmos em cada solicitação subsequente dessa página.
Isso levanta uma questão interessante: Como lidaríamos com scripts e estilos dinâmicos e em linha? Talvez queiramos permitir a execução de scripts e estilos inline específicos sem abrir a porta para a inclusão de todos os scripts e estilos inline.
Para esse cenário, é possível introduzir valores de nonce ou hashes para garantir que, mesmo que a origem de um script ou estilo não esteja explicitamente listada no CSP, ele ainda possa ser executado, desde que corresponda ao valor de nonce ou hash especificado pelo cabeçalho do CSP.
Esses valores de nonce ou hashes podem ser alterados em cada solicitação, o que os torna exclusivos. Portanto, eles precisariam ser gerados e gerenciados em um servidor. No entanto, só porque esses nonces ou hashes precisam ser executados em um servidor, eles não precisam necessariamente ser executados no servidor principal do seu site. E é aí que entra a computação de borda.
O que é computação de borda?
A computação de borda é essencialmente o conceito de que alguns cálculos podem ser configurados para serem executados na borda externa da rede, geograficamente perto dos usuários finais. Basicamente, é um tipo de computação distribuída que possibilita chegar mais perto das velocidades de computação em tempo real, mesmo pela Internet, além de reduzir a latência da rede.
Com a computação de borda, você pode transferir as preocupações, gerando nonces e hashes para os cabeçalhos do CSP mais perto dos usuários finais, reduzindo o tempo que eles precisam esperar para que você proteja o site.
Como a computação de borda pode ajudar com o CSP
Um dos principais motivos pelos quais a CSP pode tornar seu site mais lento é que os nonces nos cabeçalhos podem causar falhas no cache, exigindo que o navegador do cliente vá até o servidor para que seu site obtenha os cabeçalhos mais recentes gerados adequadamente. Para resolver isso, você pode implementar um gerador dinâmico de nonce de CSP em uma instância de borda. Isso proporcionará uma maneira de garantir que seu cache ainda seja útil e, ao mesmo tempo, manter a segurança.
Os benefícios dessa abordagem incluem:
- Latência reduzida: A instância de computação de borda gera e insere o nonce na solicitação. As solicitações, agora com o nonce inserido, continuam a percorrer o cache, evitando assim a necessidade de acessar o servidor de origem para buscar novas respostas sempre que uma solicitação é feita.
- Segurança distribuída: Usar a computação de borda significa que você tem uma camada extra de segurança antes que os clientes precisem interagir com os servidores primários e o código do aplicativo do seu sistema. Mesmo que haja uma vulnerabilidade no aplicativo, a computação de borda que calcula o nonce do CSP fornece uma camada adicional de segurança, ajudando você a atenuar possíveis problemas.
- Facilidade de manutenção: Se você gerenciar o nonce dinâmico do cabeçalho do CSP na borda com uma abordagem sem servidor, isso simplificará suas tarefas de manutenção. Em particular, você pode gerenciar as políticas de CSP sem modificar o código do aplicativo. Normalmente, também é possível gerenciar esses tipos de alterações a partir de um sistema de controle central sem a necessidade de fazer implementações especiais de código. Essas funções de computação de borda também podem ser usadas por vários aplicativos independentes, separando, assim, as preocupações das equipes específicas que trabalham em cada aplicativo e permitindo que os profissionais de segurança se certifiquem de que a geração correta de nonce esteja ocorrendo.
Conclusão
Você tem interesse em saber mais sobre o uso da computação de borda? Se sim, confira alguns dos produtos em destaque da Akamai. Em particular, os EdgeWorkers criam uma experiência sem servidor que pode fazer exatamente o que discutimos neste artigo, sem a complexidade de descobrir como implantar servidores na borda de suas redes por conta própria.
Quando estiver pronto para experimentar por si mesmo, inscreva-se para uma avaliação gratuita hoje mesmo! É hora de trabalhar para proteger seu site com cabeçalhos CSP melhores, que não estraguem seu esquema de cache!
Comentários