HTTPS iFrame incorporato nella pagina HTTP: implicazioni PCI?

6

Attualmente sono volontario in una organizzazione non profit. Durante la ricerca di qualcosa di non correlato, ho notato che $ sisteragency utilizzava un iFrame incorporato per accettare donazioni online. Mentre l'origine del frame utilizza HTTPS, la pagina su cui si trova è HTTP.

$ sisteragency utilizza software CRM di terze parti per gestire le donazioni, fornito da $ crmcompany. $ crmcompany afferma di essere conforme PCI, ma le sue istruzioni sembrano essere costruite attorno all'aggiunta di iFrame a una pagina non sicura. La sua knowledge base contiene un messaggio suggerito per mostrare agli utenti che si riduce a "Anche se non è possibile visualizzare il lucchetto o https nella barra degli indirizzi, la parte della pagina che cattura le informazioni di pagamento [l'iFrame] è sicuro." La loro pagina YouTube ha un'esercitazione video in cui mostrano l'iFrame (con un https src) che viene aggiunto a una pagina http. Il loro sito ha anche istruzioni dettagliate per rispondere alle richieste di conformità PCI da un processore di pagamento (come in, esattamente cosa inserire in ogni campo).

Questo mi sembra davvero losco. Non è possibile che un uomo nel mezzo di attacco modifichi lo src di iFrame, poiché la pagina contenente è http? Nonostante le affermazioni di $ crmcompany, non è $ sisteragency anche responsabile della conformità PCI ($ crmcompany dice che è responsabile della conformità dei suoi clienti)? $ Crmcompany è negligente e / o non conforme fornendo istruzioni per incorporare il sistema di pagamento sicuro in una pagina non sicura?

In sostanza, ho ragione ad essere così turbato da tutto questo?

    
posta Sigvaldr 28.04.2016 - 17:06
fonte

3 risposte

2

Usando un iframe https in una pagina Web http proteggi solo contro gli attaccanti passivi .

Non è una buona soluzione perché:

  • Non protegge dall'attaccante attivo (può riscrivere l'url dell'iframe, vedere sslstrip)
  • Il browser non può visualizzare un lucchetto per https (perché la pagina principale non è protetta)

L'unico modo per gestire i dati in modo sicuro è con HTTPS nella pagina web completa :

  • Tutto è crittografato anche se un utente malintenzionato attivo non può leggere i dati o modificarli (inclusi i collegamenti)
  • L'utente ottiene conferma dal browser che tutto è crittografato (con il lucchetto)

Si noti che avere quella pagina usando https non è sufficiente: I link a quella pagina dovrebbero essere protetti (se la home page http mostra un link https "donazione", un utente malintenzionato può riscriverlo). Quindi per proteggere davvero un sito web che gestisce dati sensibili (nota che, secondo la legge europea, i dati personali devono essere protetti) l'intero sito web dovrebbe utilizzare HTTPS.

L'utilizzo di HTTPS + HSTS sull'intero sito Web è il modo migliore per proteggere un sito Web che deve proteggere alcuni dati, anche se si trova in poche pagine web .

(Siamo spiacenti, so che non risponde sulla conformità PCI, solo sulla sicurezza.)

    
risposta data 01.05.2016 - 12:30
fonte
0

È difficile credere che $ crmcompany sia veramente conforme a PCI con quel tipo di iFrame "sicuro" all'interno di una configurazione di documento non protetta. Anche se $ crmcompany è conforme allo standard PCI (e richiederei una copia del loro audit più recente che mostri la conformità), le organizzazioni non profit non sono conformi allo standard PCI e sono obbligate a farlo poiché eseguono pagamenti attraverso il loro sito (indipendentemente da iFrame). Dal momento che i pagamenti sembrano arrivare attraverso il sito no-profit, devono essere conformi PCI. Inoltre, se recuperano e archiviano le PII correlate alla transazione di pagamento, sono anche responsabili della conformità PCI e, come menzionato da @Tom, dovranno proteggere le PII in base alle leggi sulla privacy dell'UE.

    
risposta data 29.10.2016 - 03:24
fonte
0

Considera che stai utilizzando un sito link non protetto con un sito sicuro link incorporato nell'iframe in un sito non protetto.

Un utente che utilizza un wifi pubblico (ospitato da un utente malintenzionato con un nome "FreeHub" in un coffee shop) e accede al sito non sicuro in cui il sito protetto viene caricato in iframe. A questo punto gli hacker ora hanno accesso al flusso di dati b / w utente e mondo esterno ( attacco MITM ). Potrebbe essere in grado di vedere tutti i dati a cui l'utente ha accesso in chiaro (solo sito HTTP ).

Poiché il sito HTTPS protetto è iframed in un sito HTTP non sicuro, c'è una possibilità per

  1. L'autore dell'attacco per inserire lo script java nel sito HTTP che potrebbe registrare tutto i tratti chiave (Key Logger).
  2. L'utente malintenzionato potrebbe anche reindirizzare l'utente a qualche altro phisphing sito semplicemente cambiando lo src dell'inframe (Poiché l'iframe è incorporato in HTTP).

Inoltre, poiché il sito ospitato in HTTP, il browser non mostra un lucchetto (che indica che il sito è protetto). L'utente istruito che ha conoscenze su HTTPS / PCI non è pronto ad inserire i propri dettagli di pagamento / carta anche se il tuo sito cita "Anche se non riesci a vedere il lucchetto o https nella barra degli indirizzi, la parte della pagina che cattura le tue informazioni di pagamento [l'iFrame] è sicuro. " Riduce così la donazione alla tua organizzazione.

Poiché riguarda i dettagli del pagamento degli utenti, è meglio ospitare un sito HTTP sicuro.

    
risposta data 28.03.2017 - 09:13
fonte

Leggi altre domande sui tag