Awesome Application Security Checklist

Awesome-Aplicação-Security Checklist

Se você estiver projetando, criando, testando seu aplicativo web/celular com segurança em mente, esta lista de verificação de contra-medidas pode ser um bom ponto de partida

Sistemas de autenticação (SignUp/Signin/2 Factor/Senha Redefinir)

• Use https em todos os lugares.
• Armazene os hashes de senha usando Bcrypt (sem necessidade de sal - Bcrypt faz isso para você).
• Destrua o identificador da sessão após logout .
• Destrua todas as sessões ativas na senha de redefinição (ou oferta).
• Deve ter o parâmetro state em OAuth2.
• Não há redirecionamentos abertos após o login bem -sucedido ou em outros redirecionamentos intermediários.
• Ao analisar a entrada/entrada de login, higienize para JavaScript: //, data: //, CRLF caracteres.
• Defina biscoitos seguros e httponly.
• Na verificação móvel móvel baseada em OTP , não envie o OTP de volta à resposta quando generate OTP ou Resend OTP é chamada.
• Limite as tentativas de Login , Verify OTP , Resend OTP e generate OTP para um usuário específico. Tenha um conjunto de retirada exponencial ou/e algo como um desafio baseado em Captcha.
• Verifique a aleatoriedade do token de senha de redefinição no link ou sms por e -mail.
• Defina uma expiração no token de senha de redefinição por um período razoável.
• Expire o token de redefinição depois de ter sido usado com sucesso.

Dados e autorização do usuário

• Qualquer acesso a recursos, como, my cart , my history deve verificar a propriedade do usuário do usuário usando o ID da sessão.
• O ID de recurso de itialmente iterial deve ser evitado. Use /me/orders em vez de /user/37153/orders . Isso atua como uma verificação de sanidade, caso você se esqueça de verificar se há token de autorização.
• Edit email/phone number deve ser acompanhado por um email de verificação para o proprietário da conta.
• Qualquer recurso de upload deve higienizar o nome do arquivo fornecido pelo usuário. Além disso, por geralmente razões, além da segurança, envie o upload para algo como S3 (e pós-processo usando o Lambda) e não o seu próprio servidor capaz de executar o código.
• O recurso Profile photo upload deve higienizar todas as tags EXIF ​​também se não forem necessárias.
• Para IDs de usuário e outros IDs, use UUID compatível com RFC em vez de inteiros. Você pode encontrar uma implementação para isso para o seu idioma no Github.
• JWT são incríveis. Use -os se necessário para o seu aplicativo/APIs de página única.

Banco de dados

• Use a criptografia para dados que identifiquem usuários e dados confidenciais, como tokens de acesso, endereços de email ou detalhes de cobrança.
• Se o seu banco de dados suportar criptografia de baixo custo em repouso (como a AWS Aurora), permita que isso proteja dados no disco. Verifique se todos os backups também são armazenados criptografados.
• Use privilégio mínimo para a conta de usuário de acesso ao banco de dados. Não use a conta raiz do banco de dados.
• Armazene e distribua segredos usando uma loja de teclas projetada para a finalidade. Não coda -se em seus aplicativos.
• Impedir totalmente a injeção de SQL usando apenas declarações preparadas com SQL. Por exemplo: Se estiver usando o NPM, não use o NPM-MYSQL, use o NPM-MYSQL2, que suporta declarações preparadas.

Aplicativo Android / iOS

• salt de gateways de pagamento não deve ser codificado.
• O token secret / auth token do 3º Party SDK não deve ser codificado.
• As chamadas da API destinadas a ser feitas server to server não devem ser feitas no aplicativo.
• No Android, todas as permissões concedidas devem ser cuidadosamente avaliadas.
• No iOS, armazenar informações confidenciais (tokens de autenticação, teclas de API etc.) no chaveiro do sistema. Não armazene esse tipo de informação nos padrões do usuário.
• A fixação de certificado é altamente recomendada.

Cabeçalhos e configurações de segurança

• Add o cabeçalho do CSP para mitigar os ataques XSS e a injeção de dados. Isso é importante.
• Add o cabeçalho da CSRF para evitar a falsificação de solicitação de local cruzado. Adicione também atributos samesite nos cookies.
• Add o cabeçalho HSTS para impedir o ataque de remoção de SSL.
• Add seu domínio à lista de pré -carga do HSTS
• Add as opções x-frame para proteger contra o ClickJacking.
• Add o cabeçalho da proteção X-XSS para mitigar ataques XSS.
• Atualize os registros DNS para adicionar registro SPF para mitigar spam e ataques de phishing.
• Adicione verificações de integridade do SubreSource se carregar suas bibliotecas JavaScript de uma CDN de terceiros. Para uma segurança extra, adicione o requisito-sri-for csp diretivo para que você não carregue recursos que não tenham um SRI SAT.
• Use tokens aleatórios de CSRF e exponha as APIs de lógica de negócios como solicitações de postagem HTTP. Não exponha os tokens CSRF sobre o HTTP, por exemplo, em uma fase de atualização de solicitação inicial.
• Não use dados críticos ou tokens nos parâmetros de solicitação GET. A exposição dos logs do servidor ou uma máquina/processamento de pilha exporia os dados do usuário por sua vez.

Sinitização da entrada

• Sanitize todas as entradas do usuário ou qualquer parâmetros de entrada expostos ao usuário para impedir o XSS.
• Sempre use consultas parametrizadas para evitar a injeção de SQL.
• Habilizar a entrada do usuário se usá -la diretamente para funcionalidades como a importação de CSV.
• Sanitize a entrada do usuário para casos especiais como robots.txt como nomes de perfil, caso você esteja usando um padrão de URL como o coolcorp.io/username.
• NÃO MARDE CÓDIGO ou CUIR JSON BY String Concatenation nunca, por menor que seja o objeto. Use suas bibliotecas ou estruturas definidas por idiomas.
• Habilize os insumos que tomam algum tipo de URLs para impedir o SSRF.
• Habilizar saídas antes de exibir para os usuários.

Negação de proteção de serviço

• Certifique -se de que os ataques do DOS nas suas APIs não prejudicam seu site. No mínimo, tenha limitadores de taxa em seus caminhos de API mais lentos, como rotinas de login e geração de token. Considere o Captcha nas APIs do front-end para proteger os serviços de back-end contra o DOS.
• Aplicar os limites da sanidade ao tamanho e estrutura dos dados e solicitações enviados pelo usuário.
• Use mitigação de negação de serviço distribuída (DDoS) por meio de um serviço global de proxy de cache como Cloudflare. Isso pode ser ativado se você sofrer um ataque de DDoS e funcionar como uma pesquisa DNS.

Operações

• Se você é pequeno e inexperiente, avalie usando o AWS Elasticbeanstalk ou um PaaS para executar seu código.
• Use um script de provisionamento decente para criar VMs na nuvem.
• Verifique se há máquinas com open ports publicamente.
• Verifique se há senhas de não/padrão para databases , especialmente MongoDB & Redis.
• Use SSH para acessar suas máquinas; Não configure uma senha, use a autenticação baseada em chave SSH.
• Instale as atualizações em tempo hábil para agir com vulnerabilidades de dia zero, como o Shellshock de coração.
• Modifique a configuração do servidor para usar o TLS 1.2 para https e desativar todos os outros esquemas. (A troca é boa.)
• Não deixe o modo de depuração ligado. Em algumas estruturas, o modo de depuração pode dar acesso a repl ou shells completos ou expor dados críticos em mensagens de erro Stacktraces.
• Esteja preparado para maus atores & ddos ​​- use um serviço de hospedagem com mitigação de DDoS.
• Configure o monitoramento para seus sistemas e log material (use nova relíquia ou algo parecido).
• Se desenvolver para os clientes corporativos, siga os requisitos de conformidade. Se o AWS S3, considere usar o recurso para criptografar dados. Se estiver usando o AWS EC2, considere usar o recurso para usar volumes criptografados (até mesmo os volumes de inicialização podem ser criptografados agora).

Configuração da nuvem

• Verifique se todos os serviços têm portas mínimas abertas. Embora a segurança através da obscuridade não seja proteção, o uso de portas fora do padrão tornará um pouco mais difícil para os atacantes.
• Banco de dados de back -end do host em VPCs privados que não são visíveis em nenhuma rede pública. Tenha muito cuidado ao configurar grupos de segurança da AWS e espiar VPCs que podem inadvertidamente tornar os serviços visíveis ao público.
• Isole os serviços lógicos em VPCs separados e VPCs de pares para fornecer comunicação entre serviços.
• Verifique se todos os serviços aceitam apenas dados de um conjunto mínimo de endereços IP.
• Restringir o tráfego de IP e porta de saída para minimizar os APTs e "Botificação".
• Sempre use papéis da AWS IAM e não credenciais raiz.
• Use privilégio mínimo de acesso para todas as OPS e equipe de desenvolvedores.
• Gire regularmente as senhas e as chaves de acesso de acordo com uma programação.

CI & CD Audite seu design e implementação com cobertura de testes de unidade/integração. Use um processo de revisão de código e desconsidere a auto-aprovação. Certifique -se de que todos os componentes de seus serviços sejam digitalizados estaticamente pelo software AV antes de pressionar para a produção, incluindo bibliotecas de fornecedores e outras dependências. Projete uma solução de reversão para implantações.

PESSOAS

• Configure um email (por exemplo, seguranç[email protected]) e uma página para que os pesquisadores de segurança relatem vulnerabilidades.
• Dependendo do que você está fazendo, limite o acesso aos bancos de dados do usuário.
• Seja educado para os repórteres de insetos.
• Faça com que sua revisão de código seja feita por um colega desenvolvedor de uma perspectiva de codificação segura. (Mais olhos)
• No caso de uma violação de hack ou dados, verifique os logs anteriores para obter acesso a dados, peça às pessoas que alterem as senhas. Você pode precisar de uma auditoria de agências externas, dependendo de onde você está incorporado.

Infraestrutura

• Certifique -se de fazer atualizações sem tempo de inatividade. Verifique se você pode atualizar rapidamente o software de maneira totalmente automatizada.
• Crie toda a infraestrutura usando uma ferramenta como o Terraform, e não através do console da nuvem. A infraestrutura deve ser definida como "código" e poder ser recriada com o pressionamento de um botão. Tenha tolerância zero para qualquer recurso criado na nuvem manualmente - a Terraform pode então auditar sua configuração.
• Use o registro centralizado para todos os serviços. Você nunca deve precisar do SSH para acessar ou recuperar logs.
• Não se espalhe a serviços, exceto o diagnóstico único. Usar SSH regularmente, normalmente significa que você não automatizou uma tarefa importante.
• Não mantenha a porta 22 aberta em nenhum grupo de serviços da AWS permanente. Em vez disso, considere permitir que apenas os IPs autorizados fossem ssh na caixa.
• Crie hosts imutáveis ​​em vez de servidores de longa duração que você corrigir e atualizar. (Ver infraestrutura imutável pode ser mais segura).
• Use um sistema de detecção de intrusão como senseDeep ou serviço para minimizar os APTs.