È possibile "proteggere" contro gli attacchi MITM su HTTP?

Stanno facendo post-invio su SSL. Ciò fornirà protezione contro un MITM passivo poiché le credenziali sarebbero crittografate sul postback, tuttavia, non fa nulla contro un attaccante attivo che è in grado di alterare il traffico poiché potrebbero semplicemente alterare l'URL postback e l'esperienza dell'utente non cambierebbe .

Uno smart client potrebbe verificare l'integrità dell'URL postback prima dell'invio delle credenziali (compresa l'ispezione della pagina per qualsiasi javascript che possa alterare l'URL) ed evitare un attacco MITM, ma praticamente, per l'utente medio di internet, non è sicuro. Il sito che stavi visitando in realtà dovrebbe passare a fornire la schermata di accesso su una pagina completamente HTTPS.

Per davvero proteggere dagli attacchi man-in-the-middle , devi:

• applicare una sorta di controllo di integrità su tutti gli scambi tra client e server;
• applica almeno l'autenticazione unidirezionale (il server deve autenticare il client o il client deve autenticare il server).

In pratica, facendo ciò che SSL fa. In un contesto Web con HTTP semplice, il client è stupido e non farà le cose necessarie. Per rendere il client "intelligente", devi includere del codice sul lato client, cioè Javascript - ma se non scarichi quel Javascript su HTTPS, perdi.

Quindi la mia ipotesi è che il tuo interlocutore sia fuorviato o bugie deliberate per te o per entrambi.

L'uomo in mezzo è un problema difficile da proteggere. È come dire che c'è un modo per fermare il tempo, o c'è un blocco che non è selezionabile. La mia risposta generale è "no", non esiste un modo per proteggere genericamente, carta bianca contro gli attacchi MiTM, periodo, né esiste un buon modo per fermarli.

Il modo migliore per risolvere sempre questi problemi è con una soluzione a più livelli, per aumentare la barra contro un attacco MiTM. Altrimenti ogni singola soluzione punto sarà sempre bypassata e voilà, hai un uomo nel mezzo.