https login iframe 2014

0

Per i consigli di sicurezza attuali e amp; supporto browser, va bene avere un iframe https in un insieme di pagine altrimenti solo http?

Non è un problema? Lo è, ma voglio le tendenze attuali perché quando ho provato alcuni mesi fa i browser mi hanno avvertito del contenuto misto, ma ora quando faccio un iframe di una pagina di accesso sicura del mio dominio non ricevo alcun avvertimento. (L'URL è a.com ma punta al mio host locale, URL principale us http://a.com/ , che ha un iframe che proviene da https://a.com/login )

Suppongo sia dovuto al fatto che https non ha colpa ed è stato JavaScript che ha portato alla vulnerabilità e ora è stato risolto?

Testato in FF 31, Chrome 36, IE 9

Ho visto:

Ho capito che il rischio è che l'utente possa avere un addon / programma dannoso che cambia la fonte dell'iframe. Se il computer dell'utente è così gravemente compromesso, non tutte le scommesse sono comunque valide?

Dovremmo comunicare al nostro cliente, anche nel 2014, nessun ifttame di accesso https? Se l'utente desidera accedere, aggiornare la pagina alla versione https o reindirizzare l'utente ad un'altra pagina di accesso e l'accesso può tornare a http in aree sicure (non checkout e account correlati).

So che non è una cosa molto computazionale, ma per qualche motivo il client è fisso sull'idea che alcune pagine siano migliori http o https (http l'utente può essere modificato manualmente dall'utente)

    
posta tgkprog 26.08.2014 - 16:47
fonte

2 risposte

2

link non aiuta contro MITM attivo .

Le vulnerabilità di js potrebbero essere state chiuse, ma il problema rimane , poiché l'html padre (pubblicato su http) può ancora essere modificato, incluso l'URL dell'iframe. Quindi il MITM può impostare la pagina di accesso tramite http e che verrà caricata dagli utenti target. Solo gli utenti che utilizzano un gestore di password noteranno la modifica, poiché i gestori di password trattano gli URL https e http come origini diverse. Questo è niente che i rivenditori di browser possano risolvere .

Ad esempio, invece di servire

<iframe src="https://site.example/login.php"name="login_frame">

l'attaccante MITM può servire

<iframe src="http://site.example/login.php"name="login_frame">

e pubblica una pagina di accesso intercettata sulla pagina http.

E javascript, come descritto nella copiatrice originale , può ancora accedere agli attributi iframe. Provalo tu stesso: link

    
risposta data 26.08.2014 - 17:08
fonte
1

Per quanto ne so, iframe è sempre vulnerabile a Clickjacking

Questa è una grande ragione per cui il sito web non dovrebbe fare il login in un iframe e perché hai bisogno dell'intestazione Opzioni X-Frame o ora frame-ancestors nella pagina di accesso.

Inoltre, come menzionato nel tuo post e quella risposta , il contenuto della pagina http può essere intercettato e cambiato da un uomo nel mezzo. Dato che il MitM può modificare l'url dell'iframe, ora sei vulnerabile all'attacco di phishing.

    
risposta data 26.08.2014 - 19:44
fonte

Leggi altre domande sui tag