Comentário: Prefácio: Depois que o HTML5 aparece, a segurança da rede atraiu atenção mais difundida. Quais melhorias a web fez para a segurança da rede? Como enfrentamos fraudes e ataques cibernéticos cada vez mais perigosos? O artigo a seguir fala sobre a mais recente solução do W3C para esse problema. Se eu tiver a oportunidade no futuro, realizarei conteúdo HTML5 no XSS, P3P, Política homóloga, CORS (compartilhamento de recursos entre domínios) e CSP.
A política de segurança da World Wide Web está enraizada em uma política homóloga. Por exemplo, o código só pode acessar dados, mas não possui permissões de acesso. Cada fonte é separada do restante da rede, criando uma caixa de areia segura para os desenvolvedores. Isso é perfeito em teoria, mas agora os atacantes encontraram uma maneira inteligente de destruir o sistema.Este é o ataque de script de sites cruzados do XSS, ignorando políticas homólogas por meio de conteúdo falso e enganando os cliques. Esse é um grande problema, se o invasor injetar com sucesso o código, uma quantidade considerável de dados do usuário será vazada.
Agora, introduzimos uma nova e eficaz estratégia de defesa de segurança para mitigar esse risco, que é a Política de Segurança do ContentSecurity (CSP).
Fonte da lista de permissões
O núcleo dos ataques XSS é que o navegador não sabe dizer se o script é injetado por terceiros ou é realmente parte do seu aplicativo. Por exemplo, o botão do Google +1 carregará e executará o código de https://apis.google.com/js/plusone.js, mas não podemos esperar contar das fotos no navegador se o código é realmente do apis.google.com ou do apis.evil.example.com. O navegador Downloads e executa uma solicitação de página para qualquer código, independentemente de sua fonte.
O CSP define o cabeçalho do conteúdo-segurança-policyhttp para permitir que você crie uma lista de permissões de fontes confiáveis, de modo que o navegador execute apenas e renderize recursos dessas fontes, em vez de confiar cegamente em tudo fornecido pelo servidor. Mesmo que um invasor possa encontrar uma vulnerabilidade para injetar um script, ele não será executado porque a fonte não está incluída na lista de permissões.
O botão +1 do Google acima é um exemplo, porque acreditamos que o apis.google.com fornece código válido, assim como nós mesmos, podemos definir uma política que permite ao navegador executar scripts de uma das duas fontes abaixo.
Content-Security-Policy: script-src 'self' https://apis.google.com
Não é muito simples? O script-src pode controlar as permissões relacionadas ao script para páginas especificadas. Dessa forma, o navegador só baixará e executará scripts de e a partir desta página.
Depois de definirmos essa política, o navegador apresentará um erro ao detectar o código injetado (observe o que é o navegador).
Políticas de segurança de conteúdo se aplicam a todos os recursos comuns
Embora os recursos de script sejam os riscos de segurança mais óbvios, o CSP também fornece um rico conjunto de instruções que permitem que as páginas controlem o carregamento de vários tipos de recursos, como os seguintes tipos:
Conteúdo-SRC: Restrinja o tipo de conexão (por exemplo, XHR, WebSockets e Eventsource)
Fonte-SRC: controla a fonte de fontes de rede. Por exemplo, você pode usar as fontes da Web do Google através do Font-Src https://themes.googleusercontent.com.
Frame-SRC: lista a fonte de quadros que podem ser incorporados. Por exemplo, o quadro-src https://youtube.com permite apenas vídeos incorporados no YouTube. .
IMG-SRC: define a fonte da imagem carregável.
Mídia-SRC: restrinja a fonte de vídeo e áudio.
Objeto-src: restrinja a fonte do flash e outros plugins.
Style-SRC: semelhante ao script-src, ele funciona apenas no arquivo CSS.
Por padrão, todas as configurações estão ativadas sem restrições. Você pode separar várias instruções dos semicolons, mas semelhante ao script-src https: //host1.com; script-src https://host2.com, a segunda instrução será ignorada. A maneira correta de escrevê-lo é script-src https://host1.com https://host2.com.
Por exemplo, você tem um aplicativo que precisa carregar todos os recursos de uma rede de distribuição de conteúdo (CDN, por exemplo https://cdn.example.net) e saber que o conteúdo de nenhum quadro e plugins é necessário, sua estratégia pode parecer seguinte:
Content-Segurança-Policy: Padrão SRC https://cdn.example.net; quadro-src 'nenhum'; Objeto-src 'nenhum'
detalhe
O cabeçalho HTTP que usei no meu exemplo é a política de segurança de conteúdo, mas os navegadores modernos já forneceram suporte por meio de prefixos: o Firefox usa a polia X-Content-Segurança, o Webkit usa X-Webkit-CSP. No futuro, ele fará uma transição gradualmente para os padrões unificados.
A estratégia pode ser definida para cada página diferente, que fornece muita flexibilidade. Porque algumas páginas do seu site podem ter botões do Google +1, enquanto outros não.
A lista de origem de cada instrução pode ser bastante flexível. Você pode especificar um padrão (dados:, https :) ou ou um nome de host em um intervalo (exemplo.com, que corresponde a qualquer fonte, qualquer modo e qualquer porta no host) ou especificar um URI completo (https://example.com:443, especificamente o protocolo HTTPS, nome do domínio do exemplo.com, porto 443).
Você também pode usar quatro palavras -chave na lista de origem:
Nenhum: você pode esperar incompatir qualquer coisa
Eu: o mesmo que a fonte atual, mas não contém subdomínios
INFERINA INSIBRA: Permite JavaScript e CSS em linha
UNSAFE-EVAL: mecanismos que permitem o texto para JS, como avaliar
Observe que essas palavras -chave precisam ser citadas.
Sandbox
Há outra instrução que vale a pena discutir aqui: Sandbox. É um pouco inconsistente com outras instruções. Ele controla principalmente o comportamento adotado na página, em vez dos recursos que a página pode carregar. Se esta propriedade estiver definida, a página se comportará como um quadro com o conjunto de propriedades Sandbox. Isso tem uma ampla gama de impactos na página, como impedir envios de formulários, etc. Isso está um pouco além do escopo deste artigo, mas você pode encontrar mais informações na seção de configurações de logotipo da Sandbox da especificação HTML5.
Código em linha prejudicial
O CSP é baseado em listas de permissões de origem, mas não resolve a maior fonte de ataques XSS: injeção de script embutida. Se um invasor puder injetar tags de script contendo código prejudicial (<SCRIPT> sendmydatatoevildotcom (); </script>), o navegador não possui um bom mecanismo para distinguir esta tag. O CSP só pode resolver esse problema proibindo completamente os scripts embutidos.
Essa proibição inclui não apenas as tags de script incorporadas no script, mas também os manipuladores de eventos em linha e o JavaSCRPT: URLs. Você precisa colocar o conteúdo da tag de script em um arquivo externo e substituir JavaScript: e <a… OnClick = [javascript]> com o addEventListener apropriado. Por exemplo, você pode colocar o seguinte formulário:
<Cript>
função doamazingthings () {
alerta ('você é incrível!');
}
</script>
<but uma botão> Eu sou incrível? </botão>
Reescrever para o seguinte formulário:
<!-Amazing.html->
<script src = 'AMBANTE.JS'> </SCRIPT>
<but uma botão> Eu sou incrível? </botão>
// Amazing.js
função doamazingthings () {
alerta ('você é incrível!');
}
document.addeventListener ('domcontentready', function () {
document.getElementById ('Amazing')
.AddeventListener ('clique', doamazingthings);
});
Independentemente de você usar o CSP ou não, o código acima realmente tem maiores vantagens. O JavaScript embutido mistura completamente a estrutura e o comportamento, você não deve fazer isso. Além disso, os recursos de divulgação são mais fáceis de abastecer nos navegadores, mais fáceis para os desenvolvedores de entender e são fáceis de compilar e compactar. Se você usar o código de divulgação, escreverá um código melhor.
Os estilos embutidos precisam ser processados da mesma maneira, os atributos do estilo e as tags de estilo precisam ser extraídos na folha de estilo externa. Isso pode impedir todos os tipos de vazamento de dados mágicos.
Se você precisar ter scripts e estilos embutidos, poderá definir o valor 'inseguro para o atributo Script-SRC ou Style-SRC. Mas não faça isso. Proibir scripts embutidos é a garantia de segurança máxima fornecida pelo CSP. Ao mesmo tempo, proibir os estilos embutidos podem tornar seu aplicativo mais seguro e mais robusto. É uma troca, mas vale a pena.
Aval
Mesmo que um invasor não possa injetar diretamente o script, ele poderá induzir seu aplicativo a converter o texto inserido em um script executável e executá -lo. Eval (), newFunction (), Settimeout ([String], ...) e SetInterval ([String], ...) podem se tornar transportadores tão perigosos. A estratégia para o CSP direcionar esse risco é bloquear completamente esses vetores.
Isso tem algumas implicações na maneira como você constrói seu aplicativo:
Parse JSON via json.parse embutido sem depender da avaliação. Os navegadores após o IE8 apoiam as operações JSON locais, o que é completamente seguro.
Reescreva o método de chamada de setTimeout e setInterval por funções embutidas em vez de strings. Por exemplo:
setTimeout (document.QuerySelector ('a'). style.display = 'nenhum';, 10);
Pode ser reescrito como:
setTimeout (function () {document.QuerySelector ('a'). style.display = 'nenhum';}, 10);
Evite modelos embutidos em tempo de execução: muitas bibliotecas de modelos usam nova função () para acelerar a geração de modelos. Isso é ótimo para programas dinâmicos, mas é arriscado para texto malicioso.
Relatório
O CSP pode bloquear recursos não confiáveis no lado do servidor, o que é muito útil para os usuários, mas é muito útil receber várias notificações enviadas ao servidor, para que possamos identificar e corrigir qualquer injeção de script maliciosa. Para esse fim, você pode instruir o navegador a enviar um relatório de interceptação no formato JSON para um endereço através da diretiva Relatório-URI.
Política de segurança de conteúdo: padrão-src 'self'; ...; Relatório-uri /my_amazing_csp_report_parser;
O relatório ficará assim:
{
CSP-RELATOR: {
document-uri :,
Referencial :,
bloqueado-uri :,
Violent-Directive: Script-Src 'Self' https://apis.google.com,
Policy original: script-src 'self' https://apis.google.com; Relatório-URI
}
}
As informações contidas nele ajudarão você a identificar a situação de bloqueio, incluindo o documento-URI que ocorre, o referenciador de página, o recurso que viola a política da página, a diretiva violada e a política original de todo o conteúdo da página.
Uso realista
O CSP já está disponível nos navegadores Chrome 16+ e Firefox 4+, e espera -se que receba suporte limitado no IE10. O Safari ainda não é suportado, mas a construção noturna do Webkit está disponível, portanto, espera -se que o Safari seja suportado na iteração abaixo.
Vejamos alguns casos de uso comumente usados abaixo:
Caso real 1: widget de mídia social
O botão Google +1 inclui scripts de https://apis.google.com, bem como iframes incorporados em https://plusone.google.com. Sua política precisa incluir essas fontes para usar o botão Google+1. A estratégia mais fácil é o script-src https://apis.google.com; Frame-src https://plusone.google.com. Você também precisa garantir que os fragmentos JS fornecidos pelo Google sejam armazenados em arquivos JS externos.
Existem muitas soluções de implementação para o botão LIFT do Facebook. Eu recomendo que você siga a versão iframe, pois ela se mantém bem isolada do restante do seu site. Isso requer o uso da Diretiva Frame-SRC https://facebook.com. Observe que, por padrão, o código IFRAME fornecido pelo Facebook usa o caminho relativo //facebook.com. Modifique este código para https://facebook.com. Não há necessidade de HTTP não usar.
O botão Tweet do Twitter depende do script e do quadro, ambos de https://platform.twitter.com (o Twitter fornece um URL relativo por padrão, edite o código ao copiar para especificá -lo como HTTPS).
Outras plataformas têm situações semelhantes e podem ser resolvidas da mesma forma. Eu recomendo definir o padrão-src para nenhum e, em seguida, olhar para o console para verificar quais recursos você precisa usar para garantir que o widget funcione corretamente.
O uso de vários widgets é muito simples: basta mesclar todas as diretivas de política e lembrar de montar as configurações da mesma diretiva. Se você quiser usar os três widgets acima, a estratégia ficará assim:
script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
Caso 2: Defesa
Suponha que você visite um site bancário e queira garantir que apenas os recursos necessários sejam carregados. Nesse caso, comece a definir uma permissão padrão para bloquear tudo (padrão-src 'nenhum') e construa a política do zero.
Por exemplo, um site do banco precisa carregar imagens, estilos e scripts do CDN de https://cdn.mybank.net e conectar -se a https://api.mybank.com/ através do XHR para puxar vários dados. Ele também precisa usar um quadro, mas os quadros são todos de páginas locais não títulos. Não há flash, fontes e outros conteúdos no site. Nesse caso, podemos enviar o mais rigoroso cabeçalho do CSP é:
Política de segurança de conteúdo: padrão-src 'nenhum'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; Connect-src https://api.mybank.com; quadro-src 'self'
Caso real 3: use apenas SSL
Um administrador do fórum do anel de casamento deseja que todos os recursos sejam carregados de maneira segura, mas não deseja realmente escrever muito código; Reescrever um grande número de scripts e estilos em linha de terceiros está além de sua habilidade. Portanto, a seguinte estratégia será muito útil:
Política de segurança de conteúdo: Https padrão-src:; script-src https: 'inseguro-inline'; HTTPS de estilo-src: 'inseguro'
Embora o padrão-SRC especifique https, scripts e estilos não são herdados automaticamente. Cada diretiva substituirá completamente o tipo de recurso padrão.
futuro
O Grupo de Trabalho de Segurança do Aplicativo da Web do W3C está desenvolvendo detalhes das especificações da política de segurança de conteúdo. A versão 1.0 entrará no estágio de revisão final, que é muito próximo do que é descrito neste artigo. O grupo de email Public-WebAppSec@ está discutindo a versão 1.1, e os fabricantes de navegador também estão trabalhando duro para consolidar e melhorar a implementação do CSP.
O CSP 1.1 tem algumas coisas interessantes na prancheta que vale a pena listar separadamente:
Adicionando políticas por meio de metatags: a maneira preferida de definir CSP são os cabeçalhos HTTP, o que é muito útil, mas será mais direto por meio de tags ou scripts, mas ainda não foi finalizado. O Webkit implementou o recurso da configuração de permissão através de meta elementos, para que você possa tentar as seguintes configurações no Chrome: Add <metahttp-equiv = x-webkit-csp Content = [Política vai aqui]> Para o cabeçalho do documento.
Você pode até adicionar políticas através de scripts em tempo de execução.
DOM API: Se esse recurso for adicionado à próxima iteração do CSP, você poderá consultar a política de segurança atual da página por meio do JavaScript e ajustá -lo de acordo com diferentes situações. Por exemplo, se EVEST () estiver disponível, sua implementação de código poderá ser um pouco diferente. Isso é muito útil para o autor da estrutura JS; E a especificação da API ainda é muito incerta, você pode encontrar a iteração mais recente na seção de interface de script da especificação de rascunho.
Novas Diretivas: Muitas novas diretivas estão em discussão, incluindo script-não: scripts embutidos só podem ser usados se os elementos de script explicitamente especificados forem usados; Tipo de plug-in: isso limitará o tipo de plug-in; Ação de formulário: permita que o formulário seja enviado apenas para uma fonte específica.
Se você estiver interessado em discussões sobre esses recursos futuros, poderá ler o arquivo da lista de discussão ou adicioná -lo à lista de discussão.
Este artigo é traduzido de:
Extraído de: Blog de Jiang Yujie