Raccolta dei dati della carta di credito in iframe HTTPS all'interno di un sito HTTP

Caveat, IANAQSA

Aggiornamento: Slate non è in realtà un SAQ A - non stanno utilizzando iframe, e stanno inviando informazioni sulla carta, per esempio, link ... la maggior parte di ciò che è ancora in basso si applica comunque nello spirito.

Could someone tell me if it is possible to securely get credit card information in the way they have described?

Sì, è possibile. Tuttavia, vi è una responsabilità implicita trasferita a te per verificare che la tua connessione sia sicura e che il sito di pagamento a cui ti rivolgi sia un processore di pagamento legittimo.

Detto questo, questa configurazione è accettabile (come per PCI) e leggermente sconsigliabile (secondo le migliori pratiche di sicurezza).

Una lettura di SAQ A - che si applica ai mercanti che esternalizzano la gestione di tutte le carte al loro processore tramite un iframe - suggerisce che si tratta di una configurazione legale. Si noti che non pone alcun requisito esplicito sulle pagine contenenti la pagina di pagamento (iframe) che include le pagine di pagamento del fornitore di servizi; solo le pagine SP provengono da SP e SP è conforme PCI DSS (che implica la crittografia):

Ora,dettoquesto,cisonoproblemicome MITM che rendono la mancanza di Crittografia esterna di Slate sconsigliabile. Molte organizzazioni si sono battute su questa gobba e alla fine hanno deciso che la crittografia di tutto sul loro sito era preferibile per affrontare la percezione di insicurezza. Ma di solito ci vuole tempo e lamentele prima che arrivino le organizzazioni. Quindi sentiti libero di lamentarti di questo.

Quello che stanno facendo è sicuramente meglio che non fare https. Tuttavia, la loro pagina http esterna è più suscettibile agli attacchi come Man-In-The-Middle che potrebbe causare la sostituzione o la compromissione dell'iFrame "sicuro" in altri modi. Questo metodo rende difficile anche agli utenti finali effettuare le proprie determinazioni: l'icona di blocco è utile ei browser stanno lavorando sodo per insegnare agli utenti come determinare se un sito è sicuro.

Dato il costo minimo di https ora e data la quantità di sicurezza aggiuntiva che offre in generale, non c'è motivo per loro di difenderlo - dovrebbero solo aggiustarlo e andare https ovunque.

Quando crittografate l'intero sito, siete protetti dagli attacchi passivi, che leggono solo il traffico senza modificarlo, così come contro gli attaccanti attivi, che cercheranno attivamente di ottenere informazioni da voi e di bypassare le misure di sicurezza. Utilizzando un iframe crittografato, sei ancora protetto dagli attacchi passivi, perché i dati di pagamento vengono crittografati durante il transito. Tuttavia, poiché la pagina originale non è crittografata, un utente malintenzionato attivo (alias un uomo nel mezzo) può semplicemente sostituire l'iframe sicuro con uno che punta al proprio sito, che può sembrare identico a quello che dovrebbe essere lì, o semplicemente forzare l'iframe da caricare e inviare tramite una connessione non protetta (a condizione che non stia utilizzando HSTS per forzare il caricamento su HTTPS). Sono quindi in grado di catturare tutto ciò che inserisci, compresi i dettagli del pagamento. Inoltre, non ci sono avvisi del browser per informarti che ciò che inserisci viene intercettato, perché gli iframe non hanno indicatori di protocollo o di origine. Ciò significa che l'unico modo per rilevare un attacco come questo sarebbe quello di ispezionare l'elemento sul modulo, che quasi nessuno farebbe.

L'uso di un iframe HTTPS è molto meglio di niente, ma sarebbe sbagliato dire che è sicuro. Personalmente, non inserirò mai i dettagli del pagamento in una pagina che non ha https nella barra degli indirizzi, ma quando su una connessione sicura (cioè non pubblica wifi), il rischio è molto piccolo.

Poiché slate.com reindirizza a (ancora) slate.com, mentre è un passaggio di protocollo da http a https, non qualifica slate.com come privo di alcun ambiente di dati di titolari di carta. Sì, c'è una maggiore sicurezza (supponendo TLS 1.2, ad esempio) tra il browser dell'utente e slate.com, ma questo è tutto.