Strumenti per sviluppatori · URL codificatore e decodificatore
La codifica URL non è una sanificazione: i parametri decodificati devono comunque essere sottoposti a escape
· Perché è importante
codifica dell'URL sicurezza xss
La codifica percentuale protegge la struttura URL, non HTML, SQL o shell. Questo post spiega perché un valore codificato correttamente diventa di nuovo pericoloso nel momento in cui viene decodificato e quale escape appartiene a dove.
Perché la codifica URL da sola non può fermare gli attacchi XSS
Un parametro "sicuro" può eseguire script se codificato per la trasmissione ma decodificato prima del rendering. Considera il payload XSS come il tag img con il gestore onerror codificato in percentuale come %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E. Se questo viaggia in URL e decodificato dal codice dell'applicazione prima di essere inserito in HTML, il browser vede il markup originale ed esegue il gestore. La codifica percentuale è il livello di rappresentazione; non cambia la minaccia sottostante.
Il payload è sicuro solo durante la trasmissione, quando è una stringa codificata senza significato speciale per il parser HTTP o URL. Nel momento in cui viene decodificato, diventa di nuovo pericoloso perché ritorna alla forma originale. Ogni contesto downstream deve applicare le proprie regole di escape adeguate al modo in cui utilizzerà i dati. La codifica URL non sostituisce l'escape HTML, la parametrizzazione SQL o la gestione degli argomenti della shell.
A cosa serve la codifica percentuale: mantenere i delimitatori inequivocabili sul cavo, niente di più
Ciò che fa la codifica percentuale è proteggere con precisione la struttura URL. La e commerciale rimane parte della sintassi della stringa di query, non reinterpretata come delimitatore. La barra non diventa separatore di percorso. Il punto interrogativo non inizia il frammento. Codificando i caratteri riservati come %XX, il parser li tratta come dati, non come sintassi. Funziona per un compito: mantenere la struttura URL inequivocabile sul cavo.
La decodifica inverte esattamente quella strada a senso unico. I byte ripristinati sono esattamente ciò che è stato codificato, niente di più e niente di meno. La stringa HTML-dangerous rimane pericolosa, il vettore SQL-injection rimane pericoloso e il comando shell rimane pericoloso. La codifica percentuale non è una convalida dell'input, né una sanificazione, né un limite di sicurezza. È solo un formato di rappresentazione.
La decodifica ripristina i byte originali, quindi ogni contesto downstream vede nuovamente il valore grezzo
La fuga specifica per il contesto è il luogo in cui la vera protezione esiste davvero. Il contesto HTML necessita di entità: minore di diventa <, maggiore di diventa >, le virgolette diventano ", la e commerciale diventa &. Il contesto SQL necessita di query parametrizzate che separano la struttura dai dati, impedendo a un utente malintenzionato di uscire. Il contesto della shell necessita di array di argomenti che evitino completamente la suddivisione delle parole e il globbing.
Ogni contesto ha caratteri pericolosi diversi e regole di fuga diverse appunto. L'entità HTML è innocua nella query SQL ma inutile per la protezione lì. La barra rovesciata impedisce l'inserimento di SQL in alcuni database ma non in altri. L'escape della shell dipende dallo stile di quotazione. Lo sviluppatore deve comprendere la destinazione prima di scegliere come gestire i dati.
Escape specifico del contesto: entità HTML per markup, query con parametri per SQL, array di argomenti per shell
Esempio funzionante: seguire il payload dal collegamento al registro alla pagina rivela dove devono avvenire la codifica e l'escape. Il collegamento contiene il payload XSS codificato come parametro di query. Il server lo riceve ancora codificato nel corpo della richiesta HTTP. L'applicazione decodifica il parametro di query per visualizzarlo nella pagina. Senza l'escape dell'output, il browser esegue il rendering del payload come HTML e lo esegue.
Se lo stesso parametro viene registrato nel file, la voce di registro contiene chiaramente il payload decodificato. La seconda applicazione legge il registro, lo decodifica di nuovo, lo inserisce nella pagina HTML senza eseguire l'escape. Il payload viene eseguito la seconda volta. Ad ogni passaggio, il contesto determinava ciò che era sicuro. La decodifica URL era sicura. L'archiviazione dei file era sicura. Ma l'output di HTML senza scappare è stato fatale.
Esempio pratico: seguire un payload dal collegamento al registro alla pagina: dove è codificato, dove è decodificato, dove deve essere eseguito l'escape
La codifica come strumento di evasione del filtro mostra perché gli aggressori effettuano una doppia codifica e mescolano in modo significativo il caso esadecimale. Se il firewall cerca il tag img, l'utente malintenzionato invia %3Cimg e spera che l'applicazione venga decodificato una volta, ma il firewall non lo fa. Se la convalida rifiuta %3Cimg ma consente casi diversi, gli stessi byte vengono decodificati nello stesso payload. La sicurezza che dipende dall'input codificato di corrispondenza dei modelli è fragile.
La decodifica deve essere assolutamente esatta e prevedibile. La forma canonica (minuscolo esadecimale, codifica nota) consente una politica coerente ma non risolve il problema sottostante. L'unico approccio affidabile è consentire la decodifica ove necessario e applicare l'output specifico del contesto immediatamente prima dell'uso. La decodifica non è mai sicura; necessario solo per la trasmissione.
Codifica come strumento di elusione dei filtri: perché gli aggressori effettuano una doppia codifica e mescolano caratteri esadecimali e perché la decodifica deve essere esatta
La difesa completa XSS richiede la comprensione completa dei flussi di dati, dei contesti che attraversa in ogni passaggio, di ciò di cui ha bisogno ogni contesto per sfuggire. La codifica URL è un piccolo pezzo: preserva la struttura solo durante la trasmissione. Ma un pezzo non è mai una difesa da sola. Molti sviluppatori confondono la codifica con la sanificazione perché entrambe implicano la sostituzione di caratteri, ma svolgono compiti importanti completamente diversi.
Web Application Firewall è in grado di rilevare modelli nei payload delle richieste, ma la codifica elude facilmente le semplici tecniche di corrispondenza dei modelli. L'ottimizzazione di WAF è complessa e va oltre la codifica di URL. Una difesa affidabile è l'escape dell'output nel codice dell'applicazione, abbinato alla convalida dell'input laddove ha senso per il contesto e i requisiti specifici.
Ciò che questo non copre: una guida completa alla difesa XSS o l'ottimizzazione del firewall delle applicazioni web
La difesa completa XSS richiede la comprensione completa dei flussi di dati, dei contesti che attraversa in ogni passaggio, di ciò di cui ha bisogno ogni contesto per sfuggire all'intera applicazione. La codifica URL è un piccolo pezzo: preserva la struttura solo durante la trasmissione. Ma un pezzo non è mai una difesa da sola. Molti sviluppatori confondono la codifica con la sanificazione perché entrambe implicano la sostituzione dei personaggi, ma svolgono compiti importanti completamente diversi durante lo sviluppo.
Testa il payload end-to-end per vedere dove la codifica e l'escape contano veramente durante l'intero processo. Incolla %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E nel decodificatore URL e guarda diventare una stringa simile al markup. Quindi incolla il risultato nell'escape dell'entità HTML per vedere come diventa testo sicuro. Due strumenti mostrano i livelli chiaramente visibili.
Conclusione: codifica per URL, escape per l'output: come il codificatore e decodificatore URL e l'escape di entità HTML si trovano fianco a fianco in un unico prodotto per i due diversi lavori
La conclusione è che la codifica e l'escape sono preoccupazioni separate a livelli diversi assolutamente ovunque. La codifica URL protegge solo la struttura trasmessa. L'escape dell'output protegge il contenuto sottoposto a rendering. Il valore codificato correttamente necessita ancora dell'escape dell'output quando raggiunge HTML. La stringa con escape corretto non necessita mai della codifica URL se non inserita in URL.
Applica sinceramente la giusta difesa al livello giusto. Non fare affidamento sulla codifica URL per fermare gli attacchi XSS. Non fare affidamento sull'escape di HTML per preservare la struttura di URL. Comprendi il tuo flusso di dati e applica la trasformazione appropriata in ogni passaggio. Il codificatore URL ti aiuta a vedere cosa fa la codifica; quindi utilizzare HTML escaper di entità per il passaggio di output.