Supponiamo che tu voglia dare ad alcuni utenti web un accesso privilegiato al tuo sito web, ma che non sei in grado (o non voglia) di offrire SSL a tutti loro - almeno dopo la pagina di accesso iniziale.
In questo caso, c'è un modo per gestire la sessione utente che annullerà FireSheep, ma non creare un'esperienza utente dolorosa?
In linea di principio potresti essere in grado di difendersi dagli attacchi passivi. Ma in pratica non è banale e non è una soluzione eccezionale.
In linea di principio, è possibile scrivere il proprio codice di crittografia in Javascript per crittografare tutto sul lato client (in Javascript). La prima cosa che si incontra è che questo ha scarse prestazioni, perché la crittografia in Javascript è sostanzialmente più lenta della crittografia nativa del browser. La reazione naturale è di suggerire di crittografare solo i dati più sensibili, ad es. Solo le password dell'utente. Tuttavia, questo è molto difficile da ottenere e ha molte piccole insidie:
Se non stai crittografando i cookie, sei vulnerabile al dirottamento di sessione e non hai ottenuto nulla. E non è facile crittografare i cookie o altre intestazioni HTTP da Javascript. Quindi probabilmente sarai costretto a inventare il tuo metodo di autenticazione utente e usare qualcosa di diverso dai cookie (qualcosa di homebrew) per la gestione delle sessioni, che è un mucchio di lavoro e facile da sbagliare.
Se cripti solo la password, potresti essere vulnerabile agli attacchi CSRF. Un intercettatore può ancora vedere tutto il contenuto della pagina e, in particolare, se i token CSRF sono inclusi nel link, l'intercettore può vedere tutti i token CSRF e montare un attacco CSRF. È possibile difendersi da questo con uno sforzo sufficiente, ma richiede ancora più lavoro sia sul client che sul server, ed è complicato da correggere.
Se gli utenti possono accedere al tuo sito utilizzando il loro account Facebook, dal momento che non controlli Facebook, non puoi impedire a un intercettatore di rubare il loro account Facebook e quindi accedere al tuo sito.
Sei ancora vulnerabile agli attacchi man-in-the-middle (attacchi attivi) che modificano il contenuto della pagina. Non sarebbe terribilmente tecnicamente difficile modificare Firesheep per usare il dirottamento ARP, attacchi razziali o altri metodi per inserirsi come man-in-the-middle e modificare tutto il contenuto della pagina. Quindi la sicurezza viene persa, poiché l'utente malintenzionato può inserire Javascript dannoso che funge da keylogger o altrimenti ruba le credenziali di autenticazione.
Devi stare attento a non perdere il vantaggio della memorizzazione nella cache.
Ora non sto dicendo che è impossibile. Quasi certamente non lo è. È quasi certamente possibile costruire un sito Web e una soluzione che prevenga la maggior parte degli attacchi passivi. Ma sarà complesso e non banale. Ciò significa che avrai bisogno di una notevole esperienza in materia di sicurezza per costruirlo, e c'è ancora una possibilità non banale di rovinare qualcosa. Significa anche che il risultato sarà costoso. E la sicurezza è intrinsecamente limitata - qualsiasi schema sarà solo una soluzione parziale / mitigazione - quindi il valore è limitato. Non penso che sia un buon compromesso.
Se vuoi leggere dei tentativi all'avanguardia per difendersi dalle intercettazioni senza l'uso di SSL, ecco una grande risorsa per te:
Mi piacerebbe anche condividere con voi alcune risorse per far sì che SSL funzioni bene:
SSL non è gratuito, ma ricorda anche che a volte le persone pensano che l'impatto sulle prestazioni di SSL sarà peggiore di quanto non sia in realtà.
È possibile evitare l'attuale Firesheep tramite uno schema di "sicurezza attraverso oscurità" che coinvolge l'autenticazione tramite la gestione dinamica delle sessioni come discusso qui . Puoi utilizzare "Autenticazione del digest" ( RFC 2617 ), ma è ancora vulnerabile a un attacco MITM, peggiora l'esperienza dell'utente e richiede al server di memorizzare la password (o una password equivalente) in chiaro.
Ma evitare SSL / TLS non aggirerebbe i due problemi fondamentali che senza crittografia: (1) tutto il contenuto privato è condiviso in aperto, e (2) un determinato attaccante potrebbe capire il tuo schema e sconfiggerlo.
Guarda alcuni esempi di attacchi attivi, mitiga le prestazioni sanzionate e consigli specifici sulla distribuzione di SSL da EFF: Come distribuire correttamente HTTPS . Nota anche la meta discussione Overflow dello stack su perché non è stato corretto su Stack Overflow (ancora).
Si noti che l'esposizione per i siti comuni è peggiore di quanto pensassi inizialmente. Per esempio. nota questa ruga come l'autore di Firesheep spiega in un ottimo post
You can’t simply avoid visiting the sites that are being attacked here. There’s an enormous amount of mixed content on the web today, such as the Facebook “Like” button, Digg’s “Digg It” button, twitter widgets, and even embedded images that are hosted on Flickr or other photo sharing sites. Every time you access any web page that includes any of this content, your browser also sends any authentication cookies you have with the request to pull down the widget.
Puoi almeno correggere gli errori che discute lì (come in realtà invalidare i cookie di sessione quando un utente si disconnette !!).
Puoi anche consigliare ai tuoi utenti su come proteggersi da questi attacchi di "sidejacking", ad es. per utilizzare una VPN o trovare una rete WPA2 wifi (ma vedere i problemi WPA2 qui ).
Grazie a @ D.W. per un collegamento con l'approccio ad interim ben pensato che ho visto: SessionLock Lite di Ben Adida. Previene almeno i dirottamenti persistenti da parte di attaccanti passivi: Benlog »continua le tue mani dai miei cookie di sessione . Semplicemente non fermarti qui - progetta una distribuzione SSL ....
Senza ombra di dubbio la risposta è NO . È necessario disporre di un livello di trasporto completamente sicuro in cui trasmettere l'ID della sessione. In nessun momento questo ID di sessione può essere trasmutato su una connessione non sicura, questa sarebbe una violazione di OWASP A9 - Insufficiente Transport Layer Protection
Sono d'accordo con la risposta di Rook. Tuttavia, ho un'idea che potresti mitigare l'uso di firesheep e in generale tutti i dirottamenti di sessione.
Il mio suggerimento è di collegare l'impronta digitale del browser a ogni utente. Se l'impronta digitale varia, l'utente deve autenticare nuovamente questa impronta digitale sul suo account.
Fondamentalmente intendo memorizzare un'impronta simile che panopticlick.eff.org può creare semplicemente guardando il tuo browser.
Maggiori informazioni sulla profilazione degli utenti Web sono disponibili qui:
In una parola, no. Per prevenire attacchi in stile FireSheep, hai bisogno di un modo per proteggere le tue intestazioni anche da un osservatore passivo. (Dopo tutto, tutte le informazioni inviate dal client, inclusa QUALSIASI forma di criteri di autenticazione, si trovano nelle intestazioni). Ciò significa sicurezza a livello di connessione. E, per HTTP, significa TLS o SSL protetto da SSL, più comunemente noto come HTTPS.
Ci sono alcune cose che possono renderlo più difficile, ma ci sono modi per aggirarle.
Leggi altre domande sui tag web-application attack-prevention session-management