Introdução
A primeira coisa é determinar se uma informação precisa de proteção para transitar ao servidor. Por exemplo, senhas, números de cartão de créditos, informações pessoais e segredos precisam de uma proteção extra, principalmente se essas informações estão sobre leis de privacidade. Para todo tipo de informação:
- Alguma informação é transmitida em forma de um texto limpo? Isso inclui protocolos como HTTP, SMTP,FTP e também usar aprimoramentos TLS como o STARTTLS. O tráfego de internet externo é perigoso. Verifique todo tráfego de internet.
- Existe algum algoritmo de criptografia ou protocolos fracos ou antigos usados tantos nos códigos padrões ou em códigos antigos?
- As chaves de criptografias que estão em uso são padrões, fracas ou reusadas, ou falta um gerenciamento apropriado de administração e rotação de chaves de criptografia? As criptografias são verificadas no código fonte?
- O certificado do servidor está apropriadamente validado?
- Estão sendo usadas senhas senhas como chave de criptografias em falta de um algoritmo de senhas bases para criptografia?
- Uma função aleatória está sendo utilizada com o propósito de criptografia sendo que ela não foi desenhada para essa função? Até mesmo se a função correta foi escolhida, a seed dela deve ser manipulada pelo desenvolvedor, e se não, o desenvolvedor sobrescreveu a seed antiga para uma seed mais forte que desempenhe uma entropia suficiente?
- Existe a utilização de funções de hash como MD5 ou SHA1 sendo utilizadas, ou funções de hash não criptografas sendo utilizadas quando eram necessárias funções de hash para criptografia?
- Existem informações sendo vazadas através de mensagens de erros que podem contribuir para o exploit da criptografia? Como por exemplo, no formulário da Oracle?
Como prevenir
Para prevenir problemas relacionados a criptografia, é necessário, no mínimo, seguir os seguintes pontos:
- Classificar as informações processadas, guardadas ou transmitidas por uma aplicação. Identificar qual informação é sensível de acordo com as leis de privacidade, requisitos de regulamentação ou necessidades empresariais.
- Não guardar nenhuma informação sensível desnecessariamente. Descartar todas as informações sensíveis o mais rápido possível. Informação que não é retida não pode ser armazenada.
- Tenha certeza de criptografar toda informação sensível em repouso.
- Tenha certeza de manter todos os algoritmos, protocolos e chaves de criptografia atualizados; utilize uma administração de chaves de criptografia apropriada.
- Criptografe todas as informações que estão transitando através de protocolos como o TLS. Reforce a criptografia utilizando directivas como HTTP Strict Transport Security (HSTS)
- Desative o caching para respostas que podem conter informações sensíveis.
- Desenvolva os controles de segurança de acordo com a classificação dos dados.
- Não utilize protocolos legados como o FTP e o SMTP para transportar informações sensíveis.
- Guarde senhas utilizando funções de hash fortes e trabalhe com um fator de trabalho (fator de tempo), como as hashs Argon2, Scrypt, Bcrypt ou PBKDF2.
- Sempre utilize criptografia autenticada ao invés de criptografia.
- Chaves de criptografia devem ser geradas aleatoriamente de maneira criptografada e devem ser armazenados na memória em formado de arrays de bytes. Se uma senha está sendo utilizada, então ela deve ser convertida para uma chave através de um sistema de conversão de derivação de senha para chave apropriado.
- Tenha certeza que a aleatoriedade da criptografia que está sendo utilizada é apropriada, e que não tem uma senha previsível ou com pouca entropia. APIs modernas não necessitam que o desenvolvedor coloque uma seed específica em prol da segurança.
- Evite utilizar funções de algoritmos ultrapassados como MD5, SHA1, PKCS number 1 v1.5.
- Verifique, de forma independente, a efetividade das configurações e ajustes.
Exemplos de cenarios de ataque
Cenário #1: Uma aplicação criptografa todos os números do cartão de crédito de seus clientes utilizando um banco de dados com criptografia automática. Contudo, a informação é descriptografada assim que requisitada pelo servidor, permitindo que um (CWE-89) SQL Injection aproveite dessa situação para ganhar acesso a todos os números de cartão de créditos de forma limpa.
Cenário #2: O site não utiliza o protocolo TLS para todas as páginas ou possui uma criptografia fraca. Um atacante pode monitorar o trafego da rede (em uma rede insegura), realizar downgrades nas conexões HTTPS para HTTP, interceptar os requests, e roubar os cookies de sessão dos usuários.
Cenário #3: O banco de dados de senha utiliza funções de hash simples para guardar a senha de todos os seus usuários. Um arquivo enviado ao servidor pode permitir que o invasor faça o download de todo o banco de dados. Hashs que foram geradas de forma despreparada ou de forma simples podem ser facilmente quebradas através de uso de GPUs.