Müssen verschlüsselte Schrägstriche auf Apache zulassen

Question

Ich versuche derzeit, eine URL innerhalb einer URL zu platzieren. Zum Beispiel:

http://example.com/url/http%3A%2F%2Fwww.url2.com 

Ich bin mir bewusst, dass ich die URL kodieren, die ich getan habe, aber jetzt bekomme ich einen 404 Fehler vom Server zurück, anstatt meine App. Ich denke mein Problem liegt bei Apache und kann mit der AllowEncodedSlashes On Direktive behoben werden.

Ich habe versucht, die Richtlinie am Ende der httpd.conf ohne Wirkung, und bin mir nicht sicher, was ich als nächstes tun soll. Lege ich es an den richtigen Ort? Wenn ja, hat jemand andere Lösungen?

Answer 1

Bearbeiten: Siehe @ CaffeineComa die Antwort.

Dieses Problem wird nicht im Zusammenhang mit Apache Bug 35256. Vielmehr es Bug 46830. Die AllowEncodedSlashes Einstellung vererbt wird nicht durch virtuelle Hosts und virtuelle Hosts verwendet werden, in vielen Standard-Apache-Konfigurationen, wie das in Ubuntu verwendet . Die Problemumgehung besteht darin, die AllowEncodedSlashes Einstellung in einem <VirtualHost> Container (/etc/apache2/sites-available/default in Ubuntu) hinzuzufügen.

Bug 35256: %2F wird in PATH_INFO decodiert werden (Dokumentation zu AllowEncodedSlashes sagt keine Decodierung getan wird)

Bug 46830: gesetzt, wenn AllowEncodedSlashes On, wird nicht von virtuellen Hosts geerbt es im globalen Kontext. Sie müssen AllowEncodedSlashes On in jedem <VirtalHost> Container explizit festlegen.

Die Dokumentation, wie die verschiedenen Konfigurationsabschnitte werden zusammengeführt, sagt:

Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.

Answer 2

Ich bekomme das gleiche Problem mit "AllowEncodedSlashes On", und habe versucht, die Direktive an ein paar verschiedenen Orten: apache2.conf, httpd.conf, und in einem Abschnitt, wie ein Beispiel bei http://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-apache.html.

Wenn Sie nicht bereits haben, können Sie Ihre Protokollierungsebene zu debuggen (eine andere Richtlinie) und sehen Sie einstellen, wenn Sie den Fehler:

gefunden% 2f (codiert ‚/‘) in URI (decodiert = '/ url/http: //www.url2.com'), Rückgabe 404

andere nicht gefundene Fehler geben diese Informationen nicht in den Protokollen an. Nur eine andere Diagnose ...

Viel Glück (für uns beide)!

Answer 3

Nach ein paar Tests und mit Blick auf den Bug in Apache, habe ich festgestellt, dass dies trotz der angebotenen Lösungen in verschiedenen Foren, ein ungelöstes Problem in Apache ist. Siehe den Fehler: https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

Die Problemumgehung, die für mich funktioniert, ist die URI neu zu gestalten, so dass das Element, das die maskierten Schrägstriche enthalten kann, im Abfrageabschnitt des URI anstelle des Pfads ist. Meine Tests zeigen, dass sie von Apache nicht herausgefiltert werden, unabhängig von den Einstellungen AllowEncodedSlashes und AcceptPathInfo.

So: http://test.com/url?http%3A%2F%2Fwww.url2.com

oder: http://test.com/url?theURL=http%3A%2F%2Fwww.url2.com

statt: http://test.com/url/http%3A%2F%2Fwww.url2.com

Das bedeutet, eine Architektur Veränderung für unser Projekt, aber es scheint nicht zu vermeiden. Hoffe, du hast eine Lösung gefunden.

Answer 4

ich auch sehr viele Stunden auf dieses Problem verschwendet. Ich bin ein bisschen zu spät zur Party, aber es scheint, dass es jetzt eine Lösung gibt.

Per this thread gibt es (war) ein Fehler in Apache, so dass, wenn Sie AllowEncodedSlashes On haben, ist es die 404 verhindert, aber es fälschlicherweise dekodiert die Schrägstriche, die nach dem RFC falsch ist.

This comment bietet eine Lösung, verwenden nämlich:

AllowEncodedSlashes NoDecode 

Answer 5

im Lichte all den Ärger, ich von urlencoding für base64_encoding gefolgt entschieden. Es funktioniert, ohne mit Apache-Server-Einstellungen oder Fehlerberichten herumalbern zu müssen. Es funktioniert auch, ohne die URL in den Abfrageabschnitt zu stellen.

$enc_url = urlencode(base64_encode($uri_string)); 

und es

$url = base64_decode(urldecode($enc_url)); 

http://example.com/admin/supplier_show/8/YWRtaW4vc3VwcGxpZXJz

http://example.com/admin/supplier_show/93/YWRtaW4vc3VwcGxpZXJzLzEwMA%3D%3D

Answer 6

Ich hielt in diesem Beitrag kommen für eine weitere Ausgabe zurück. Lass mich das einfach erklären.

Ich hatte die gleiche URL-Stil und versuchte auch, es zu proxy.

Beispiel: Proxy-Anfragen von /example/ an einen anderen Server.

/example/http:%2F%2Fwww.someurl.com/ 

Problem 1: Apache glaubt, das ist eine ungültige URL

Lösung: AllowEncodedSlashes On in httpd.conf

Problem 2: Apache decodiert die codierten Schrägstriche

Lösung: AllowEncodedSlashes NoDecode in httpd.conf (Erfordert Apache 2.3.12+)

Ausgabe 3: mod_proxy versucht, die URL, die %2F in %252F ändert (z. /example/http:%252F%252Fwww.someurl.com/)

Lösung: In httpd.conf verwenden, um das ProxyPass Schlüsselwort nocanon die rohe URL durch den Proxy zu passieren.

ProxyPass http://anotherserver:8080/example/ nocanon 

httpd.Datei conf:

AllowEncodedSlashes NoDecode 

<Location /example/> 
    ProxyPass http://anotherserver:8080/example/ nocanon 
</Location> 

Referenz:

• http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
• http://www.silverdisc.co.uk/blog/2009/02/28/url-canonicalisation-and-normalisation
• Cannot match %2F in mod_rewrite

Answer 7

ersetzen %2F mit %252F auf der Client-Seite.

Dies ist die doppelt codierte Form des Schrägstrichs.

Also, wenn es den Server erreicht und vorzeitig decodiert wird es in% 2F dekodieren, was genau das ist, was Sie wollen.