streamalism.org

1. Introduktion

Når vi udvikler webservices, Vi skal muligvis håndtere komplekse eller uventede URL-stier, der kan indeholde skråstreg. Som en konsekvens kan vi støde på problemer med de webservere eller rammer, vi bruger.

Foråret kan specifikt være lidt vanskeligt i denne henseende på grund af de standardkonfigurationer, det giver.

I denne vejledning vi viser nogle almindelige løsninger og anbefalinger til håndtering af webadresser med skråstreger om foråret. Vi ser også, hvorfor vi ikke skal bruge nogle almindelige hacks til at løse disse problemer. Fortsæt læsning for at vide mere om det!

2. Parse anmodningen manuelt

I vores webtjenester er vi undertiden nødt til at kortlægge alle anmodningerne under en bestemt sti til det samme slutpunkt. For at gøre tingene værre ved vi måske ikke, hvordan resten af ​​stien vil se ud. Vi skal muligvis også på en eller anden måde modtage denne sti som en parameter for at kunne bruge den bagefter.

Lad os sige, at vi kan modtage anmodninger med en hvilken som helst sti under / mypaths:

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

Og antag, at vi vil gemme alle disse forskellige stier i en database for at vide, hvilke anmodninger vi modtager.

Den første løsning, der sandsynligvis vil komme i vores sind, er at fange den dynamiske del af stien ind i en PathVariable:

@GetMapping ("mypaths / {anything}") offentlig StringstiVariabel (@PathVariable ("noget") String alt) {returner noget; }

Desværre finder vi snart ud af det dette returnerer a 404 hvis den PathVariable indeholder en skråstreg. Slash-tegnet er URI-standardsti-afgrænser, og alt det, der følger efter det, tæller som et nyt niveau i stihierarkiet. Som forventet følger Spring denne standard.

Det kan vi let løse dette ved at oprette en reserve for alle anmodninger under en bestemt sti ved hjælp af ** jokertegn:

@GetMapping ("all / **") offentlig String allDirectories (HttpServletRequest anmodning) {return request.getRequestURI () .split (request.getContextPath () + "/ all /") [1]; }

Så skal vi selv analysere URI for at få den del af den vej, vi er interesseret i.

Denne løsning er meget praktisk, når du arbejder med URL-lignende parametre, men som vi vil se i det næste afsnit, er det ikke nok til nogle andre sager.

3. Brug forespørgselsparametre

I modsætning til vores tidligere eksempel er der andre tilfælde, hvor vi ikke bare kortlægger forskellige stier, men modtager nogen Snor som en parameter i URL'en.

Lad os forestille os, at vi i vores tidligere eksempel laver en anmodning med en styparameter, der indeholder på hinanden følgende skråstreg:

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

Først kunne vi tænke, at dette skulle fungere, men vi indså snart, at vores controller vender tilbage http: /myurl.com. Dette sker fordi Spring Security normaliserer URL'erne og erstatter ethvert dobbelt skråstreg med en enkelt.

Spring normaliserer også andre sekvenser i webadresser, såsom stiovergange. Det tager disse forholdsregler for at forhindre ondsindede webadresser i at omgå de definerede sikkerhedsbegrænsninger, som forklaret i den officielle Spring Security-dokumentation.

I disse tilfælde anbefales det stærkt at bruge forespørgselsparametre i stedet:

@GetMapping ("alle") offentlige String queryParameter (@RequestParam ("param") String param) {return param; }

På denne måde kan vi modtage enhver Snor parameter uden disse sikkerhedsbegrænsninger, og vores webservice vil være mere robust og sikker.

4. Undgå løsninger

De løsninger, vi har præsenteret, kan medføre nogle ændringer i vores kortlægningsdesign. Dette kan friste os til at bruge nogle almindelige løsninger til at få vores originale slutpunkter til at fungere, når vi modtager skråstreg i webadresserne.

Den mest almindelige løsning er sandsynligvis at kode skråstreg i stiparametrene. Imidlertid, nogle sikkerhedssårbarheder blev rapporteret tidligere, og de fleste web- og applikationsservere reagerede på det ved at afvise de kodede skråstreger som standard. Det er stadig muligt at ændre denne adfærd bare ved at ændre den tilsvarende indstilling, som i Tomcat.

Andre som Apache Server gik lidt længere og introducerede en mulighed for at tillade kodede skråstreger uden at afkode dem, så de ikke fortolkes som stiafgrænsere. Under alle omstændigheder dette anbefales ikke, og det kan medføre potentielle sikkerhedsrisici.

På den anden side tager webrammer også nogle forholdsregler. Som vi har set før, Spring tilføjer nogle mekanismer som beskyttelse mod mindre strenge servletbeholdere. Så hvis vi tillader kodede skråstreger på vores server, er vi stadig nødt til at tillade dem i foråret.

Endelig er der andre slags løsninger som at ændre URI-normaliseringen, som Spring giver som standard. Som før skal vi være meget forsigtige, hvis vi ændrer disse standardindstillinger.

5. Konklusion

I denne korte artikel har vi vist nogle løsninger til håndtering af skråstreger i webadresser om foråret. Vi har også introduceret nogle sikkerhedsproblemer, der kan opstå, hvis vi ændrer standardkonfigurationerne af servere eller rammer som Spring.

Som en tommelfingerregel er forespørgselsparametre normalt den bedste løsning til at håndtere skråstreg i webadresser.

Som altid er den fulde kildekode til eksemplerne tilgængelig på GitHub.