Utilizando Políticas de Segurança de Conteúdo

Um objetivo primário do CSP é de mitigar e reportar ataques XSS. Os ataques de XSS exploram a confiaça do navegador sobre o conteúdo recebido pelo servidor. Scripts maliciosos são executados pelo navegador da vítima porque o navegador confia na origem do conteúdo, mesmo quando sua origem não está vindo de onde parece que está vindo.

O CSP faz com que seja possível para administradores de servidores reduzirem ou eliminarem os vetores em que os ataques de XSS podem ocorrer, especificando os domínios que o navegador deve considerar como origens válidas de scripts para serem executados. Um navegador compatível com o CSP só irá executar então scripts que vierem de arquivos que estejam presentes nos domínios que foram previamente especificados como confiáveis, ignorando todos os outros scripts (incluindo scripts inline e atributos HTML de manipulação de eventos).

Como uma forma de proteção final, os sites que querem nunca permitir a execução de scripts podem optar para desabilitar a execução globalmente.

Além da restrição de domínios deonde o conteúdo pode ser carregado, o servidor consegue especificar quais protocolos estão habilitados para utilização; por exemplo (e literalmente, de um ponto de vista de segurança), um servidor pode especificar que todo conteúdo deve ser carregando utilizando HTTPS. Uma estratégia completa de transmissão de dados segura inclui não só impor o protocolo HTTPS para transferência de dados, mas também marcar todos os cookies com a secure flag e prover redirecionamentos automáticos de páginas HTTP para suas versões HTTPS. Os sites também podem utilizar o cabeçalho Strict-Transport-Security para garantir que os navegadores se conectem neles apenas usando um canal criptografado.

Configurar uma Política de Segurança de Conteúdo envolve adicionar o header HTTP Content-Security-Policy a uma página web e adicionar valores para controlar recursos que o user-agent é habilitado para carregar para aquela página. Por exemplo, uma página que faz o upload e exibe imagens poderia permitir imagens de qualquer lugar, mas restringir um form action de um end point específico. Uma política de segurança de conteúdo devidamente concebida ajuda a proteger a página contra ataques do tipo cross site scripting. Este artigo explica como construir tais headers devidamente, e provê exemplos.

Anteriormente ao Firefox 23, o header HTTP X-Content-Security-Policy era utilizado. Do Firefox 23 em diante começou-se a usar o novo padrão, o header Content-Security-Policy. Durante a transição do header anterior para o novo header, sites podiam enviar ambos os header X-Content-Security-Policy e Content-Security-Policy. Neste caso, o header X-Content-Security-Policy seria ignorado e a política contida no header Content-Security-Policy seria utilizada.

Você pode usar o Content-Security-Policy HTTP header para especificar sua política, dessa forma:

Content-Security-Policy: policy

A política é uma string contendo as diretivas de políticas descrevendo seu Content Security Policy.

Uma politica é descrita usando uma série de diretivas de políticas, cada uma descrevendo uma política para certos tipos de recursos ou áreas de política. Sua política deve incluir uma diretiva de política padrão default-src, que cobre os outros tipos de recursos quando eles não possuem política própria. (Para uma lista completa, veja a descrição da diretiva default-src.) Uma política precisa incluir uma diretiva default-src ou script-src para evitar que scripts inline sejam executados, assim como bloquear o uso de eval(). Uma política precisa incluir uma diretiva default-src ou style-srcpara restringir estilos inline de serem aplicados a partir de um elemento <style> ou um .style atributo.

A sintaxe para uma política é uma string de diretivas separadas por ponto e vírgula ;, cada seguindo a sintaxe descrita em Diretivas de políticas suportadas.

A sessão provê alguns exemplos de alguns cenários comuns de política de segurança.

Um administrador de web site quer que todo o conteúdo venha do mesmo site de origem (excluindo seus subdomínios).

Content-Security-Policy: default-src 'self'

Um administrador de web site quer que todo o conteúdo venha do mesmo site de origem, e também de um domínio confiável e seus todos seus subdomínios (não necessariamente precisa ser o mesmo domínio onda a CSP está inserida).

Content-Security-Policy: default-src 'self' *.trusted.com

A web site administrator wants to allow users of a web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

Here, by default, content is only permitted from the document's origin, with the following exceptions:

• Images may loaded from anywhere (note the "*" wildcard).
• Media is only allowed from media1.com and media2.com (and not from subdomains of those sites).
• Executable script is only allowed from userscripts.example.com.

A web site administrator for an online banking site wants to ensure that all its content is loaded using SSL, in order to prevent attackers from eavesdropping on requests.

Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

The server only permits access to documents being loaded specifically over HTTPS through the single origin onlinebanking.jumbobank.com.

A web site administrator of a web mail site wants to allow HTML in email, as well as images loaded from anywhere, but not JavaScript or other potentially dangerous content.

Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

Note that this example doesn't specify a script-src; with the example CSP, this site uses the setting specified by the default-src directive, which means that scripts can be loaded only from the originating server.

To ease deployment, CSP can be deployed in "report-only" mode. The policy is not enforced, but any violations are reported to a provided URI. Additionally, a report-only header can be used to test a future revision to a policy without actually deploying it.

You can use the Content-Security-Policy-Report-Only HTTP header to specify your policy, like this:

Content-Security-Policy-Report-Only: policy

If both a Content-Security-Policy-Report-Only header and a Content-Security-Policy header are present in the same response, both policies are honored. The policy specified in Content-Security-Policy headers is enforced while the Content-Security-Policy-Report-Only policy generates reports but is not enforced.

Note that the X-Content-Security-Policy-Report-Only header was used before Firefox 23. If both the X-Content-Security-Policy-Report-Only and Content-Security-Policy-Report-Only are sent, the Content-Security-Policy-Report-Only will be used and the X-Content-Security-Policy-Report-Only will be ignored.

The UserCSP Addon also helps test and develop Content Security Policies for a site.

• Introducing Content Security Policy
• CSP policy directives
• Using CSP violation reports
• Content Security Policy recommendation bookmarklet