Orientações para Correção

Encontrar vulnerabilidades é metade do trabalho. O valor duradouro de um teste de invasão está em ajudar a equipe a corrigi-las.

Uma boa orientação de correção transforma um relatório de uma reclamação em um roteiro.

Conselhos genéricos, como 'higienize a entrada', desperdiçam o tempo do leitor. Relacione a correção à tecnologia exata em uso.

• Fraco: valide a entrada do usuário.
• Forte: use consultas parametrizadas por meio da API de instruções preparadas.

Sempre que possível, inclua um breve exemplo do padrão corrigido. Os engenheiros agem mais rapidamente quando conseguem ver a estrutura esperada do código.

Mostre o código vulnerável e o corrigido lado a lado.

Recomende correções que resolvam a causa raiz, não apenas o sintoma encontrado.

Se um ponto de acesso tinha uma injeção de SQL, a correção real é aplicar consultas parametrizadas em todos os lugares, não corrigir apenas aquela linha.

Recomende controles em camadas para que uma única falha não leve ao comprometimento.

• Correção primária: consultas parametrizadas.
• Secundária: conta do banco de dados com o mínimo de privilégios.
• Detecção: alertas sobre consultas anômalas.

As camadas ganham tempo e reduzem o raio de impacto.

Às vezes, uma correção completa leva semanas. Ofereça tanto uma mitigação rápida quanto uma correção duradoura para que o cliente possa reduzir o risco hoje.

Deixe claro que a mitigação é temporária.

Ajude o cliente a se planejar estimando o esforço junto com a prioridade. Uma falha crítica que leva dez minutos para ser corrigida é uma escolha óbvia para começar.

Combine a gravidade com o esforço para sugerir uma ordem adequada.

Indique fontes confiáveis, como os guias práticos da OWASP, os guias de reforço de segurança dos fornecedores e as notas de mitigação do CWE.

Isso oferece aos engenheiros um recurso mais aprofundado e mostra que sua orientação está alinhada ao setor.

Diga ao cliente como verificar cada correção e ofereça um novo teste. Uma correção que não é verificada pode estar incompleta.

Reutilize suas etapas de reprodução como teste de verificação: se as etapas não funcionarem mais, a correção foi eficaz.

Apresente a orientação de forma colaborativa. A equipe de engenharia conhece a própria pilha tecnológica e as próprias restrições melhor do que você.

Ofereça opções quando for razoável e evite um tom acusatório. Seu objetivo é tornar os sistemas da equipe mais seguros, não vencer uma discussão.

Recomende que o cliente acompanhe cada achado até o encerramento em seu sistema de acompanhamento de problemas, vinculado ao ID do relatório.

Um achado não está concluído quando é lido; está concluído quando é corrigido, verificado e encerrado.

Você aprendeu a fornecer orientações eficazes de correção.

• Seja específico para a tecnologia; mostre o código corrigido.
• Corrija as causas raiz, não apenas os sintomas.
• Recomende defesa em profundidade e correções de curto e longo prazo.
• Estime o esforço para ajudar na priorização e consulte referências de OWASP e CWE.
• Ofereça verificação e novos testes; acompanhe os achados até o encerramento.

Você concluiu o curso de elaboração de relatórios de testes de invasão.