I moduli di carte di credito sulle pagine HTTP rischiano un rischio MITM?

Sì, l'ultima persona è corretta, oltre alla crittografia ( riservatezza ) HTTPS ti dà l'assicurazione che il modulo proviene da dove pensi che sia ( autenticazione ), e che non ha subito interferenze durante il transito ( integrità ). Senza HTTPS il modulo potrebbe essere modificato da un MITM come descritto.

È Non usare HTTPS per questo è semplicemente una cattiva pratica (dato che l' utente è spesso il link più debole), quando si inseriscono dati importanti l'utente dovrebbe semplicemente aspettarsi di vedere HTTPS (lucchetto / barra verde / altro) ad ogni passo, senza eccezioni.

La maggior parte dei browser avviserà per impostazione predefinita se si esegue il POST da una pagina HTTPS a un URL non HTTP, ma non tutti indicano chiaramente che i dati vengono inviati in modo sicuro nel caso opposto. La mancanza di HTTPS significa anche che il sito non utilizzerà i cookie "sicuri".

Vedi anche: Pubblica da HTTP a HTTPS una cattiva pratica?

Affrontare correttamente questo problema richiede HTTP STS ( RFC6797 ), anche se nella maggior parte dei casi rimane un problema di bootstrap con le prime richieste HTTP.

Un problema simile è la pratica dell'utilizzo di iframe in un sito HTTPS all'interno di una pagina HTTP, ad es. Servizio di carta di credito di terzi. In questo caso, sebbene il modulo e il post siano HTTPS, non c'è garanzia di integrità nel contenuto non HTTPS contenente iframe . Il browser non mostra il modulo è HTTPS (almeno non nel modo normale, se non del tutto), quindi questo viola anche le aspettative di un utente attento alla sicurezza.

Un uomo nel mezzo potrebbe facilmente manipolare il target del post, quindi non punta più sull'URL HTTPS sicuro. L'utente non può vedere se il target è sicuro (senza guardare il codice HTML), quindi deve solo credere che il target POST sia sicuro.

Questo schema di un modulo HTTP non sicuro che chiama un URL HTTPS sicuro, è sempre vulnerabile a SSL-strip .

Mentre alcune delle risposte sono davvero utili, tutti hanno trascurato di menzionare un aspetto molto importante, l'iniezione di codice dannoso.

Un MITM è in grado di modificare la pagina visualizzata su HTTP, rendendolo in tal modo in grado di iniettare Javscritpt malevolo che, ad esempio, attende fino a quando si passa il mouse sul pulsante di invio e fa un POST Ajax al server dell'attaccante che invia il modulo informazione. Questo è fondamentalmente ciò che il governo tunisino ha fatto per raccogliere le credenziali dei dissidenti di Facebook .

Quindi ci sono, per quanto ne so, due problemi di sicurezza per servire i form via HTTP (beh, in realtà sono uno solo, ma possono essere sfruttati in due modi diversi):

1. L'attaccante che cambia la destinazione della submission (il campo action )
2. L'autore dell'attacco che inserisce il codice Javascript che invia i dati del modulo a una terza parte.

Ok, per essere chiari, NON dovresti farlo come sviluppatore del sito, ma se hai bisogno di lavorare con un sito che si comporta in questo modo, la mia risposta è progettata per dire cosa può essere fatto in sicurezza. Fondamentalmente non puoi fidarti di nulla sulla pagina stessa, tutto quello che puoi fidarti è che se il certificato SSL si risolve, allora il post sta parlando al server legittimo per l'URL che afferma di essere. Devi convalidare manualmente che sta inviando a quell'URL e che è l'URL appropriato. Questo può essere fatto solo se la risposta raggiunge lo stesso URL di primo livello che ha servito la pagina poiché sai che stai tentando di connettersi a quel dominio di primo livello.

Finché l'utente stava verificando che il post target era il server previsto e quella post-connessione era HTTPS e che non c'erano script che potevano alterare il contenuto presente sulla pagina e il browser non inviava tramite un collegamento HTTPS che non ha un certificato valido per l'URL inviato, quindi il modulo sarebbe perfettamente sicuro. Si noti che è possibile conoscere il server previsto solo se sta pubblicando sullo stesso TLD di come la pagina è ospitata. Ad esempio, non sapresti se www.bobp.com ti dice di inviare il modulo a www.bobspayments.com era valido. È anche possibile che se le stesse informazioni inviate a due servizi diversi facciano cose diverse, allora un utente malintenzionato potrebbe farne uso. Il problema è che un utente non lo farà. Protegge dallo sniffing passivo, ma non fornisce all'utente la conferma che il sito è legit che DOVREBBE (ma probabilmente non lo farà in molti casi) sollevare preoccupazioni da parte dell'utente.

Un aggressore MITM attivo potrebbe semplicemente cambiare pagina per restituire loro le informazioni, ma poi di nuovo, questo potrebbe essere fatto anche se la pagina stessa fosse HTTPS poiché molti utenti non noterebbero se si trattasse effettivamente di una pagina HTTP che era restituito, quindi non sono sicuro se ci sia davvero una minaccia significativamente più grande da un MITM attivo in entrambi i casi.

Il vero problema sarebbe l'esperienza dell'utente e il fatto che si presenti all'utente in quanto la pagina non è protetta, quindi HTTPS è ancora preferibile per l'intera pagina per questo motivo. Per chiarire, c'è molto che può andare storto se i contenuti della pagina non sono autentici, quindi è preferibile provare l'autenticità, ma finché le informazioni vengono effettivamente inviate su SSL, saranno protette. Il problema è garantire che sarà senza rivedere manualmente il codice della pagina.