‫Portanto, tudo o que fizemos nesta seção até
‫agora foi para proteger todos os
‫aplicativos e os dados de nossos usuários da melhor forma possível.
‫E falei sobre muitas coisas que
‫podemos fazer para conseguir isso.
‫Mas todas essas informações
‫foram espalhadas por todas essas palestras.
‫Portanto, decidi criar este resumo rápido
‫com muitas das melhores práticas que já implementamos
‫e que ainda implementaremos no
‫restante desta seção.
‫Porque a segurança é extremamente importante,
‫mas, infelizmente, muitos cursos não abordam isso o suficiente.
‫Agora, eu também
‫não estou ativando este Nodo. curso js em um curso de segurança.
‫Existem melhores cursos e especialistas para isso.
‫Mas vou mostrar algumas coisas
‫que você pode fazer para proteger adequadamente seus aplicativos e dados.
‫Vou examinar alguns ataques comuns
‫e dar algumas sugestões para evitá-los.
‫E, em primeiro lugar, temos o caso de um banco de dados
‫comprometido, o que significa que um invasor obteve acesso ao nosso banco de dados.
‫Claro, este é um problema extremamente grave,
‫mas para evitar problemas ainda
‫maiores, devemos sempre criptografar as senhas e tokens de redefinição de
‫senha, assim como fizemos nos vídeos desta seção.
‫Dessa forma, o invasor não pode
‫pelo menos roubar as senhas de nossos usuários e também não pode redefini-las.
‫Agora, sobre como prevenir ataques, vamos
‫falar sobre o ataque de força
‫bruta em que o invasor basicamente tenta adivinhar
‫uma senha tentando milhões e milhões de senhas aleatórias
‫até encontrar a correta.
‫E o que podemos fazer é tornar a solicitação de login muito lenta.
‫E o pacote bcrypt
‫que estamos usando faz exatamente isso.
‫Outra estratégia é implementar a limitação de taxa,
‫que limita o número de
‫solicitações provenientes de um único IP.
‫E este vamos
‫implementar em um dos próximos vídeos.
‫Além disso, uma boa estratégia é realmente implementar
‫um número máximo de tentativas de login para cada usuário.
‫Por exemplo, poderíamos fazer com
‫que, após 10 tentativas falhas, o usuário tivesse
‫que esperar uma hora até que pudesse tentar novamente.
‫Agora, não vou implementar essa
‫funcionalidade nesta seção, mas sinta-se à
‫vontade para experimentá-la por conta própria.
‫Provavelmente é uma experiência de aprendizado muito legal codificar
‫isso sozinho e, na verdade,
‫não é tão difícil.
‫Tudo bem.
‫Em seguida, há o ataque de script entre sites,
‫em que o
‫invasor tenta injetar scripts em nossa página para executar seu código malicioso.
‫Do lado dos clientes, isso é especialmente
‫perigoso porque permite que o invasor leia o armazenamento
‫local, razão pela qual
‫nunca devemos armazenar o token da Web JSON no armazenamento local.
‫Em vez disso, ele deve ser armazenado em um cookie somente HTTP,
‫de forma que o navegador
‫possa apenas receber e enviar o
‫cookie, mas não pode acessá-lo ou modificá-lo de nenhuma forma.
‫E isso torna impossível para qualquer invasor
‫roubar o token da Web JSON que está armazenado no cookie.
‫Novamente, estamos implementando isso em um segundo.
‫Agora, no lado do backend, para evitar ataques XSS, devemos limpar
‫os dados de entrada do
‫usuário e definir alguns cabeçalhos HTTP especiais
‫que tornam esses ataques um pouco mais difíceis de acontecer.
‫E o Express não vem com essas práticas
‫recomendadas fora da caixa, então usaremos middleware para
‫definir todos esses cabeçalhos especiais.
‫Em seguida, temos ataques de negação de serviço.
‫E talvez você já tenha ouvido falar deles.
‫Acontece quando o
‫invasor envia tantas solicitações a um servidor que
‫ele quebra e o aplicativo fica indisponível.
‫Novamente, implementar a limitação de
‫taxa é uma boa solução para isso.
‫Além disso, devemos limitar a quantidade de dados
‫que podem ser enviados em um corpo em uma postagem ou solicitação de patch.
‫E também, devemos evitar o
‫uso das chamadas expressões regulares malignas em nosso código.
‫E essas são apenas expressões regulares
‫que levam um tempo exponencial para serem executadas para entradas não
‫correspondentes e podem ser exploradas para desativar todo o nosso aplicativo.
‫Ok, em seguida, temos o ataque de injeção de consulta NoSQL.
‫E a injeção de consulta acontece quando
‫um invasor, em vez de inserir dados válidos, injeta alguma
‫consulta para criar expressões de
‫consulta que serão convertidas em verdadeiras.
‫Por exemplo, para estar logado mesmo
‫sem fornecer um nome de usuário ou senha válidos.
‫É um pouco complexo
‫e você definitivamente deveria pesquisar no Google para aprender mais.
‫Mas o que você precisa saber é que usar
‫o Mongoose é na verdade
‫uma estratégia muito boa para prevenir esse tipo
‫de ataques porque um bom esquema força cada valor a
‫ter uma guia de dados bem definida.
‫O que torna
‫esse tipo de ataque muito difícil de executar.
‫No entanto, é sempre uma boa ideia
‫ainda higienizar os dados de entrada, apenas para ter certeza.
‫E cuidaremos disso um pouco mais tarde.
‫Certo, e agora
‫para terminar, só tenho algumas práticas recomendadas
‫e sugestões sobre como melhorar
‫os mecanismos de autenticação e autorização que implementamos.
‫Portanto, a primeira coisa
‫que preciso repetir continuamente é que,
‫em um aplicativo de produção, toda
‫a comunicação entre o servidor e o
‫cliente precisa acontecer por meio de HTTPS.
‫Caso contrário, qualquer pessoa pode ouvir a conversa e
‫roubar nosso token JSON da web.
‫Em seguida, sempre crie tokens de senha aleatórios.
‫Não gerado a partir de datas ou algo parecido.
‫Por serem efetivamente senhas e,
‫portanto, devem ser tratados como tal.
‫Além disso, sempre forneça datas de
‫validade, assim como implementamos.
‫Tudo bem?
‫E também implementamos que um determinado token da web
‫JSON não é mais válido depois que o usuário altera sua senha.
‫Portanto, basicamente revogamos o token
‫assim que o usuário altera a senha.
‫O que faz muito sentido, mas,
‫novamente, muitos tutoriais por aí simplesmente não fazem isso.
‫Outra grande coisa é nunca comprometer um arquivo
‫de configuração, como para variáveis de ambiente, para um controle
‫de versão como o Git.
‫Na verdade, não o carregue em nenhum
‫lugar porque esse arquivo
‫contém os dados mais confidenciais de todo o aplicativo.
‫Por exemplo, se alguém obtiver acesso ao
‫segredo do token da
‫Web JSON, todo o seu processo de autenticação será comprometido.
‫Ok, e agora só um pequeno detalhe é para sempre que
‫houver um erro,
‫não envie todo o erro para o cliente.
‫Portanto, coisas como o rastreamento de pilha podem fornecer ao
‫invasor alguns insights valiosos sobre o seu sistema
‫e, portanto, é claro, não queremos isso.
‫A seguir, podemos usar o pacote csurf para
‫combater um tipo de ataque chamado Cross-Site Request Forgery, que é um ataque
‫que força um usuário a executar
‫ações indesejadas em um aplicativo da web no qual ele
‫está conectado no momento.
‫Não vamos fazer isso nesta seção, no entanto.
‫Mas eu ainda queria mencioná-lo aqui.
‫Em seguida, podemos exigir que o
‫usuário se reautentique antes de realizar uma ação de alto valor.
‫Por exemplo, fazer um pagamento ou excluir algo.
‫Novamente, esta é apenas uma sugestão
‫que você pode experimentar.
‫Outro recurso interessante que você pode implementar
‫é uma lista negra de tokens não confiáveis.
‫Portanto, já sabemos que não
‫há realmente uma maneira de desconectar os usuários do
‫aplicativo se eles mostrarem alguma atividade maliciosa.
‫Mas o que podemos fazer é criar uma lista de tokens
‫não confiáveis que são validados em cada solicitação.
‫E a seguir, um recurso que poderíamos ter implementado é confirmar
‫o endereço de e-mail depois que uma conta for criada pela primeira vez.
‫Então, basicamente enviando um link para o e-mail
‫do usuário, como muitos aplicativos reais realmente fazem.
‫Mas eu queria apenas manter as coisas simples aqui, e
‫é por isso que não fiz isso aqui.
‫Mas sinta-se à vontade para implementar
‫isso sozinho, se desejar.
‫Agora, um grande recurso que muitos aplicativos
‫têm é o conceito de tokens de atualização.
‫Que são basicamente para lembrar os usuários.
‫Portanto, para mantê-los logados para
‫sempre ou até que decidam se desconectar.
‫Nossa implementação atual faz com que
‫o usuário tenha basicamente que fazer login novamente depois
‫que o token da Web JSON expirar.
‫Mas, com tokens de atualização, isso não é mais necessário.
‫E é um pouco complexo de implementar e, portanto,
‫é um recurso para outra hora.
‫E, finalmente, o último que
‫poderíamos ter implementado é a autenticação de dois fatores, com a
‫qual tenho certeza que você está familiarizado.
‫Basicamente, com a autenticação de dois
‫fatores, após efetuar login no aplicativo, o
‫usuário precisa
‫realizar uma segunda ação para realmente se autenticar.
‫E, normalmente, é para inserir um código
‫enviado por mensagem de texto para um telefone celular.
‫Então, essas são muitas funcionalidades que
‫nossa autenticação poderia ter.
‫E se você quiser que eu implemente algum
‫deles, por favor, me avise na seção de perguntas e respostas.
‫E, se houver muita demanda para um
‫deles, vou mostrar como funciona.
‫Ok, mas novamente, eu não queria virar
‫este Nodo. curso js
‫em um curso completo de segurança e autenticação.
‫E só para terminar, algo que vamos implementar no
‫resto da seção é
‫evitar a poluição dos parâmetros.
‫Por exemplo, tente inserir apenas dois parâmetros de campo na
‫string de consulta que pesquisa todos os passeios.
‫E se você fizer isso, verá que
‫haverá um erro porque
‫nosso aplicativo não está preparado para isso.
‫E assim, os invasores tentam usar esses tipos de fraquezas para
‫travar os aplicativos, o que, obviamente, não é bom.
‫E então, precisamos consertar isso.
‫Ok, isso acabou por demorar muito mais do que eu esperava.
‫E existem cursos inteiros sobre segurança, se
‫você realmente gosta de segurança.
‫Tudo bem, mas estou deixando por
‫isso mesmo, então, vamos passar direto para o próximo.