Verwenden eines Schrägstrichs in Spring-URLs

1. Einleitung

Bei der Entwicklung von Webdiensten müssen wir uns möglicherweise mit komplexen oder unerwarteten URL-Pfaden befassen, die Schrägstriche enthalten können . Infolgedessen können Probleme mit den von uns verwendeten Webservern oder Frameworks auftreten.

Die Feder kann in dieser Hinsicht aufgrund der Standardkonfigurationen, die sie bietet, etwas schwierig sein.

In diesem Tutorial zeigen wir einige allgemeine Lösungen und Empfehlungen für den Umgang mit URLs mit Schrägstrichen im Frühjahr . Wir werden auch sehen, warum wir einige gängige Hacks nicht verwenden sollten, um diese Probleme zu umgehen. Lesen Sie weiter, um mehr darüber zu erfahren!

2. Analysieren Sie die Anforderung manuell

In unseren Webdiensten müssen wir manchmal alle Anforderungen unter einem bestimmten Pfad demselben Endpunkt zuordnen. Um die Sache noch schlimmer zu machen, wissen wir möglicherweise nicht, wie der Rest des Pfades aussehen wird. Möglicherweise müssen wir diesen Pfad auch irgendwie als Parameter empfangen, um ihn anschließend verwenden zu können.

Angenommen , wir können Anfragen mit einem beliebigen Pfad unter / mypaths empfangen :

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

Angenommen, wir möchten all diese verschiedenen Pfade in einer Datenbank speichern, um zu wissen, welche Anforderungen wir erhalten.

Die erste Lösung, die uns wahrscheinlich in den Sinn kommen wird, besteht darin, den dynamischen Teil des Pfades in einer PathVariable zu erfassen :

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

Leider stellen wir bald fest, dass dies eine 404 zurückgibt, wenn die PathVariable einen Schrägstrich enthält . Das Schrägstrichzeichen ist das URI-Standardpfadtrennzeichen, und alles, was danach folgt, zählt als neue Ebene in der Pfadhierarchie. Wie erwartet folgt Spring diesem Standard.

Wir können dies leicht lösen, indem wir mithilfe des Platzhalters ** einen Fallback für alle Anforderungen unter einem bestimmten Pfad erstellen :

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

Dann müssen wir die URI selbst analysieren, um den Teil des Pfades zu erhalten, an dem wir interessiert sind.

Diese Lösung ist sehr praktisch, wenn Sie mit URL-ähnlichen Parametern arbeiten . Wie wir im nächsten Abschnitt sehen werden, reicht sie für einige andere Fälle nicht aus.

3. Verwenden Sie Abfrageparameter

Im Gegensatz zu unserem vorherigen Beispiel gibt es andere Fälle, in denen wir nicht nur verschiedene Pfade zuordnen, sondern einen beliebigen String als Parameter in der URL erhalten.

Stellen wir uns vor, dass wir in unserem vorherigen Beispiel eine Anfrage mit einem Pfadparameter stellen, der aufeinanderfolgende Schrägstriche enthält :

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

Zuerst könnten wir denken, dass dies funktionieren sollte, aber wir stellen bald fest, dass unser Controller http: /myurl.com zurückgibt. Dies liegt daran, dass Spring Security die URLs normalisiert und jeden doppelten Schrägstrich durch einen einzelnen ersetzt .

Spring normalisiert auch andere Sequenzen in URLs, z. B. Pfadüberquerungen. Diese Vorsichtsmaßnahmen verhindern, dass böswillige URLs die definierten Sicherheitsbeschränkungen umgehen , wie in der offiziellen Spring Security-Dokumentation erläutert.

In diesen Fällen wird dringend empfohlen, stattdessen Abfrageparameter zu verwenden:

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

Auf diese Weise können wir jeden String- Parameter ohne diese Sicherheitsbeschränkungen empfangen , und unser Webdienst wird robuster und sicherer.

4. Vermeiden Sie Problemumgehungen

Die von uns vorgestellten Lösungen können einige Änderungen in unserem Zuordnungsdesign implizieren. Dies könnte uns dazu verleiten, einige gängige Problemumgehungen zu verwenden, damit unsere ursprünglichen Endpunkte funktionieren, wenn Schrägstriche in den URLs empfangen werden.

Die häufigste Problemumgehung besteht wahrscheinlich darin, die Schrägstriche in den Pfadparametern zu codieren. In der Vergangenheit wurden jedoch einige Sicherheitslücken gemeldet, und die meisten Web- und Anwendungsserver reagierten darauf, indem sie die codierten Schrägstriche standardmäßig nicht zuließen . Es ist weiterhin möglich, dieses Verhalten zu ändern, indem Sie die entsprechende Einstellung ändern, wie in Tomcat.

Andere wie Apache Server gingen noch einen Schritt weiter und führten eine Option ein, mit der codierte Schrägstriche ohne Dekodierung zugelassen werden können, damit sie nicht als Pfadbegrenzer interpretiert werden. In jedem Fall wird dies nicht empfohlen und kann potenzielle Sicherheitsrisiken mit sich bringen.

Andererseits treffen Web-Frameworks auch einige Vorsichtsmaßnahmen. Wie wir bereits gesehen haben, fügt Spring einige Mechanismen zum Schutz vor weniger strengen Servlet-Containern hinzu . Falls wir verschlüsselte Schrägstriche auf unserem Server zulassen, müssen wir sie im Frühjahr noch zulassen.

Schließlich gibt es andere Arten von Problemumgehungen, z. B. das Ändern der URI-Normalisierung, die Spring standardmäßig bereitstellt. Nach wie vor sollten wir sehr vorsichtig sein, wenn wir diese Standardeinstellungen ändern.

5. Schlussfolgerung

In diesem kurzen Artikel haben wir einige Lösungen für den Umgang mit Schrägstrichen in URLs im Frühjahr gezeigt. Wir haben auch einige Sicherheitsprobleme eingeführt, die auftreten können, wenn wir die Standardkonfigurationen von Servern oder Frameworks wie Spring ändern.

Als Faustregel gilt, dass Abfrageparameter normalerweise die beste Lösung sind, um mit Schrägstrichen in URLs umzugehen.

Wie immer ist der vollständige Quellcode für die Beispiele auf GitHub verfügbar.