Az URL egyetlen szövegsornak látszik, de a böngésző, proxy és szerver strukturált címként értelmezi. Meghatározza a kommunikáció módját, a hálózati célt, az erőforrás útvonalát, a nézet paramétereit és néha a dokumentumon belüli pozíciót. Ha az alkalmazás egyszerű string-összefűzéssel készít URL-t, adatot és szintaxist kever össze. Megbízható rendszer komponensekkel, parserrel és builderrel dolgozik.
A séma az első értelmezési szabály
A https biztonságos HTTP kapcsolatot kér. Más sémák levelezőklienst, helyi fájlt vagy alkalmazást nyithatnak meg. Tetszőleges, felhasználó által megadott séma engedélyezése ezért nem pusztán formázási kérdés.
A policy csak az adott kontextushoz szükséges sémákat fogadja el. Egy kommentben szereplő linknek rendszerint HTTP és HTTPS elegendő.
Az authority a hálózati célt írja le
A két perjel utáni rész hostot, portot és történelmileg user infot tartalmazhat. A domén címkéit jobbról balra kell értelmezni. Az example.com.attacker.test nem az example.com része.
Allowlist normalizált hostot és teljes labeleket hasonlít. Az IDN kezelés, a pont a végén és a port külön figyelmet igényel.
Az útvonal nyilvános routing szerződés
A path perjellel elválasztott szegmensekből áll. Egy dinamikus szegmens nem azonos a teljes útvonallal. Ha az érték perjelet tartalmaz, külön kell kódolni, különben a router több részre bontja.
A pontszegmensek, ismételt perjelek és trailing slash normalizálását a proxy és az alkalmazás azonos elv szerint végezze. Ellenkező esetben a security layer mást engedélyezhet, mint amit a backend kiszolgál.
A query paramétereket és nézetállapotot hordoz
A kérdőjel utáni rész szűrést, rendezést, oldalszámot vagy keresést írhat le. Egy név többször is előfordulhat, és a parserek eltérően választhatják az elsőt, utolsót vagy tömböt.
A form-urlencoded szabály a pluszt szóközzé alakítja, az általános URL-szintaxis nem feltétlenül. A framework után végzett újabb kézi decode gyakori hiba.
A fragment többnyire a kliensnél marad
A # utáni rész szakaszt vagy kliensállapotot jelöl. Normál HTTP kérésben nem jut el a szerverhez. A backend nem várhat ott tokent, hacsak a frontend külön át nem küldi.
A fragment a böngészési előzményben és a felhasználó által másolt linkben továbbra is megjelenhet. Érzékeny adatnak ez sem jó hely.
A percent encoding választja el az adatot a szintaxistól
A karakter először bájtokká, általában UTF-8-cá alakul, majd a kiválasztott bájtok százalék és két hex szám formát kapnak. A megengedett jelek komponensenként eltérnek.
A dinamikus értéket a strukturális elválasztók hozzáadása előtt kell kódolni. A teljes URL egyben történő escape-elése a kettőspontot, perjeleket és kérdőjelet is adatként kezelné.
A relatív cím megbízható alapot igényel
A ../login vagy ?page=2 csak base URL-lel együtt kap teljes jelentést. Server-side fetchnél a feloldott abszolút célt kell ellenőrizni, nem csak az eredeti szöveget.
SSRF-védelemnél a DNS-feloldás, belső IP-tartomány, redirect és újbóli feloldás is számít. A host szintaktikai helyessége önmagában nem elég.
Az URL nem titoktároló
A cím bekerülhet historyba, proxy- és alkalmazáslogba, analitikába, screenshotba és Referer fejlécbe. A HTTPS a hálózati utat védi, ezeket a legitim másolatokat nem szünteti meg.
Jelszó és hosszú életű bearer token ne kerüljön querybe. Az egyszer használatos reset link rövid lejáratot, nagy entrópiát, szűk célt és felhasználás utáni érvénytelenítést igényel.
Az abszolút link függ a proxybeállítástól
Load balancer mögött az alkalmazás forwarded fejlécekből olvashat sémát és hostot. Ha közvetlen kliensértéket is megbízhatónak tekint, támadó befolyásolhatja a reset linket vagy redirectet.
Trusted proxy lista és konfigurált public base URL szükséges. Az integrációs teszt a valódi TLS termination útvonalon fusson végig.
A normalizálás biztonsági politika
A host kisbetűsítése, default port elhagyása és pontszegmensek kezelése kanonikus alakot adhat. A normalizálásnak azonban az ellenőrzés előtt, egyetlen közös helyen kell megtörténnie.
Routing, cache, aláírás és authorization ugyanazt a strukturált címet használja. Az eredeti request target auditcélból megőrizhető, de ne legyen második konkurens identitás.
A hosszkorlát minden réteget véd
Rendkívül hosszú URL vagy paraméterek ezrei már a business logika előtt terhelik a CDN-t, parsert és naplózást. A rétegek egymással összehangolt limitet alkalmazzanak.
A hiba legyen kiszámítható, és ne másolja a teljes támadó inputot a logba. A limit a publikus szerződés része.
Az URL felhasználói felület is
Az olvasható cím megosztáskor, supportban és incidensnél kontextust ad. A stabil útvonal túléli a redesign-t és a külső hivatkozásokat.
Az URL ezért nyilvános termékarchitektúra, nem csak routerrészlet. A parser, builder és közösen dokumentált szabályok teszik megbízható címmé emberek és gépek számára.
Az IDN és a látható host külön vizsgálatot kér
A nemzetközi doménnevek Unicode karaktereket használhatnak, a hálózati forma pedig Punycode lehet. Két vizuálisan hasonló betű eltérő írásrendszerből származhat, ami megtévesztő linket eredményez. A böngésző saját megjelenítési szabálya nem helyettesíti az alkalmazás allowlistjét.
A biztonsági összehasonlítás normalizált ASCII hoston, teljes labelekkel történjen. A felhasználói felület külön jelezheti a tényleges célt, különösen redirect, OAuth callback és webhook konfiguráció esetén.
A cache kulcs ugyanazt a kanonikus címet használja
Ha a CDN másképp kezeli a paramétersorrendet, default portot vagy trailing slasht, mint az alkalmazás, ugyanaz a tartalom több kulcson tárolódhat, vagy eltérő válaszok ütközhetnek. Authorizationtól függő query paramétert a cache policynek is értenie kell.
A kanonizálás szabályát az edge és origin együtt tesztelje. A cache nem támaszkodhat olyan normalizált alakra, amelyet az alkalmazás később más erőforrásként értelmez.