it-swarm.dev

Rischi specifici di incorporare un iframe HTTPS in una pagina HTTP

Ho bisogno di aiuto per elencare i rischi specifici di incorporare un iframe HTTPS che abilita il pagamento con carta di credito all'interno di una pagina HTTP. Ci sono problemi di sicurezza con l'incorporazione di un iframe HTTPS in una pagina HTTP? fornisce alcune preoccupazioni di alto livello, ma sto cercando di essere il più specifico possibile sui potenziali vettori di attacco. Fai clic su Acquista ora per un buon esempio di iframe sicuro all'interno di una pagina non sicura, utilizzata oggi per le transazioni con carta di credito. Ecco cosa ho finora:

  • La conversione sarà probabilmente inferiore perché gli utenti istruiti sapranno di non inserire il numero della loro carta di credito senza vedere un lucchetto verde nell'URL nel browser Chrome. (Gli utenti meno esperti potrebbero non sapere che non dovrebbero fidarsi di un lucchetto che appare nel frame del browser, come nell'esempio sopra.)
  • Anche se gli utenti sono a proprio agio con questo approccio, è generalmente una cattiva idea incoraggiare gli utenti a inserire il numero della loro carta di credito quando non vedono una conferma di blocco SSL nella barra degli URL. Insegna agli utenti cattive abitudini di sicurezza. Questo post sottolinea che SSL riguarda la sicurezza più che la semplice crittografia e autenticazione.
  • Un uomo attivo nel mezzo potrebbe iniettare una sceneggiatura canaglia nella pagina principale che potrebbe premere ficcanaso. Credo che questo sia ciò che il governo tunisino ha fatto per rubare le credenziali di Facebook dei dissidenti. (Credo che allo script canaglia sarebbe impedito l'accesso al nome utente e alla password dall'iframe sicuro, ma potrebbe comunque accedere alle sequenze di tasti). Naturalmente, un'autorità governativa più determinata potrebbe sovvertire il DNS e creare anche un certificato SSL, come apparentemente il governo iraniano , nel qual caso una pagina padre sicura non sarebbe di aiuto.

Ho anche questo elenco di preoccupazioni non realistiche:

  • Un altro oggetto Javascript nella pagina padre non protetta potrebbe ficcare il contenuto dell'iframe sicuro. Credo che questo non sia più possibile a condizione che siano supportati solo i browser IE8 e versioni successive.
  • Un oggetto Javascript non valido nella pagina principale potrebbe eseguire la registrazione dei tasti per acquisire il numero di carta di credito di un utente. Ciò può essere possibile, ma il rischio non è influenzato dal fatto che la pagina padre sia servita tramite SSL o meno. Una sceneggiatura canaglia potrebbe premere ficcanaso in entrambi i modi.
  • L'utente non può vedere l'URL da cui viene fornito l'iframe sicuro. Con una pagina padre sicura o non sicura, devi essere un utente tecnicamente sofisticato per visualizzare l'URL di origine iframe.

Potresti dirmi quali altre vulnerabilità realistiche e non realistiche mi mancano? Non ho dubbi che l'opzione migliore sia sempre quella di incorporare un iframe sicuro in una pagina padre sicura. Quello che sto cercando di decidere sono i rischi e i benefici relativi dell'abilitazione di un iframe sicuro all'interno di una pagina non sicura rispetto alla scarsa esperienza utente di saltare gli utenti fuori dal sito non sicuro in cui vedono il prodotto al fine di completare un checkout sicuro altrove.

24
Dan Kohn

Fai clic su Acquista ora per un buon esempio di iframe sicuro all'interno di una pagina non protetta, utilizzato oggi per le transazioni con carta di credito.

A parte tutti i motivi tecnici citati, questa è una cosa disastrosamente negativa, che è esplicitamente contro i requisiti PCI-DSS. Vedi "Navigating DSS 2.0" requisito 4.1:

When using SSL secured websites, ensure “https” is part of the URL

L'interfaccia collegata è in violazione delle condizioni PCI che i commercianti sottoscrivono come parte del loro accordo con la propria banca. ShopLocket sembra fornire/incoraggiare un approccio palesemente non conforme a PCI e profondamente discutibile all'elaborazione delle carte.

15
bobince

Un utente malintenzionato che può incorporare uno script canaglia nella pagina principale può anche semplicemente modificare l'URL per l'iframe, reindirizzandolo a una posizione arbitraria, a quel punto tutti i tipi di phishing e configurazioni man-in-the-middle sono facili. Non c'è bisogno di giocare trucchi DNS a quel livello. Questo è il problema principale con un tale iframe HTTPS: non puoi facilmente sapere se hai la cosa genuina (devi essere sicuro della modalità di debug del browser per essere veramente sicuro - uno sguardo superficiale all'origine della pagina non è in definitiva sufficiente perché gli script caricati dalla pagina può manipolarlo a piacimento a livello di DOM, quindi ciò che sembra vedere nel codice sorgente non è necessariamente quello che ottieni).

Si riduce davvero alla mancanza della barra degli URL per l'iframe. Per un sito HTTPS, la barra dell'URL indica che è presente SSL corretto, con un certificato server valido, e indica il nome del server stai effettivamente parlando. Rimuovi la barra e diventano possibili tutti i tipi di cattivi trucchi.

Sul lato positivo, un iframe HTTPS, come un URL di destinazione HTTPS per un modulo di accesso in una pagina HTTP, è ottimo contro gli attaccanti solo passivi (il tipo di attaccanti che ascolta tutti i byte scambiati ma non inietta mai nulla da solo). Accade semplicemente che credere che la maggior parte degli attaccanti sia solo passiva al giorno d'oggi è diventato singolarmente ingenuo.


Per quanto riguarda l'esperienza dell'utente, la consueta raccomandazione è semplicemente quella di rendere HTTPS l'intero sito. È molto meno costoso, dal punto di vista computazionale, di quanto si pensi di solito. Su base generale, gli umani non sono bravi a prevedere i problemi di prestazione. Le prestazioni sono una questione di misurazione, non di ipotesi. Ti suggerisco di provarlo.

Inoltre, come utente (sebbene non necessariamente un utente tipico ), Mi piace la transizione visibile da HTTP a HTTPS. Il checkout riguarda il denaro e, soprattutto, il denaro il mio . Pertanto, è importante .

21
Tom Leek