Compartilhe

Introdução

Antes de prosseguirmos, precisamos estabelecer algumas regras básicas que, na minha opinião, representam uma boa administração, mas pode-se até argumentar que essas coisas são necessárias em 2021.

Usar TLS

Quantas vezes você navegou na web hoje em dia e não viu aquele cadeado verde na barra de URL? Aposto que não é frequente e, quando aconteceu, foi em um site muito estático.

Hoje em dia é totalmente proibido usar HTTP, FTP, … quando temos opções seguras facilmente disponíveis. Por exemplo:

https://letsencrypt.org/

Este é um site muito fácil de usar que pode facilmente ajudá-lo a colocar esse bloqueio seguro em seu site. A melhor parte? É grátis!

O mesmo vale para o FTP, é claro, podemos continuar usando o FTP, mas deve haver um bom motivo quando o SFTP existir se ele se referir a dados confidenciais.

https://qiita.com/alokrawat050/items/709d3c777407ab658aa9

Biscoitos

Hoje em dia, temos vários sinalizadores que podemos definir em cookies que devemos usar, se pudermos.

HttpOnly: Este cookie não pode ser lido ou definido pelo código javascript. Isso pode proteger um aplicativo contra ataques XSS, mas apenas não permitindo que o invasor roube esse cookie específico. Lembre-se de habilitar isso em TODOS os cookies sensíveis.
Sessão: Este cookie é válido apenas para a sessão atual e será destruído posteriormente. Útil se você deseja que os cookies sejam sensíveis ao contexto da sessão e nada mais. (ou seja, quando o usuário está logado)
Seguro: se esse sinalizador for definido, o cookie nunca será enviado em nenhuma solicitação que não seja baseada em TLS. (HTTPS)
HostOnly: Este sinalizador impossibilita a leitura de cookies de outros domínios, INCLUINDO outros subdomínios. O cookie “a” estará disponível em hackxpert.com , mas não em mail.hackxpert.com

Teste cada parte da entrada do usuário

Pode parecer óbvio a princípio, mas tudo o que os usuários podem controlar precisa ser rigorosamente testado. Não podemos confiar nele em nenhum grau e especialmente se o seu aplicativo for voltado para o público. Você ficaria surpreso como os hackers podem encontrar um ponto de entrada. Eu filtrei cada entrada do meu aplicativo uma vez… mas eles encontraram uma maneira porque o id do meu objeto também foi refletido na página em um campo de entrada oculto e eles conseguiram abusar da única coisa que eu nunca esperei que os usuários controlassem.

Isso significa:

Entradas ocultas
Nomes de arquivo
Conteúdo do arquivo
Parâmetros ativos, mas não usados
Cabeçalhos

E mesmo que você pense que está seguro, não está. Basta dar uma olhada

https://hackxpert.com/RXSS/GET/50.php

Este laboratório aceita apenas endereços de e-mail, então recomendo que você tente ” "><svg/onload=alert(1)>"@x.y“

Não permita inundações

Isso significa que não deve permitir que o usuário insira mais dados do que deveria. Um exemplo seria uma descrição em que não seria sensato permitir que o usuário inserisse dados infinitos, pois isso poderia matar rapidamente um banco de dados completo. Alguns itens mais óbvios também vêm à mente, como números de telefone, endereços de e-mail e endereços.

Sempre que necessário e possível, use criptografia

Você realmente não quer ser conhecido como a empresa que salvou as senhas dos clientes em texto simples, mas também ao enviar dados entre serviços ou APIs, devemos criptografar todos os dados confidenciais para evitar que um ataque MiTM cause sérios danos.

Além disso, você precisa criptografar todos os dados armazenados que parecem ser confidenciais ou, pelo menos, colocar segurança em camadas no banco de dados, mas mais sobre isso no próximo capítulo.

Use a segurança multicamadas

Eu sei que isso parece um empecilho e dar a cada novo funcionário que está na empresa há apenas alguns dias acesso de administrador em vez de arranjar uma conta adequada para eles.

Use bibliotecas conhecidas, especialmente para coisas como criptografia

Não é uma boa ideia escrever código personalizado para soluções existentes, como plug-ins e bibliotecas. Ao falar sobre funções de segurança importantes, como autenticação, autorização e dados relacionados, devemos nos certificar de não usar nosso próprio código para protegê-lo, mas usar uma biblioteca bem conhecida e testada que provou resistir ao teste de tempo.

Faça uso de atrasos e limitação de taxa sempre que possível

Os invasores geralmente contam com técnicas que exigem que eles disparem várias solicitações por segundo, mas algumas taxas de limitação decente para algumas solicitações por segundo e até mesmo o banimento temporário de endereços IP quando enviam spam ao sistema não é uma má ideia.

A última opção que temos é adicionar um captcha que geralmente não afeta muito os usuários normais hoje em dia, mas desde que o Google o adquiriu, parece aparecer com frequência para bots. Acho que todos nós conhecemos o captcha “Selecione as imagens com uma zebra azul”, mas como você deve saber, você não os vê mais com frequência, então isso não é um grande impedimento para os consumidores.

Embora isso possa ser eficaz, você precisa ter certeza de não atrapalhar os usuários que desejam usar seu aplicativo a uma taxa decentemente rápida, mas quanto mais você puder atrasar os bots, melhor.

Uma boa abordagem para isso pode ser o “recuo gradual”, em que você dobra o tempo de espera antes que uma nova solicitação possa ser enviada após o envio de uma solicitação inválida, como uma tentativa de login inválida.

Construir muros de segurança

Por mais que o usuário médio odeie redigitar sua senha, isso pode fornecer proteção eficaz contra invasores que podem comprometer uma conta, pois serão limitados a cada vez que exigirem a digitação de uma senha. Você também não quer incomodar o consumidor, mas o seguinte seria recomendado para pelo menos conter um local para reinserir a senha do usuário:

Em uma ação de compra
Em uma ação de alteração de senha
Em uma ação de e-mail de alteração
Quando os dados de acesso podem ser considerados confidenciais, como a exibição de dados de cartão de crédito

APIs

É importante falar sobre dividir seu código em APIs lógicas porque, se o fizer, será muito mais fácil auditar as interações entre suas APIs internas. Você sabe que auditar o tráfego interno no código-fonte nunca é fácil, mas se expormos isso por meio de APIs, é muito mais provável que produzamos código seguro, auditável e reutilizável.

Revisão por pares

As revisões por pares são uma parte importante das boas práticas de código e, embora a maioria das pessoas pense que qualquer outro desenvolvedor pode realizar auditorias de código, acho vital que pelo menos uma pessoa com muita experiência na área de segurança também olhe para o código de maneira crítica antes de ser enviado para os pipelines de produção.

Pode até ser benéfico trazer um auditor externo que dê uma olhada objetiva no código e na arquitetura e traga sua experiência. Possivelmente até regularmente.

Use analisadores de código conhecidos

Os analisadores de código podem encontrar facilmente bugs que os humanos não percebem e são uma adição vital ao seu conjunto de ferramentas. Ferramentas como SonarQube ou findBugs podem revelar explorações ocultas que são fáceis de perder para os humanos. Eles podem exigir alguma configuração inicial, mas valem a pena.

O caminho do menor privilégio

Cada função, cada entrada do usuário, cada processo único deve receber apenas tantos privilégios quantos forem necessários para funcionar corretamente. Se você conceder mais direitos a determinados usuários ou processos, poderá se expor a ataques, portanto, pode ser um pouco mais difícil implementar todas essas medidas de segurança e garantir que seu aplicativo ainda funcione. Um ataque real custaria várias vezes o valor que você ‘teria que gastar em tempo de desenvolvimento e controle de qualidade.

Limite os detalhes da sua mensagem de erro

Você realmente não deseja fornecer aos invasores nenhuma informação, portanto, depurar, registrar, informações e mensagens de erro devem ser todos desativados e mantidos no registro interno. Mesmo algo tão simples como um nome de banco de dados SQL pode ser suficiente para um invasor concluir seu ataque SQLi.

Credenciais padrão

Nunca deixe nenhuma credencial padrão, sempre desative a conta padrão e certifique-se de que as páginas de administração não tenham senhas/nomes de usuário preguiçosos, como test/test ou admin/admin

Isso deve falar por si, mas me dói ver quantas vezes isso é esquecido e uma conta de teste é enviada para produção ao copiar o módulo de autenticação, então, por favor, não cometa esses erros.

Atualizações

Mantenha todos os softwares, bibliotecas e plug-ins atualizados. Isso parece mais fácil do que é porque, se seu aplicativo crescer, as bibliotecas e os plug-ins usados podem ficar fora de controle ou você pode perder uma visão geral. É por isso que você precisa trabalhar diligentemente para manter as coisas atualizadas, porque geralmente essas atualizações também contêm atualizações de segurança e você não quer perdê-las

Não guarde senhas em arquivos

Se você carregar esses arquivos em um repositório público, as senhas também serão públicas e, mesmo que você remova o arquivo, o histórico de confirmação também existirá. É muito melhor manter senhas confidenciais em variáveis de ambiente. Dessa forma, você pode transferir essas senhas para sua solução de CI/CD e garantir que os invasores nunca vejam os valores reais.

Use filtragem/validação do lado do cliente e do servidor

É importante saber que a validação do lado do cliente pode formar uma pequena barreira para os invasores, hoje em dia, eles nem se importam. Com proxies MiTM e habilidades para desabilitar essas validações do lado do cliente, temos que garantir também a implementação de validações do lado do servidor.