URL kodér / dekodér

Převeďte libovolný text na procentuální kódování bezpečné pro URL okamžitě. Náš nástroj zvládá mezery, speciální znaky, Unicode a emodži.

Vyberte si mezi:

• kódováním komponent (pro hodnoty dotazů)
• kódováním URI (zachování struktury URL)
• kódováním dat formuláře (+ pro mezery)

Dekódujte libovolnou URL kódovanou v procentech zpět na čitelný text. Vložte zakódované URL adresy, řetězce dotazů nebo jednotlivé parametry a okamžitě uviděte původní text.

Zpracovává:

• sekvence %HH
• plus jako mezera
• vícebajtové znaky UTF-8

Kódování URL funguje tak, že nahradí jakýkoli znak, který je v URL nebezpečný nebo vyhrazený, znakem procenta následovaným dvěma šestnáctkovými číslicemi představujícími hodnotu bajtu tohoto znaku, což je schéma formálně definované v RFC 3986 komisí IETF.

Mezera se stane %20, ampersand se stane %26 a lomítko se stane %2F. Ne-ASCII znaky se nejprve převedou na svou bajtovou sekvenci UTF-8 a poté se každý bajt zakóduje v procentech, takže písmeno „é“ se stane %C3%A9.

Podle dokumentace MDN Web Docs to prohlížeče aplikují automaticky prostřednictvím funkcí jako encodeURIComponent. Nedotčeny zůstávají pouze nevyhrazené znaky (A-Z, a-z, 0-9, spojovník, podtržítko, tečka, vlnovka).

encodeURI zakóduje kompletní URL při zachování vyhrazených strukturálních znaků, zatímco encodeURIComponent zakóduje jednu komponentu a escapuje také tyto strukturální znaky.

Jak dokumentuje MDN Web Docs, encodeURI ponechává :, /, ?, #, &, a = nedotčené, takže celá adresa zůstává funkční, což je správné pro úplné URL adresy. encodeURIComponent escapuje vše kromě nevyhrazené sady RFC 3986, takže je správnou volbou pro hodnoty parametrů dotazu, segmenty cesty nebo text fragmentu, který může obsahovat vyhrazené znaky.

Použití encodeURI tam, kde je vyžadován encodeURIComponent, je častou chybou: nezakódovaný & uvnitř hodnoty bude chybně přečten jako oddělovač parametrů, čímž tiše dojde k poškození požadavku.

RFC 3986 dělí znaky URL na nevyhrazené a vyhrazené sady a toto rozlišení určuje, co se zakóduje v procentech.

• Nevyhrazené znaky jsou písmena A-Z a a-z, číslice 0-9 a čtyři symboly: spojovník, podtržítko, tečka a vlnovka; ty nevyžadují kódování.
• Vyhrazené znaky zahrnují obecné oddělovače : / ? # [ ] @ a dílčí oddělovače ! $ & ' ( ) * + , ; =, které nesou syntaktický význam.

Podle specifikace IETF se vyhrazené znaky mohou objevit nezakódované, když slouží jako oddělovače, ale musí být zakódovány v procentech, pokud se používají doslovně uvnitř komponenty. Všechno mimo obě sady, včetně mezer a Unicode, by mělo být vždy zakódováno.

URL používá %20 pro mezery, protože znak mezery nesmí v URI podle RFC 3986 objevovat doslovně, takže je zakódován pomocí procenta (percent-encoding) na svou bajtovou hodnotu v ASCII, hexadecimálně 20.

Existuje druhá konvence: v datech application/x-www-form-urlencoded, což je formát používaný odesíláním formulářů HTML a mnoha řetězci dotazů, se mezera kóduje jako znaménko plus (+) namísto %20, jak určuje standard URL od WHATWG a specifikace formulářů W3C.

Proto dekodéry musí znát svůj kontext. %20 je univerzálně bezpečné v cestě, dotazu a fragmentu, zatímco + znamená mezeru pouze uvnitř formulářově kódovaných dat dotazu a jinde jde o doslovné plus.

Kódování URL zpracovává Unicode tak, že nejprve převede každý znak na jeho bajtovou sekvenci UTF-8 a poté zakóduje každý jednotlivý bajt pomocí procent. Konsorcium Unicode definuje body kódu a UTF-8 (specifikované v RFC 3629) je mapuje na jeden až čtyři bajty.

Například:

• Jednobajtový znak ASCII jako 'A' zůstává jako 'A'
• 'é' se kóduje jako %C3%A9
• znak CJK '日' se mění na %E6%97%A5
• emotikon jako 😀 se kóduje do čtyř bajtů, %F0%9F%98%80

MDN Web Docs uvádí, že funkce encodeURIComponent v JavaScriptu pracuje s UTF-8 ve výchozím nastavení. Dekodéry to obracejí tak, že shromažďují bajty kódované pomocí procent a interpretují je zpět jako proud UTF-8, aby získaly původní text.

Dvojité kódování nastane, když je již jednou procentuálně zakódovaný řetězec zakódován znovu, čímž se každé % změní na %25, takže se z %20 stane %2520 a hodnotu již nelze správně přečíst.

To je častý zdroj nefunkčních odkazů a podle OWASP také bezpečnostní problém, protože útočníci používají dvojité kódování k prostrčení škodlivého vstupu přes filtry, které dešifrují pouze jednou.

Abyste tomu předešli, zakódujte hodnotu přesně jednou v okamžiku, kdy vstupuje do URL, a nikdy znovu nekódujte data, která pocházejí z jiného zakódovaného zdroje. Pokud si nejste jisti, zda je řetězec již zakódován, nejprve jej dekódujte; pokud se výstup změní a vypadá čitelně, byl zakódován a neměli byste jej kódovat znovu.

Kódování URL není bezpečné a neposkytuje žádnou důvěrnost; jde o vratnou transformaci pro zajištění bezpečnosti při přenosu, nikoliv o šifrování. Kdokoli může okamžitě dekódovat řetězec zakódovaný procenty, takže citlivá data umístěná v URL zůstávají plně čitelná a, jak varuje OWASP, jsou také vystavena v historii prohlížeče, protokolech serveru a hlavičkách Referer.

Kódování pouze zajišťuje, že speciální znaky nenaruší syntaxi URL. Šifrování naproti tomu používá klíč a algoritmy jako AES (standardizované NIST) k tomu, aby byla data bez tohoto klíče nečitelná.

Správné bezpečnostní použití kódování je kombibováno se správným escapováním výstupu, aby se zabránilo útokům injektáže; nikdy jej nepoužívejte jako způsob utajení nebo ochrany informací.

Chcete-li řetězec dotazu kódovat správně, použijte encodeURIComponent na každý klíč a hodnotu parametru zvlášť před jejich spojením pomocí & a =, namísto kódování celého složeného řetězce najednou.

To zajišťuje, že vyhrazené znaky uvnitř hodnoty, jako je & nebo = ve vstupu uživatele, jsou escapovány na %26 a %3D, takže si je nelze splést s oddělovači, podle pravidel application/x-www-form-urlencoded popsaných standardem URL od WHATWG. Například hodnota 'hello world&x=1' se musí změnit na 'hello%20world%26x%3D1'.

Podle MDN Web Docs toto rozhraní URLSearchParams automatizují bezpečně. Data poskytnutá uživatelem vždy před vložením do řetězce dotazu zakódujte, abyste zabránili injektáži parametrů a chybnému formátování požadavků.

Nejčastější chybou kódování URL je volba špatné funkce: použití encodeURI na hodnotu dotazu ponechává &, = a ? neescapované, což umožňuje uživatelskému vstupu poškodit strukturu URL.

Mezi další časté chyby, z nichž některé označily OWASP a MDN Web Docs, patří:

• dvojité kódování hodnoty, takže se z %20 stane %2520
• zapomenutí, že + znamená mezeru pouze v datech kódovaných ve formuláři
• kódování celého URL až po jeho sestavení namísto kódování každé součásti předem

Vývojáři také nesprávně zacházejí s UTF-8 tím, že dekódují bajty jako Latin-1, což u textů s diakritikou a ne-latinských textů vytváří zkomolený text (mojibake). Nakonec se nikdy spoléhejte na kódování kvůli bezpečnosti; opomenutí escapování výstupu pro cílový kontext ponechává zranitelnosti vůči injektáži otevřené navzdory platnému kódování pomocí procent.