È sicuro fornire i miei dettagli tramite un iframe, se la pagina dell'iframe è protetta con SSL? [duplicare]

È un cattivo design e l'intera pagina dovrebbe utilizzare HTTPS, poiché questo allena gli utenti alla pratica non sicura di fidarsi e inviare informazioni private su HTTP. Sarebbe banale per un aggressore man-in-the-middle modificare la pagina HTTP esterna per non utilizzare l'iframe HTTPS corretto, ma invece un iframe controllato dagli hacker (possibilmente HTTPS per un dominio controllato da un attaccante).

Quindi è necessario controllare il codice sorgente dell'iframe ogni volta che si inviano dati privati (in quanto non ci sono garanzie che la prima volta che è stato ispezionato andasse bene, ma la prossima volta che è stato alterato da un tamper HTTP).

Inoltre, poiché la pagina viene caricata su HTTP, un utente malintenzionato MITM può inserire ed eseguire qualsiasi javascript che desiderano sulla pagina esterna (e nascondere queste modifiche in uno script offuscato caricato esternamente). Potrebbero lasciare l'iframe originale con l'URL https corretto se si è fatto clic su view-source della pagina HTML, ma in javascript potrebbero nascondere o sostituire quell'iframe con elementi DOM malevoli che sembrano identici (ma trasmettono i dettagli all'utente malintenzionato). Questo è meno un problema con un ispettore DOM interattivo nei moderni strumenti di sviluppo (che mostra il DOM così com'è attualmente, quindi dovresti essere in grado di ispezionare l'iframe), ma anche questo richiede un sacco di lavoro di verifica per ogni utente che vuole per inviare dati in sicurezza.

Poiché l'iframe è su HTTPS ma la pagina Web principale è HTTP; questo sarebbe contenuto misto, ma i browser darebbero solo un avvertimento se il contenuto HTTP è incorporato in una pagina protetta da SSL, e non viceversa come in questo caso.

È ancora una combinazione non sicura in quanto la pagina principale sarebbe in grado di comunicare con i contenuti dell'iframe tramite la chiamata dell'API postMessage HTML. In questo scenario tra domini, questo funziona solo se il documento nell'iframe accetta e risponde a queste query basate sui messaggi dalla pagina principale. Vedi questo esempio . Ecco un altro esempio che mostra agli sviluppatori come aggirare questo incrocio sicurezza del dominio incorporando gli iframe della pagina principale all'interno dell'iframe stesso, quindi è un hack che potrebbe non durare a lungo mentre i browser vengono aggiornati nel tempo e correggere queste lacune.

L'unico problema che vedo qui è che se vengono scambiati dati tra la pagina HTTP principale (non protetta) e la pagina di pagamento protetta HTTPS, quanto è sensibile e quanto è protetta quando si passa al dominio HTTP non protetto .

Ma ancora una volta, questo tipo di problema è valido ovunque un'app Web passi la sessione / transazione dell'utente a un'altra app Web, indipendentemente dal fatto che gli iframe siano coinvolti o meno. Come utenti finali, non conosciamo il tipo di comunicazione in corso dietro le quinte tra diversi fornitori di servizi al momento del completamento di una transazione. Questi sono il tipo di controlli che PCI-DSS e altri dovrebbero convalidare.

Ti suggerisco di fidarti di loro se entrambi i server appartenenti alle pagine HTTP e HTTPS appartengono alla stessa compagnia di servizi di streaming.

No, non è sicuro.

Se la pagina padre non è protetta con https, non vi è alcuna garanzia che l'utente vedrà l'url iframe https corretto.

Un utente malintenzionato può eseguire un attacco man-in-the-middle sulla pagina padre e causare il rendering di un iframe sul sito Web dell'attaccante. Poiché i browser non indicano lo stato dell'URL o degli https degli iframe, l'utente non sarebbe nessuno più saggiamente comunicano con qualcuno fraudolento.