9 em 10 aplicativos sem servidor estão em apuros na segurança frontend

Renato em HackerNoon.com Segue em 9 de jul · 4 min ler

Todos nós odiamos violações de segurança e todos ficamos entediados ao investigar maneiras de proteger nossos aplicativos. Vamos encarar: é muito mais emocionante criar um recurso novo e amado do que garantir possíveis vulnerabilidades que alguém possa explorar um dia só para irritar todo mundo. No entanto, nenhum de nós quer ser pego como sendo preguiçoso em garantir o nosso software e é por isso que nos preocupamos com segurança para os mais altos padrões.

Foto de Matthew Henry no Unsplash

Flexível nem sempre é seguro

Muitas vulnerabilidades de segurança vêm de muitas flexibilidades ou não seguem o princípio do menor privilégio, por exemplo. Nos aplicativos front-end, esse problema surge do uso do LocalStorage para guardar segredos (ou seja, tokens de autenticação) e dados confidenciais do usuário.

Pare de fazer isso o mais rápido possível!

Eu sei, eu sei, o LocalStorage é muito legal: é puro JavaScript, é flexível para armazenar dados, vem com uma API fácil, suportada por todos os principais navegadores, sim, sim, é adorável. Mas, pelas mesmas razões, também é um demônio. Ao armazenar informações confidenciais no LocalStorage , você torna esses dados acessíveis para qualquer pessoa que queira executar JavaScript no seu aplicativo. Se um invasor encontrar uma maneira de injetar e executar código JS de alguma forma, você estará condenado, já que ele poderá roubar virtualmente todas as informações confidenciais de usuários registrados. Heck, é possível que essa pessoa possa até se passar por qualquer usuário e começar a fazer solicitações em nome dele sem que você saiba.

Caso você não esteja convencido e tenha mais tempo para ler sobre este assunto, leia Por favor, pare de usar o armazenamento local , por Randall Degges. Confie em mim, isso vai convencer você.

Ok, esta vulnerabilidade de segurança pode não estar afetando 9 em 10 aplicativos sem servidor, poderia ser mais, poderia ser menos. De qualquer forma, usar o LocalStorage para esse propósito é algo muito comum e não posso enfatizar o suficiente como é importante repensar essa abordagem.

Nós odiamos cookies, mas não devemos

Foto por fotógrafo de alimentos | Jennifer Pallian em Unsplash

Olha, eu também não gosto de cookies, mas eles vêm em nosso socorro quando se trata de proteger tokens de autenticação e dados confidenciais do usuário.

Eu sei o que você está pensando: “ Ei, mas não é certo começar a gerenciar cookies em uma arquitetura distribuída sem servidor, como o AWS Lambda ”!

Bem, usando cookies em vez de LocalStorage , isso não significa que você deve ter um aplicativo com estado , por isso, tenha paciência comigo nas próximas linhas.

Usar um JWT ( JSON Web Token ) – ou uma estratégia semelhante – para proteger um aplicativo da Web é muito comum hoje em dia. Basicamente, empacotamos em um hash: algumas informações do usuário, como nome de usuário, e-mail, etc, alguns dados do aplicativo e um mecanismo de hashing de validação para preservar a integridade do token. O que os desenvolvedores fazem com relativa frequência é armazenar o JWT no LocalStorage , o que facilita a coleta e o envio junto com solicitações para o back-end para fins de autenticação e autorização. O problema com essa implementação é o imenso risco de segurança que mencionamos acima.

Cookies feitos corretamente em servidores

Para limpar seu aplicativo dessa vulnerabilidade, o JWT (ou qualquer outro tipo de token de autenticação) deve ser definido pelo aplicativo como um cookie. Além disso, certifique-se de que ele fique longe dos dedos do JavaScript. Os cookies, por padrão, também podem ser acessados por JS, mas há um sinalizador chamado httpOnly , que informa ao navegador que um determinado cookie deve ser usado apenas em chamadas HTTP, ficando longe do código JS local. Veja, por exemplo, a Especificação do Cookie Mozilla e observe o sinalizador httpOnly que mencionamos.

Isso também está de acordo com as diretivas OWASP para uso de cookies e LocalStorage .

Foto de Pablo García Saldaña em Unsplash

Configurar cookies de um servidor da web tradicional geralmente é simples. Em arquiteturas sem servidor, não é tão simples. Na AWS, por exemplo, você pode usar o serviço do API Gateway com o Lambda para expor cookies personalizados ao seu aplicativo. Depois que um cookie é definido no navegador do usuário (contendo um JWT, por exemplo), ele acompanhará todas as outras solicitações para o back-end. Sua função do Lambda pode então analisar o cookie, extrair o token, autenticar o usuário e autorizar a operação como faria normalmente.

A equipe da AWS publicou um tutorial fácil de seguir explicando como fazer isso: Usando o AWS Lambda para expor cookies personalizados com o API Gateway .

Nunca há muita segurança

Agora que você aprendeu sobre essa vulnerabilidade comum e uma maneira simples de corrigi-la, continue estudando como proteger melhor seus aplicativos. OWASP tem recursos tremendamente bons.

Vivemos em uma internet divertida e rica, mas perigosa, e você nunca pode estar seguro demais . Um grande aliado em sua busca para proteger um aplicativo sem servidor são seus registros. Se você estiver gravando as informações corretas e puder acessar esses registros com eficiência em seu benefício, você terá uma boa vantagem inicial para evitar e atenuar ataques mal-intencionados.

Texto original em inglês.