A primeira muralha! Segurança no Front-End
A segurança de um sistema deve ser responsabilidade de todos, não apenas do pessoal do back-end. A equipe de testes, devops e, claro, as pessoas do front-end, têm também a responsabilidade de garantir sistemas seguros e confiáveis.
Primeiro, vamos ser claros, as muralhas de uma aplicação estão no back-end, o front-end seria como as estacas de madeira na defesa de Winterfell. Apesar de não ser a principal defesa, elas tiveram como objetivo atrasar os atacantes, e, conforme veremos, essa analogia faz bastante sentido quando falamos de segurança no front-end.
Registro do usuário
A primeira interação que nosso usuário terá com a nossa aplicação será o seu registro. Nessa etapa já existem diversas preocupações com segurança.
A segurança começa na seleção das informações que você requisita do seu usuário para se registrar. Sempre se pergunte, qual é o mínimo de informação que a minha aplicação necessita? Isso tem algumas motivações:
- Você quer que seu usuário tenha o mínimo de trabalho para acessar a sua aplicação.
- Quanto menos informações pessoais você possui do seu usuário, mais segura é sua aplicação, pois a melhor proteção é nunca ter a informação em primeiro lugar.
- Em leis de proteção à informação, como LGPD e GDPR, menos informações é menos trabalho e mais aderência a lei.
Um ponto importante é prevenir que seu usuário faça mal a si próprio. Por isso, é boa prática colocar um medidor de força de senha no seu formulário de registro.
Uma política de senhas pode ser uma opção. Porém, aumenta o atrito, pois usuários podem se frustrar, caso a política seja muito restrita.
Uma dica muito simples, mas muito importante, é utilizar corretamente as tags html para a criação do seu formulário.
Utilize os tipos corretos. Isso melhora a acessibilidade ( que é muito importante!) e melhora o suporte de ferramentas de vault de senhas como o Dashlane e o LastPass.
Login
A primeira dica que parece óbvia é: Não ajude o invasor. É comum nessa tela sistemas informarem que o usuário está correto, mas a senha está errada, ou pior, que informam que a senha existe, mas o usuário não…
Invasores podem criar scripts que exploram essa “ajuda”. Então, o ideal é sempre retornar uma mensagem padrão, como, por exemplo, “O usuário ou senha estão incorretos”.
Controle a quantidade de tentativas, bloqueando ou então exigindo que o usuário espere um número aleatório de segundos para tentar novamente.
Permissões
Depois que o usuário acessou a aplicação, como a sua interface deve se comportar e como garantir que ele navegue apenas onde ele tem permissão?
Após o acesso é comum guardar essas informações de permissão e autenticação do usuário. E os meios mais comuns são cookies e o JWT.
Cookies e sessão são os meios mais antigos e estabelecidos de armazenar e controlar autorização e permissões.
Para a sua utilização segura, utilize os atributos:
- Expire: para determinar um tempo de validade e assim o cookie ser invalidado automaticamente.
- HttpOnly: Para o cookie não ser manipulado via JavaScript.
- Secure: Para obrigar o envio de cookies somente por https.
Um meio mais recente que ganhou popularidade é o Json Web Token (JWT). O nome pode impressionar, mas ele é bem simples.
Ele é um objeto JavaScript (JSON), que é convertido para uma string base64. Porém, o seu diferencial é ele ser auto assinado. Isso quer dizer que ele tem um hash composto pelo objeto json (chamado de payload) e uma chave secreta.
O JWT, em si, não garante a segurança da aplicação e, por isso, precisamos tomar cuidado.
O mais importante é selecionar muito bem as informações do payload, nunca inserindo informações sensíveis. Lembre-se que o payload somente é transformado em base64. NÃO É CRIPTOGRAFIA.
Reforçando as defesas
A noite é escura e cheia de horrores, então antes de colocar seu site em produção, vamos ver alguns cuidados essenciais para a seu web app.
USE SEMPRE O HTTPS. Atualmente, não é aceitável o lançamento de qualquer site sem o uso do HTTPS.
No passado, o custo era incômodo, mas atualmente com a iniciativa do Lets Encrypty!(https://letsencrypt.org/), não existem justificativas para não utilizar.
Um dos ataques mais comuns é o cross-site request forgery(CSRF), onde o invasor através de alguma técnica de engenharia social tenta fazer com que o usuário clique em um link que utilizará possíveis cookies ou tokens armazenados, para realizar requisições não autorizadas.
Para evitar, podemos utilizar um token anti-CSRF, onde o servidor envia um cookie com um dado aleatório. O Front-End deve guardar essa informação e enviá-la a cada requisição.
O cross-site scripting(XSS) acontece quando o código malicioso é executado por dentro da sua aplicação. Ele normalmente pode ser executado como uma dependência maliciosa ou um campo input sem tratamento de sanitização.
Para se proteger de dependências maliciosas, você deve primeiro saber quais elas são. Dê preferência para projetos open-source.
Uma vez adicionadas, certifique-se que elas estejam sempre atualizadas. O npm e o GitHub já possuem um serviço gratuito de auditoria de dependências.
No tratamento de entradas do sistema, o Angular possui um compilador de template que trata por padrão os campos input.
Um cuidado importante é que manipular diretamente o DOM não garante essa proteção. Porém, temos métodos que podemos utilizar manualmente.
Também proteja o back-end, sanitizando todas os dados que vieram da API.
Conclusão
A segurança deve ser um processo e uma preocupação constante. Ela não deve ser apenas um requisito no backlog, deve ser um item de cada entrega e precisa ser pensada desde o começo do projeto.
