Ich habe eine Java-Webapp, die anfällig für das Verzeichnis Transversal (aka Path Transversal) Angriff über URL-Codierung ist. Nach der Authentifizierung:
Laut der Servlet-Spezifikation soll der WEB-INF-Ordner nicht öffentlich zugänglich sein, aber irgendwie funktioniert es in diesem Fall. Ich verwende Websphere 5.1 mit Java 1.4, Spring Security 2.0.5 und Struts 1.3. Von dem, was ich gelesen habe, scheint es mit der Codierung verwandt zu sein,% c0% ae ist '.' (Punkt) in UTF-8.
Ich habe dasselbe auf einer anderen Webanwendung versucht, die in einer anderen Umgebung läuft (Tomcat 6 mit Java 7, Spring Security 3 und Spring MVC) und ich konnte das Problem nicht reproduzieren. Diese zweite Webanwendung hat einen Filter, um die Seiten in UTF-8 ( org.springframework.web.filter.CharacterEncodingFilter ) zu kodieren, also habe ich die gleiche Konfiguration in der ersten Webapp versucht, aber das hat nicht funktioniert.
Irgendwelche Ideen?
Danke.
Ich werde meine eigene Frage beantworten.
Mit den begrenzten Optionen, die ich hatte, fügte ich in der Spring Security-Konfigurationsdatei eine Sicherheitsregel wie zB
Es beschränkt den Zugriff auf WEB-INF auf die Rolle des "Nicht-Zugriffs", die tatsächlich keine Rolle spielt. Das verhindert den Zugriff auf alle Benutzer. Es ist nicht ideal, aber wird den Trick tun, bis es ein Upgrade gibt.
Sie können beheben oder diese Anfragen verweigern, bevor sie Websphere getroffen, indem sie durch einen anderen Webserver / appserver Proxying oder Web Application Firewalls . Entweder ein anderer Java-Applikationsserver oder möglicherweise so etwas wie Nginx oder Varnish den Trick tun könnte.
Natürlich ist die real Lösung ist zu aktualisieren. Dies ist nur ein Pflaster, das untergraben werden könnte. Es ist wirklich die falsche Art, Sicherheitsprobleme zu "reparieren".
Der Filter ändert die Zeichencodierung für den Hauptteil der Anfrage, nicht die URL.
Um die URL-Codierung in Tomcat festzulegen, müssen Sie ein Attribut im & lt; Connector & gt; Element von server.xml:
%Vor%Wenn Sie nicht upgraden können (älteres WebSphere + Java 1.4, autsch!), ist eine mögliche Lösung (eher eine Hacker-Aktion), einen einfachen Filter zu schreiben, der jeder Anfrage zugeordnet ist und die korrekte Zeichensatzkonvertierung durchführt verwirft ungültige Anfragen.
Ich bin sicher, dass Sie mit etwas Graben eine Implementierung finden können, die nach Dingen sucht, an die Sie vielleicht nicht gedacht haben.
Natürlich bleiben noch weitere acht Jahre Sicherheit (ganz zu schweigen von der Produktivität) Probleme.
bemerkte nicht bemerkt nicht, wie alt die Frage ist.
Dies ist meine Implementierung
%Vor%Und füge Filter zu meiner web.xml
hinzu %Vor%