Como funciona a Política de segurança de conteúdos?

A meta-marca Content-Security-Policy permite-lhe reduzir o risco de ataques XSS, permitindo-lhe definir de onde os recursos podem ser carregados, impedindo os navegadores de carregar dados de quaisquer outros locais. Isso torna mais difícil para um atacante injetar código malicioso em seu site.

Bati com a cabeça contra uma parede a tentar perceber porque estava a receber erros de PSC um após o outro, e não parecia haver instruções claras e concisas sobre como é que isso aconteceu. trabalhar. Então aqui está a minha tentativa de explicar alguns pontos da CSP brevemente, concentrando-me principalmente nas coisas que achei difíceis de resolver. Por brevidade, não vou escrever a etiqueta completa em cada amostra. Em vez disso, só vou mostrar a propriedade, por isso uma amostra que diz content="default-src 'self'" significa isto:

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

1. Como permitir múltiplas fontes?

Pode simplesmente listar as suas fontes a seguir a uma directiva como uma lista separada por espaços:

content="default-src 'self' https://example.com/js/"

Note que não há citações. em torno de parâmetros diferentes dos especiais , Como 'self'. Além disso, não há cólon ([18]} depois da Directiva. Só a Directiva, depois uma lista de parâmetros separados por espaço.

Tudo Abaixo dos parâmetros especificados é implicitamente permitido. Isso significa que no exemplo acima estas seriam fontes válidas:

https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js

Estes, no entanto, não seriam válidos:

http://example.com/js/file.js
^^^^ wrong protocol

https://example.com/file.js
                   ^^ above the specified path

2. Como usar diferentes diretivas, o que cada uma delas faz?

A as directivas mais comuns são:

• default-src a Política por omissão para carregar javascript, imagens, CSS, fontes, pedidos AJAX, etc
• script-src define fontes válidas para os ficheiros javascript
• style-src define fontes válidas para os ficheiros CSS
• img-src define as fontes válidas para as imagens
• connect-src define objectivos válidos para o XMLHttpRequest (AJAX), WebSockets ou EventSource. Se for feita uma tentativa de ligação a uma máquina que não é permitida aqui, o navegador irá emular um erro 400

Há outros, mas estes são os que mais provavelmente vai precisar.

3. Como usar várias diretivas?

Define todas as suas directivas dentro de uma meta-marca, terminando - as com um ponto e vírgula.(;):

content="default-src 'self' https://example.com/js/; style-src 'self'"

4. Como lidar com portos?

Tudo menos as portas predefinidas precisa de ser permitido explicitamente adicionando o número do porto ou um asterisco após o permitido domínio:

content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"

O acima resultaria em:

https://ajax.googleapis.com:123
                           ^^^^ Not ok, wrong port

https://ajax.googleapis.com - OK

http://example.com/free/stuff/file.js
                 ^^ Not ok, only the port 123 is allowed

http://example.com:123/free/stuff/file.js - OK

Como mencionei, também pode usar um asterisco para permitir explicitamente todos os portos:

content="default-src example.com:*"

5. Como lidar com diferentes protocolos?

Por omissão, só são permitidos protocolos padrão. Por exemplo, para permitir WebSockets ws:// você terá que permitir explicitamente:

content="default-src 'self'; connect-src ws:; style-src 'self'"
                                         ^^^ web sockets are now allowed on all domains and ports

6. Como permitir o protocolo de arquivo file://?

Se tentar defini-lo como tal, não vai funcionar. Em vez disso, você vai permitir com o parâmetro filesystem:

content="default-src filesystem"

7. Como usar scripts incorporados e definições de estilo?

A menos que explicitamente permitido, não pode usar definições de estilo em linha, códigos dentro das marcas <script> ou em Propriedades de marcas como onclick. Permite - lhes assim:

content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"

Também terá de permitir explicitamente imagens codificadas em linha e base64:

content="img-src data:"

8. Como permitir eval()?

Tenho a certeza que muitas pessoas diriam que tu ... não o faças, já que "eval é mau" e a causa mais provável para o fim iminente do mundo. Essas pessoas estariam erradas. Claro, você pode definitivamente perfurar grandes buracos na segurança do seu site com eval, mas tem casos de uso perfeitamente válidos. Só tens de ser esperto em usá-lo. Você permite assim:

content="script-src 'unsafe-eval'"

9. O que significa exactamente 'self'?

Você pode tomar {[17] } para significar localhost, sistema de arquivos local, ou qualquer coisa na mesma máquina. Não significa nada. o. Significa fontes que têm o mesmo esquema (protocolo), o mesmo host, e o mesmo porto que o arquivo em que a Política de conteúdo é definida. A servir o teu site por HTTP? Nada de https para si, a menos que o defina explicitamente.

Eu usei 'self' na maioria dos exemplos como normalmente faz sentido incluí-lo, mas não é de forma alguma obrigatório. Deixa de fora se não precisares.

Mas espera um minuto!Não posso usar o content="default-src *" e acabar com isto?

Não. Além de as vulnerabilidades de segurança óbvias, isto deixaria que também não funcionasse como seria de esperar. Apesar de alguns documentos afirmarem que permitem tudo, isso não é verdade. Ele não permite inlining ou evals, então para realmente, realmente tornar o seu site mais vulnerável, você usaria isso:

content="default-src * 'unsafe-inline' 'unsafe-eval'"

... mas acredito que não.

Mais leitura:

Http://content-security-policy.com

Http://en.wikipedia.org/wiki/Content_Security_Policy