In che modo inserire un link a un sito in un iframe (e quando viene aperto in iframe) indica che il sito è vulnerabile a un attacco di click jacking? Ho anche letto che se il sito è una base di forum, la vulnerabilità potrebbe essere critica. Perché? si prega di fornire alcuni esempi, se possibile.
Immagina che Facebook possa essere inserita in un iframe. Potrei creare una pagina web con un pulsante che dice "vinci la bicicletta gratis!", E sopra quel luogo un iframe trasparente con la mia pagina facebook, in modo che il pulsante mi piace esattamente sopra / copre la "bicicletta gratis!" pulsante. Se qualcuno fa clic su quel pulsante, non vincerà una bicicletta, ma preferirà la mia pagina di Facebook senza accorgersene.
Sì, hai ragione a chiedertelo.
Un sito vulnerabile al clickjacking e la vulnerabilità che in realtà è sfruttabile sono due cose diverse.
Bhuvanesh discute un piccolo sottoinsieme di attacchi clickjacking in la loro risposta . Questo tipo di clickjacking è menzionato nell'articolo OWASP :
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.
Questo tipo di clickjacking potrebbe essere applicato ai siti che utilizzano 3-D Secure o Verified By Visa per chiedere la tua password bancaria segreta all'interno di un IFrame. Il sito esterno potrebbe posizionare con cura le proprie caselle di testo per acquisire la password. Tuttavia, questo non è ciò che normalmente si intende per attacco o vulnerabilità di clickjacking.
La risposta di Bhuvanesh è corretta in quanto la stessa politica di origine impedirebbe la generazione di un IFrame nel proprio sito da un'altra origine. Tuttavia, non impedirebbe a un altro sito di inquadrare il tuo sito nella sua pagina web. È questo il caso in cui la maggior parte dei siti è vulnerabile al clickjacking. Questo è essenzialmente ciò che un attacco clickjacking è. L'utente malintenzionato carica la pagina sul tuo dominio in un IFrame, ma usa i CSS per rendere la tua pagina invisibile. L'attaccante posiziona i propri pulsanti sotto la tua pagina. Quando questi vengono cliccati dalla vittima, il browser invia effettivamente i clic al tuo sito.
Un esempio: il tuo sito è example.com :
confirmDeleteAccount.php con un pulsante nel mezzo. <iframe src="http://example.com/confirmDeleteAccount.php"></iframe>IconfirmIwanttodeletemyExample.comaccountsullapaginacaricatanell'IFrame.Poichél'IFrameèinvisibile,ilpulsantedell'aggressoreappareallavittimacomel'unicovisibile.Clickheretoclaimyourfreeholiday.L'impostazioneX-Frame-Options in modo appropriato impedirà il frame del tuo sito (nota che questo è stato sostituito dal frame-ancestors di CSP. , tuttavia entrambi sono consigliabili per ora poiché non tutti i browser supportano ancora frame-ancestors ).
X-Frame-Options / frame-ancestors ? L'esempio sopra mostra una vulnerabilità di clickjacking sfruttabile. Il clickjacking è solo un problema sul tuo sito se ci sono dei pulsanti singoli che hanno delle conseguenze. Quindi ci sono due requisiti per sfruttare una vulnerabilità di clickjacking:
X-Frame-Options / frame-ancestors ). Pertanto, se si dispone di una pagina che richiede l'input dell'utente e non è possibile che l'autore dell'attacco fornisca quell'input dell'utente, allora quella pagina non sarebbe sfruttabile. Se, tuttavia, il modulo sulla pagina è completato dai valori della stringa di query o dai dati POST, l'autore dell'attacco avrà un metodo con cui fornire i dati per l'attacco.
Può essere complicato capire se il tuo sito è sfruttabile o meno, senza tenere conto di tutte le pagine del tuo sito e di quali dati vengono forniti e da dove. Pertanto, molte valutazioni di sicurezza e test di penetrazione tendono a segnalare che il tuo sito è vulnerabile se mancano queste intestazioni. Il mio consiglio è solitamente che, a meno che il tuo sito non debba essere incorniciato come parte delle sue funzionalità, quindi aggiungi sempre le intestazioni. È anche utile impostare queste intestazioni per attenuare altre vulnerabilità come importazione del foglio di stile relativa al percorso (PRSSI) , Cross History Manipulation (XSHM) o framesniffing .
Maggiori informazioni: Clickjacking: Help, I Was Framed! (Blog SANS AppSec) .
Immagina di avere un semplice modulo di accesso e un pulsante di invio. Il pulsante di invio invia le credenziali al server.
L'utente malintenzionato può caricare questa pagina di accesso all'interno di un iFrame e, dopo aver creato un modulo di accesso simile alla pagina originale, posiziona il nuovo su quello originale sulla pagina. Dopo aver ottenuto i dati, li inviano manualmente e tentano di hackerare l'account.
La Stanford Web Security Research ha trovato modi intelligenti per contrastare questo:
E puoi trovare altri esempi qui:
In realtà Click jacking non sta solo caricando un iframe nel tuo sito Web. È solo un test per dimostrare che il tuo sito è vulnerabile a Click Jacking.
Al giorno d'oggi i browser moderni non permetteranno questo test, perché i browser come Chrome, IE, Firefox seguono Stessi criteri di origine che non consentono il caricamento di un iframe nel tuo sito web.
Puoi provare dal tuo localhost per questa vulnerabilità. Ma devi sfruttare qualche cosa caricando un iframe nel tuo sito web, ad esempio devi cambiare la password di un utente senza la conoscenza dell'utente, chiedendo loro di fare clic su Offerta per te. Puoi fare riferimento a questo link per sapere come funziona il click jacking Click Jacking
Puoi anche indirizzare i primi dieci progetti OWASP per questa vulnerabilità. OWASP Click jacking
Leggi altre domande sui tag clickjacking