però una cosa mi è poco chiara: se il sito terzo malevolo invia i dati via post (comprensivi del token criptato preso dal codice html) al sito ufficiale quest'ultimo poi farà il controllo su quel token col proprio token salvato in sessione e perciò risulterà sempre uguale.. o sbaglio?
un'altra considerazione che mi è venuta: il controllo del token (inserito in un campo hidden) nel form di login avrebbe senso o no?
Per esempio, attualmente nel form di login di un mio script non ho messo il controllo del token perchè ho pensato che in questo modo all'attaccante non viene reso disponibile il token da prelevare e da inviare successivamente per il confronto.
Viceversa, nelle varie pagine dello script invece faccio confrontare il token del campo hidden. Ho fatto bene?
Perché il sito terzo possa leggere il token dall'html ed averlo uguale a quello con cui verrà confrontato dopo l'invio del form dovrebbe anche aver "rubato" la sessione (il token dipende dal session_id che è unico per ogni sessione), che però è legata ad un cookie che è sulla macchina dell'utente loggato e probabilmente anche settato come HttpOnly, quindi non facilmente leggibile.
In un login non ha molto senso, basta validare correttamente username e password. Anche perché solitamente la sessione si fa partire dopo il login e quindi prima non avresti nemmeno il session_id per generare un token.
Non ho capito cosa intendi quando dici che lo verifichi nelle varie pagine dello script, lo verifichi solo dove c'è un form o comunque un invio di dati da parte dell'utente? Oppure in ogni pagina del sito a prescindere dalla sua funzione?
non ho capito: se il sito malevolo legge il token nel campo hidden della pagina login non gli basterà poi inviarlo come un qualsiasi campo via post?Originariamente inviata da M4V1
Edit: ho fatto dei test: mi loggo come utente legittimo, poi da un altra pagina invio i dati via post con lo stesso token dell'utente legittimo e accedo al form senza problemi inviando i dati e facendo danni.
Invece io il session_start() lo metto proprio ad inizio pagina di login perchè faccio un altro controllo su un'altra cosa (cioè vedo se l'utente è loggato e in base a questo lo redirigo alle pagine interne dello script)
lo verifico solo dove c'è un form e quindi dei dati da inviare via post e in questo modo:
if ( $_POST['post_token'] !== md5(session_id() ) {
//non abilitato
}
Ultima modifica di LucianoS; 07-12-2017 a 21:48
Mi intrometto.Edit: ho fatto dei test: mi loggo come utente legittimo, poi da un altra pagina invio i dati via post con lo stesso token dell'utente legittimo e accedo al form senza problemi inviando i dati e facendo danni.
La prova l’hai fatta sullo stesso computer con lo stesso browser ? Se si allora la prova non vale.
La sessione è legata al computer che è collegato. Poi i dati veri della sessione sono sul server mica sul pc cliente. Dopo c’è il same origin security policy che impedisce l’invio di dati da un dominio ad un altro.
In altre parole, se copi una pagina con una form che punta a un altro dominio e la esegui dal tuo, non funzionerà. Comunque occhio a questo perché si puo’ facilmente bypassare.
Ridatemi i miei 1000 posts persi !!!!
Non serve a nulla ottimizzare qualcosa che non funziona.
Cerco il manuale dell'Olivetti LOGOS 80B - www.emmella.fr
ho provato ad inviare i dati Post dal mio pc localhost ad un mio sito online dove gira la stessa applicazione con quei controlli e son riuscito a far passare il form inserendo i dati.
In pratica, faccio questi controlli:
Questo codice funziona ed impedisce l'invio di dati da siti terzi. MA se recupero il token (dal campo hidden di quel form) e lo invio dal sito terzo (insieme agli altri campi) allora ecco che riesco a passare.codice:if ( !isset($_POST['token']) OR $_POST['token'] !== md5(session_id() ) { //non puoi postare }
Perché lo fai dal tuo browser dove hai il cookie di sessione attivo, quindi per il server è sempre la stessa sessione.
Permessi di invio
Rispondi quotando