Iniziamo una serie di articoli sulla sicurezza delle applicazioni web realizzate in PHP.
Come primo argomento analizziamo il problema del Session Hijacking e cerchiamo di difenderci come possibile.
In cosa consiste
La pratica del Session Hijacking consiste nel conseguire l’accesso non autorizzato su un sistema tramite l’abuso delle chiavi di sessione e generalmente prevede la manipolazione dei cookie dei browser.
La tecnica più banale dal punto di vista tecnico prevede il furto dei cookie dal browser della vittima, ma proteggere da questo tipo di attacco è difficile e dovrebbe essere responsibilità di ogni utente la protezione dagli accessi diretti non autorizzati al proprio computer.
Session Fixation
Questo metodo prevede l’assegnazione alla vittima di un preciso id di sessione, conosciuto dall’attaccante.
Un semplice modo per ottenere questo effetto è quello di inviare un link alla vittima e fare in modo che questa lo apra. Il link deve contenere al suo interno l’id di sessione scelto dall’attaccante e quando la vittima effettuerà l’accesso al sito, anche l’attaccante si ritroverà automaticamente autenticato.
In PHP è possibile assegnare un id di sessione in un link, usando la variabile PHPSESSID in GET.
Esempio di attacco
- L’attaccante si collega al sito da violare ed esaminando il cookie del suo browser identifica il suo ID di sessione “ABC123”.
- L’attaccante invia una mail alla vittima con all’interno un link del tipo “http://sito.com?PHPSESSID=ABC123”, invitando la vittima a seguire il link.
- La vittima segue il link e il suo ID di sessione diventa automaticamente “ABC123” e si autentica sul sito.
- A questo punto la sessione con ID “ABC123” risulta autenticata anche sul browser dell’attaccante, che ha libero accesso a tutte le informazioni riservate cui aveva accesso la vittima.
Come difendersi
Ci sono diversi sistemi di difesa dal Session Fixation ma ognuno ha un limite o prevede alcuni requisiti:
- Se sul server è presente l‘estensione suhosin è possibile cifrare i cookie e quindi rendere difficile la scoperta dell’ID di sessione all’attaccante. Ovviamente così facendo non sarà possibile leggere il cookie neanche da codice javascript presente sul sito, ma allo stesso tempo guadagneremo una protezione anche per altre potenziali informazioni sensibili presenti all’interno del cookie oltre all’ID di sessione.
- Disabilitare l’uso della variabile PHPSESSID impostando session.use_only_cookies = true nel php.ini. In questo modo non è possibile passare un ID di sessione tramite un link, ma allo stesso tempo è obbligatorio, perché le sessioni possano funzionare, che i cookie siano attivi sul browser dell’utente. Questo in passato poteva essere un grosso limite, ma ai giorni nostri è un requisito che è possibile dare per scontato.
- Generare un nuovo session ID ad ogni login. Con questo accorgimento possiamo fare in modo che venga assegnato un nuovo ID di sessione all’utente, che quindi non sarà più uguale a quello assegnatogli dall’attaccante, impedendogli di condividere la sessione della vittima. L’operazione in PHP è molto semplice e non prevede controindicazioni: è sufficiente una chiamata alla funzione session_regenerate_id.
Session Sidejacking
In questo caso l’attaccante cerca di scoprire l’ID di sessione di un utente, per poterlo usare lui stesso, ottenendo l’accesso autenticato al sito.
Per ottenere l’ID, l’attaccante utilizza tecniche di packet sniffing per intercettare i pacchetti di rete trasmessi tra server e browser dell’utente, e leggendone i dati contenuti identifica l’id di sessione e potenzialmente anche altri dati sensibili come indirizzi email o passwords.
Come difendersi
Realizzare questo tipo di attacco è più complicato del caso precedente, ma allo stesso tempo è anche più complicato proteggersi.
Il metodo migliore è sicuramente l’uso di un certificato ssl per la connessione sicura tra browser e server (https).
I sistemi informatici coinvolti nel traffico di rete devono anche prevedere dei controlli di sicurezza contro attacchi di tipo man in the middle o packet spoofing, ma spesso il nodo più vulnerabile è il computer della vittima o l’uso di reti wireless con protezioni di sicurezza troppo deboli o del tutto assenti (vedi WEP).
Alcuni accorgimenti sono comunque possibili all’interno dell’applicazione web:
- Cifrare i cookie con l’estensione suhosin resta un sistema consigliato. In questo modo il contenuto del cookie risulta illeggibile anche se l’attaccante riuscisse a leggere il traffico di rete, rendendolo inservibile. L’utente potrebbe comunque provare a utilizzare il cookie direttamente senza decifrarlo, ma suhosin utilizza una chiave di decodifica che contiene lo user-agent del browser e parte dell’indirizzo IP, rendendo l’operazione più difficile anche se non impossibile
- Se non è possibile usare suhosin, si può comunque emulare almeno una parte del suo controllo di sicurezza sullo user-agent e sull’IP della richiesta. Potremmo quindi impedire l’accesso alle richieste il cui user-agent e parte dell’indirizzo IP non corrispondano a quelli utilizzati per fare il login. E’ meglio non utilizzare l’indirizzo IP completo perché alcuni ISP utilizzano una rete di proxy studiata in modo che l’IP utilizzato possa cambiare ad ogni richiesta, ma la sottorete dovrebbe molto probabilmente rimanere invariata.
Conclusioni
Abbiamo visto come alcuni accorgimenti alle nostre applicazioni web possano incrementare notevolmente la resistenza ad alcuni tipi di attacchi, ma le difese che possiamo adottare non coprono tutti i tipi di attacchi possibili (alcuni hacker sostengono che non esistano sistemi impenetrabili) ed in questi casi una connessione cifrata https e un server con adeguati sistemi di sicurezza garantiscono la miglior protezione possibile.
