Come proteggere i widget da richieste forgiati

Question

Diciamo che avere un widget JavaScript che ha bisogno di sparare una richiesta per l'applicazione web se e solo se l'utente vuole clic su di esso. Se non si desidera la richiesta di essere vulnerabile a CSRF così si scrive un iframe alla pagina. Sulla base del norme origine eredità sito padre non sarà in grado di leggere il token CSRF. Tuttavia per quanto riguarda clickjacking (o likejacking )? A causa di CSRF è necessario essere all'interno di un iframe e là per le X-Frame-opzioni Non si può fare, e lo stesso vale per frame-busters .

L'attaccante sta per applicare un SVG maschera l'iframe dopo il widget è stato caricato. Questa maschera renderà l'iframe invisibile. A questo punto l'aggressore può o ridimensionare l'iframe per essere la dimensione della pagina o di avere questo iframe invisibile ora seguire il cursore. In entrambi i casi ogni volta che l'utente fa clic in qualsiasi punto della pagina, l'iframe riceve l'evento click e il suo game over.

Quindi c'è una dualità, a quanto pare si sono bloccati tra CSRF e clickjacking. Che la soluzione migliore (se presente) a questo problema?

Answer 1

Cliccando sul widget ha bisogno di aprire una finestra pop-up contenente una nuova pagina - un iframe non è abbastanza buono, deve essere una nuova finestra - che è interamente sotto il controllo della propria applicazione web. Confermare l'azione, qualunque essa sia, in quella pagina.

Sì, questo è un po 'poco elegante, ma l'attuale architettura di sicurezza Web non ti dà le opzioni migliori.

Answer 2

Non v'è alcun modo per impedire request forgery, mentre sotto un attacco di clickjacking. No difesa CSRF esiste che può resistere a un attacco di clickjacking, perché non c'è modo di distinguere un vero e proprio scatto da un falso clic sul lato client.

menzioni nella loro prevenzione CRSF foglio di lavoro che uno dei presupposti per la difesa CSRF token per lavoro è che nessun attacco XSS è in corso.

A mio parere questo dovrebbe anche includere clickjacking, come il CSRF il gettone anche nascosto all'interno iframe non può difendersi da clickjacking. La richiesta sta per essere forgiato da un utente clicca diretta.

Quindi, alla fine non siamo davvero bloccati tra CSRF e clickjacking -. Difese CSRF sono pensati per un diverso tipo di attacchi in cui c'è molta meno energia sul lato dell'attaccante

Quindi, verso le domande che menzione riguardante clickjacking e CSRF:

• Qual è la soluzione migliore (se presente) a questo problema -? La miglior difesa per clickjacking sul lato client è quello di aprire una nuova scheda del browser o di una finestra del browser ridimensionata con un pagina del tuo sito e confermare l'azione c'è, come cita @Zack. Questo è ciò che il pulsante di Twitter lo fa, e non ci può essere richiesta la contraffazione in questo scenario sia.

• per cui v'è una dualità, a quanto pare si sono bloccati tra CSRF e clickjacking - Le difese CSRF non sono stati pensati per casi come XSS o attacchi clickjacking, sono efficaci solo contro meno potente attacchi (e-mail con link maligno, dopo collegamento dannoso presente in forum, ecc.)

Answer 3

Non v'è alcuna buona programmabile soluzione on clickjacking . Alcune compagnie di citare in giudizio gli spammer come una difesa a clickjacking. Altri scelgono di mostrare finestre pop-up, una volta utente fa clic all'interno iframe, anche se si degrada l'esperienza degli utenti, soprattutto in caso di click-tasto singolo. Questo è esattamente ciò che Twitter per fare il pulsante “Retweet”. Facebook attualmente impiega questo approccio per il pulsante “Mi piace”, per chiedere conferma ogni volta che le richieste provengono da domini nella lista nera. Ho sentito dire che Googlebot eseguire alcune euristiche clickjacking mentre le pagine di indicizzazione con il suo pulsante “+1” (controllo stili calcolati, elementi sovrapposti e così via) ...

Answer 4

- UPDATE - Quando si dice "Widget", se vuoi dire qualcosa al di fuori della vostra applicazione che non autenticato le persone interagiscono con l'allora ignorare questa risposta. Ho riletto la tua domanda e non avete mai realmente stato quello che si intende per "Widget". Abbiamo tutti i tipi di "widget" che sono con nella nostra applicazione. Ho pensato che è quello che stavi parlando, tutto all'interno di un'applicazione che solo gli utenti autenticati sono stati interagendo con. Se questo è il caso, allora questa risposta è ciò che OWASP raccomanda.

- Risposta originale - "Tu non vuoi la richiesta di essere vulnerabile a CSRF così si scrive un iframe alla pagina." No, non fare un iframe, in questo modo si può fare il normale raccomandazione OWASP per la protezione contro inquadratura Cross Site.

Per la protezione da CSRF hash qualche valore (s), includerlo nel modulo (o ajax dati POST), quindi controllare il valore hash sul back-end. Se corrisponde è dal tuo sito. I dati più specifici si può mettere in hash, meglio è.

Esempio: quando un utente accede è possibile creare una stringa lunga casuale e cravatta che, per la loro sessione. Questa stringa non deve mai essere visibile sul vostro sito o durante la visualizzazione del sorgente. Quindi diciamo che l'utente tira un po 'di record specifico che vogliono modificare. Si potrebbe quindi prendere che gli utenti lunga stringa casuale si è creato, aggiungere che i record chiave primaria ad essa, poi hash loro. Il risultato di tale hash è possibile includere nella vostra forma come nascosta. Poi sul back-end prima di fare qualsiasi cosa si controlla per la presenza di quel nascosto, se non esiste, interruzione. Se esiste, prendere quella stringa utenti di sessione casuale e il testo chiave primaria chiaro che presentate, hash loro, se corrisponde a sapere che è dal tuo sito.

Ed è facile aggiungere questo in tutto il mondo anche se il sito è già scritto (supponendo che il sito ha qualche singolo pezzo di codice inclusi in tutte le pagine, come un piè di pagina). Rendere il valore hash e metterlo da qualche parte in un div nascosto nel vostro piè di pagina. Quindi è possibile utilizzare jQuery per aggiungere in modo dinamico il valore di hash nascosto a tutte le forme sulla pagina. Ed è possibile utilizzare jQuery.ajaxPrefilter per aggiungerlo a tutti i posti ajax automaticamente nel caso in cui si sta facendo un post Ajax e non un normale messaggio modulo. Abbiamo protegge alcuni siti molto grandi che sono stati già codificati in questo modo.

https://www.owasp.org/index.php/ Cross-Site_Request_Forgery_ (CSRF) _Prevention_Cheat_Sheet

Se questo suona come quel percorso si vuole prendere potrei mostrare una parte del codice jQuery per farlo. Per quanto riguarda ciò che il vostro sono hashing, come si desidera controllare sul backend, ecc ... che tutto dipende se si utilizza ColdFusion, PHP, PL / SQL (PSP) ecc ... Posso indicarvi la direzione giusta se uno di quelli.

Answer 5

Credo di capire quello che stai facendo. Si desidera consentire ad alcun sito di iframe tuo widget, quindi un attaccante ha il controllo completo del codice sorgente del genitore e può creare clickjacking routine per forzare gli utenti a fare clic sul widget di.

Quindi, l'iframe sarebbe in grado di utilizzare un token CSRF, come dovrebbe, che proteggerà da questo tipo di attacco a condizione che il frame principale non è in grado di leggere il token.

clickjacking, come sono sicuro che si sa, è un tipo completamente diverso di attacco di CSRF e ha bisogno di una difesa diversa.

In realtà, se il widget è super importante di implementare l'autenticazione a 2 fasi. Utilizzare http://twilio.com per chiamare l'utente e averlo ingresso un perno. O inviare una e-mail per l'utente con un link di verifica. O chiedere all'utente di verificare l'azione volta successiva che l'utente accede nel sito web del widget.

Se si ha il controllo del frame principale, allora si dovrebbe avere più opzioni. Sarebbe allora una questione di protezione XSS.

Aggiornamento dopo aver selezionato la risposta corretta

Quindi il mio approccio alla protezione contro il clickjacking è un po 'in mare. Sembra che possono essere protetti utilizzando una finestra pop-up con un'azione di conferma.

Answer 6

A causa di CSRF è necessario essere all'interno di un iframe ...

No. Non si può correggere CSRF con i biscotti di forma e altri trucchi nonce. Non importa dove li metti.

Quindi non v'è una dualità, a quanto pare si sono bloccati tra CSRF e clickjacking. Che la soluzione migliore (se presente) a questo problema?

Per rimediare CSRF, è necessario rimuovere la minaccia fissando il server che ha l'iniezione o codice dannoso, fermando l'e-mail di phishing, ecc In assenza di un ambiente favorevole, è necessario ri-autenticare l'utente (o fornire un'altra sfida / risposta per garantire un utente interattivo). Vedi:

• Cross-Site Request Forgery (CSRF) Prevenzione Cheat Sheet

Te remdiate clickjacking, utilizzare X-Frame-Options o cornice codice di rottura in Javascript. Ma non credo che neanche sono infallibili. Vedi:

• clickjacking Difesa Cheat Sheet