Strumenti per sviluppatori · URL codificatore e decodificatore
Doppia codifica URL: come avviene %2520 e come rilevarla e annullarla
· Come funziona
codifica dell'URL javascript flusso di lavoro dello sviluppatore debug
Un %2520 in un URL significa che uno spazio è stato codificato due volte. Questo post spiega gli errori della pipeline che lo causano, come riconoscere la firma e quanti passaggi di decodifica sono sicuri.
Doppia codifica URL: quando %2520 significa che uno spazio è passato attraverso due codificatori
Un nome file che arriva come "my%20file.pdf" invece di "my file.pdf" segnala una doppia codifica: uno spazio è stato codificato in %20, quindi il segno di percentuale stesso è stato codificato in %25, producendo %2520 nel finale URL. Ogni livello di un sistema come codice client, framework web o proxy inverso potrebbe essere codificato una volta. Quando vengono codificati due livelli separati, un singolo carattere viene danneggiato.
La doppia codifica emerge molto spesso in catene di reindirizzamento complesse e sistemi di modelli. Uno sviluppatore potrebbe generare un URL codificato all'interno di un framework che codifica a sua volta tutto l'output per impostazione predefinita. Un proxy inverso o una rete per la distribuzione di contenuti potrebbe ricodificare gli URL già arrivati codificati dal sistema backend. Un parametro contenente un valore già codificato viene nuovamente codificato prima di essere annidato all'interno di un'altra struttura URL.
Perché %25 è la chiave: il segno di percentuale stesso viene codificato, quindi %20 diventa %2520 e %C3%A9 diventa %25C3%25A9
Il segno rivelatore della doppia codifica è che %25 appare dove normalmente ti aspetteresti di vedere un singolo segno di percentuale in URL o nei dati. In un URL con codifica normale, non vedrai mai %25 a meno che non invii il valore letterale "%25". Se uno spazio codificato come %20 viene codificato nuovamente, diventa %2520.
Un carattere accentato come é, che normalmente viene codificato in %C3%A9, diventa %25C3%25A9 se codificato due volte da due sistemi diversi in sequenza. Imparare a individuare il modello %25 nelle barre, nei log e nei messaggi di errore URL fa risparmiare innumerevoli ore di frustrante lavoro di debug negli ambienti di produzione in cui i dati scorrono attraverso più servizi.
Dove viene introdotta la doppia codifica: codice client più framework, reindirizzamenti, proxy e helper di modelli
La doppia codifica distrugge sia la leggibilità che la capacità dei sistemi lato server di analizzare correttamente URL. Un file denominato "my file.pdf" diventa "my%20file.pdf" se codificato correttamente. Se la stringa codificata viene ricodificata, magari tramite un modulo, diventa "my%2520file.pdf".
Quando il server lo riceve e lo decodifica una volta, vede "my%20file.pdf" come nome file letterale anziché riconoscerlo come "my file.pdf". Qualsiasi applicazione che prevede di ricevere solo un singolo passaggio di decodifica riceverà un risultato alterato. Ancora peggio, uno sviluppatore che decodifica due volte per risolvere problemi su valori codificati solo una volta corromperà effettivamente i dati legittimi con il passaggio di decodifica aggiuntivo.
Esempio pratico: decodificare un URL doppiamente codificato un passaggio alla volta: cosa rivela ciascun passaggio e quando interrompere
Il codice JavaScript lato client e le impostazioni predefinite del framework lato server sono le fonti più comuni di doppia codifica accidentale nei sistemi di produzione. Un'applicazione JavaScript potrebbe utilizzare encodeURIComponent su un valore, quindi passarlo direttamente a un framework che codifica tutte le stringhe di output per impostazione predefinita, codificando così il segno di percentuale una seconda volta. Un livello proxy inverso inteso a disinfettare gli URL potrebbe ricodificare i parametri già precodificati dall'applicazione backend.
Un reindirizzamento URL creato concatenando l'input fornito dall'utente con una funzione di supporto del framework può codificare in entrambi i passaggi contemporaneamente. Esempio realizzato: un utente invia "test&value" tramite il modulo HTML, il browser lo codifica come "test%26value". Il framework vede il testo percentuale letterale e lo codifica, producendo "test%2526value". Una decodifica fornisce "test%26value", ancora sbagliato.
Quando la doppia codifica è intenzionale: un URL trasportato all'interno del parametro di query di un altro URL
La doppia codifica deliberatamente è valida in un caso specifico: quando un URL deve viaggiare all'interno del parametro di query di un altro URL. I flussi OAuth e i collegamenti di ritorno all'accesso a volte richiedono l'annidamento di un URL completo all'interno di un altro. Il URL interno deve essere prima codificato completamente in percentuale, quindi l'intera stringa codificata deve essere codificata nuovamente come valore di parametro per il URL esterno.
Questa doppia codifica è voluta e assolutamente necessaria in questi casi. Il parser del parametro esterno decodifica una volta, producendo il URL interno ancora codificato. Il sistema interno quindi decodifica nuovamente, recuperando il URL originale. La chiave fondamentale è comprendere l'intento e documentarlo chiaramente nei commenti del codice per i futuri manutentori.
Errori comuni: decodifica fino a quando non cambia nulla, che corrompe i valori che contengono legittimamente %25
L'errore classico e pericoloso è decodificare ripetutamente finché non cambia nulla, il che corromperebbe i valori che contengono legittimamente i segni di percentuale nei dati effettivi. Un parametro come "sconto%2525" (che rappresenta un valore letterale "%25" codificato come valore di parametro, quindi codificato nuovamente per il trasporto) è completamente corretto in base alla progettazione. Decodificandolo una volta si ottiene "sconto%25", che è ancora corretto. Decodificandolo una seconda volta si ottiene "sconto%", che è sbagliato e perde informazioni.
Uno sviluppatore potrebbe presumere che "%25" sia un errore e decodificarlo ripetutamente, perdendo il segno di percentuale. Decodifica invece esattamente quante volte richiede la tua architettura: una volta per un parametro, due volte nidificate. Conta i livelli per conoscere le giuste operazioni di decodifica.
Cosa non copre: codifica dell'entità HTML sovrapposta agli URL, gestita dall'escape dell'entità HTML
Gli errori comuni includono la codifica di un intero URL con encodeURIComponent e quindi l'aspettativa che barre e due punti funzionino come delimitatori strutturali, cosa che non possono dopo la codifica. Un altro errore frequente è mescolare diversi standard di codifica: alcuni codici utilizzano la codifica percentuale per RFC 3986 e altri codici utilizzano la codifica dei moduli con segni più che rappresentano gli spazi. Un valore come "mio+file" diventa veramente ambiguo: potrebbe significare "il mio file" o potrebbe significare il testo letterale "mio+file" con un segno più.
Se la codifica percentuale tocca prima "mio+file", diventa "mio%2Bfile". Se segue la decodifica del modulo, aspettandosi più come spazio, rimane sbagliato. La coerenza tra i livelli è essenziale. Ogni sistema deve utilizzare lo stesso standard di codifica oppure ogni livello deve essere documentato esplicitamente.
Conclusione: codifica esattamente una volta per livello: come il codificatore e decodificatore URL ti consente di decodificare un passaggio alla volta e vedere ogni risultato intermedio
Una volta identificata con successo la doppia codifica che si verifica nei sistemi di produzione, la correzione dipende interamente da dove si verifica la duplicazione nella pipeline. Se vengono codificati sia il codice client che un framework, rimuovere completamente la codifica da uno di essi. Se un parametro viaggia attraverso più servizi backend, traccia il percorso completo attraverso ciascun servizio e trova quale servizio sta codificando quando non dovrebbe farlo.
Testa attentamente la correzione passando i dati di esempio attraverso la pipeline end-to-end completa e verifica che i dati arrivino completamente invariati a destinazione. Documentare chiaramente il presupposto della codifica a ciascun limite: "questo endpoint restituisce parametri codificati in percentuale" o "questo middleware si aspetta UTF-8 non elaborato e vi applica la codifica". Includere il numero di passaggi di decodifica previsti nella documentazione per i futuri sviluppatori.