Ao longo do curso, aprendemos uma série de métodos para descobrir bugs e
vulnerabilidades em diferentes tipos de software e infraestrutura, geralmente no final do teste você precisará informar ao cliente com todas as
vulnerabilidades que você encontrou ou com todos os descobertas.
Isso é feito usando um relatório de teste.
Basicamente, o que queremos dizer com relatório de teste é apenas um documento que inclui tudo o que
você encontrou por meio de seu contrato, para que o cliente ou administrador possa prosseguir e corrigir todas as vulnerabilidades e
fraquezas que você encontrou.
Esses relatórios também são lidos por executivos muitas vezes.
Portanto, você precisa levar isso em consideração.
Portanto, um bom relatório deve ser bastante fácil.
Mas também é fácil de entender agora, se você estiver trabalhando como um testador, a empresa para a qual
você está trabalhando provavelmente terá seu próprio modelo e seus próprios padrões que você deve seguir ao escrever um
relatório.
E, em muitos casos, você nem mesmo fará isso.
Você simplesmente encaminhará suas descobertas para outro membro de sua própria equipe e eles preencherão os espaços
em branco corretamente no relatório.
Portanto, você provavelmente não precisará escrever um do zero.
E, em muitos casos, você nem mesmo escreve o relatório real que o cliente vê.
Dito isso, ainda quero mostrar como isso é feito, só para dar uma ideia de como
é um relatório de teste.
Agora, em primeiro lugar, antes de mostrar o exemplo que tenho, vou incluir
este repositório, que basicamente contém um grande número de relatórios Pantazis.
Portanto, você pode realmente olhar para eles em busca de inspiração e apenas para ver os diferentes estilos que
diferentes empresas seguem ao fazer um relatório de teste.
Então você pode clicar em qualquer um deles e você encontrará o relatório e você pode realmente percorrê-lo
para aprender como esta empresa específica, você escreve seus relatórios e talvez encontre algo que você goste e que
comece a incluir em seu próprio relatório .
Portanto, vou incluir isso nos recursos da palestra para que você possa voltar a ela para se inspirar.
Mas o que realmente quero fazer é orientar você em uma amostra de relatórios que usamos aqui na segurança.
Apenas para lhe dar uma ideia das principais seções que a maioria dos relatórios possui.
Eu também vou incluir isso nos recursos.
Portanto, sinta-se à vontade para modificá-lo e usá-lo ou retirar alguns elementos dele se desejar.
Portanto, você observará no repositório aqui, cada empresa tem seu próprio estilo de escrever relatórios, mas
em geral sempre há algumas seções principais que você encontrará em cada relatório.
Então, começando com a primeira página bem aqui, temos a página de rosto.
Então, novamente, você pode vender isso como quiser.
Normalmente, você tem o logotipo da empresa, o título e, em seguida, a data do relatório e
a versão.
Isto é muito importante.
E então temos a empresa, as informações da nossa empresa.
Portanto, este relatório foi escrito por nós.
Estas são as informações da nossa empresa.
E então você tem no campo de força, você tem a empresa para a qual você está escrevendo este relatório.
Então você teria o nome da empresa, você teria um ID específico para esta empresa.
Essa é a ideia de que você identificou essa empresa em seus próprios registros.
Novamente, isso provavelmente não é algo que você mesmo fará.
Você receberá essa ideia de sua própria empresa.
E então temos as informações de contato de ambas as empresas.
Você pode ver nesta empresa que temos um e o Testador dois com seus endereços de e-mail.
Esta poderia ser obviamente uma lista maior com toda a equipe que está fazendo o teste e semelhante à empresa para
a qual você está fazendo o teste.
Novamente, você tem seus nomes, sua posição na empresa e suas informações de contato.
Agora, novamente, lembre-se de que você nem sempre precisa estilizar a primeira página dessa forma, mas mais ou menos
geralmente na primeira página, você terá o título, a data, a versão e as informações de contato.
É assim que nós fazemos.
Mas, novamente, você pode fazer da maneira que quiser e pode se inspirar no recurso que vou
incluir aqui.
Em seguida, normalmente temos o índice novamente, como você pode ver, coisas simples normalmente teriam
em qualquer tipo de documento.
Isso o ajudará a navegar por todo o documento.
E como eu disse aqui, podemos ver as principais seções de qualquer relatório de protesto.
Portanto, é muito importante ter um sumário executivo.
Este é um resumo de todo o engajamento projetado para pessoas menos técnicas.
Portanto, deve dar a eles uma ideia de suas descobertas, sem se aprofundar muito nos detalhes técnicos.
Em seguida, temos um resumo de engajamento onde detalhamos o escopo.
Isso é o que você testou, quais partes do sistema deles você testou, as classificações de risco que
você usou e uma visão geral de tudo que você encontrou.
Então, novamente, até agora, não estamos mergulhando fundo ou simplesmente este é apenas um resumo de todo o envolvimento.
Você terá uma ideia melhor de tudo isso à medida que eu ler o relatório.
E então, na seção de detalhes técnicos, é aqui que você mergulha muito fundo em tudo o que
encontrou.
Portanto, basicamente temos uma seção para cada descoberta.
Como você pode ver, esta é apenas uma amostra.
Portanto, fiz apenas três descobertas.
Temos injeção inicial, uma falsificação de solicitação entre sites.
sim.
SRF e uma divulgação de informações.
Como você pode ver na primeira seção, basicamente tínhamos apenas um resumo
de tudo o que encontramos, enquanto nos detalhes técnicos estávamos basicamente dividindo cada descoberta.
E vamos falar sobre como o encontramos em detalhes, como replicá-lo.
Você vai incluir capturas de tela, se puder, para que a equipe técnica possa entender exatamente
a gravidade dessa vulnerabilidade e como corrigi-la.
Você notará que outras empresas incluirão um apêndice no final, elas incluirão recomendações
onde dirão exatamente como corrigir vulnerabilidades.
Como eu disse, depende muito da empresa.
Cada empresa tem seu próprio estilo e cada empresa tem seu próprio formato.
Então, o que estou mostrando aqui é apenas uma amostra de como fazemos isso.
Você pode se inspirar nos recursos e, em muitos casos, terá apenas que seguir o modelo que sua empresa
possui, porque eles não querem que você faça do seu próprio jeito.
Então, vamos para a próxima página e você verá nesta página que temos as informações legais.
E é por isso que eu realmente disse que você provavelmente não faria isso sozinho.
Você nunca precisará fazer isso sozinho porque terá partes do relatório como esta.
Você nunca terá que modificar e eles realmente serão escritos pela equipe jurídica da sua empresa.
Portanto, eles responderão por qualquer coisa que possa sair do controle para garantir que você não seja processado.
Se algo der errado, ele conterá coisas como isenções de responsabilidade, PIB, nossa privacidade, coisas legais e todas essas
coisas que realmente não conhecemos muito bem.
Eu testadores e pessoas jurídicas geralmente escrevem, e então temos o changelog do documento.
Portanto, toda vez que uma alteração é feita no documento, você pode ver que temos a data, temos a versão
e temos um comentário.
Por que fizemos essa mudança ou o que há de tão significativo nessa mudança?
Então esse foi o relatório inicial quando o fizemos no dia 1º de janeiro e depois no dia 10 de janeiro,
fizemos uma segunda versão onde concluímos a segunda etapa.
Novamente, são apenas amostras.
Mas só para ter uma ideia de que manter um changelog de todas as mudanças pelas quais este
documento passa é muito, muito importante.
Nem todas as empresas fazem isso.
Mas, novamente, é apenas nossa escolha adicioná-lo em nosso relatório.
Sempre digo isso para dar a você uma ideia de que não há regras definidas para fazer esse tipo de documento.
Você pode adicionar ou remover o que quiser, mas as partes principais seriam a parte jurídica, o sumário executivo
e depois a parte técnica.
Estas serão as partes principais do relatório.
Portanto, agora temos o resumo executivo e você pode lê-lo.
Isso não deveria demorar muito.
Então, na minha opinião, precisa ter no máximo uma página de duas páginas se você realmente precisar.
E basicamente diz que fomos instruídos a testar um sistema.
Explicará como este documento está organizado, onde a primeira seção é menos detalhada, apenas para dar
uma ideia do risco.
E o segundo é detalhado para que o pessoal técnico entenda esses riscos e os conserte e então receba
a classificação de risco.
Portanto, estamos assumindo que há um alto risco com base nas vulnerabilidades que encontramos.
Ele irá detalhar a metodologia que seguimos.
E então temos alguns gráficos aqui.
Lembre-se, esta parte está sendo lida pelos executivos.
São pessoas que na maioria das vezes não são muito técnicas e também não têm muito tempo.
Então, estamos incluindo gráficos aqui para mostrar a eles a quantidade de vulnerabilidades que encontramos.
Portanto, podemos ver que temos cinco vulnerabilidades altas.
Temos 10 que são médios e oito que são baixos.
Portanto, isso lhes dará uma boa compreensão das ameaças que enfrentam.
E então vamos voltar ao resumo.
Isso ainda será lido por pessoas menos técnicas.
Então, em primeiro lugar, estamos detalhando o escopo para ter certeza de que contaremos a eles o que testamos, mesmo
que eles já nos tenham dito o que testar, apenas para que, no caso no futuro, se algo fosse descoberto
fora do nosso escopo e eles voltam para nós, podemos dizer, bem, isso estava fora do escopo.
Não testamos no próximo ano, incluindo a classificação de risco.
Portanto, você terá isso em todos os documentos.
Você quer que eu modifique isso.
Basicamente, estamos apenas dizendo como classificaríamos uma determinada vulnerabilidade como baixa, média, alta ou
crítica.
E estamos dizendo, em nossa opinião, como você deve lidar com as vulnerabilidades baixas, médias, altas e críticas que você pode ver
para as vulnerabilidades críticas que estamos dizendo que você precisa consertar imediatamente, enquanto que pela lei você
precisa consertar no próximo ciclo de atualização.
Novamente, esta é apenas nossa opinião.
A seguir, temos as conclusões da revisão.
Portanto, ainda estamos na seção um.
Isso ainda é para os executivos.
Não precisamos mergulhar muito fundo.
Então, acabamos de ter a ideia da vulnerabilidade.
E você pode ver a primeira vulnerabilidade, é crítica.
É uma injeção Ezequial.
E em muitos casos, em muitos relatórios, eles realmente param, dizendo que é apenas uma injeção de ESKIL.
Gostamos de realmente mostrar o impacto nesta seção porque, como eu disse, esses caras não são técnicos.
Portanto, se for uma injeção, eles podem não saber o que é uma injeção de ESKIL.
Eles se preocupam com o impacto dessa vulnerabilidade.
Novamente, eles não têm muito tempo, então você precisa ir direto ao ponto.
Então, o que estamos fazendo é dizer que é uma injeção natural que pode levar ao acesso autorizado ao banco
de dados.
Então, agora eles sabem com esta vulnerabilidade, um hacker pode acessar seu banco de dados.
Isso provavelmente é muito ruim.
Outra vulnerabilidade que encontramos é média e excessiva.
SRF de novo, muitos relatórios vão parar por aqui, realmente não explica nada para pessoas não técnicas.
Portanto, estamos dizendo que os clientes podem ser forçados a enviar certas solicitações não críticas.
É por isso que é uma solicitação de mídia, não não crítica.
Mas eles podem ser forçados a enviar coisas.
E então temos uma vulnerabilidade em que a versão da HP é divulgada.
Portanto, isso não é realmente muito crítico porque não é uma vulnerabilidade real que pode ser explorada
para obter acesso ou expor dados do usuário.
Mas essas informações podem ser úteis para que os hackers conheçam outros ataques ou descubram vulnerabilidades
para esta versão específica.
E é por isso que é baixo.
É por isso que não precisa ser atendido com muita urgência, como os críticos, como mencionamos
acima e aqui.
E fique à vontade para ler o texto aqui, você verá que muito dele é basicamente apenas para limpar nossas costas
e ter certeza de que eles entenderam tudo o que está no relatório.
E isso seria o fim do verão.
E agora estamos nos detalhes técnicos.
Portanto, nesta seção, basicamente temos, como eu disse, uma subseção para cada descoberta que
temos.
E estamos mergulhando realmente nos detalhes dessa descoberta.
Portanto, você pode ver que esta é a injeção real que mencionamos anteriormente no resumo.
Mas desta vez, estamos fornecendo a eles a URL vulnerável.
Estamos dando a eles o parâmetro vulnerável.
Estamos dando a eles referências para entender o que é injeção de Eskil.
Caso eles não entendam, estamos dando a eles a solicitação exata e a resposta exata que recebemos,
o que nos fez determinar que esta página em particular é vulnerável a uma injeção.
Então, estamos dando a eles o impacto aqui em detalhes, não apenas dizendo que eles podem acessar o banco de dados.
Portanto, estamos dizendo que eles podem acessar o banco de dados.
Eles podem recuperar dados que temos acesso à tabela do usuário.
Então, você vai mergulhar nos detalhes e deve até incluir capturas de tela aqui.
Se você acha que eles serão úteis na seção de mitigação.
Estamos apenas dando a eles uma recomendação rápida.
Como eu disse, algumas empresas fornecem recomendações detalhadas.
Isso realmente depende do engajamento também.
Portanto, neste exemplo, estamos basicamente dizendo usar instruções prepare com consultas parametrizadas e estamos dando a eles
uma referência para aprender como fazer isso ou entender como funciona.
E é basicamente isso.
Então, você vai repetir isso para cada vulnerabilidade que encontrar?
Estou deixando o resto vazio, pois esta é apenas uma amostra, mas você entendeu.
Portanto, você terá uma subseção para cada descoberta em que explicou tudo em detalhes para que eles
entendam a vulnerabilidade e possam ir em frente e corrigi-la.
No final, muitas empresas teriam um apêndice e poderiam ter uma seção de recomendações maior, como eu
disse, esse é o nosso estilo de escrever relatórios que cada empresa tem seu próprio estilo, se quiser.
Isso pode levar algum tempo examinando os relatórios de amostra que temos neste repositório.
Obviamente, incluirei os dois links para meu exemplo e para os outros exemplos e os recursos, para que
você mesmo possa examiná-los e ter uma ideia de como são os relatórios Pennhurst.
Mas, como eu disse, em muitos casos, você simplesmente preencherá uma amostra semelhante à que temos aqui.
Portanto, você nunca será solicitado a criar um do zero.