A Base64URL nem új titkosítási módszer. Ugyanúgy hatbites csoportokra osztja a bájtokat, mint a szabványos Base64. Csak néhány karaktert cserél le, amelyeknek URL-ekben, űrlapokban és fájlnevekben már saját szintaktikai jelentésük van. Ez a kis különbség dönti el, hogy egy router, query parser vagy framework változatlanul továbbítja-e az értéket.

A plusz és a perjel ütközik a webes szintaxissal

A szabványos ábécé + és / jelet használ, a padding pedig =. A perjel útvonalszegmenst választ el, a pluszt form-urlencoded feldolgozás szóközzé alakíthatja, az egyenlőségjel paraméternevet és értéket választ szét.

A percent encoding megvédheti ezeket, de hosszabbá teszi a szöveget és újabb transzformációs réteget hoz létre. A Base64URL a pluszt kötőjelre, a perjelet aláhúzásra cseréli.

A legtöbb tesztérték nem mutatja meg a különbséget

A betűk és számok mindkét ábécében azonos helyen állnak. Sok egyszerű bemenet ezért pontosan ugyanazt a kimenetet adja. Az eltérés csak akkor látszik, amikor valamelyik hatbites érték az utolsó két szimbólumra mutat.

A teszteknek szándékosan elő kell állítaniuk pluszt, perjelet, kötőjelet és aláhúzást, valamint egy- és kétpaddinges bemenetet. Egyetlen ASCII szó nem bizonyít interoperabilitást.

A padding a szöveges identitás része

A hagyományos Base64 rendszerint négy karakter többszörösére egészít. Sok Base64URL protokoll padding nélküli kanonikus alakot kér, mert a hiányzó jelek a hosszból visszaállíthatók.

Azonos bájtoknak így több szöveges alakja lehet. Adatbáziskulcs, cache key vagy aláírt input esetén ez valódi különbség, ezért a producer mindig egyetlen formátumot bocsásson ki.

A JWT a legismertebb Base64URL példa

A JSON Web Token három, ponttal elválasztott szegmensből áll. A header, payload és signature Base64URL formátumú, rendszerint padding nélkül. Így a token jól használható HTTP fejlécben és cookie-ban.

A claims továbbra is olvasható. Bárki dekódolhatja az első két részt. A manipulációt az aláírás jelzi, a titkossághoz külön titkosítási mechanizmus szükséges.

Az aláírás az eredeti karakterekhez kötődik

A JWT aláírás az encoded headerből, egy pontból és az encoded payloadból készül. Ha a verifier dekódolja, átrendezi a JSON mezőket, majd újra serializálja, más szöveget kap. A padding hozzáadása is módosítja az inputot.

Az ellenőrzésnek az eredetileg fogadott szegmenseket kell használnia. A bájtok kanonizálása nem írhatja felül a kriptográfiai bizonyíték részét képező reprezentációt.

Az URL-safe nem jelent secret-safe tulajdonságot

A query paraméterbe tett token bekerülhet böngészési előzménybe, proxy logba, analitikába és Referer fejlécbe. Az ábécé csak a szintaktikai ütközést oldja meg.

Az érzékeny bearer tokent megfelelő fejlécben vagy védett cookie-ban kell továbbítani, rövid élettartammal és logredakcióval. A Base64URL nem ad jogosultságot vagy titkosítást.

Minden URL-réteg máshogy normalizálhat

A CDN, webszerver, framework és router eltérő sorrendben dolgozhatja fel a százalékjeleket és pluszokat. A kliensnél helyes érték az alkalmazásig érve már megváltozhat.

Az integrációs tesztnek a tényleges infrastruktúrán kell végigmennie, és össze kell vetnie az elküldött request targetet, a nyers szerveroldali alakot és a dekóder bemenetét.

A toleráns javítás sérülést rejthet el

Egy adapter lecserélheti a kötőjelet és aláhúzást, majd visszapótolhatja a paddinget. Ez csak akkor helyes, ha előtte szigorúan ellenőrzi az ábécét és a hosszt. Tetszőleges karakterek eldobása kétértelmű parserhez vezet.

Az érvénytelen inputot egyértelmű hibával kell elutasítani. Kompatibilitási normalizáció csak egy dokumentált határon történjen.

A kanonikus alak megelőzi a duplikátumokat

Sikeres validáció után a szolgáltatás egyetlen engedélyezett Base64URL alakot készíthet az általános tároláshoz. Így padded és unpadded input nem hoz létre két cache-bejegyzést vagy adatbázisrekordot.

Az eredeti stringet ott kell megőrizni, ahol aláírás vagy audit része. A rendszer különböztesse meg a dekódolt bájtok azonosságát a fogadott üzenet azonosságától.

A fájlneveknek további korlátaik vannak

A perjel hiánya segít object storage kulcsoknál, de nem oldja meg a maximális hossz, case sensitivity vagy foglalt nevek problémáját. A Base64URL megfelelő ábécé, nem teljes platformfüggetlenségi garancia.

Egy content hash esetén a hosszabb hex alak könnyebben olvasható és diagnosztizálható lehet. A reprezentációt az üzemeltetési környezet alapján kell választani.

A migrációnak számolnia kell a régi kliensekkel

Szabványos Base64-ről Base64URL-re váltáskor a tárolt adatok és SDK-k nem egyszerre változnak. A szerver átmenetileg fogadhat mindkét szigorúan validált alakot, mérheti a használatot, és mindig az új kanonikus formát adhatja vissza.

A helyes változatot a környező protokoll határozza meg. MIME és PEM továbbra is szabványos Base64-et kér, JWT Base64URL-t. Egyik sem kriptográfiailag erősebb; a pontos szerződés teszi őket interoperábilissá.

Az API-séma nevezze meg a változatot

A „Base64 encoded” leírás nem elegendő, ha a mező valójában URL-safe, padding nélküli alakot vár. Az OpenAPI séma, az SDK és a példák ugyanazt a pontos elnevezést használják. A tesztvektoroknak olyan bájtokat is tartalmazniuk kell, amelyek valóban előállítják az eltérő jeleket.

Az, hogy az API HTTPS-en működik, nem dönti el az ábécét. Egy JSON mező teljesen jogosan használhat szabványos Base64-et, miközben egy path paraméter Base64URL-t igényel. A mező szerződése fontosabb, mint a teljes kérés szállítási protokollja.

A cache és az adatbázis kanonikus kulcsot igényel

Ha egy szolgáltatás paddinges és padding nélküli alakot is közvetlenül kulcsként tárol, ugyanaz a bájtsorozat kétszer jelenhet meg. Validáció után az általános identitáshoz egyetlen kanonikus szöveget kell előállítani.

Aláírt protokollnál azonban az eredeti reprezentációt külön meg kell őrizni. Az üzleti azonosság normalizálható, a fogadott kriptográfiai üzenet nem írható át az ellenőrzés előtt.