Gerador e verificador de CSP

O que é uma Content Security Policy

Uma Content Security Policy é um cabeçalho HTTP que diz ao navegador de onde uma página pode carregar coisas. É uma lista de directivas — script-src, img-src, style-src e afins — cada uma seguida das fontes que permite. Se a página tentar carregar algo que a política não permite, o navegador recusa.

A ideia é limitar estragos. Se um atacante conseguir injectar marcação na sua página, uma boa política é o que impede essa marcação de carregar o script dele. A CSP não substitui escapar bem o que se imprime; é a camada que limita a gravidade da falha quando o escape corre mal.

Escrever uma é fácil. Saber o que realmente escreveu não é, e é essa lacuna que esta página tenta fechar. As regras de correspondência do CSP Level 3 são mais surpreendentes do que parecem, e várias fazem com que partes de uma política sejam ignoradas em silêncio: uma política pode listar uma dúzia de anfitriões permitidos que não produzem efeito nenhum, e nada o avisa.

Como usar

1. Comece por um modelo ou cole a sua própria política. A estrita assenta em nonce e é o que as recomendações actuais defendem; a típica é mais parecida com o que a maioria dos sítios leva de facto. Edite o texto à vontade: tudo o que está abaixo actualiza à medida que escreve.
2. Leia o que a política faz mesmo. O painel de baixo enumera achados: expressões ignoradas, directivas em falta e fontes que desfazem a protecção que julgava ter. Cada um é uma regra da especificação e não uma opinião.
3. Depois verifique um URL real contra ela. Escolha o tipo de recurso, cole o URL que quer carregar e a origem de onde a sua página é servida. Recebe um veredicto, a directiva consultada depois da cadeia de recurso, e a expressão exacta que o decidiu.

As regras de correspondência que quase ninguém conhece

A correspondência de esquema é assimétrica e ainda por cima faz upgrade. A especificação diz que o esquema http corresponde a https, o que significa que script-src http://example.com permite também https://example.com, mas não ao contrário. Escrever a forma insegura permite em silêncio as duas. A mesma regra faz com que ws corresponda a wss, http e https ao mesmo tempo, uma concessão bem mais larga do que quase ninguém pretende.

Um anfitrião com asterisco não inclui o próprio domínio. O padrão *.example.com é resolvido retirando o asterisco inicial e exigindo que o anfitrião termine em .example.com, e example.com não termina assim. Ou seja, uma política que permite *.example.com bloqueia example.com, exactamente o contrário do que quase toda a gente julga ter escrito. Implica também que nenhum padrão de anfitrião corresponde jamais a um endereço IP, porque o algoritmo exige um domínio.

Os caminhos só são correspondência por prefixo quando terminam em barra. Sem barra final a correspondência é exacta, portanto script-src https://cdn.example/js permite exactamente aquele URL e nada por baixo. Além disso os segmentos são descodificados de percentagem antes de comparados, pelo que uma barra codificada continua a ser um só segmento e não dois.

E as portas caem no valor por omissão. Uma fonte sem porta corresponde à porta por omissão do esquema, portanto https://example.com e https://example.com:443 são a mesma origem — que é também o que 'self' tem de significar.

As partes da sua política que não fazem nada

Há duas regras que fazem com que certas expressões estejam na política sem efeito nenhum, e nenhuma delas se vê se não souber procurá-la.

A primeira é o 'strict-dynamic'. Quando aparece em script-src ou default-src, a especificação diz que as fontes de anfitrião e de esquema, juntamente com o 'unsafe-inline' e o 'self', são ignoradas ao carregar scripts. Só os nonces e as hashes continuam a contar. É deliberado e é como funciona a abordagem moderna baseada em nonce, mas significa que uma política que diga script-src 'strict-dynamic' 'nonce-abc' https://cdn.example 'self' não permite nada daquele CDN pelo anfitrião. O verificador enumera todas as expressões que ignorou e diz que regra as ignorou.

A segunda é o 'unsafe-inline' ao lado de um nonce ou de uma hash. Nesse caso o 'unsafe-inline' é ignorado, que é precisamente o truque para escrever uma política que degrada com elegância em navegadores antigos: os que percebem nonces obedecem ao nonce e os que não percebem recorrem ao 'unsafe-inline'. Útil quando é deliberado e alarmante quando é acidental, por isso esta página distingue os dois casos em vez de assinalar o 'unsafe-inline' da mesma maneira em ambos.

Há uma terceira lacuna que é de ausência e não de ser ignorado. As directivas frame-ancestors, form-action e base-uri não recorrem ao default-src. Uma política de default-src 'self' não restringe portanto o enquadramento de todo, não restringe para onde os formulários são enviados, e deixa o base-uri aberto, de modo que marcação injectada pode reapontar todos os URL relativos da página. O verificador dir-lhe-á claramente que não se aplica nenhuma directiva.

Limites honestos

Isto verifica a correspondência de URL, que é a parte da CSP com regras a sério e surpresas a sério. Não modela tudo o que um navegador faz. O script e o estilo em linha, o eval, os redireccionamentos, a herança em workers, o sandbox, os trusted types e o envio de relatórios ficam fora do que o verificador responde, e uma política que aqui permite um URL pode continuar a bloquear o recurso num navegador por um desses motivos.

Os nonces e as hashes são reconhecidos mas não avaliados. Se um dado script em linha casa com um nonce depende da marcação e não da política, portanto o verificador trata-os como expressões que existem sem afirmar que deixam passar qualquer URL em concreto.

Os achados são regras, não uma nota de segurança. Uma política pode passar todas as verificações daqui e continuar fraca, porque a CSP não consegue proteger uma página cuja própria origem serve script controlado pelo atacante. Nada nesta página substitui codificar bem o que se imprime.

Não existe bateria de conformidade da CSP nem comparador de referência no npm que implemente os algoritmos das expressões de fonte, portanto o motor foi verificado contra os exemplos trabalhados da própria especificação e contra os seus algoritmos transcritos como asserções com o número da secção. Cada regra assimétrica é testada nas duas direcções, porque uma bateria que só verifica a direcção permissiva é satisfeita por uma implementação que permite de mais — que é justamente a falha que aqui importa.

Porque é grátis

Porque não custa nada manter. A política é analisada e o URL verificado no seu navegador à medida que escreve; nada é enviado, nada é registado e nenhum servidor vê a política nem os URL que cola.

Nem conta, nem registo, nem nada guardado atrás de um. As regras de correspondência saem da especificação Content Security Policy Level 3 e não do resumo que outro sítio faz dela, e as verificações que as confirmam estão guardadas ao lado da página.