Inserimento di informazioni sensibili in un sito non SSL che utilizza iFrame sicuro

I'm wondering what are the security risks of this type of setup for the users.

È quasi così male come servire tutto su un semplice HTTP.

Ottieni protezione contro attacchi di ascolto puramente passivi, ma in realtà chiunque sia nella posizione di fare questo tipo di attacco man-in-the-middle è molto probabile che sia anche in grado di fare un attacco attivo, cambiando il contenuto che viene inviato di nuovo al browser. Ciò potrebbe includere la modifica del iframe src nella pagina padre non protetta o l'iniezione di alcuni script di attacco.

In pratica, l'iframe HTTPS ti protegge da un aggressore occasionale che fiuta il traffico generale, ma per qualsiasi tipo di targeting manuale nel sito è banale rendere la misura inefficace.

Dipende dal fornitore se pensa che questa sicurezza HTTP appena più che semplice sia adatta al tipo di informazioni che verranno inserite nel frame - eccetto se tali informazioni contengono dati di carte di credito, nel qual caso avere l'obbligo di rispettare le regole PCI-DSS che richiedono HTTPS. (Gli esperti devono verificare che gli indicatori HTTPS siano visibili nel chrome del browser.)

seeing the browser's address bar unable to provide identity/encryption information is disconcerting.

Sì. Indipendentemente dalla questione della sicurezza effettiva, si tratta di una scarsa sicurezza percepita e potrebbe scoraggiare alcuni utenti.

Without viewing the source of the page, how do I know where the iframe content is from?

Molto. La visualizzazione di sorgenti / DOM non è qualcosa che puoi aspettarti da un utente medio.

Inoltre, anche se si verifica la presenza dell'iframe tramite HTTPS, non c'è nulla che impedisca alla pagina madre non protetta di interferire con gli attacchi "clickjacking", ad esempio un modulo di overlay di keylogging.

Is relying on the godaddy seal sufficient?

I sigilli non offrono alcuna sicurezza, in quanto sono banali in grado di falsificarli. Non sono altro che un esercizio di marketing; Le CA dovrebbero vergognarsi di questo comportamento deliberatamente fuorviante.

Il mixaggio di HTTP e HTTP elimina quasi tutti i vantaggi di HTTPS. Per uno, un utente malintenzionato potrebbe presentare un frame HTTP genitore malintenzionato, con l'iframe che collega al proprio sito. Il browser non lo troverebbe sospetto. Neanche l'utente. L'URL iframe è nascosto e l'iframe non pretende di essere HTTP. Nessuno saprebbe la differenza, a meno che non abbiano controllato.

Il "sigillo" è solo un elemento HTML, facilmente falsificato. Non so come funziona, ma probabilmente è solo un collegamento a una pagina di GoDaddy con informazioni sul certificato SSL. L'iframe malizioso può semplicemente utilizzare lo stesso HTML e il link alla stessa pagina GoDaddy. Oppure, possono visualizzare le informazioni sulla sicurezza in un modo diverso (all'interno dell'iframe stesso, ecc.) E coloro che non sanno che aspetto ha l'autenticatore originale non conosceranno mai la differenza.