Esaminiamo ogni caso dal punto di vista di un malintenzionato attivo Malroy e di un passivo malvivente.

Caso 1: una pagina non sicura che carica un iframe sicuro per trasmettere dati riservati

Passivo: sei al sicuro dagli attacchi passivi mentre usi l'iframe sicuro. Tuttavia, nel caso di iframe di accesso, se il token di sessione viene inviato in chiaro, Eve può impersonare te. (Conosco ancora la rappresentazione come "passiva" qui, dal momento che Eva non sta alterando attivamente la tua connessione, ma sta solo facendo i suoi collegamenti con le nuove informazioni che ha appreso.)

Attivo: se la pagina HTML non è sicura, hai già perso completamente. Puoi fare in modo che tutte le risorse secondarie della pagina vengano trasmesse in modo sicuro, ma non importa: Malroy ha già riscritto la tua pagina per utilizzare risorse totalmente diverse.

Caso 2: una pagina sicura che carica una pagina non sicura tramite un iframe

Passivo: ovvio problema principale qui: tutto ciò che fai nell'iframe è in bella vista. Tuttavia, Eve non può vedere quello che fai nella pagina sicura di alto livello. Tuttavia, l'utente rimane confuso su quali elementi della pagina possono essere interagiti in modo sicuro e quali non possono.

Attivo: Malroy può far apparire qualsiasi cosa nell'iframe; Spero che tu non lo stia usando per qualcosa di importante. Non credo pensi che ci sia un modo per Malroy di uscire dall'iframe e leggere o alterare la tua pagina esterna sicura, perché i browser presuppongono già che gli iframe di origine incrociata non sono affidabili. Se ci fosse un modo per uscire dall'iframe, penso che sarebbe considerato un serio bug di sicurezza nel tuo browser (il che non vuol dire che non esistano, ma questo è un problema di implementazione, non un problema teorico con contenuto).

Caso 3: una pagina sicura che collega a JS non protetto

Passiva: Eve può sapere quale sito HTTPS stai visualizzando, in base alle risorse HTTP caricate. (È possibile che sia in grado di eseguire questa operazione tramite una connessione protetta, in base all'indirizzo IP di destinazione e alle dimensioni / modello delle risorse crittografate recuperate. Indipendentemente da ciò, HTTP le rende le cose solo più semplici.)

Attivo: Come hai intuito, Malroy può rendere la tua pagina HTTPS completamente riscritta alimentandola con uno script modificato.

Caso 4: una pagina sicura che collega a fonti non sicure come immagini, CSS

Passiva: come nel caso 3, sopra.

Attivo: CSS è piuttosto potente. Se Malroy potrebbe riscrivere una risorsa CSS, potrebbe fare una manipolazione di presentazione piuttosto pesante. Ad esempio, forse Malroy rimodella i campi di input della pagina "Crea nuovo thread" di un forum per apparire come una pagina di accesso. Questo induce l'utente a pensare che la sua sessione è scaduta, e lui inconsapevole sottomette le sue credenziali come un nuovo post pubblico.

Un utente malintenzionato attivo può anche utilizzare CSS per richiedere a un client di partecipare a un attacco CSRF, ad es. utilizzando background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy) .

Questa pagina ha un'ottima spiegazione e demo: link

Se si presume che l'attaccante possa modificare le parti non crittografate di una pagina, sarà in grado di modificarle in modo che includano il proprio modulo di accesso malevolo, invece del modulo di accesso sicuro.

Una possibilità che mi viene in mente è il jacking ad alta sessione. Se il cookie di sessione, per esempio, viene trasferito in un modo non sicuro, allora potrebbe essere ad alto jack.