Alla fine di questo tutorial l'autore fornisce alcune idee per migliorare un attacco di phishing di base.
Uno di questi mi ha incuriosito, in particolare: è possibile utilizzare le credenziali che una vittima entra nella tua pagina di phishing e utilizzare, ad esempio l'API di Facebook o Twitter (o qualsiasi altra) e inviare quelle credenziali al servizio effettivo, creando così una sessione autentica in modo che la vittima non si sia mai accorta di essere stata vittima di phishing?
Sì, è possibile che un sito di phishing funga da proxy tra l'utente e il sito Web previsto e quindi registra / inserisce dati. Tuttavia, richiederebbe qualcosa di più sofisticato rispetto a SSLstrip che si trova sul sito di phishing.
L'URL nel browser fa riferimento al sito di phishing durante la sessione.
Penso che tutto dipenda dal modo in cui le credenziali sono effettivamente gestite da queste API. Io davvero non so come Facebook o Twitter gestiscono queste informazioni. Se l'autenticazione è fatta solo da username e password, quindi .. Penso che sia possibile.
Ma se vengono utilizzati il nome utente e la password, in aggiunta a una terza credenziale disponibile solo nel computer della vittima e non catturata dalla pagina di phishing, potrebbe non funzionare.
Se la tua domanda è principalmente correlata all'affermazione della vittima senza mai rendersi conto che è stata phishing, penso che sarebbe molto difficile, se non impossibile.
Per quanto ne so, è per questo che usiamo i token csrf ( Cross-site request forgery ).
In teoria, qualsiasi cosa può inviare dati POST a un URL che accetta i dati POST ...
Dire dodgysite.com/login gestisce una richiesta POST per registrare gli utenti. Tutto questo sito accetta è username / password. Qualsiasi script dovrebbe essere in grado di inviare una richiesta, incluso il tuo sito di phishing.
Sebbene securesite.com/login possa inoltre gestire un token csrf univoco, che non accetta la richiesta se il token non corrisponde. Poiché questo token viene generato casualmente ogni volta che viene caricato il modulo di login, sarebbe impossibile per un attore malintenzionato inviare dati POST validi da altrove.
Oltre a controllare ogni richiesta di un token csrf valido, securesite.com/login dovrebbe anche controllare che la richiesta provenga dalla stessa origine (cioè il modulo di accesso legittimo sul sito Web).
Se questi due requisiti non sono soddisfatti, allora sì, sarete in grado di interagire con il modulo di accesso da un'applicazione dannosa.
Leggi altre domande sui tag phishing social-engineering