Executando verificação de segurança...
1

Gostei da iniciativa RavenaStar. Gosto desse tipo de conteúdo.

Só a título de exemplo, em uma PoC (Prova de Conceito) que realizei há alguns anos, utilizei como subterfúgio para "enganar" uma possível vítima, o emprego de um subdomíno bastante longo a fim de se passar pelo site original "escondendo" o real domínio na barra de endereços. Algo como:

https://www.google.com-search-q-long-subdomain-in-url.chrome.69i57j69i61j69i60j69i61-utf-8-source-tsa-Xved.2ahUKEwiHrbDSk8v8AhVhqZUCHXqTA3kQpwV6BAgBEBg-biw-1920.bih-929dpr1qdr.msxsrf-AJOqlzU8VcOtI0yD0QgDesN8NwEHnjq5pA1673839927635.example.com

E ainda utilizei um certificado SSL válido. Muitas vezes o olhar do usuário se acostuma a buscar ao que seria o TLD e não avalia o restante a URL. Nesse exemplo, é provável que o olhar se limitasse a www.google.com.

Eu outra situação explorei uma falha de Open Redirect em um site confiável, no qual o usuário era levado inicialmente para o site real, contudo, após a autenticação e, devido a falha de Open Redirect, eu levava o usuário para uma página falsa exatamente igual exibindo uma mensagem de "senha incorreta".

Nesse momento, muitos pessoas não verificam novamente a URL e inserem cuidadosamente a senha para não "errar novamente". Dessa forma eu poderia capturar a senha e então redirecionar o usuário de volta para o site real, onde ele já havia se autenticado da 1ª vez sem perceber e tudo parece ter fucionado como devia desta vez.

1

Sempre é bom verificar a URL mais de uma vez em horários diferentes por causa do 0-day, fazer diversos scan/análise em várias plataformas de análise, quando o domínio tem algum redirect na raiz/matriz do site que é usado muitas vezes pra enganar a detecção de ferramentas de análise o macete é usar site_aqui/informação_adicinal_aqui, exemplo => google.com/RavenaStar daí em algumas ferramentas em vez de mostrar informação do domínio que foi redirecionado vai mostrar a informação do domínio que é responsável pelo redirect.