Introdução a Segurança na Web

Um guia para desenvolvedores sobre CORS, CSP, HSTS e as siglas encontradas em Segurança na Web!

Image for post
Image for post
Foto de Jose Fontano no Unsplash

⭐️️ Créditos

Existem muitas razões para aprender sobre segurança na Web, tais como:

E assim por diante…

Nesse artigo, iremos explorar algumas siglas comuns de Segurança da Web, uma maneira que seja fácil de entender, mas ainda sim, bem precisa.

Antes de fazermos isso, vamos nos certificar de que entendemos alguns conceitos básicos de segurança.

Dois conceitos principais de segurança

1. Ninguém está 100% seguro

Não há noção de estar 100% protegido de ser hackeado. Se alguém lhe disser isso, eles estão errados.

2. Uma camada de proteção não é suficiente

Você não pode simplesmente dizer:

Ah, porque eu tenho CSP implementado, estou seguro. Eu posso cruzar scripts entre sites da minha lista de vulnerabilidades, porque isso não vai acontecer.

Talvez isso seja o argumento de alguns e é fácil pensar dessa maneira. Acho que uma das razões pelas quais os programadores podem facilmente pensar dessa forma é que escrever código é quase 0 ou 1, true ou false. Segurança não é tão simples.

Iremos começar com uma vulnerabilidade que encontramos logo no início de nossas carreiras como desenvolvedor web. Você olha no StackOverflow e encontra um monte de respostas mostrando como contorná-la.

Cross-Origin Resource Sharing (CORS)

Você já teve um erro que se parecia com:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Você certamente não está sozinho. Você usa o Google e alguém lhe diz para usar essa extensão que fará com que todos os seus problemas vão embora!

Ótimo, certo?

Image for post
Image for post

CORS existe para te proteger, não te machucar!

Para explicar como o CORS te ajuda, vamos primeiro falar sobre cookies, especificamente cookies de autenticação. Os cookies de autenticação são usados ​​para informar ao servidor que você está logado, e eles são enviados automaticamente com qualquer solicitação que você faça para esse servidor.

Digamos que você esteja conectado ao Facebook e use cookies de autenticação. Você clica em bit.ly/r43nugi que te redireciona para superevilwebsite.rocks. Um script dentro de superevilwebsite.rocks faz uma solicitação do lado do cliente para o facebook.com no qual envia o seu cookie de autenticação.

Em um mundo sem CORS, eles podem fazer alterações em sua conta sem que você saiba. Até que, é claro, eles postem bit.ly/r43nugi em sua linha do tempo, e todos os seus amigos cliquem nele, e então publiquem bit.ly/r43nugi em todas as contas de seus amigos e então o ciclo continua em um esquema maligno que conquista todos os usuários do Facebook, e o mundo é consumido por superevilwebsite.rocks. 😆

Em um mundo com CORS, no entanto, o Facebook só permitiria solicitações com origem facebook.com para edição de dados de um usuário em seu servidor. Em outras palavras, eles limitariam o compartilhamento de recursos de origem cruzada. Você pode então perguntar:

Eles podem tentar, mas não funciona porque o navegador simplesmente ignora a alteração e usa a origem real.

Nesse caso, eles poderiam ignorar o CORS, mas não funcionaria porque não teremos um cookie de autenticação para a requisição. O script precisaria ser executado no lado do cliente para obter acesso aos cookies do lado do cliente.

Content Security Policy (CSP)

Para entender o CSP, primeiro precisamos falar sobre uma das vulnerabilidades mais comuns na Web: XSS, que significa cross-site scripting (scripting entre sites, outro acrônimo).

XSS é quando alguma pessoa malvada injeta JavaScript em seu código do lado do cliente. Você pode pensar:

Vamos supor que alguém tenha injetado com sucesso o JavaScript no código do lado do cliente de um site que você está visitando.

O que eles poderiam fazer que seria malicioso?

As possibilidades são infinitas.

Image for post
Image for post

O CSP tenta evitar que isso aconteça limitando:

Então, como isso funciona?

Quando você clica em um link ou digita uma URL na barra de endereços do seu navegador, o seu navegador faz uma solicitação GET. Eventualmente, ele faz o caminho para um servidor que serve HTML junto com alguns cabeçalhos HTTP. Se você está curioso sobre quais cabeçalhos você recebe, abra a guia Network no seu console e visite alguns sites.

Você pode ver um cabeçalho de resposta semelhante a este:

content-security-policy: default-src * dados: blob:; script-src * .facebook.com * .fbcdn.net * .facebook.net * .google-analytics.com * .virtualearth.net * .google.com 127.0.0.1:* * .spotilocal.com: * 'inseguro-in-line' 'inseguro-eval' * .atlassolutions.com blob: dados: 'auto'; dados estilo-src: blob: 'inseguro-em linha' *; -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 'auto' chrome-extension: // boadgeojelhgndaghljhdicfkmllpafd chrome-extension: // dliochdbjfkdbacpmhlcpmleaejidimm;

Essa é a política de segurança de conteúdo do facebook.com. Vamos reformatá-lo para facilitar a leitura:

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: * 'inseguro inline '' inseguro-eval '* .atlassolutions.com blob: data:' self ';
dados style-src : blob: 'unsafe-inline' *;
conecte-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 'auto' chrome-extension: // boadgeojelhgndaghljhdicfkmllpafd chrome-extension: // dliochdbjfkdbacpmhlcpmleaejidimm;

E detalhando as diretivas:

Perceba que há muito mais diretivas CSP do que apenas estas três mostradas acima. O navegador lerá o cabeçalho CSP e aplicará essas diretivas em tudo dentro do arquivo HTML que foi exibido. Se as diretivas são definidas apropriadamente, elas permitem apenas o que é necessário.

Se nenhum cabeçalho CSP estiver presente, tudo será executado e nada será restrito. Em todo lugar que você ver *, significa que é um curinga. Você pode imaginar a substituição de * por qualquer coisa, e ela será permitida/executada.

HTTPS ou HTTP

Certamente você já ouviu falar sobre HTTPS. Talvez você tenha ouvido algumas pessoas dizerem:

Ou talvez você tenha ouvido o outro lado:

Talvez você tenha ouvido falar que o Google Chrome agora marcará seu site como inseguro se não for HTTPS.

Em essência, o HTTPS é bastante simples. HTTPS é criptografado e HTTP não é.

Então, por que isso importa se você não está enviando dados confidenciais?

Prepare-se para outro acrônimo: MITM, que significa Man in the Middle.

Se você estiver usando Wi-Fi público sem senha em uma cafeteria, é muito fácil para alguém agir como um roteador, onde todas as solicitações e respostas passem por ele. Se os seus dados não estiverem criptografados, esse roteador pode fazer o que quiser com eles. Podem editar o HTML, CSS ou JavaScript antes mesmo de chegar ao seu navegador. Agora que sabemos sobre o XSS, você pode imaginar o quão ruim isso poderia ser.

É aí que entra o SSL (Secure Sockets Layer) e, mais recentemente, o TLS (Transport Layer Security). O TLS assumiu o controle do SSL em 1999 como a tecnologia de criptografia usada no HTTPS. Exatamente como o TLS funciona está fora do escopo deste artigo.

HTTP Strict-Transport-Security (HSTS)

Este é bastante simples. Vamos usar o cabeçalho do Facebook como exemplo novamente:

strict-transport-security: max-age=15552000; preload

Este cabeçalho só se aplica se você acessou o site usando HTTPS. Se você acessou o site via HTTP, o cabeçalho será ignorado. A razão é que, simplesmente, o HTTP é tão inseguro que não é confiável.

Vamos usar o exemplo do Facebook para ilustrar melhor como isso é útil na prática. Você está acessando facebook.com pela primeira vez e você sabe que o HTTPS é mais seguro que o HTTP, então você o acessa via HTTPS https://facebook.com. Quando o seu navegador recebe o HTML, ele recebe o cabeçalho acima, que informa ao seu navegador para forçar o redirecionamento para HTTPS para solicitações futuras. Um mês depois, alguém lhe envia um link para o Facebook usando HTTP http://facebook.com, e você clica nele. Como um mês é menor do que os 15552000 segundos especificados pela diretiva max-age, o seu navegador enviará a solicitação como HTTPS, evitando um potencial ataque do MITM.

Finalizando

A segurança na Web é importante, não importa em qual momento da jornada de desenvolvimento você esteja. Quanto mais você se aventurar por esses termos, mais preparado você estará. Segurança é algo que deve ser importante para todos, não apenas para as pessoas que tem o nome “segurança” no cargo! 👮

Image for post
Image for post

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store