streamalism.org

1. Introduksjon

Når vi utvikler nettjenester, vi må kanskje håndtere komplekse eller uventede URL-stier som kan inneholde skråstreker. Som en konsekvens kan vi støte på problemer med webserverne eller rammene vi bruker.

Våren kan spesifikt være litt vanskelig i denne forbindelse på grunn av standardkonfigurasjonene den gir.

I denne veiledningen, vi viser noen vanlige løsninger og anbefalinger for håndtering av nettadresser med skråstreker om våren. Vi ser også hvorfor vi ikke bør bruke noen vanlige hack for å omgå disse problemene. Fortsett å lese for å vite mer om det!

2. Analyser forespørselen manuelt

I våre nettjenester må vi noen ganger kartlegge alle forespørslene under en bestemt vei til samme endepunkt. For å gjøre saken verre, vet vi kanskje ikke hvordan resten av stien vil se ut. Vi må kanskje også motta denne banen som en parameter for å kunne bruke den etterpå.

La oss si at vi kan motta forespørsler med hvilken som helst vei under / mypaths:

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

Og antar at vi vil lagre alle disse forskjellige banene i en database for å vite hvilke forespørsler vi mottar.

Den første løsningen som sannsynligvis vil komme til hjernen vår er å fange den dynamiske delen av stien inn i en PathVariable:

@GetMapping ("mypaths / {anything}") offentlig streng pathVariable (@PathVariable ("noe") streng hva som helst) {returner noe; }

Dessverre finner vi snart ut av det dette returnerer a 404 hvis PathVariable inneholder en skråstrek. Slash-tegnet er URI-standardbaneavgrenser, og alt som følger etter, teller som et nytt nivå i stihierarkiet. Som forventet følger vår denne standarden.

Vi kan enkelt Løs dette ved å opprette en reserve for alle forespørsler under en bestemt bane ved å bruke ** jokertegn:

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

Så må vi analysere URI selv for å få den delen av veien vi er interessert i.

Denne løsningen er veldig praktisk når du arbeider med URL-lignende parametere, men som vi ser i neste avsnitt, er det ikke nok for noen andre tilfeller.

3. Bruk spørringsparametere

I motsetning til vårt forrige eksempel er det andre tilfeller der vi ikke bare kartlegger forskjellige veier, men mottar noen String som en parameter i URL-en.

La oss forestille oss at i vårt forrige eksempel lager vi en forespørsel med en styparameter som inneholder påfølgende skråstreker:

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

Først kunne vi tenke at dette skulle fungere, men vi innså snart at kontrolleren vår kommer tilbake http: /myurl.com. Dette skjer fordi Spring Security normaliserer nettadressene og erstatter dobbelt skråstrek med en enkelt.

Våren normaliserer også andre sekvenser i URL-er, for eksempel banepasseringer. Det tar disse forholdsreglene for å forhindre at ondsinnede nettadresser går utenom de definerte sikkerhetsbegrensningene, som forklart i den offisielle Spring Security-dokumentasjonen.

I disse tilfellene anbefales det sterkt å bruke spørringsparametere i stedet:

@GetMapping ("all") offentlig streng queryParameter (@RequestParam ("param") strengpar) {return param; }

På denne måten kan vi motta noe String parameter uten disse sikkerhetsbegrensningene, og vår nettjeneste vil være mer robust og sikker.

4. Unngå løsninger

Løsningene vi har presentert kan innebære noen endringer i kartleggingsdesignet vårt. Dette kan friste oss til å bruke noen vanlige løsninger for å få de originale endepunktene til å fungere når vi mottar skråstreker i URL-ene.

Den vanligste løsningen er sannsynligvis å kode skråstrekene i baneparametrene. Derimot, noen sikkerhetsproblemer ble rapportert tidligere, og de fleste nett- og applikasjonsservere reagerte på det ved å ikke tillate kodede skråstreker som standard. Det er fortsatt mulig å endre denne oppførselen bare ved å endre den tilsvarende innstillingen, som i Tomcat.

Andre som Apache Server gikk litt lenger og introduserte et alternativ for å tillate kodede skråstreker uten å dekode dem slik at de ikke tolkes som stiavgrensere. I alle fall, dette anbefales ikke, og det kan innføre potensielle sikkerhetsrisikoer.

På den annen side tar nettrammer også noen forholdsregler. Som vi har sett før, Spring legger til noen mekanismer som beskyttelse mot mindre strenge servletbeholdere. Så hvis vi tillater kodede skråstreker på serveren vår, må vi fortsatt tillate dem om våren.

Til slutt er det andre typer løsninger som å endre URI-normaliseringen som Spring gir som standard. Som før, bør vi være veldig forsiktige hvis vi endrer disse standardene.

5. Konklusjon

I denne korte artikkelen har vi vist noen løsninger for å håndtere skråstreker i nettadresser om våren. Vi har også introdusert noen sikkerhetsproblemer som kan oppstå hvis vi endrer standardkonfigurasjonene til servere eller rammer som Spring.

Som en tommelfingerregel er spørringsparametere vanligvis den beste løsningen for å håndtere skråstrek i nettadresser.

Som alltid er hele kildekoden for eksemplene tilgjengelig på GitHub.