L'invio di un modulo può essere crittografato anche se la barra degli indirizzi mostra HTTP?

2

Stavo per presentare una carta di identità studentesca tramite ISIC, ma ho notato che il modulo in cui viene richiesto il pagamento (come il numero della carta di credito) non è disponibile tramite HTTPS.

L'URL del modulo di acquisto è link

Ho chiesto a ISIC di questo e hanno risposto che l'invio del modulo è crittografato.

È possibile crittografare in modo affidabile l'invio di un modulo quando si accede al modulo tramite il protocollo HTTP?

Come può un utente in questo tipo di casi confermare che l'invio del modulo è crittografato, poiché il browser (nel mio caso Firefox) non indica la crittografia evidenziando l'URL in verde?

    
posta x457812 26.11.2014 - 18:22
fonte

3 risposte

7

Per espandere la risposta di Thebluefish, il processo di invio del modulo sembra utilizzare HTTPS (un protocollo crittografato) per l'elemento della carta di credito a https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing quando guardo la pagina. Ma questo non significa che questa configurazione è sicura da usare.

La configurazione generale è molto vulnerabile e deve essere risolta. Non vorrei inviare alcun dettaglio della carta di credito tramite questo servizio e raccomanderei di non utilizzarlo. Se è assolutamente necessario utilizzarlo, è necessario ottenere una carta di credito prepagata con solo la quantità necessaria per questo servizio e quindi utilizzare quella carta di credito per ridurre al minimo il danno in caso di furto. O se la tua carta di credito offre i numeri di carta di credito utilizzabili una sola volta , potresti usarla (anche se, di nuovo, in alcuni casi rischio che la carta di credito utilizzata una sola volta venga catturata e utilizzata per un altro acquisto).

Il problema con la pagina è che tutto, tranne l'invio del modulo, viene inviato su HTTP non crittografato, che qualsiasi attaccante di rete può banalmente alterare. Ad esempio, un utente malintenzionato potrebbe acquistare un dominio e quindi modificare il dominio in cui viene inviato il modulo HTTPS a uno che controlla (che potrebbe anche sembrare simile).

Potrebbero mantenere il modulo inviando i dati al dominio corretto tramite HTTPS, ma inserire javascript dannoso ovunque nella pagina o in una delle librerie per associare un'azione per inviare i dati del modulo a un URL controllato da un utente malintenzionato.

Ancora una volta, potremmo esaminare la pagina come viene visualizzata al momento per noi e determinare che non faccia alcuna azione dannosa. Tuttavia, qualsiasi router / ISP / computer tra te e il server www.myisic.com potrebbe modificare il contenuto corrente della pagina http non crittografata in qualcosa di malevolo, consentendo il furto dei dati della tua carta di credito.

    
risposta data 26.11.2014 - 21:31
fonte
3

Se osservi il codice sorgente relativo al modulo della carta di credito, puoi vedere quanto segue:

<form name="form" method="post" action="https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing" id="payForm">

Pertanto l'invio del modulo è su HTTPS. Questo dovrebbe andar bene nel garantire che i dati della tua carta di credito non vengano rubati, anche se le tue informazioni personali (nome, indirizzo, ecc ...) sono trasmesse via HTTP.

    
risposta data 26.11.2014 - 18:34
fonte
-1

La crittografia potrebbe essere stata eseguita con javascript prima che il modulo venga pubblicato. Per fare ciò, l'algoritmo di crittografia e la chiave pubblica devono essere inviati al client se si utilizza la crittografia asimmetrica. Per la crittografia simmetrica, è necessario inviare sia l'algoritmo che la chiave.

Tuttavia, non ho trovato alcuna libreria o funzione di crittografia javascript utilizzata nella pagina. Un esempio di tale libreria sarebbe CryptoJS. Pertanto i tuoi dati personali non vengono crittografati.

    
risposta data 26.11.2014 - 18:43
fonte

Leggi altre domande sui tag