Token in php

Salve a tutti

spesso in alcun web application, quando mi spossto da una sezione all'altra mediante link

trovo una dicitura del genere:

index.php?tab=AdminCatalog&token=23e2ae22909fcf30324004f26abe6dfc

ora mi chiedevo, cosa è un token? e a cosa serve?

Grazie mille  :D

inviato 5 anni fa
RainboxSix
X 0 X

In questo caso, immagino, si tratti di una chiave univoca per identificare la sessione che tu hai aperto con il server in quel momento. Permette di migliorare la sicurezza dei servizi offerti.

risposto 5 anni fa
Mario Santagiuliana
X 0 X

ok grazie della risposta

come posso creare un token  ???

risposto 5 anni fa
RainboxSix
X 0 X

Ci sono vari sistemi, in genere lo si fa tramite un algoritmo che tiene conto di alcune informazioni del client in modo da creare un codice univoco che caratterizza la comunicazione del server con quel determinato client.

risposto 5 anni fa
Mario Santagiuliana
X 0 X

Io ero rimasto che php te lo fa in automatico e lo chiama PHPSESSID (nome modificabile da php.ini) attivando session.use_trans_sid (sempre in php.ini)

risposto 5 anni fa
Massimiliano Arione
X 0 X

Immagino che qualcuno programmi ancora applicazioni con un proprio token...

risposto 5 anni fa
Mario Santagiuliana
X 0 X
Immagino che qualcuno programmi ancora applicazioni con un proprio token...

Per carità, uno può anche scriversi i propri driver binari di accesso a mysql, invece di usare quelli messi a disposizione da php...

risposto 5 anni fa
Massimiliano Arione
X 0 X

Garak, a volte il Not Invented Here può far più danni del reinventare la proverbiale ruota. Ci sono casi, infatti, in cui si hanno requisiti specifici per non utilizzare qualcosa che già c'è.

Se poi uno (o il principale) di questi motivi è l'ignoranza allora il tuo commento ha un senso, in tutti gli altri casi sarebbe solo un commento vanaglorioso per urtare la tranquillità degli altri utenti, visto che non viene esposto niente di interessante.

Consideralo come un richiamino :)

Tom.

risposto 5 anni fa
Andrea Turso
Andrea Turso
86
modificato 5 anni fa
X 0 X

Garak, a volte il Not Invented Here può far più danni del reinventare la proverbiale ruota. Ci sono casi, infatti, in cui si hanno requisiti specifici per non utilizzare qualcosa che già c'è.

Se poi uno (o il principale) di questi motivi è l'ignoranza allora il tuo commento ha un senso, in tutti gli altri casi sarebbe solo un commento vanaglorioso per urtare la tranquillità degli altri utenti, visto che non viene esposto niente di interessante.

E non ti sembra esattamente questo il caso?

risposto 5 anni fa
Massimiliano Arione
X 0 X

Quel token presente nella query string può servire veramente a tante cose, può essere l'identificativo della sessione dell'utente, può essere un codice casuale utilizzato contro gli attacchi di tipo CSRF, può essere un sistema per impedire la manipolazione degli URL della pagina (usando HMAC ad esempio)

Essendo lungo 32 caratteri esadecimali mi fa pensare ad un codice ottenuto con MD5, ma neanche questo è detto.

Insomma, si può dire ben poco di questo token.

P.S.: prego tutti di mantenere bassa la temperatura del forum  :bye:

risposto 5 anni fa
Gianni Tomasicchio
X 0 X

Quel token presente nella query string può servire veramente a tante cose, può essere l'identificativo della sessione dell'utente, può essere un codice casuale utilizzato contro gli attacchi di tipo CSRF, può essere un sistema per impedire la manipolazione degli URL della pagina (usando HMAC ad esempio)

Essendo lungo 32 caratteri esadecimali mi fa pensare ad un codice ottenuto con MD5, ma neanche questo è detto.

Insomma, si può dire ben poco di questo token.

Hai fatto bene a parlare di CSRF, perché credo sia un problema troppo spesso sottovalutato dagli sviluppatori.

Devo però farti notare che in questo caso non è applicabile, perché un attacco CSRF per definizione viene eseguito su un url che si occupa di una modifica o di una cancellazione, url che quindi dovrebbe essere acceduta non con metodo get, ma con post (o al limite con put o delete)

risposto 5 anni fa
Massimiliano Arione
X 0 X

Forse mi sto confondendo, ma se nella pagina prodotta da quell'URL ci fosse un form con action vuota, all'invio del form il POST verrebbe inviato allo stesso URL, che contiene ancora il token, quindi sarebbe ancora possibile valutare la bontà del post. O mi sbaglio?

 :bye:

risposto 5 anni fa
Gianni Tomasicchio
X 0 X
Forse mi sto confondendo, ma se nella pagina prodotta da quell'URL ci fosse un form con action vuota, all'invio del form il POST verrebbe inviato allo stesso URL, che contiene ancora il token, quindi sarebbe ancora possibile valutare la bontà del post. O mi sbaglio?

Hai ragione, ma io non consiglierei l'utilizzo di action vuote in un form, meglio esplicitare sempre.

Tra l'altro non amo nemmeno mescolare i parametri get e post, anche se credo che sia legittimo.

risposto 5 anni fa
Massimiliano Arione
X 0 X

Non solo è legittimo ma nei casi di cui parla Gianni è necessario, vedi il caso di creare un token (:-P) per assicurarsi la legittimità di un post.

Il lasciare l'action vuoto non comporta nessun rischio dato che comunque viene aggiunto in automatico il nome del file passante, è il token che ha la funzione di validarlo, in pratica se non corrisponde la pagina o non corrisponde il token il post non passa, altrimenti va.

Metterlo pieno di default d'altra parte ha la stessa funzione ,dato che come si può aggiungere ad un action vuoto, lo si può modificare ad uno pieno ;-)

risposto 5 anni fa
Marco Grazia
X 0 X

Si può tranquillamente avere un token anti-CSRF e l'action del form: basta mettere il token in un campo hidden.

risposto 5 anni fa
Massimiliano Arione
X 0 X

Sì ma se hai paura che ti modificano i campi del forum tendi ad evitare di usarli, è dal '96 cioè da quando si fregava ebay modificando a mano il prezzo di un bene proprio taroccando i campi hidden che non si usano più per scopi che richiedano l'autenticazione di un valore.

Un metodo di autenticazione CAPTCHA (da usarsi preferibilmente assieme ad altri metodi) ancora valido è quello di usare un campo hidden e di lasciarlo vuoto, poi si controlla, se il campo è ancora vuoto bene, se viene riempito si scarta l'email.

I BOT in genere tendono sempre a riempire tutti i campi che incontrano in un form, ma questa è altra storia :)

risposto 5 anni fa
Marco Grazia
X 0 X

Guarda che qui stiamo parlando di CSRF.

Che c'entra la possibilità di cambiare i campi hidden? A parte che sarà sempre più facile cambiare un valore in get di un campo hidden, stiamo proprio parlando di altro: di un valore che va passato al form e che andrà verificato con un valore memorizzato (probabilmente in sessione). Se uno cambia quel valore, il form non si valida ed è questo lo scopo del controllo anti-CSRF.

risposto 5 anni fa
Massimiliano Arione
X 0 X

E' lo stesso che tu lo passi per GET o POST quindi anche il suo uso può essere lo stesso, eppoi modificare un form è una cosa banale come modificare una get.

risposto 5 anni fa
Marco Grazia
X 0 X

No guarda, mi sa che hai perso il filo del discorso.

Ripartiamo dalla tua prima affermazione:

Non solo è legittimo ma nei casi di cui parla Gianni è necessario, vedi il caso di creare un token (:-P) per assicurarsi la legittimità di un post.

Hai capito di che stiamo parlando? Di un token anti-CSRF.

Perché dovrebbe essere necessario mischiare get e post?

risposto 5 anni fa
Massimiliano Arione
X 0 X

Non è che sia necessario, ma puoi farlo, in pratica se usi il modo di passare una get sull'url con il token con un form che manda i dati via post diviene ovvio pensare di usare i due metodi (get e post) non è mica vietato farlo!

D'altra parte allo stesso modo come dici tu puoi passare il token con un campo nascosto così da usare un solo metodo, che sia get o post dipende dal form.

D'altra parte per migliorare la stabilità del metodo puoi persino usare tutte e due i metodi insieme, cioè passare la token via get e via post con il campo hidden e poi verificare in remoto se sono ancora uguali.

risposto 5 anni fa
Marco Grazia
X 0 X
Effettua l'accesso o registrati per rispondere a questa domanda