PHP Modulo di Sicurezza Con Referer

Sto mettendo insieme un sito che si renderà disponibile per l’input dell’utente. Mi chiedevo se la scrittura di una funzione come:

if(getenv("HTTP_REFERER") != 'http://www.myURL.com/submitArea'){
        die('don\'t be an jerk, ruin your own site');   
    }else{
        //continue with form processing    
    }

è sufficiente a prevenire cross site invio di form.

EDIT: E se no, qual è la migliore pratica per prevenire le forme dall’essere presentate da altri host?

  • Odio dirlo, ma avete ottenuto la risposta sbagliata per questa grande questione. Si prega di leggere il mio post, non ho prove a sostegno.
  • No, la tua risposta è chiaramente sbagliato. I può forge Referer intestazioni e è un rischio per la sicurezza.
  • non importa, questo non stava accadendo nel vostro browser, ma di qualcun altro browser.
  • Scusa, ma non capisco cosa stai dicendo. Cosa vuoi dire con questo non accadrà nel mio browser?
  • Se posso forgiare richieste nel mio browser, qual è il problema con la ricerca di un browser exploit (foro) che mi permetta di farlo in un altro popolare browser? Firefox / Chrome / Opera, tutti non sono esattamente dei segnali di sicurezza. Il solo modo di lavorare è quello di assumere tutto ciò che viene consegnato a voi (dal browser, client, altri siti, database) è completamente e assolutamente cestino. Sterilizzare i vostri dati e non lasciare alcun margine di errore. Se si dispone di un modulo che ha il potenziale per complicare le cose, si dovrebbe sempre eseguire l’autenticazione con qualcosa di controllo, come la SESSIONE.
  • Egli intende dire che è sicuro, perché il browser giocare secondo le regole. E si può manomettere il vostro browser e fare, ma non vi è alcun modo possibile che potesse mai accadere a qualcun altro browser a meno che non era intenzionale.
  • Ah, vedo. Ma si dovrebbe mai fiducia input dell’utente – non importa che cosa!
  • Questo è fondamentalmente ciò che stiamo ottenendo, sì. 😉
  • accidenti, questo è impressionante questione, e non mi importa di ottenere il -3.
  • Franky, non c’è modo di impedire a qualcuno di inviare i dati del modulo da “altrove”. Se si parla di CSRF, quindi controllando l’intestazione di Origine o l’utilizzo di token è la cosa giusta da fare, ma no, non mi impedisce di inviare il modulo tramite Telnet, non importa quanto si tenta. Si può solo costruire infallibile tecnologie sulla parte superiore del vostro sistema per tenere i bimbi di distanza.
  • se si desidera ottenere risposte per l’esempio di codice, quindi credo che sia una questione diversa del tutto. Proporrei di prendere fuori della questione (e, facoltativamente, post come nuova), in quanto la domanda è già creato un sacco di discussione. Per favore cerchiamo di rimanere concentrati sul REFERER parte. Grazie.
  • questo nuovo codice, forse, considerato un “deferenza approccio più approfondito”, comunque sia CSRF controlli saranno escluse da una vulnerabilità XSS. Si dovrebbe utilizzare un numero casuale come uniqid(mt_rand(), true), non l’hash della password. Dovrebbe essere notato che c’è molto poco di prove a sostegno di molte delle contro-argomentazione al mio post.
  • La torre, Grazie di nuovo, ho preso la pagina come in realtà è tutto un altro barattolo di vermi. Ma ho fatto quello che hai suggerito. In realtà, ora sto andando con i cookie e memorizzato l’id di sessione utilizzando il uniqid() metodo… il sito non ha bisogno di essere sicuro CHE, quindi spero che questo almeno compensa i media hack.

 

6 Replies
  1. 3

    Effettivamente sì, secondo il OWASP CSRF Prevenzione Cheat Sheet nella maggior parte dei casi si verifica il referer è sufficiente per la patch di un TIPO di vulnerabilità. Anche se è banale per falsificare il referer sul tuo PROPRIO BROWSER è impossibile di parodia su un altro browser (via CSRF) perché rompe le regole.

    Infatti controllando il referer è molto comune vedere embedded hardware di rete, dove la Memoria è scarsa. Motorola fa questo per la loro tavola da Surf Modem via Cavo. So che questa prima mano, perché Ho fatto loro con csrf e poi patchato con un referer di controllo. Questa vulnerabilità ricevuto una gravità metrica di 13,5 e secondo il Dipartimento di Homeland Security, questo è il più pericoloso TIPO di vulnerabilità scoperte e i 1.000 software più pericolosi difetti di tutti i tempi.

    • la torre, grazie mille per l’invio di questo. Ho intenzione di aggiungere tutti gli elementi forniti in queste risposte, ma visto il “Referer bloccato BLOCCATO bloccato BLOCCATO” mi ha fatto respirare un po ‘ più facile. grazie!
    • Sono felice di aiutare.
    • -1 per ogni risposta tranne questo.
    • Ah, accidenti, anche se io di solito voto di gente che scende per suggerire una vulnerabilità in questo caso specifico non è ben conosciuto. Il browser di Google sec manuale è impressionante, tutti dovrebbero leggerlo.
    • Questa risposta è SBAGLIATO e dovrebbe essere evitato. Come ho detto nella mia risposta, si dovrebbe utilizzare una qualche forma di autenticazione.
    • Regole significa nulla. Esso deriva dal browser o l’utente che non deve mai mai mai essere attendibile. È quello che è.
    • dopo qualche pensiero, credo che la Torre è corretto. Quando si tratta di browser e di sicurezza, ho sempre supporre alcuni browser, da qualche parte, sta andando a vite ma a google di riferimento, che tutti abbiano il diritto. Quindi, a meno che non si sta parlando di custom file eseguibili, o se si vuole essere assolutamente sicuri-che è completamente difendibile — controllo del referer potrebbe essere abbastanza buono.
    • Ma tutto ciò che serve è qualcuno iscritto il proprio proprio browser e puff! tutto va verso il basso in fumo. Inoltre, il post si parla di cover chiamate AJAX.
    • Sto andando a prendere un mio commento modifica? Assicurarsi di rimuovere le parolacce (mi dispiace), ma il resto davvero così terribile?
    • Anche allora, questo potrebbe bloccare i clienti innocenti/proxy che non invia il previsto referer da configurazione/natura.
    • Esattamente. Non so che continua a upvoting questa risposta – si, è sicuramente fondamentalmente sbagliato.
    • Concordato. È come dire di non aver mai bisogno di agenti di polizia, perché tutti a seguire le regole. Si supponga nessuno a seguire le regole e sarete molto più sicuri.
    • Fate a non capire la differenza tra il codice non attendibile può fare e ciò che un utente può intenzionalmente fare a vite di se stesso? Sono sicuro che l’unico motivo per cui non fare affidamento sul referer solo perché alcune persone disabilitare la loro referers a causa della paranoia.
    • Secondo voi la gente è logica, se qualcuno usa un nonce in ogni POST di richiesta, potrei modificare il mio browser, che di codice remoto da altri siti andrà a scoprire che nonce e utilizzare.
    • In questo caso la soluzione sarebbe merda. Capisci che c’è una differenza tra in teoria, e in pratica?
    • Secondo voi la tua logica non abbiamo bisogno di garanzie, perché tutti potranno “giocare secondo le regole.”
    • K: Scusa, ma tu proprio non capire un punto fondamentale qui. Si NON usa il tuo sito web per forza qualcuno browser lo spoofing di un referente. Se è possibile, il browser è BROKEN, e così insicuro.
    • Mi dispiace, proprio come non si può dire, l’attacco del computer di qualcuno per creare un attacco DDOS? Fatto che. Non è possibile installare un cavallo di troia che permetterà di modificare il browser? Fatto che. Non è possibile sfruttare un falla di sicurezza nel browser? Fatto che. Ho assolutamente , non per vedere il merito dicendo “non puoi farlo, perché non è permesso. Se non è possibile allora è rotto” quando non garantisce la validità di tutti l’input dell’utente qualsiasi. CHE è il punto fondamentale qui, non se il browser può essere compromessa.
    • Atwood, vi Ringrazio molto, e al resto di voi WOW non avevo idea di questo sarebbe così controversi tutti devono leggere il Browser di Google sec manuale, anche se è d’accordo con me.
    • Josh K. assolutamente di destra. tutto ciò che può essere violato sarà.
    • K, si prega di leggere la domanda, accettata risposta, e andare a leggere su CSRF, e poi, post qualcosa, perché voi non siete nemmeno a parlare in un contesto più… Quello che stai affermando è completamente irrilevante. Un exploit è un game over, qual è il tuo punto?
    • Si prega di ri-leggere il mio varie commenti. Il mio punto è che se si ottiene informazioni dal browser dovrebbe mai essere attendibile. Mai. Posso renderlo ultra bold? ****Mai****, ****mai****. Non credo, ma spero che si ottiene il mio punto.
    • K, ho letto tuoi post. Che punto è irrilevante in questo contesto. Dubito ancora di sapere che TIPO è.
    • Penso che siamo tutti d’accordo che la domanda deve rewording in entrambi i modi. Perché non risolvere tutto?
    • Edison: No, non è così.
    • Edison in realtà è stato pesantemente modificato e mi piace per come è.
    • Questo è sbagliato per due motivi. Primo, l’intestazione viene spesso omesso. In secondo luogo, se il TIPO di attacco che accade sul sito di riferimento e ‘ corretto. Per esempio, l’immissione di un immagine sul sito vero e proprio in alcuni commenti possono lanciare attacchi CSRF. Oltre a questo, le richieste di alcune persone su regole sono irrilevanti. Probabilmente non si capisce cosa CSRF è davvero.
    • Non in un post di richiesta. E il controllo di un referente, non è davvero “fiduciosa” input dell’utente. Just sayin’.
    • Quello che hai descritto è XSS.
    • Sellgren Ciò che si sta descrivendo sarebbe un metodo per bypassare questo TIPO di sistema di sicurezza in particolare per OTTENERE basati csrf sul alcuni applicazioni. Chiaramente questa patch funziona bene per Motorola modem, ma se si dove che consentono di personalizzare la url dell’immagine del assicuratevi di usare il POST per importanti cambiamenti di stato (come la sostituzione della password). Questo uso della POSTA vs OTTENERE è coperto da RFC 2616 parti 9.3 e 9.5, e sì, mi rendo conto che la maggior parte dei web gli sviluppatori di app ignorare RFC.
    • Se il “Referer” possono essere contraffatti (o rimosso), sarà. Il confronto di un token di sessione con un POST token è più facile e più sicuro.
    • È impossibile falsificare il Referer su qualcun altro browser utilizzando CSRF. Ho inviato le prove a sostegno, non hai.
    • No, quello che ho descritto non aveva nulla a che fare con XSS. In realtà, non aveva nulla a che fare con JavaScript o “script”. È stato solo l’invio di richieste sul conto dell’utente.
    • Rook Solo se si utilizza uno di questi browser. Credo che tu abbia ragione in quanto coprono quasi ogni situazione, ma perché questo metodo se c’è la possibilità? E cosa succede se l’intestazione REFERER è stato nascosto? L’unico aspetto negativo che posso pensare per il TIPO di token di sessione è che essi richiedono i cookie per essere attivato solo se si sta passando l’id di sessione attraverso l’url. Tuttavia, CSRF, di solito, solo gli obiettivi privilegi di utenti registrati. Se si ricrea il token per ogni forma, sembra completamente hackproof per me. Anche se, grazie per avermi aperto gli occhi, vorrei poter annullare il mio downvote.
    • hmm effettivamente hai ragione, non è XSS. Ma il referrer metodo è ancora sicuro, ma non lasciare che la gente posta i link delle immagini per la tua autenticato le pagine o solo usare il POST per autenticato azioni. Se solo il web è stato concepito per essere sicuro 🙁
    • È possibile utilizzare i token CSRF i cookies? Avete un esempio di questa implementato? Per quanto ne so l’unico modo per farlo è quello di inviare loro tramite GET/POST, le richieste e generare una nuova ogni volta. In entrambi i casi si hanno ancora bisogno di un cookie per evitare di essere registrato quando si chiude la pagina e aprirne uno nuovo. “E cosa succede se l’intestazione REFERER è stato nascosto” Utente viene bloccato.
    • Questo è esattamente perché questa domanda è così impressionante! Penso che un sacco di persone hanno imparato qualcosa da questo (anche Jeff Atwood!). Sono andato avanti e ha fatto una modifica per la pagina, se qualcuno vuole cambiare il loro voto.
    • Se non mi sbaglio, i token CSRF richiedono i cookie, a meno che si utilizza sessione id nell’url (generalmente considerati non sicuri). L’idea è che si stanno confrontando il token memorizzato nella Sessione corrisponde a quello incorporato in un campo nascosto dalla forma su invia i dati. Ricordati che utilizzando le sessioni memorizza un cookie con l’identificatore di sessione sul computer client, ma si potrebbe anche fare manualmente con il proprio cookie se si voleva, invece di usare le sessioni. @La Torre Ancora non riesco a cambiare il mio voto :(. Comunque, come si affronta il problema della mancanza di ‘REFERER’?
    • si infatti non bisogno di un cookie per il POST gettoni. Es: 1) l’Utente visita il sito, senza i cookies. 2) l’Utente accede tramite POST. 3) Sito genera una pagina in modo tale che ogni link include un token in, lo stoccaggio {token -> user_id} in una persistente mappa 4) l’Utente fa clic su un link, presentando il token. 5) Server elimina il token dopo l’elaborazione della richiesta, procedere con il passo 3. È insicuro di mettere il token di OTTENERE le richieste perché l’utente potrebbe quindi copiare e incollare il link a una fonte esterna; l’utente dovrebbe essere in grado di copiare quello che vuole, lui non interessa se è insicuro.
    • Ahh, mi ero dimenticato di quel metodo. Ma sì, io preferisco avere abbastanza url così l’id di sessione o token CSRF in OTTENERE i parametri non sono l’ideale.

  2. 10

    No – HTTP_REFERER può essere liberamente contraffatti sul lato client e non è un indicatore affidabile di cui una richiesta venuto.

    Aggiornamento: ho letto male la parte su cross site contraffazione: Per questo, controllando il referer è una valida misura di sicurezza, perché CSRF contare su manipolato i link che puntano a pagine protette (che attaccato utente ha privilegi). Utente @Torre è corretto.

    L’unica eccezione è se l’attacco può avvenire all’interno dell’applicazione web che è stato attaccato, ad esempio, con l’iniezione di codice JavaScript malevolo. In questo caso, una verifica dei referer è inutile perché l’attacco proviene da un “sicuro” URL ma così è senza dubbio una soluzione basata su di una sessione o di una volta token, perché il token è a portata di mano il codice JavaScript dannoso e può essere facilmente recuperato.

    Tuttavia, l’utilizzo di una sola volta token è altamente preferibile per proteggere contro questo tipo di attacchi, perché HTTP_REFERER è spogliato fuori da alcune deleghe.

    • Sto assumendo che non voglio che qualcuno sbattere il mio gestore del modulo da un altro url.
    • il modo più adeguato potrebbe essere l’utilizzo di una sessione o di un one-time token che viene impostata in forma, e viene controllato durante l’elaborazione del modulo. (Si memorizzano i token in un database). In questo modo, si potrebbe almeno fare in modo che le persone hanno per richiedere il modulo di prima (se è davvero di aiuto).
    • Awesome risposte. Grazie.
    • Quando un avversario si può iniettare l’esecuzione di javascript nel dominio reale invece che la richiesta di un altro dominio, è CSS, non CSRF. La soluzione è semplice, non permettere alle persone di iniettare codice javascript nella tua pagina.
    • punto di presa, hai ragione.
  3. 3

    Utilizzando una SESSIONE sarà probabilmente la via migliore per evitare cross-site invio di form.

    • Io sto usando quello. Sono così terrorizzata sto cercando di aggiungere come molti failsafe possibile.
    • Avete considerato la possibilità di utilizzo di una qualche forma di captcha?
    • Che sta per essere di livello tre. Vi ringrazio gentilmente per le vostre risposte.
    • Se si sta andando hog wild come quella con più livelli di sicurezza, gettando un HTTP_REFERER correttore nel mix non fa male nulla. Potrebbe essere po ‘ eccessivo, ma se si rende voi o il vostro client di dormire meglio la notte, in modo da essere, giusto? Utilizzando come unica linea di difesa non è la scelta migliore.
    • Esattamente. La cosa divertente è che questa volta il client è in me, e questo mi rende più ansiosi come fosse mia reputazione sulla linea. Non voglio entrare in scena sociale, con l’uovo di tutto il viso.
  4. 3

    Mentre è impossibile spoof un Referer in un altro browser dell’utente, è facile falsificare una mancanza-di-referrer (es. utilizzando un meta refresh), oltre ad alcuni user-agent non l’invio di un Referer a tutti.

    In modo che si permettono mancanti-referente e non a tenuta stagna XSRF protezione, o si richiedono un referente che corrisponde al tuo sito, nel qual caso si prende un grande successo per l’accessibilità. Che colpo potrebbe essere accettabile se l’unica persona che utilizza lo script è si, e sai che dovrai essere sempre utilizzando un browser/firewall/proxy/etc combinazione che passa referrer attraverso affidabile. Ma per qualsiasi cosa ci si aspetta dagli altri, non è generalmente una buona idea.

    Referer è abbastanza debole anti-XSRF meccanismo. Molto meglio utilizzare per utente/evento token rilasciato dal server che deve tornare indietro al server per convalidare la presentazione.

    $query = “SELECT * FROM users DOVE name = ‘$nome'”;

    Potenziale vulnerabilità di tipo SQL injection. Si prega di utilizzare mysql_real_escape_string o query parametrizzata.

    ingresso.setAttribute(‘nome’, ‘add_bar’);

    ingresso.setAttribute(‘value’, “);

    Non utilizzare setAttribute degli attributi HTML. Ci sono bug in IE che smettere di lavorare, in alcuni casi, e ci sono alcuni attributi che non fai quello che ti pare. Per esempio, impostando il value attributo è non la stessa impostazione del value proprietà. La proprietà contiene il valore corrente del campo modulo; l’attributo contiene solo il ‘valore di default’ del campo, a cui verrà resettato se un <input type="reset"> è utilizzato. Questa mappa l’ defaultValue proprietà. In alcuni browser, impostazione del valore predefinito consente anche di impostare il valore, ma questo non è standard e non essere oggetto di affidamento.

    Utilizzare il DOM Level 1 di proprietà HTML, sono entrambi più leggibile e più affidabile:

    input.name= 'add_bar';
    input.value= <?php echo json_encode(generate_session_token(), JSON_HEX_TAG); ?>;

    Utilizzare json_encode per creare valori per JavaScript letterali. Anche se si può essere certi che la somma MD5 non contenere caratteri speciali per JS come ' o \, o il </ sequenza che termina un <script> blocco (contro il quale il HEX_TAG argomento protegge), non è l’output del modello di lavoro di sapere che cosa il token di sessione può contenere. Questo è un modo sicuro per uscita qualsiasi stringa in un <script> blocco.

    Vedere questa domanda per un approccio alla generazione di anti-XSRF token che non richiede di token di archiviazione in sessione o database.

    • Va notato che XSS ignora token basato xsrf di protezione così come referer di controllo. Puoi dirci come un approccio è più debole di un altro?
  5. 2

    Sì, è sicuro

    Purtroppo, la santo testo incoraggia a fornire un’opzione per disattivare il referrer (ma ancora non si può inventare il proprio meccanismo di cosa un referente); così, infatti, qualcuno potrebbe disattivare referenti sul suo browser, così se stesso negando l’accesso al tuo sito.

    La tua soluzione è sicuro, ma gli utenti possono legittimamente lamentarsi se il sito funziona solo con i referenti abilitati.

    Questo è molto triste, perché significa che ora che non c’è sane modo per garantire che il vostro sito non è protetto contro CSRF.

    Alternativa

    L’unica cosa che si può davvero fare è mettere un nonce in ogni richiesta di autenticazione per il servizio web. Questo, però, è un po ‘ pericoloso, perché è necessario assicurarsi ogni richiesta point sul proprio servizio web convalida il nonce. Tuttavia, è possibile utilizzare un framework per fare questo per voi, per un po ‘ migitate questo fastidio. Stack Overflow di per sé sembra essere utilizzando nonces.

    Tuttavia

    Referenti in linea di principio sono un po ‘ più sicuro perché si può semplicemente applicare una regola globale che dice di no richiesta può aver luogo solo se il referente è nello stesso dominio. Questo è accettabile se si è disposti a rilasciare gli utenti che disattiva il referrer.

    Contrariamente a quello che sciocchezze dice la gente, qui, è non problema di una richiesta HTTP con un falsificato di intestazione da non privilegiato il codice del browser. Come previsto, Flash è stato in grado di fare questo una volta per bypassare anti-csrf che si basa su referrer, ma è stato patchato. Perché è stato patchato? Perché RFC HTTP determina il referrer è, e pertanto, non è consentito di modificare il significato di esso nel vostro codice cliente, per timore che il tuo client di essere insicuro.

    Qualcuno qui anche affermato che un applet Java possono emettere arbitrario intestazioni su HTTP per altro dominio, ma che semplicemente non è il caso, perché un sandbox Java applet non è consentito effettuare le richieste di nulla, tranne il dominio su cui è stato caricato. Ha rapidamente rimosso il suo commento prima che qualcuno potesse correggere lui…

    Caso

    Un browser web è un client HTTP. Un client HTTP, deve essere conforme alla Rfc di HTTP, quindi ha per aderire a ciò che la RFC stati un referente intestazione dovrebbe essere simile. Dal momento che un browser web è un client HTTP, qualsiasi applicazione embedded in un browser web non deve essere in grado di fare le richieste che violano il protocollo HTTP. Il fatto è che ogni violazione di una norma è un potenziale problema di sicurezza.

    In ogni caso: ci non è modo corretto per determinare il tempo di una richiesta dal proprio dominio o di un avversario di dominio. Questo è solo uno dei tanti tristi difetti del web. È necessario utilizzare uno di questi citati soluzioni alternative.

    • Che assurdità! Dite a voi stessi Flash was able to do this once to bypass anti-csrf that relies on referrer, but it was patched. Così che le persone che stanno utilizzando la versione senza patch? È chiaro che non capire di che cosa stiamo dicendo. QUALSIASI RICHIESTA PUÒ ESSERE FORGIATO. L’effettivo pacchetti TCP potrebbe essere manipolato… poi cosa?
    • NON. Flash è noto per il flusso costante di critiche falle di sicurezza. E il resto di quello che hai detto è irrilevante.
    • il falso problema è meno rilevante che il fatto che alcuni proxy (o all’impazzata configurato browser) rimuoverà tutti i referrer, come BalusC notare in un commento sulla questione. Quindi, se si domanda a un certo referer, si potrebbe bloccare gli utenti legittimi, come pure.
    • Non pensi che alcune persone non aggiornare il loro software? Qual è il tuo sogno terra vivi in? In teoria è sicuro, in pratica, se è così importante, allora non ci dovrebbero essere ulteriori modalità per la protezione, vale a dire utilizzare un SESSION e un unico auth_token in forma.
    • L, la maggior parte dei browser è scritto in C, e avere l’occasionale smash stack vulnerabilità e se non, semantica vulnerabilità. Utilizzando referrer è altrettanto sicuro come un token di autenticazione. Jeff è corretto, l’unica cosa brutta che può succedere è che l’utente viene bloccato. È altrettanto probabile che per un browser per rompere referrer regole per il browser, che abbia qualche vulnerabilità.
    • Perché questo downvoted? Senza ragione?

  6. -3

    In realtà, è possibile utilizzare un indirizzo ip dinamico per tale modulo. Come quando vai al modulo da inoltrare lui a una pagina con indirizzo casuale, come http://www.something.com/form.php inoltrata a http://www.something.com/form.php?13mklasdkl34123 dove 13mklasdkl34123 è generato in modo casuale per ogni utente e conservarlo in $_SESSION. Alla ricezione di invio del form, è possibile controllare il referente indirizzo è l’indirizzo che si è generato per l’utente. Riferimento può essere falsificato, ma una dinamica di riferimento non è il spoofer non può sapere l’indirizzo a meno che lui (individualmente) di visitare la pagina del modulo.

    • NON. 1. Referrer essere catturabili non è un problema qui. L’unico problema referrer soluzione è che si nega servizio per alcuni utenti. 2. La tua soluzione è sbagliata. Se lo fai in questo modo, è DEVE generare un nuovo token per tutti richiesta. Questo significa che ogni volta che si carica una pagina, il server memorizza un token corrispondente all’id di sessione, e tutti i link generati dal server hanno il token in loro. Quando si carica una nuova pagina, il processo viene ripetuto. Si non utilizzare lo stesso token per ogni richiesta, o si può essere di proprietà, in diversi modi, come immagini e i riferimenti ad altri siti.
    • correzione al mio precedente commento: in realtà, Ci sono modi per utilizzare un singolo token, ma questo non è uno di loro.

Lascia un commento