Clickjacking
Cos'è, dove si trova e prevenzione
OWASP
Il clickjacking è un attacco che inganna gli utenti nel cliccare un bottone "malvagio" che è stato fatto sembrare legittimo.
Utenti malintenzionati possono usare delle tecniche di sovrapposizione di pagine HTML per nascondere una pagina all'interno di un'altra.
Il clickjacking si basa su di una caratteristica HTML chiamata iframe.
Questi iframe permettono agli sviluppatori di includere una pagina all'interno di un'altra piazzando la tag <iframe> per poi specificare il percorso del sito nell'attributo src.
Creiamo un file usando il blocco note ed inseriamo il seguente codice:
<html>
<h3>Questa è la pagina web di Hayden.<h3>
<iframe src="https://it.wikipedia.org/wiki/Pagina_principale" width="500" height="500"></iframe>
<p>Se questa finestra non è bianca, la pagina contenuta nell'iframe può essere inclusa.</p>
</html>
Salviamo il nostro file come html e lo apriamo, ottenendo:
Alcune pagine web non possono essere incluse, come nel seguente caso:
Gli iframe sono utili per diverse cose: dall'includere pubblicità sulle pagine web, ad inserire video da YouTube.
Gli iframe hanno reso Internet un posto più interattivo, ma anche un po' più pericoloso.
Immaginiamo che esempio.com sia un sito di una banca che include una pagina web per trasferire dei soldi con un click e che si possa accedere alla pagina con l'URL www.esempio.com/trasferimento.
Questo URL accetta due parametri: l'ID dell'account destinatario e la somma da trasferire.
Se si visita l'URL con questi parametri presenti, come www.esempio.com/trasferimento?destinatario=hayden&somma=500, il form sulla pagina appare precompilato e basta cliccare il pulsante "Invia" per trasferire il denaro.
Immaginiamo che un utente malintenzionato includa nel suo sito (apparentemente innocuo) un iframe che come URL ha proprio
www.esempio.com/trasferimento?destinatario=hayden&somma=500
e renda l'iframe invisibile modificandone l'opacità, quindi lo posizioni sopra ad un form per l'iscrizione ad una newsletter, oppure al pop-up che chiede di salvare i cookie.
Ora, l'utente clicca pensando di accettare i cookie, o di iscriversi alla newsletter, ma essendo l'iframe sopra a questi, finisce per cliccare il bottone "Invia", accettando a sua insaputa il trasferimento della somma dal suo account.
Questo è solo un esempio semplificato per spiegare il concetto, nel mondo reale i metodi di pagamento non vengono inclusi in questo modo, perché violerebbero gli standard di sicurezza dei dati.
Prevenzione
Per poter avere un clickjacking due condizioni devono essere soddisfatte.
La prima è che la pagina vulnerabile abbia una funzione che vada a cambiare qualcosa nell'account dell'utente (impostazioni dell'account, e/o dati sensibili).
La seconda è che la pagina vulnerabile possa essere inclusa in un iframe.
L'header di risposta HTTP "X-Frame-Options" indica se il contenuto di una pagina può essere incluso in un iframe, in caso non sia presente, una pagina web può essere inclusa in un iframe di default.
Questo header ha due opzioni: DENY e SAMEORIGIN.
La prima opzione rende impossibile includere la pagina in un iframe, mentre la seconda opzione permette il framing solo di pagine con la stessa origine (pagine che condividono lo stesso protocollo, host e porta).
Per prevenire il clickjacking, il sito dovrebbe includere una di queste due opzioni in tutte le pagine che hanno una funzione che permette di cambiare qualcosa nell'account dell'utente.
L'header di risposta Content-Security-Policy è un altro metodo possibile di difesa.
La direttiva "frame-ancestors" di questo header permette di indicare se una pagina possa essere inclusa in un iframe.
Impostando la direttiva su "none" si impedisce a qualsiasi sito di creare un iframe con la pagina, mentre l'impostazione "self" permette al sito di includere la pagina in un iframe:
Content-Security-Policy: frame-ancestors 'none';
Content-Security-Policy: frame-ancestors 'self';
Impostando il frame-acenstors ad un origine specifica permette a quell'origine di crare un iframe con il contenuto. Questo header permette al sito corrente, così come ad ogni pagina nei subdomini esempio.com, di creare un iframe:
Content-Security-Policy: frame-ancestors 'self' *.esempio.com
Un altro modo di proteggersi dal clickjacking è con il cookie SameSite.
Una web app dice al browser di impostare i cookie tramite l'header Set-Cookie.
Per esempio, questo header farà impostare al browser il valore del cookie PHPSESSID come UFKSldflskK:
Set-Cookie: PHPSESSID=UFKSldflskK
Il Set-Cookie può essere usato anche per includere flag opzionali che si possono usare per proteggere i cookie degli utenti.
Uno di questi è il flag SameSite, che aiuta nel prevenire gli attacchi di clickjacking.
QUando il flag SameSite di un cookie è impostato su Strict o Lax, quel cookie non verrà incluso nelle richieste fatte da un iframe di terze parti.
Ciò significa che ogni attacco di clickjacking che richiede la vittima di essere autenticata, come l'esempio del sito della banca precedente, non funzionerebbe, anche se nessun header di risposta limita il framing, perché la vittima non è autenticata nella richiesta falsata.