streamalism.org

1. Bemutatkozás

Amikor webes szolgáltatásokat fejlesztünk, szükségünk lehet összetett vagy váratlan URL-útvonalakra, amelyek perjeleket tartalmazhatnak. Ennek következtében problémákba ütközhetünk az általunk használt webszerverekkel vagy keretrendszerekkel kapcsolatban.

A tavasz kifejezetten kissé bonyolult lehet ebben a tekintetben az általa biztosított alapértelmezett konfigurációk miatt.

Ebben az oktatóanyagban tavasszal bemutatunk néhány általános megoldást és ajánlást a perjelekkel ellátott URL-ek kezelésére. Meglátjuk azt is, hogy miért ne használhatnánk néhány gyakori feltörést ezeknek a problémáknak a megoldására. Olvassa tovább, hogy többet tudjon meg róla!

2. A kérelem kézi elemzése

Webszolgáltatásainkban időnként fel kell térképeznünk az összes kérelmet egy adott elérési út alatt ugyanahhoz a végponthoz. A helyzetet tovább rontja, hogy nem tudjuk, hogy fog kinézni az út további része. Előfordulhat, hogy ezt az utat valamilyen formában meg kell kapnunk paraméterként, hogy utólag használhassuk.

Tegyük fel, hogy kérelmeket fogadhatunk bármilyen útvonal alatt / mypaths:

// localhost: 8080 / mypaths / any / custom / path

Tegyük fel, hogy ezeket a különböző útvonalakat egy adatbázisban szeretnénk tárolni, hogy tudjuk, milyen kéréseket kapunk.

Az első megoldás, amely valószínűleg eszünkbe jut, az, hogy az út dinamikus részét befogjuk a PathVariable:

@GetMapping ("mypaths / {bármi}") public String pathVariable (@PathVariable ("bármi") String bármi) {return anything; }

Sajnos ezt hamarosan megtudjuk ez adja vissza a 404 ha a PathVariable perjelet tartalmaz. A perjel az URI szabványos útvonalhatároló, és minden utána következő új szintnek számít az elérési út hierarchiájában. Ahogy az várható volt, Spring követi ezt a szabványt.

Könnyen megtehetjük oldja meg ezt úgy, hogy egy bizonyos útvonalon található összes kéréshez tartalékot hoz létre a ** helyettesítő karakter:

@GetMapping ("all / **") public String allDirectories (HttpServletRequest kérés) {return request.getRequestURI () .split (request.getContextPath () + "/ all /") [1]; }

Ezután magunknak kell elemeznünk az URI-t annak érdekében, hogy megkapjuk az út azon részét, amely érdekel.

Ez a megoldás nagyon kényelmes, ha URL-szerű paraméterekkel dolgozik, de amint a következő szakaszban látni fogjuk, ez más esetekhez nem elegendő.

3. Használja a Lekérdezési paramétereket

Korábbi példánkkal ellentétben vannak más esetek, amikor nemcsak feltérképezzük a különböző utakat, hanem fogadunk is egyet Húr paraméterként az URL-ben.

Képzeljük el, hogy az előző példánkban elkészítjük kérelem útvonalparaméterrel, amely egymást követő perjeleket tartalmaz:

//localhost:8080/all///myurl.com

Eleinte azt gondolhattuk, hogy ennek működnie kell, de hamar rájövünk, hogy a kontrollerünk visszatér http: /myurl.com. Ez azért történik, mert A Spring Security normalizálja az URL-eket, és minden kettős perjelet egyetlenre cserél.

A tavasz az URL-ek más szekvenciáit is normalizálja, például az utak bejárását. Ezeket az óvintézkedéseket veszi figyelembe megakadályozza, hogy a rosszindulatú URL-ek megkerüljék a meghatározott biztonsági megszorításokat, amint azt a hivatalos tavaszi biztonsági dokumentáció is elmagyarázta.

Ezekben az esetekben erősen ajánlott a lekérdezési paraméterek használata:

@GetMapping ("all") public String queryParameter (@RequestParam ("param") String param) {return param; }

Így bármelyiket megkaphatjuk Húr paraméter ezen biztonsági korlátozások nélkül, és webes szolgáltatásunk erőteljesebb és biztonságosabb lesz.

4. Kerülje a megoldásokat

Az általunk bemutatott megoldások néhány változtatást jelenthetnek a leképezések tervezésében. Ez arra késztethet minket, hogy használjunk néhány általános megoldást eredeti végpontjaink működéséhez, amikor perjeleket kapunk az URL-ekbe.

A leggyakoribb megoldás valószínűleg a perjelek kódolása az útvonal-paraméterekben. Azonban, néhány biztonsági rést jelentettek a múltban, és a legtöbb web- és alkalmazáskiszolgáló úgy reagált rá, hogy alapértelmezés szerint nem engedélyezte a kódolt perjeleket. Ennek a viselkedésnek a megváltoztatása csak a megfelelő beállítás megváltoztatásával lehetséges, például a Tomcat-ban.

Mások, mint például az Apache Server, egy kicsit tovább mentek, és bevezettek egy lehetőséget, amely lehetővé teszi a kódolt perjelek dekódolása nélkül, hogy ne értelmezzék őket útvonalhatárolóként. Mindenesetre, ez nem ajánlott, és potenciális biztonsági kockázatokat jelenthet.

Másrészt a webes keretrendszerek bizonyos óvintézkedéseket is megtesznek. Amint azt korábban láttuk, Spring hozzáad bizonyos mechanizmusokat, amelyek védelmet nyújtanak a kevésbé szigorú szervlet konténerek ellen. Tehát, ha kódolt perjeleket engedélyezünk a szerverünkön, tavasszal még engedélyeznünk kell őket.

Végül vannak másféle megoldások is, mint például a Spring alapértelmezés szerint az URI normalizálásának megváltoztatása. Mint korábban, nagyon óvatosnak kell lennünk, ha megváltoztatjuk ezeket az alapértelmezéseket.

5. Következtetés

Ebben a rövid cikkben bemutattunk néhány megoldást az URL-ek tavaszi perjelének kezelésére. Bevezettünk néhány biztonsági problémát is, amelyek felmerülhetnek, ha megváltoztatjuk a kiszolgálók vagy keretrendszerek alapértelmezett konfigurációit, mint például a Spring.

Alapszabályként a lekérdezési paraméterek jelentik a legjobb megoldást az URL-ek perjelének kezelésére.

Mint mindig, a példák teljes forráskódja elérhető a GitHubon.