Existem práticas recomendadas para testar a segurança em uma loja de desenvolvimento Agile?[fechado]

Question

Em relação ao desenvolvimento Agile, quais são as melhores práticas para testar a segurança por versão?

Se for um lançamento mensal, há lojas fazendo pen-tests todos os meses?

Answer 1

Qual é o domínio do seu aplicativo?Depende.

Como você usou a palavra "Ágil", acho que é um aplicativo da web.Eu tenho uma resposta fácil e agradável para você.

Compre uma cópia do Burp Suite (é o resultado nº 1 do Google para “arrotar” – um endosso garantido!);custará 99EU, ou ~$180USD, ou $98 dólares Obama se você esperar até novembro.

Burp funciona como um proxy web.Você navega pelo seu aplicativo da web usando Firefox ou IE ou qualquer outro, e ele coleta todos os acessos gerados.Esses hits são alimentados em um recurso chamado "Intruder", que é um web fuzzer.O Intruder descobrirá todos os parâmetros que você fornece para cada um de seus manipuladores de consulta.Em seguida, ele tentará valores malucos para cada parâmetro, incluindo SQL, sistema de arquivos e metacaracteres HTML.Em uma postagem típica de formulário complexo, isso gerará cerca de 1.500 ocorrências, que você analisará para identificar respostas de erro assustadoras --- ou, mais importante em um contexto Agile, novas ---.

Difundir cada manipulador de consulta em seu aplicativo da web a cada iteração de lançamento é a principal coisa que você pode fazer para melhorar a segurança do aplicativo sem instituir um "SDLC" formal e adicionar número de funcionários.Além disso, revise seu código para os principais pontos de acesso de segurança de aplicativos da web:

• Use apenas instruções SQL preparadas parametrizadas;nunca simplesmente concatene strings e alimente-as no identificador do seu banco de dados.

• Filtre todas as entradas para uma lista branca de caracteres bons conhecidos (alnum, pontuação básica) e, mais importante, produza dados de filtro dos resultados da sua consulta para "neutralizar" metacaracteres HTML em entidades HTML (quot, lt, gt, etc).

• Use identificadores aleatórios longos e difíceis de adivinhar em qualquer lugar em que você esteja usando IDs de linhas inteiras simples em parâmetros de consulta e certifique-se de que o usuário X não possa ver os dados do usuário Y apenas adivinhando esses identificadores.

• Teste todos os manipuladores de consulta em seu aplicativo para garantir que eles funcionem somente quando um cookie de sessão válido e conectado for apresentado.

• Ative a proteção XSRF em sua pilha da web, que gerará parâmetros de token de formulário ocultos em todos os seus formulários renderizados, para evitar que invasores criem links maliciosos que enviarão formulários para usuários desavisados.

• Use bcrypt --- e nada mais --- para armazenar senhas com hash.

Answer 2

Não sou especialista em desenvolvimento Agile, mas imagino que integrar algum software básico de pen-test automatizado em seu ciclo de construção seria um bom começo.Já vi vários pacotes de software que fazem testes básicos e são adequados para automação.

Answer 3

Não sou especialista em segurança, mas acho que o fato mais importante que você deve saber, antes de testar a segurança, é o que você está tentando proteger.Somente se você souber o que está tentando proteger, poderá fazer uma análise adequada de suas medidas de segurança e só então poderá começar a testar essas medidas implementadas.

Muito abstrato, eu sei.No entanto, acho que deveria ser o primeiro passo de toda auditoria de segurança.

Answer 4

Teste de unidade, Programação de Defesa e muitos registros

Teste de unidade

Certifique-se de testar a unidade o mais cedo possível (por exemplo,a senha deve ser criptografada antes do envio, o túnel SSL está funcionando, etc).Isso evitaria que seus programadores tornassem acidentalmente o programa inseguro.

Programação de Defesa

Eu pessoalmente chamo isso de Programação Paranóica, mas a Wikipedia nunca está errada (sarcasmo).Basicamente, você adiciona testes às suas funções que verificam todas as entradas:

• os cookies do usuário são válidos?
• ele ainda está logado?
• os parâmetros da função estão protegidos contra injeção de SQL?(mesmo sabendo que as entradas são geradas por suas próprias funções, você testará de qualquer maneira)

Exploração madeireira

Registre tudo como um louco.É mais fácil remover logs do que adicioná-los.Um usuário fez login?Registre-o.Um usuário encontrou um 404?Registre-o.O administrador editou/excluiu uma postagem?Registre-o.Alguém conseguiu acessar uma página restrita?Registre-o.

Não se surpreenda se o seu arquivo de log atingir mais de 15 Mb durante a fase de desenvolvimento.Durante a versão beta, você pode decidir quais registros serão removidos.Se desejar, você pode adicionar um sinalizador para decidir quando um determinado evento será registrado.