Content-Security-Policy

Uma camada extra de seguranças

Um cadeado aberto sobre um computador.

Neste artigo vou falar um pouco sobre Content-Security-Policy ou CSP e a sua importância quando se trata de segurança.

Esta funcionalidade dos navegadores modernos permite com que seja adicionada uma camada extra de segurança em seu site, através de diretivas que bloqueiam ações não permitidas.

É importante ressaltar que é apenas uma camada extra, então se você utiliza outros métodos de segurança é importante que continue fazendo.

O que é CSP?

Basicamente é uma lista de domínios e regras (allowlist) que diz para o navegador de onde seu site vai poder carregar recursos como JavaScript, CSS, fontes, imagens, dentre outros.

Há duas maneiras de adicionar o CSP ao seu site:

• A primeira e mais recomendada é através dos headers HTTP.
• A segunda é através de meta tags no HTML, porém nem todas as regras de CSP funcionam dessa maneira e só é indicada quando não é possível utilizar os headers HTTP.

O CSP me protege do que?

Ele serve para proteger principalmente contra ataques XSS (Cross-site scripting), onde scripts ou conteúdos maliciosos são carregados em seu site sem permissão, alguns exemplos:

• keyloggers: quando o script faz um registro de tudo que é digitado pela vítima.
• cryptojacking: quando o script utiliza o computador dos usuários do seu site para minerar moedas digitais.

Um ataque antigo, mas que vale sua atenção, foi quando conseguiram injetar um script malicioso em um fórum sobre epilepsia, fazendo com que o site tivesse várias formas geométricas piscando cores diferentes, então pacientes portadores da doença que acessaram o site no momento tiveram ataques de epilepsia (ver mais).

Com isso em mente temos que considerar a evolução de tecnologias como o CSS, que com algumas linhas pode prejudicar os seus usuários, quebrar o layout ou tornar o seu site inacessível. Um outro exemplo são keyloggers utilizando apenas CSS (ver mais).

Isso nos leva a um alerta ao pensar “inocentemente” que CSP é só sobre JavaScript, pois abre um mundo de possibilidades para pessoas má intencionadas.

O CSP funciona para todos os casos de XSS?

Não, esse é o caso do SELF XSS, que é quando o usuário envia comandos via console com permissões privilegiadas, é por isso que sites como o Facebook mantém esse tipo de mensagem em seu console:

Aviso de ESPERE no console de desenvolvedor no site do Facebook.

Ok, mas alguém usa isso? Eu nunca ouvi falar 🤔

O CSP é utilizado amplamente na web, porém ele não é simples de ser encontrado. Vou dar alguns exemplos de algumas empresas que utilizam:

1. Facebook
2. Instagram
3. Github
4. Apple

Para encontrar o CSP que foi adicionado nos headers HTTP, você deve:

1. Acessar o site desejado.
2. Abrir o devtools do navegador.
3. Ir na aba “Network”.
4. Pesquisar pela url que corresponde o domínio (ex: www.facebook.com).
5. Selecionar e abrir os headers, você deve ver algo como:

Facebook content-security-policy.

Agora se o CSP foi adicionado através de meta tags você pode encontrá-lo da seguinte forma:

1. Acessar o site desejado
2. Clicar com o botão direito do mouse na página e ir em ‘View Page Source’
3. Realizar uma pesquisa por ‘content-security-policy’, você deve ver algo como:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

Como funciona?

O CSP utiliza como guia suas diretivas, são elas que ditam o tipo do conteúdo a ser carregado, como por exemplo:

• script-src: de onde os seus scripts JavaScript devem ser carregados
• style-src: de onde seus estilos devem ser carregados
• font-src: de onde suas fontes devem ser carregadas
• img-src: de onde suas imagens devem ser carregadas
• default-src: esta regra é muito útil, serve de fallback para quando você não tem uma regra específica para outra diretiva, exemplo: se você não declarar nenhuma das regras acima e declarar apenas o default ela servirá para as outras.

Porém cuidado com a utilização do default-src, ele cobre a maioria das diretivas mas não todas, estas são as diretivas que não são cobertas:

• base-uri
• form-action
• frame-ancestors
• report-uri
• sandbox

Quero usar, mas gostaria de testar as regras antes

Há o Content-Security-Policy-Report-Only onde as ações não serão bloqueadas. Ele pode ser utilizado em paralelo ao CSP normal e aliado ao report-uri como diretiva, que indica uma url para que seja enviado um payload com as informações da tentativa de burlar alguma regra, a partir dai você pode analisar os reports e a medida que forem diminuindo, passa-los para o CSP normal.

Exemplo de report gerado através do report-uri.

Pontos de atenção ao escrever um CSP

É sempre bom prestar a atenção ao escrever algumas regras, para evitar algum tipo de efeito ‘surpresinha 🎁’, pois elas podem acabar se anulando e tornar o seu site vulnerável mesmo com CSP.

Utilização dos unsafe

• unsafe-inline: permite que inline scripts e inline styles sejam carregados em seu site. A utilização do unsafe-inline pode anular algumas regras, a própria documentação não recomenda a utilização, a menos que você tenha certeza do que está fazendo.
• unsafe-eval: permite que javascript seja interpretado a partir de uma string, isso pode ser um risco inclusive para JQuery. (ver mais)

Utilização do wildcard

• *: o wildcard isolado permite o recurso ser carregado de qualquer URL que não seja (data: blob: filesystem: schemes). Isso pode se tornar um risco ao ser utilizado no default-src. Uma boa maneira de se utilizar seria apenas para completar URL ex: ‘*.cloudfare.com’.

Divergências entre headers

Também há a possibilidade de ocorrer divergências entre as regras contidas nos headers, um exemplo seria a utilização do header Strict-Transport-Security sem a diretiva de upgrade-insecure-requests no CSP, pois enquanto o Strict-Transport-Security diz que as conexões ao seu site feita pelos usuários devem ser como HTTPS, a ausência da diretiva upgrade-insecure-requests permite com que seu site carregue recursos de fontes não seguras (HTTP).

Conclusão

Através desse overview sobre o que é CSP, do que protege seu site e como implementar, podemos afirmar que ele é indispensável se você quer manter a segurança do seu site, mas também pode se tornar um problema caso as regras não estejam bem estruturadas. Com esse artigo espero ter ajudado a esclarecer um pouco mais esse tema, para mais sugiro o site Content-Security-Policy.

Obrigado e até uma próxima 😄.