Campi password Web protetti + reindirizzamento http a https

@Hendrik ha ragione nel dire che questo è un rischio per la sicurezza in quanto una pagina di accesso non HTTPS può consentire a un utente malintenzionato di modificare il link di invio prima che l'utente lo faccia, comunque al punto della domanda su webscarab.

Esso (insieme ad altri proxy) intercetta il traffico HTTPS (supponendo che tu l'abbia impostato come proxy per tutti i protocolli), quindi non significa necessariamente che il traffico avrebbe attraversato Internet in chiaro. Se il post era su un URL HTTPS, sarebbe crittografato.

Solitamente si può dire quando si utilizza uno dei proxy di intercettazione, poiché si otterrà un messaggio di errore SSL sul certificato che non corrisponde (a meno che non si sia configurato il browser in modo specifico per fidarsi dei certificati dal proxy)

Sì, questo è un problema di sicurezza perché un utente malintenzionato potrebbe essere in grado di modificare il codice HTML. Può modificare l'attributo action del modulo in modo che punti al proprio server. O meno ovvio e migliore: aggiungi del codice javascript che rispecchia la password sul proprio server senza interrompere l'accesso al sito reale.

Purtroppo sia Facebook che Twitter hanno dato un cattivo esempio qui. Google Plus, tuttavia, reindirizza immediatamente a https, quindi c'è un po 'di speranza.

Che cosa dovresti fare? Informa gli utenti che devono controllare la barra degli indirizzi per https e il dominio corretto prima di inserire le informazioni private nei moduli Web.

Rory ha esattamente ragione, ma vorrei sottolineare che tu (e i tuoi utenti) dovresti essere estremamente diffidente nei confronti dei certificati SSL corrotti. Ci sono intercettazione di proxy SSL nel mondo in grado di leggere e modificare qualsiasi cosa tu invii, basandoti sui giochi con certificati che portano esattamente a questi errori.

Se ti abitui, o peggio, ai tuoi utenti di accettare errori di certificato, il vantaggio di sicurezza di SSL scompare essenzialmente di fronte a chiunque nel percorso del pacchetto (ad esempio, nello stesso coffe shop o nello stesso hotel, non per citare il dipartimento IT).

So zero su webscarab, quindi perdonami se questo è fuori dal contesto, ma dovresti sempre essere sospettoso ogni volta che vedi le password in chiaro nelle acquisizioni di pacchetti. Se stai inviando password in chiaro sul back-end della tua app, è meglio essere sicuri di comprendere le proprietà di sicurezza della rete in questione.

SSL è economico e facile. Accendilo ovunque tu possa e sii felice.

Non ho ancora provato il webscarab, ma presumo che intercetti il traffico HTTPS generando certificati https non firmati. Una pagina di accesso http, in cui l'invio per sta puntando a una risorsa https, dovrebbe essere sicuro. Probabilmente hai accettato un certificato ssl webscarab nelle tue precedenti sessioni di debug e normalmente riceverai un avviso a riguardo.

Ma https è rotto in molti modi. Nel caso dell'intercettazione di https, la generazione di nuovi certificati SSL non è affatto necessaria! Perché?

Se l'attaccante utilizza un proxy di intercettazione (MiTM), può riscrivere in modo intelligente tutti i collegamenti html da https: // uri a http: //. Ora il tuo sito non utilizza più SSL per crittografare i dati sensibili e l'utente non riceverà alcun avviso di certificato SSL, perché non vengono utilizzati!

sslstrip è un proxy che fa esattamente questo.

Una contromisura per questo potrebbe essere quella di offuscare i tuoi link in modo tale che sslstrip non sarà in grado di riscrivere i tuoi link link . Mi vengono in mente Javascripts e CSS.