streamalism.org

1. Inleiding

Wanneer we webservices ontwikkelen, we hebben mogelijk te maken met complexe of onverwachte URL-paden die schuine strepen kunnen bevatten. Als gevolg hiervan kunnen we problemen tegenkomen met de webservers of frameworks die we gebruiken.

Vooral de lente kan in dit opzicht een beetje lastig zijn vanwege de standaardconfiguraties die het biedt.

In deze tutorial we zullen enkele algemene oplossingen en aanbevelingen laten zien voor het omgaan met URL's met schuine strepen in het voorjaar. We zullen ook zien waarom we enkele veelvoorkomende hacks niet zouden moeten gebruiken om deze problemen te omzeilen. Blijf lezen om er meer over te weten!

2. Parseer het verzoek handmatig

In onze webservices moeten we soms alle verzoeken onder een bepaald pad naar hetzelfde eindpunt in kaart brengen. Tot overmaat van ramp weten we misschien niet hoe de rest van het pad eruit zal zien. Het kan zijn dat we dit pad op de een of andere manier als parameter moeten ontvangen om het daarna te gebruiken.

Laten we zeggen dat we verzoeken kunnen ontvangen met elk pad onder / mijnpaden:

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

En stel dat we al deze verschillende paden in een database willen opslaan om te weten welke verzoeken we ontvangen.

De eerste oplossing die waarschijnlijk in ons opkomt, is om het dynamische deel van het pad vast te leggen in een PadVariabele:

@GetMapping ("mypaths / {alles}") openbaar String pathVariable (@PathVariable ("alles") String iets) {return alles; }

Helaas komen we daar al snel achter dit geeft een 404 als het PadVariabele bevat een schuine streep. De schuine streep is het URI-standaardpadscheidingsteken en alles wat erna komt, telt als een nieuw niveau in de padhiërarchie. Zoals verwacht volgt Spring deze norm.

We kunnen gemakkelijk los dit op door een fallback te maken voor alle verzoeken onder een bepaald pad met behulp van de ** jokerteken:

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

Dan moeten we de URI zelf ontleden om het deel van het pad te krijgen waarin we geïnteresseerd zijn.

Deze oplossing is erg handig bij het werken met URL-achtige parameters, maar zoals we in de volgende sectie zullen zien, is het niet genoeg voor sommige andere gevallen.

3. Gebruik queryparameters

In tegenstelling tot ons vorige voorbeeld zijn er andere gevallen waarin we niet alleen verschillende paden in kaart brengen, maar er ook een ontvangen Draad als parameter in de URL.

Laten we ons voorstellen dat we in ons vorige voorbeeld een verzoek met een padparameter die opeenvolgende schuine strepen bevat:

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

In eerste instantie konden we denken dat dit zou moeten werken, maar al snel realiseren we ons dat onze controller terugkeert http: /myurl.com. Dit gebeurt omdat Spring Security normaliseert de URL's en vervangt elke dubbele slash door een enkele.

Spring normaliseert ook andere reeksen in URL's, zoals padtraversals. Het neemt deze voorzorgsmaatregelen om te voorkomen dat kwaadwillende URL's de gedefinieerde beveiligingsbeperkingen omzeilen, zoals uitgelegd in de officiële documentatie van Spring Security.

In deze gevallen wordt het ten zeerste aanbevolen om in plaats daarvan queryparameters te gebruiken:

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

Op deze manier kunnen we ze ontvangen Draad parameter zonder deze beveiligingsbeperkingen, en onze webservice zal robuuster en veiliger zijn.

4. Voorkom tijdelijke oplossingen

De oplossingen die we hebben gepresenteerd, kunnen enkele wijzigingen in ons toewijzingsontwerp met zich meebrengen. Dit zou ons kunnen verleiden om enkele veelvoorkomende tijdelijke oplossingen te gebruiken om onze oorspronkelijke eindpunten te laten werken bij het ontvangen van schuine strepen in de URL's.

De meest gebruikelijke oplossing is waarschijnlijk het coderen van de schuine strepen in de padparameters. Echter, sommige beveiligingsproblemen zijn in het verleden gemeld en de meeste web- en applicatieservers reageerden erop door de gecodeerde schuine strepen standaard niet toe te staan. Het is nog steeds mogelijk om dit gedrag te veranderen door de overeenkomstige instelling te wijzigen, zoals in Tomcat.

Anderen, zoals Apache Server, gingen een beetje verder en introduceerden een optie om gecodeerde schuine strepen toe te staan ​​zonder ze te decoderen, zodat ze niet worden geïnterpreteerd als padscheidingstekens. In elk geval, dit wordt niet aanbevolen en kan potentiële veiligheidsrisico's met zich meebrengen.

Aan de andere kant nemen webframeworks ook enkele voorzorgsmaatregelen. Zoals we eerder hebben gezien, Spring voegt een aantal mechanismen toe als bescherming tegen minder strikte servletcontainers. Dus als we gecodeerde schuine strepen op onze server toestaan, moeten we ze nog steeds toestaan ​​in het voorjaar.

Ten slotte zijn er andere soorten oplossingen, zoals het wijzigen van de URI-normalisatie die Spring standaard biedt. Net als voorheen moeten we erg voorzichtig zijn als we deze standaardinstellingen wijzigen.

5. Conclusie

In dit korte artikel hebben we enkele oplossingen laten zien voor het omgaan met schuine strepen in URL's in het voorjaar. We hebben ook enkele beveiligingsproblemen geïntroduceerd die kunnen optreden als we de standaardconfiguraties van servers of frameworks zoals Spring wijzigen.

Als vuistregel geldt dat queryparameters meestal de beste oplossing zijn om met slashes in URL's om te gaan.

Zoals altijd is de volledige broncode voor de voorbeelden beschikbaar op GitHub.