Session Hijacking: affidabilità di User-agent

[kappabit]

Ciao
ho letto tutta la guida di phpsecurity consortium ed anche quelle che ho trovato su html.it ma c'è una soluzione per l'attacco hijacking che ancora mi sfugge.

Viene consigliato di concatenare una stringa segreta alla stringa User-Agent ricevuta da headr HTTP perchè controllare la validità di una sessione affidandosi solo alla corrispondeza di questa con quella salvata in sessione è poco affidabile dal momento che la stringa User-agent è facilmente rintracciabile ed inviabile al server (vedi: http://phpsec.org/projects/guide/4.html#4.2).

Non ho ben capito come il rimedio spiegato nel link indebolirebbe questo tipo di attacco quindi vado per passetti e vediamo se tra risposte e controrisposte riesco a far capire i dubbi ed ottenere delucinazioni

La domanda è:
se al caricamente di pagina.html io inserisco in testa questo: header('User-Agent: ".(md5($_SERVER['HTTP_USER_AGENT']."stringa_Segreta"))); dovrei ricevere un User-agent crifrato e più sicuro di quello standard che a quanto pare è facilmente ottenibile. E' una giusta soluzione?

Grazie..

[k.b]

La scarsa sicurezza data dal semplice controllo del user-agent deriva dal fatto che e' relativamente facile indovinare quello valido, visto che ce ne sono un numero limitato: prova e riprova prima o poi lo becchi. Per questo l'idea e' creare un codice che garantisca che l'utente sia quello legittimo con buona sicurezza (si parla sempre di compromessi, perche' il livello di sicurezza e' inversamente proporzionale alla comodita' di navigazione per l'utente). Per questo l'autore dell'articolo suggerisce di creare un hash basandosi sulla stringa del user-agent e su una segreta -- questa aggiunta e' necessaria, perche' se e' facile indovinare l'user-agent giusto e' altrettanto facile fornirne un hash. Inoltre suggerisce di passare questa stringa tramite URL perche' se si assume che il session id sia stato ottenuto "rubando" i cookie, allora metterlo nei cookie sarebbe inutile.

[kappabit]

dunque tra le prime linee della pagina html invio via post l'MD5 dell'user-agent concatenato ad una stringa segreta, vero?

Quale differenza c'è con il token che si crea per prevenire l'attacco CSRF?

[k.b]

No, non e' necessario un form, basta aggiungere l'hash alla query string e recuperarlo via $_GET.

[kappabit]

ok grazie, e la differenza con il token per prevenire l'attacco CSRF?
Con questo controllo diventa inutile la generazione di un token da mettere in ciascun form?

[k.b]

No sono due cose diverse. Il token ti serve per verificare che una richiesta POST venga da una sorgente sicura (cioe' la *tua* pagina in cui il form viene compilato e che genera il token): il semplice fatto che un utente abbia una sessione valida non garantisce che ti invii dati dalla pagina giusta.

[kappabit]

perfetto, molte grazie

[kappabit]

Hai un'idea di come fare per agganciare la var nella query string senza doverla aggiungere manualmente a tutti i link?

[kappabit]

Nel senso, essendo un parametro da inserire in GET a tutti i link è più corretto che ci sia un modo automatico per attaccarlo al link al momento del click sullo stesso...

[k.b]

No, devi aggiungerlo al link.