Clickjacking è una vera vulnerabilità alla sicurezza?

31

A quanto ho capito, questo è il modo in cui un utente malintenzionato potrebbe sfruttare il clickjacking:

  1. Crea un nuovo sito web malicioussite.com che include il mio sito in una cornice, ma sovrappone campi o pulsanti di input dannosi sugli elementi HTML del mio sito.
  2. Invia email di phishing per fare in modo che gli utenti facciano clic sul link che si trova su malicioussite.com anziché sul mio sito (o usi qualche altra tecnica per distribuire il link di phishing).
  3. Gli utenti inseriscono i dati in o fanno clic sugli elementi dannosi.
  4. Utile

Gli utenti esperti non farebbero clic sul collegamento o noteranno che la barra degli indirizzi non è corretta. Tuttavia, molta gente probabilmente non se ne accorgerebbe.

La mia domanda è questa: l'attaccante non può ottenere la stessa cosa usando malicioussite.com come proxy inverso? Tutti i passaggi precedenti sarebbero gli stessi, tranne che malicioussite.com inoltrerebbe le richieste al mio sito e quindi inserirà un tag <script> aggiuntivo nella risposta HTML per eseguire il codice dannoso e aggiungere gli elementi HTML dannosi. L'intestazione X-FRAME-OPTIONS non sarebbe di aiuto in questo caso perché non ci sono frame (e il proxy inverso può eliminarli comunque).

L'attacco si basa sull'utente che non controlla la barra degli indirizzi, quindi se l'attaccante può implementare lo stesso attacco in un modo diverso che non può essere sconfitto, perché preoccuparsi di X-FRAME-OPTIONS o altre protezioni di clickjacking?

    
posta Nathan 23.03.2015 - 05:32
fonte

1 risposta

49

Questa è una domanda molto interessante.

Innanzitutto, iniziamo con il tuo scenario: un utente che visita il sito web www.evil.com che è un proxy inverso che carica www.good.com e modifica il suo contenuto. Congratulazioni ! Hai appena re-inventato un classico attacco MiTM , ma molto povero. Visitare evil.com significa che il tuo browser non invierà good.com cookies, il che significa che il tuo proxy inverso non sarà in grado di agire per conto dell'utente. Per risolvere il problema, ora dovrai ingannare l'utente per accedere al tuo proxy inverso con il suo good.com . Congratulazioni ! Hai re-inventato un attacco con una pagina di destinazione falsa.

Lo scenario che stai descrivendo non ha nulla a che fare con il clickjacking, e in realtà impieghiamo la protezione da clickjacking per una ragione molto diversa: con clickjacking, un utente malintenzionato indurrebbe un utente autenticato ad eseguire alcune azioni. Anche se l'utente sta visitando evil.com , a differenza dello scenario proposto con un proxy inverso, la sua richiesta viene comunque inviata a good.com insieme ai cookie contenenti il suo ID di sessione. Pertanto, l'azione verrà eseguita all'interno della sessione dell'utente autenticato.

Suona familiare? Sì, perché è così che funziona un attacco CSRF , ma l'unica differenza è che, con CSRF, l'azione viene eseguito programmaticamente .. tranne che per una piccola cosa: il Clickjacking sconfigge i meccanismi anti-CSRF. Con il clickjacking, l'azione viene eseguita all'interno del browser dell'utente, dall'utente stesso e all'interno della pagina legittima (caricata all'interno di iFrame).

Quindi, in breve: il tuo attacco proposto è davvero plausibile, ma usiamo il anti-clickjacking per sconfiggere attacchi completamente diversi. Per questo, sì, il clickjacking è davvero un problema di sicurezza reale e distinto.

    
risposta data 23.03.2015 - 06:06
fonte

Leggi altre domande sui tag