Domanda:
Esistono problemi di sicurezza con l'incorporamento di un iframe HTTPS in una pagina HTTP?
Yahel
2010-11-30 23:13:04 UTC
view on stackexchange narkive permalink

Ho visto siti web che inseriscono iframe HTTPS su pagine HTTP.

Ci sono problemi di sicurezza con questo? È sicuro trasmettere informazioni private come i dettagli della carta di credito in un tale schema (dove le informazioni vengono inserite solo nel modulo iframe HTTPS e non nella pagina principale HTTP)?

Vedi anche https://security.stackexchange.com/q/38317/16960
Sei risposte:
#1
+47
user502
2010-11-30 23:35:09 UTC
view on stackexchange narkive permalink

Se solo l'iframe è https, l'utente non può vedere banalmente l'URL a cui punta. Pertanto, la pagina http di origine potrebbe essere modificata per puntare l'iframe ovunque si desideri. Questa è praticamente una vulnerabilità di game over che elimina i vantaggi di https.

+1 per sottolineare l'importanza dell '* autenticazione del server *, che viene spesso dimenticata come vantaggio di SSL.
Riconosco che questa è una vecchia domanda, ma speravo che qualcuno potesse spiegare in che modo avere HTTPS nella pagina di origine risolve un problema di uno script canaglia che cambia la posizione dell'iframe?Se la pagina di origine è HTTPS, potresti comunque avere uno script canaglia che cambia la destinazione dell'iframe, no?
@MattJames, se la pagina di origine è anche HTTPS, non può essere modificata durante il transito a meno che MitM non abbia un certificato valido per il dominio (cosa che non dovrebbe accadere a meno che le CA non stiano facendo il loro lavoro).Possono comunque intercettare il caricamento HTTP -> HTTPS originale e reindirizzarlo a un dominio sotto il loro controllo.Gli utenti sarebbero in grado di rilevarlo guardando l'URL e il certificato, entrambi visualizzati solo per il frame più in alto.Detto questo, la maggior parte degli utenti probabilmente non se ne accorgerebbe, motivo per cui a volte gli account vengono compromessi.
Il presupposto ovviamente è che l'attaccante sia seduto nella rete.Se possono modificare la pagina di origine sul server per includere codice non autorizzato, tutte le scommesse sono disattivate.Allo stesso modo, se possono ottenere uno script in grado di alterare il contenuto della pagina installato nel browser dell'utente, sono altrettanto vulnerabili.(Quindi le persone che usano Greasemonkey / Tampermonkey / ecc. Devono stare attenti, anche se molti non lo fanno.)
#2
+18
goodguys_activate
2010-12-01 01:01:06 UTC
view on stackexchange narkive permalink

iFrame esporrà il sito HTTPS interno a numerosi attacchi javascript e cookie nei browser meno recenti e potrebbe causare problemi nei browser più recenti.

Per risolvere questo problema, cerca "Frame Busting" per rilevare se vengono utilizzati iFrame. Considera questa soluzione su StackOverflow:

https://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

In quel codice, puoi rilevare se vengono utilizzati iFrame e offrire contenuti alternativi per indirizzare l'utente al sito appropriato.

#3
+15
Paul
2010-12-01 01:18:20 UTC
view on stackexchange narkive permalink

Un iframe HTTPS all'interno di una pagina servita su HTTP non consentirà all'utente di essere sicuro di utilizzare effettivamente la connessione HTTPS che si aspetta di essere; pertanto, questo potenzialmente consente il dirottamento dell'iframe con un semplice attacco come un'iniezione di iframe. Ciò consentirebbe, tra le altre cose, la raccolta delle password. Un attacco di questo tipo potrebbe iniziare tramite un Trojan, un virus o semplicemente visitando un sito Web dannoso.

#4
+7
symcbean
2010-12-01 22:06:35 UTC
view on stackexchange narkive permalink

Sì, mentre i browser più recenti eseguono correttamente il sandboxing delle parti SSL, stai minando tutte le funzionalità aggiunte al Chrome del browser per fornire feedback agli utenti in merito ai contenuti. Io per primo non fornirei alcuna informazione sensibile senza controllare l'URL visualizzato nel mio browser.

#5
+2
Dominique
2011-06-04 02:38:00 UTC
view on stackexchange narkive permalink

Oltre ai possibili scenari di dirottamento già forniti, potresti incorrere in problemi su IE6 / 7 se punti a una pagina HTTP o HTTPS che richiede l'accesso. Fondamentalmente, i cookie dalla pagina dell'iframe si aspettano che tu stia utilizzando lo stesso protocollo (HTTP o HTTPS) e quindi se la pagina su cui stai inserendo l'iframe utilizza HTTP invece di HTTPS, impedirebbe all'utente di essere in grado di accedi.

questa risposta sembra confusa. Non sono sicuro di cosa stai cercando di dire, oa quale problema stai alludendo.
I cookie non sono condivisi tra http e https
#6
  0
gnasher729
2019-10-19 18:16:23 UTC
view on stackexchange narkive permalink

Qualsiasi richiesta http significa due cose: uno, gli hacker potrebbero ficcare il naso e leggere sia la richiesta che la risposta. Due, gli hacker potrebbero essere in grado di restituire un sito web diverso da quello originale.

Quindi, se accedo al tuo sito web tramite http e ricevo un link https, gli hacker potrebbero venire a conoscenza di quel link https, ma tutto sommato non è meno sicuro di un link http.

Tuttavia, non è affatto garantito che ho ricevuto il tuo sito web e non quello fornito da un hacker. Quindi quel frame https potrebbe non essere nemmeno presente sul sito corretto, solo su quello hackerato. E non c'è nessuna garanzia dove punta, quindi nessuna sicurezza.

Una volta che inizi con http, per quanto riguarda la sicurezza, il gioco finisce.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...