streamalism.org

1. Úvod

Keď vyvíjame webové služby, možno budeme musieť riešiť zložité alebo neočakávané cesty URL, ktoré môžu obsahovať lomky. V dôsledku toho sa môžeme stretnúť s problémami s webovými servermi alebo štruktúrami, ktoré používame.

Jar môže byť v tomto ohľade trochu komplikovaná kvôli predvoleným konfiguráciám, ktoré poskytuje.

V tomto návode na jar si ukážeme niekoľko bežných riešení a odporúčaní na zaobchádzanie s lomkami na URL. Uvidíme tiež, prečo by sme na riešenie týchto problémov nemali používať niektoré bežné hacky. Čítajte ďalej a dozviete sa o tom viac!

2. Manuálne analyzujte požiadavku

V našich webových službách niekedy musíme mapovať všetky požiadavky pod určitou cestou k rovnakému koncovému bodu. Aby toho nebolo málo, možno nevieme, ako bude vyzerať zvyšok cesty. Možno budeme musieť túto cestu nejako prijať ako parameter, aby sme ju mohli neskôr použiť.

Povedzme, že môžeme prijímať žiadosti s ľubovoľnou cestou pod / moje cesty:

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

A predpokladajme, že chceme všetky tieto rôzne cesty uložiť do databázy, aby sme vedeli, aké požiadavky dostávame.

Prvé riešenie, ktoré nás pravdepodobne napadne, je zachytenie dynamickej časti cesty do a PathVariable:

@GetMapping ("mypaths / {anything}") public String pathVariable (@PathVariable ("anything") String anything) {vrátiť čokoľvek; }

Bohužiaľ to čoskoro zistíme toto vráti a 404 ak PathVariable obsahuje lomku. Symbol lomky je štandardný oddeľovač cesty URI a všetko, čo nasleduje, sa v hierarchii ciest považuje za novú úroveň. Podľa očakávania sa Spring týmto štandardom riadi.

Môžeme ľahko Vyriešte to vytvorením rezervy pre všetky požiadavky v rámci určitej cesty pomocou súboru ** divoká karta:

@GetMapping ("all / **") public String allDirectories (požiadavka HttpServletRequest) {návrat request.getRequestURI () .split (request.getContextPath () + "/ all /") [1]; }

Potom musíme analyzovať URI sami, aby sme sa dostali na tú časť cesty, ktorá nás zaujíma.

Toto riešenie je veľmi výhodné pri práci s parametrami podobnými URL, ale ako uvidíme v nasledujúcej časti, na niektoré ďalšie prípady to nestačí.

3. Použite parametre dotazu

Na rozdiel od nášho predchádzajúceho príkladu existujú ďalšie prípady, keď nielen mapujeme rôzne cesty, ale aj prijímame akékoľvek String ako parameter v adrese URL.

Poďme si predstaviť, že v našom predchádzajúcom príklade robíme požiadavka s parametrom cesty, ktorá obsahuje za sebou nasledujúce lomky:

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

Spočiatku sme si mohli myslieť, že by to malo fungovať, ale čoskoro si uvedomíme, že náš kontrolór sa vráti http: /myurl.com. To sa deje preto Spring Security normalizuje adresy URL a nahradzuje každú lomku jedinou.

Jar tiež normalizuje ďalšie sekvencie v adresách URL, napríklad prechádzanie cesty. Prijíma tieto preventívne opatrenia na zabránenie tomu, aby škodlivé adresy URL obchádzali definované bezpečnostné obmedzenia, ako je vysvetlené v oficiálnej dokumentácii Spring Security.

V týchto prípadoch sa dôrazne odporúča použiť namiesto toho parametre dotazu:

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

Týmto spôsobom môžeme prijať akékoľvek String bez týchto bezpečnostných obmedzení a naša webová služba bude robustnejšia a bezpečnejšia.

4. Nepoužívajte alternatívne riešenia

Riešenia, ktoré sme predstavili, môžu znamenať určité zmeny v našom dizajne mapovania. To by nás mohlo zvádzať k použitiu niektorých bežných riešení, aby sme pri prijímaní lomiek v adresách URL fungovali naše pôvodné koncové body.

Najbežnejším riešením je pravdepodobne kódovanie lomiek v parametroch cesty. Avšak v minulosti boli hlásené niektoré chyby zabezpečenia a väčšina webových a aplikačných serverov na ne reagovala tak, že predvolene nepovolila kódované lomítka. Toto správanie je stále možné zmeniť jednoduchou zmenou zodpovedajúceho nastavenia, napríklad v Tomcat.

Iné, ako napríklad Apache Server, išli o niečo ďalej a zaviedli možnosť povoliť kódované lomky bez ich dekódovania, aby sa nevykladali ako oddeľovače cesty. V každom prípade, toto sa neodporúča a môže to predstavovať potenciálne bezpečnostné riziká.

Na druhej strane webové rámce tiež prijímajú určité preventívne opatrenia. Ako sme už videli predtým, Pružina pridáva niektoré mechanizmy ako ochranu pred menej prísnymi nádobami servletov. Takže v prípade, že na našom serveri povolíme kódované lomítka, musíme ich ešte na jar povoliť.

Nakoniec existujú ďalšie druhy riešení, ako napríklad zmena normalizácie URI, ktorú Spring poskytuje v predvolenom nastavení. Rovnako ako predtým by sme mali byť veľmi opatrní, ak zmeníme tieto predvolené hodnoty.

5. Záver

V tomto krátkom článku sme si ukázali niektoré riešenia riešenia lomiek v adresách URL na jar. Taktiež sme predstavili niekoľko bezpečnostných problémov, ktoré môžu nastať, ak zmeníme predvolené konfigurácie serverov alebo rámcov ako Spring.

Pravidlom je, že parametre dotazu sú zvyčajne najlepším riešením na riešenie lomiek v adresách URL.

Úplný zdrojový kód príkladov je ako vždy k dispozícii na serveri GitHub.