<\/p>\n
Nas \u00faltimas semanas, abordamos no blog v\u00e1rios cabe\u00e7alhos HTTP relacionados \u00e0 seguran\u00e7a, mas o principal de todos eles \u00e9 o Content-Security-Policy<\/a>(CSP). O chefe, tanto pelo n\u00edvel de prote\u00e7\u00e3o que oferece quanto, infelizmente, pela dificuldade de implement\u00e1-lo corretamente na primeira vez. Assim como todas as regras de gerenciamento de tr\u00e1fego do flightPATH que discutimos recentemente, n\u00f3s mesmos as usamos para proteger o site da edgeNEXUS e seus visitantes. <\/p>\n Fizemos o trabalho duro e sentimos a dor para que voc\u00ea n\u00e3o precise fazer isso, mas n\u00e3o h\u00e1 como negar que \u00e9 necess\u00e1rio pensar e planejar um pouco antes da implementa\u00e7\u00e3o. No entanto, vale a pena. O conceito por tr\u00e1s desse cabe\u00e7alho \u00e9 bastante simples<\/a> e igualmente poderoso. Em poucas palavras, voc\u00ea o usa para especificar as origens permitidas do conte\u00fado que pode ser carregado no seu site. Isso oferece uma forte prote\u00e7\u00e3o contra v\u00e1rios ataques de inje\u00e7\u00e3o de c\u00f3digo predominantes na Internet cada vez mais din\u00e2mica de hoje, como XSS (Cross Site Scripting) e Clickjacking. <\/p>\n Os tipos de conte\u00fado que podem ser controlados incluem: JavaScript, CSS (sim, o CSS pode ser perigoso), quadros HTML, fontes, imagens e objetos incorpor\u00e1veis, como applets Java. \u00c9 \u00f3timo ter tantas op\u00e7\u00f5es, mas \u00e9 a\u00ed que surge a dificuldade. Os sites atuais (inclusive o nosso) cont\u00eam uma infinidade desses tipos de conte\u00fado de v\u00e1rias fontes, e identificar e contabilizar todos eles em uma pol\u00edtica pode ser um grande esfor\u00e7o. <\/p>\n Antes de entrarmos nesse assunto, vamos dar uma olhada nos elementos do valor do cabe\u00e7alho e na apar\u00eancia de uma pol\u00edtica. Como voc\u00ea ver\u00e1, ela \u00e9 essencialmente uma longa lista de tipos de conte\u00fado (todos terminando com -src neste exemplo) e as fontes permitidas para cada tipo. Juntos, eles s\u00e3o conhecidos como diretivas de pol\u00edtica. <\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:; child-src \u201cself\u201d<\/strong><\/p>\n H\u00e1 outros tipos de conte\u00fado que podemos considerar, mas as diretrizes mostradas acima s\u00e3o as mais importantes (em nossa opini\u00e3o, com base no risco e na preval\u00eancia). Aqui voc\u00ea encontra os detalhes sobre o conte\u00fado a que cada uma delas se refere; <\/p>\n Esses tipos de conte\u00fado e seus valores s\u00e3o separados uns dos outros (delimitados) por um ponto e v\u00edrgula. Cada tipo pode ter um ou mais dos seguintes valores; <\/p>\n Um espa\u00e7o simples \u00e9 usado para delimitar cada valor. As aspas simples ‘ s\u00e3o necess\u00e1rias, a menos que o valor seja um nome de dom\u00ednio. Observe que as extens\u00f5es e os plug-ins do navegador est\u00e3o isentos, pois s\u00e3o considerados seguros porque t\u00eam a confian\u00e7a do usu\u00e1rio (que os instalou, afinal). <\/p>\n Tudo isso parece um tanto t\u00e9cnico e complexo, mas se voc\u00ea abordar uma etapa de cada vez, ser\u00e1 muito r\u00e1pido criar uma pol\u00edtica. Vamos analisar rapidamente dois exemplos. Primeiro, vamos tentar um site interno simples servido por HTTP. Aqui est\u00e1 o que voc\u00ea precisa; <\/p>\n O valor completo do cabe\u00e7alho \u00e9 razoavelmente curto:<\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:<\/strong><\/p>\n Segundo, um site protegido por SSL\/TLS voltado para a Internet que usa o Google Analytics (GA), CSS em linha, fontes e imagens, CSS do seu site e imagens de v\u00e1rios outros sites. Vamos analisar o que voc\u00ea precisa, pe\u00e7a por pe\u00e7a (n\u00e3o \u00e9 muito diferente); <\/p>\n Somando tudo isso, temos essa pol\u00edtica um pouco mais longa:<\/p>\n default-src \u201cself\u201d data: https:; script-src \u201cself\u201d \u201cunsafe-inline\u201d *.google-analytics.com https:; img-src \u201cself\u201d \u201cunsafe-inline\u201d * https:; style-src \u201cself\u201d \u201cunsafe-inline\u201d https:; font-src \u201cself\u201d \u201cunsafe-inline\u201d https:<\/strong><\/p>\n Eu diria que \u00e9 bem f\u00e1cil. No passado, o Google n\u00e3o era t\u00e3o \u201camig\u00e1vel\u201d com o CSP (esse valor de cabe\u00e7alho costumava ter pelo menos o dobro do comprimento), mas, felizmente, eles fizeram grandes progressos recentemente. Voc\u00ea notar\u00e1 que n\u00e3o foi necess\u00e1rio adicionar o dom\u00ednio *.google-analytics.com ao script-src como um valor de tipo de conte\u00fado, pois o c\u00f3digo deles \u00e9 executado como um script em linha.<\/p>\n O ideal \u00e9 que voc\u00ea crie uma pol\u00edtica por p\u00e1gina do seu site, pois os recursos carregados, sem d\u00favida, ser\u00e3o diferentes de acordo com a p\u00e1gina, mas isso \u00e9 bastante oneroso e \u00e9 muito mais simples, mas ainda assim eficaz, criar uma pol\u00edtica que abranja todas as fontes poss\u00edveis. A maioria dos exemplos em nossa p\u00e1gina do GitHub adota essa abordagem, mas tamb\u00e9m h\u00e1 um exemplo se voc\u00ea quiser oferecer maior prote\u00e7\u00e3o a p\u00e1ginas espec\u00edficas. <\/p>\n Para testar e solucionar problemas, recomendo que voc\u00ea use as Ferramentas do desenvolvedor do Google Chrome. V\u00e1 para o site em quest\u00e3o e pressione F12, clique em Rede, verifique se Desativar cache est\u00e1 marcado e recarregue a p\u00e1gina. Todos os erros ser\u00e3o destacados claramente. Na parte inferior deste blog h\u00e1 uma tela do que voc\u00ea poder\u00e1 ver se sua pol\u00edtica estiver bloqueando o unsafe-inline<\/strong> e voc\u00ea estiver usando o Google Analytics; as mensagens de erro s\u00e3o muito \u00fateis. <\/p>\n Ajuste sua pol\u00edtica conforme necess\u00e1rio, enx\u00e1gue e repita. O ideal \u00e9 que voc\u00ea fa\u00e7a isso usando um servi\u00e7o virtual de teste dedicado com a regra flightPATH que voc\u00ea est\u00e1 testando aplicada, mas que atenda ao mesmo site, apenas por meio de um IP virtual diferente para n\u00e3o afetar clientes reais enquanto estiver testando. <\/p>\n Como sempre acontece, a grande vantagem de usar um balanceador de carga \u00e9 que s\u00f3 precisamos fazer isso em um local central para proteger todos os nossos servidores (e sites). N\u00e3o precisamos depender de desenvolvedores ou de reconfigura\u00e7\u00f5es de servidores da Web. No balanceador de carga edgeNEXUS, basta importar um modelo de configura\u00e7\u00e3o autom\u00e1tica do jetPACK e atribuir uma regra de tr\u00e1fego flightPATH ao(s) servi\u00e7o(s) virtual(is) que desejamos proteger (ap\u00f3s as modifica\u00e7\u00f5es adequadas). <\/p>\n A regra s\u00f3 adiciona o cabe\u00e7alho se ele n\u00e3o existir, portanto, funcionar\u00e1 mesmo quando nossos servidores da Web j\u00e1 o inserirem ou talvez s\u00f3 o insiram em p\u00e1ginas espec\u00edficas. Essa regra deve fazer parte da configura\u00e7\u00e3o padr\u00e3o do Virtual Service – voc\u00ea n\u00e3o tem nada a perder, seja qual for o site, embora, \u00e9 claro, seja sempre recomend\u00e1vel fazer testes. Voc\u00ea pode fazer o download desse jetPACK e de muitos outros no site do Github da edgeNEXUS<\/a>. <\/p>\n O flightPATH \u00e9 um mecanismo de regras din\u00e2mico e baseado em eventos desenvolvido pela edgeNEXUS para manipular e rotear de forma inteligente o tr\u00e1fego IP, HTTP e HTTPS com balanceamento de carga. Ele \u00e9 altamente configur\u00e1vel e poderoso, mas muito f\u00e1cil de usar. <\/p>\n Vale a pena ler esses links relacionados se voc\u00ea quiser saber mais;<\/p>\n http:\/\/www.html5rocks.com\/en\/tutorials\/security\/content-security-policy\/<\/a><\/p>\n https:\/\/developer.mozilla.org\/en\/docs\/Web\/Security\/CSP\/CSP_policy_directives<\/a><\/p>\n\n
\n
\n
\n