A Política de Segurança de Conteúdos (CSP) é uma funcionalidade de segurança implementada nos navegadores Web para proteger os sítios Web e as aplicações Web de vários tipos de ataques, tais como XSS (cross-site scripting) e ataques de injeção de dados. A CSP controla e limita as fontes de diferentes tipos de conteúdo que podem ser carregados ou executados numa página Web. Esses tipos de conteúdo incluem:
- Scripts
- Folhas de estilo
- Imagens
Neste post, vamos primeiro dar uma olhada em como o CSP funciona. Veremos que um uso mais eficaz e dinâmico do CSP inclui alguns cálculos que precisam ser feitos no servidor. No entanto, é possível mover esse cálculo para a periferia, reduzindo a latência e garantindo uma experiência óptima para o utilizador final. Também exploraremos como essa solução de computação de ponta pode funcionar.
Está pronto para mergulhar? Comecemos por perceber como funciona o CSP.
Como funciona a CSP
Um CSP é tipicamente definido do lado do servidor, adicionando um Content-Security-Policy na sua resposta HTTP. Este cabeçalho é enviado pelo servidor Web a um utilizador que solicita uma página Web. Este cabeçalho especifica as regras que o navegador deve seguir ao carregar e executar o conteúdo da página.
Exemplos de definição do Content-Security-Policy cabeçalho
Imaginemos que estava a trabalhar com o Express em Node.js. O cabeçalho CSP seria definido desta forma:
const express = require('express'); |
Se estivesse a utilizar Python com 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 definição fornecida. Estas diretivas definem as regras de segurança para vários tipos de recursos. Por exemplo, a diretiva script-src especifica as fontes permitidas para folhas de estilo.
Considere o seguinte cabeçalho 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 os respectivos valores.
- O
default-srcdefinida como'self'especifica que, por defeito, todo o conteúdo deve ser carregado a partir 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 é bastante exaustiva. 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
Ligar o CSP ao HTML
Assim que o cabeçalho CSP é definido no servidor, o browser aplica estas regras ao carregar recursos na página Web.
Na fonte HTML, os programadores podem adicionar elementos (como scripts ou folhas de estilo) em linha, ou referenciando recursos (da mesma origem ou de outra). O navegador verificará então o cabeçalho do CSP para garantir que estes recursos cumprem as regras definidas. Se um recurso não for permitido pelo CSP, o navegador bloqueará a sua inclusão e execução.
Único em cada pedido
Devido à forma como os cabeçalhos CSP são definidos, são normalmente consistentes em todos os pedidos de uma determinada página Web. Os detalhes e as diretivas para cada pedido de uma única página serão os mesmos em cada pedido subsequente dessa página.
Isto levanta uma questão interessante: Como lidaríamos com scripts e estilos dinâmicos e em linha? Podemos querer permitir a execução de scripts e estilos em linha específicos sem abrir a porta para a inclusão de todos os scripts e estilos em linha.
Para este cenário, é possível introduzir valores nonce ou hashes para garantir que, mesmo que a fonte de um script ou estilo não esteja explicitamente listada no CSP, ainda pode ser executada - desde que corresponda ao valor nonce ou hash especificado pelo cabeçalho do CSP.
Estes valores nonce ou hashes podem mudar em cada pedido, tornando-os assim únicos. Assim, teriam de ser gerados e geridos num servidor. No entanto, só porque estes nonces ou hashes têm de ser executados num servidor, não têm necessariamente de ser executados no servidor principal do seu sítio. E é aqui que entra a computação periférica.
O que é a computação periférica?
A computação periférica é essencialmente o conceito de que alguns cálculos podem ser configurados para serem executados no limite exterior da sua rede - geograficamente perto dos seus utilizadores finais. Basicamente, é um tipo de computação distribuída que permite aproximar-se das velocidades de computação em tempo real, mesmo através da Internet, reduzindo simultaneamente a latência da rede.
Com a computação periférica, pode deslocar as preocupações, gerando nonces e hashes para os cabeçalhos CSP mais perto dos utilizadores finais, reduzindo o tempo que estes têm de esperar que proteja o seu sítio.
Como é que a computação periférica pode ajudar com os CSP
Uma das principais razões pelas quais o CSP pode tornar o seu site mais lento é o facto de os nonces nos cabeçalhos poderem causar falhas na cache, exigindo que o browser do cliente vá até ao servidor para que o seu site obtenha os cabeçalhos mais recentes gerados corretamente. Para resolver este problema, pode implementar um gerador de nonce CSP dinâmico numa instância de extremidade. Isso fornecerá uma maneira de garantir que o armazenamento em cache ainda seja útil e, ao mesmo tempo, manter a segurança.
As vantagens desta abordagem incluem:
- Latência reduzida: A instância de computação de borda gera e insere o nonce na solicitação. Os pedidos, agora com o nonce inserido, continuam a atravessar a cache, evitando assim a necessidade de aceder ao servidor de origem para obter novas respostas sempre que é efectuado um pedido.
- Segurança distribuída: A utilização de computação periférica significa que tem uma camada extra de segurança antes de os clientes necessitarem de interagir com os servidores primários e o código de aplicação do seu sistema. Mesmo que exista uma vulnerabilidade na aplicação, a computação periférica que calcula o nonce CSP fornece uma camada adicional de segurança, ajudando-o a mitigar potenciais problemas.
- Facilidade de manutenção: Se gerir o nonce dinâmico para o cabeçalho CSP na extremidade com uma abordagem sem servidor, isso simplificará as suas tarefas de manutenção. Em particular, é possível gerir as políticas CSP sem modificar o código da aplicação. Normalmente, também é possível gerir este tipo de alterações a partir de um sistema de controlo central, sem necessidade de efetuar quaisquer implementações especiais de código. Estas funções de computação de ponta também podem ser utilizadas por várias aplicações independentes, separando assim as preocupações das equipas específicas que trabalham em cada aplicação e permitindo que os profissionais de segurança se certifiquem de que está a ser gerada a nonce correta.
Conclusão
Você está interessado em saber mais sobre o uso da computação de borda? Em caso afirmativo, 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.
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