Altre volte abbiamo già dedicato questa rubrica all’esposizione di vulnerabilità non tanto di applicativi o dei sistemi operativi, ma a carenze delle interfacce web sempre più diffuse a causa della loro usabilità. Torniamo oggi sull’argomento parlando di Session Fixation. (http://www.acros.si/papers/session_fixation.pdf) Sintetizzandone il funzionamento: un sito web protetto da password affetto da questa vulnerabilità attribuisce già al momento della risposta alla prima pagina richiesta dal browser l’identificativo di sessione. Questa richiesta può essere fatta da un attaccante che poi prende l’identificativo e lo manda all’interno di un URL ad un utente legittimo del sistema. Se l’utente legittimo cliccasse su questo link il server gli richiederebbe un’autentificazione, e se ora l’autentificazione fosse portata a termine con successo sarebbe impossibile per il server distinguere le successive richieste dell’attaccante da quelle dell’utente legittimo (e vittima) poiché entrambe sarebbero accompagnate dal medesimo identificativo di sessione. Attacchi come quello visto coinvolgono tre soggetti (attacker, utente, server) e le carenze di sicurezza di chi gestisce il server possono tramutarsi in problemi per un terzo soggetto “ignaro” che in caso di danni potrebbe citare l’amministratore del server anche se quest’ultimo non è stato materialmente autore di un azione illecita. Per difendersi da questo attacco bisogna scrivere le applicazioni web in modo che esse inviino gli identificativi di sessione solo dopo l’autentificazione oppure non basarsi solo sugli “id-session” per identificare gli utenti. Invitiamo anche ad approfondire le caratteristiche di HTTP Response Splitting. (http://www.sanctuminc.com/pdf/Whitepaper_HTTPResponse.pdf) Si tratta di una tecnica che consente, attraverso l'invio di caratteri di tipo CR e LF, di creare una risposta del webserver che il client interpreti in due tempi. In questa maniera, ad esempio, si può forzare un reverse proxy a mettere nella cache una pagina alterata simulando in questo modo un defacement della pagina richiesta. In realtà nessuno ha modificato la pagina presente sul server web, come si potrebbe verificare accedendovi da una via che non passi per il server proxy vittima del poisoning Questa classe di vulnerabilità oltre il Web Cache Poisoning può consentire altre categorie di attacco come ad esempio: Cross User Defacement, Hijacking o anche i più noti XSS (Cross Site Scripting). Per evitarne le conseguenze è valida ancora una volta la raccomandazione di controllare e filtrare tutti gli input che vengono passati al sistema.