O autor do material, cuja tradução publicamos hoje, diz que há muitas razões para estudar a segurança na web. Por exemplo, os usuários de sites preocupados com o roubo de seus dados pessoais estão interessados em questões de segurança. A segurança diz respeito aos desenvolvedores da Web que procuram aumentar o nível de proteção de seus projetos. O mesmo pode ser dito de programadores iniciantes que procuram trabalho e se preparam para entrevistas. O objetivo deste artigo é entender algumas tecnologias importantes de segurança da Web em um idioma compreensível. Antes de começarmos a falar sobre essas tecnologias, geralmente chamadas de abreviações como CORS, CSP e HSTS, veremos alguns conceitos básicos de segurança.
Dois conceitos básicos de segurança na web
100% de proteção é um mito
No mundo da segurança, não existe "100% de proteção contra hackers". Se alguém lhe falar sobre esse nível de proteção, saiba que ele está errado.
▍Um nível de proteção não é suficiente
Suponha que alguém acredite que, ao implementar o CSP, ele protegeu completamente seu projeto contra ataques XSS. Talvez alguém perceba que a proteção absoluta não existe como um dado, mas pensamentos como o descrito acima podem visitar alguém. Se falamos de programadores que decidiram entender questões de segurança, talvez o motivo de tais pensamentos seja o fato de que, ao escrever o código do programa, eles operam principalmente com conceitos como "preto" e "branco", 1 e 0, "verdadeiro" e "falso". Mas a segurança não é tão simples.
Tecnologias de Segurança na Web
Vamos começar a discussão sobre segurança na Web com tecnologia, na qual os desenvolvedores costumam prestar atenção muito cedo, digamos, no início de seu caminho profissional. A propósito, se você quiser ignorar esse método de proteção, poderá encontrar uma tonelada de informações sobre como fazer isso no StackOverflow. É sobre o CORS.
▍CORS
Você já viu esse erro:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Diante disso, você acha que certamente não é o primeiro com quem isso aconteceu. Pesquisando no Google, você descobre que, para resolver esse problema, basta instalar algum tipo de extensão. Bem, não é maravilhoso? No entanto, a tecnologia CORS (compartilhamento de recursos de origem cruzada, compartilhamento de recursos entre fontes diferentes) não existe para interferir com os desenvolvedores, mas para proteger seus projetos.
Para entender como o CORS protege os projetos da Web, falaremos primeiro sobre cookies, em particular, cookies usados para autenticar usuários. Esses cookies são usados ao trabalhar com um determinado recurso da web para informar o servidor que o usuário está logado. Eles são enviados automaticamente com solicitações em execução no servidor correspondente.
Suponha que você esteja conectado à sua conta do Facebook e o Facebook use cookies de autenticação. Trabalhando na Internet, você clica no link
bit.ly/r43nugi , é redirecionado para um site malicioso, por exemplo, algo como
superevilwebsite.rocks . O script baixado junto com a página deste site executa uma solicitação do cliente ao
facebook.com usando seu cookie de autenticação.
Em um mundo sem o CORS, um script do
superevilwebsite.rocks poderia secretamente fazer alterações no seu perfil do FB, roubar algumas informações, com todas as conseqüências resultantes. Nesse mundo, um "superevilwebsite.rocks da epidemia" poderia facilmente surgir, quando um script que captura o gerenciamento de contas do usuário publica um link em sua página, clicando no qual os amigos desse usuário "se infectam" e, nos links publicados em suas páginas, uma epidemia em última análise, abrange todo o Facebook.
No entanto, em um mundo em que o CORS existe, o Facebook só permitiria solicitações para modificar os dados da conta no
facebook.com . Em outras palavras, a administração do site limitaria o compartilhamento de recursos entre diferentes fontes.
Aqui você pode ter a seguinte pergunta: "Mas o superevilwebsite.rocks pode simplesmente alterar o cabeçalho da fonte em suas solicitações e parecerá que eles vêm do facebook.com?"
Um site fraudulento pode tentar fazer isso, mas não terá êxito, porque o navegador ignorará esse cabeçalho e usará dados reais.
“E se o superevilwebsite.rocks fizer uma solicitação semelhante do servidor?”, Você pergunta.
Em uma situação semelhante, o CORS pode ser contornado, mas não haverá utilidade nisso, pois, executando uma solicitação do servidor, não será possível transmitir um cookie de autenticação ao Facebook. Portanto, o script, para concluir com êxito essa solicitação, deve ser executado no lado do cliente e ter acesso aos cookies armazenados no cliente.
▍CSP
Para entender o que é CSP (Política de Segurança de Conteúdo, Política de Proteção de Conteúdo), primeiro você precisa falar sobre uma das vulnerabilidades da Web mais comuns. É sobre XSS (script entre sites, script entre sites).
Ao executar um ataque XSS, o invasor injeta código JavaScript especial na parte do cliente de um determinado site. Você pode pensar: “Bem, o que esse script fará? Alterar as cores dos elementos da página? ”
Suponha que alguém tenha incorporado com êxito o script JS nas páginas do site que você está visitando. O que um script semelhante poderia fazer? De fato, muitas coisas:
- Ele pode fazer solicitações HTTP para outros sites, fingindo que você os está fazendo.
- Ele pode redirecioná-lo para um site que se parece exatamente com o qual você está conectado, mas foi projetado, por exemplo, para roubar credenciais.
- É capaz de adicionar tags
<script> a páginas que contêm algum código JavaScript ou foram projetadas para carregar algum tipo de arquivo JS. - Ele pode adicionar um elemento
<iframe> à página, que, por exemplo, será exatamente igual aos campos para inserir o nome e a senha para entrar no site. Nesse caso, esses campos para inserir esses dados serão ocultados.
De fato, as possibilidades que um invasor pode executar com êxito um ataque XSS são infinitas.
A política de proteção de conteúdo tenta impedir isso aplicando as seguintes restrições:
- Limitações sobre o que pode ser aberto em um
<iframe> . - Limitações nas quais folhas de estilo podem ser carregadas.
- Limitações sobre quais consultas podem ser executadas.
Como o CSP funciona?
Quando você clica no link ou insere o URL do site na barra de endereços do navegador, o navegador executa uma solicitação GET. A solicitação chega ao servidor, que passa algum código HTML para o navegador junto com os cabeçalhos HTTP. Se você estiver interessado em examinar esses títulos, abra a guia Rede nas ferramentas de desenvolvedor do navegador e visite vários sites. O cabeçalho da resposta pode ser algo como isto:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Esta é a política de segurança de conteúdo do
facebook.com . Converta-o para uma aparência mais legível:
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Considere as diretrizes de CSP apresentadas aqui:
default-src - proíbe tudo o que não está definido explicitamente.script-src - introduz restrições sobre scripts para download.style-src - impõe restrições às folhas de estilo carregadas.connect-src - introduz restrições em URLs a partir dos quais os recursos podem ser carregados usando interfaces de script, como fetch , XHR , ajax e assim por diante.
Observe que, de fato, existem muitas dessas diretrizes. O navegador lê o cabeçalho do CSP e aplica as regras apropriadas no arquivo HTML carregado. As diretivas configuradas corretamente permitem apenas as ações necessárias para a operação correta da página.
Se a página não tiver um cabeçalho CSP, não haverá proibições. Os caracteres * no cabeçalho do CSP são curingas. Esse sinal pode ser substituído por qualquer coisa, e o que acontecer será permitido.
▍HTTPS
Certamente você já ouviu falar de HTTPS (HTTP Secure). Talvez você tenha se deparado com algo assim: "Por que eu deveria me preocupar com HTTPS se eu apenas jogar um jogo no site?" Ou, talvez, você tenha a seguinte ideia: “Se você não possui HTTPS, isso é uma loucura. No quintal 2018 ano! Não acredite em ninguém que diga que HTTPS pode ser dispensado. ”
Você deve ter ouvido falar que o Chrome agora marca o site como inseguro se ele não usa HTTPS.
A principal diferença entre HTTPS e HTTP é que, ao transmitir dados via HTTPS, eles são criptografados, mas ao transmitir via HTTP, eles não são.
Por que vale a pena prestar atenção ao transferir dados valiosos? O fato é que, ao organizar a troca de dados por um canal de comunicação inseguro, existe a possibilidade de um ataque MITM (Man In The Middle, um ataque intermediário ou um homem no meio).
Se você, sentado em um café, acessa a Internet através de um ponto de acesso Wi-Fi aberto, alguém, simplesmente, pode fingir ser um roteador através do qual todos os seus pedidos e respostas passam. Se seus dados não estiverem criptografados, o intermediário poderá fazer com ele o que ele quiser. Digamos que ele possa editar o código HTML, CSS ou JavaScript antes que ele chegue do servidor no seu navegador. Dado o que já sabemos sobre ataques XSS, você pode imaginar quais podem ser as consequências.
"Como isso é possível: meu computador e servidor sabem como criptografar e descriptografar os dados que trocamos, mas o intermediário malicioso não?", Você pergunta. Isso é possível graças ao uso do protocolo SSL (Secure Sockets Layer) e ao protocolo TLS (Transport Layer Security) mais recente. O TLS substituiu o SSL em 1999 como a tecnologia de criptografia usada no HTTPS. Uma discussão sobre os recursos do TLS está além do escopo deste artigo.
▍HSTS
A tecnologia HSTS (HTTP Strict-Transport-Security, o mecanismo de ativação forçada de uma conexão segura via protocolo HTTPS) é bastante simples. Como exemplo, considere o cabeçalho correspondente do Facebook novamente:
strict-transport-security: max-age=15552000; preload
Vamos analisá-lo:
max-age define o tempo durante o qual o navegador deve forçar o usuário a trabalhar com o site via HTTPS.preload - preload - para nossos propósitos, isso não é importante.
Este cabeçalho se aplica apenas se você estiver acessando o site usando HTTPS. Se você trabalha com o site via HTTP, esse cabeçalho é ignorado. A razão para isso é bastante simples: a comunicação HTTP é tão fraca que um cabeçalho desse tipo não pode ser confiável.
Vamos usar novamente o exemplo do Facebook para demonstrar a utilidade prática do mecanismo HSTS. Suponha que você faça login no facebook.com pela primeira vez e saiba que o HTTPS é mais seguro que o HTTP; portanto, use este link:
https://facebook.com . Quando o navegador recebe o código HTML, ele também recebe um cabeçalho que informa ao navegador que ele deve forçar você a mudar para HTTPS ao fazer solicitações futuras. Depois de um mês, alguém envia um link HTTP para o Facebook,
http://facebook.com , e você clica nele. Como o mês é inferior ao período de 15552000 segundos especificado pela diretiva de
max-age , o navegador enviará uma solicitação via HTTPS, impedindo um possível ataque MITM.
Sumário
Hoje discutimos algumas tecnologias que são universalmente usadas para garantir a segurança de projetos da web. Acreditamos que os problemas de segurança são muito importantes, pois dizem respeito a todos os que estão conectados à Internet. O tópico de segurança na Web é enorme, então você não pode dizer que, depois de ler vários artigos, alguém se tornará um especialista nesse campo ou pelo menos aprenderá o suficiente para proteger efetivamente seu projeto da Web ou seus dados pessoais. Mas, como em qualquer outro campo, o conhecimento no campo da segurança, se houver um desejo de recebê-lo, é acumulado e sua quantidade gradualmente se transforma em qualidade. Esperamos que este material tenha contribuído para o seu conhecimento de segurança na web.
Caros leitores! Você encontrou problemas de segurança inconsistentes de desenvolvedores da Web?
