Script FrameBusting

Bella domanda. FrameBusting è difficile da implementare correttamente e in quasi tutti i casi è rotto a causa di incompatibilità di browser, bug o errori degli sviluppatori.

Recentemente ci siamo imbattuti in una domanda abbastanza simile qui: link . Dove viene detto per richiedere all'utente con una breve spiegazione di cosa sta succedendo. Non posso essere in disaccordo, la spiegazione più semplice - meglio per la comprensione dell'utente, fai solo attenzione a non perdere dettagli che tocchino la privacy degli utenti. Con i dettagli forniti, l'utente deve pensare da solo a cosa non fare paura.

E OWASP ha un buon documento di ricerca su questo argomento: link

La soluzione che preferirei a un utente sarebbe: consenti al tuo sito di essere incorniciato, ma assicurati che i siti dannosi non possano recare danno. Non continuare la sessione dell'utente da un'altra scheda se ci si trova in una cornice. Considera di rendere il sito di sola lettura in questo caso. Se si consente all'utente di accedere nuovamente al frame, visualizzare un avviso. Ovviamente questo è un sacco di lavoro da implementare per un caso d'uso raro, quindi potrebbe non essere pratico.

Se vuoi davvero smantellare i frame, ti suggerirei una soluzione non invasiva. Usa il normale codice framebusting, magari in combinazione con le Opzioni X-Frame Intestazione HTTP e fornire una nota evidenziata sulla pagina invece di un popup.

A sidenote: il modello di sicurezza HTML si basa sul fatto che un sito non può fare cose ad altri siti. Questo ci dà la politica della stessa origine. Molti hack si basano sul bypassare questo, iniettando il codice in altri siti, ecc. Il clickjacking è correlato, ma invece di usare il codice per eseguire una funzione nell'altro sito, la pagina di attacco induce l'utente a fare clic da qualche parte.

Personalmente, penso che il modello di sicurezza HTML, in cui i server si fidano del browser per mantenere gli script confinati, è concettualmente imperfetto. Preferirei un modello in cui il codice possa fare quasi tutto ciò che l'utente può fare, e invece si affiderebbero invece a token di sicurezza. Certo, uno script di attacco potrebbe inviare un modulo per eliminare un post, ma senza l'ID di sessione e la password corretti sarebbe ignorato. Ciò consentirebbe applicazioni molto più interessanti come mashup, aggregatori di contenuti client-only, ecc. Ovviamente è troppo tardi per passare il web a un tale modello di sicurezza ora.

Sto scrivendo questo per motivare il mio consiglio: anche senza fare affidamento sulla separazione imposta dal browser (ad esempio framebusting) è possibile scrivere siti sicuri in cui ogni azione è autorizzata dall'utente. Non fare affidamento sulla sicurezza sui no-frame, ma supponiamo che il tuo sito sia incorniciato, che il SOP sia compromesso e che il sito del frame possa premere pulsanti (con o senza strumentalizzare l'utente).