web-dev-qa-db-fra.com

Besoin d'autoriser les barres obliques codées sur Apache

J'essaie actuellement de placer une URL dans une URL. Par exemple:

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

Je sais que je dois encoder l'URL, ce que j'ai fait, mais maintenant je reçois un 404 erreur de retour du serveur plutôt que de mon application. Je pense que mon problème réside avec Apache et peut être résolu avec le AllowEncodedSlashes On directive.

J'ai essayé de mettre la directive au bas du httpd.conf sans effet, et je ne sais pas quoi faire ensuite. Suis-je le mettre au bon endroit? Si oui, quelqu'un a-t-il d'autres solutions?

66
tommizzle

Ce problème n'est pas lié au bogue Apache 35256. Il est plutôt lié au bogue 46830. Le paramètre AllowEncodedSlashes n'est pas hérité par les hôtes virtuels et les hôtes virtuels sont utilisés dans de nombreuses configurations Apache par défaut, comme celle de Ubuntu. La solution consiste à ajouter le paramètre AllowEncodedSlashes à l'intérieur d'un <VirtualHost> récipient (/etc/Apache2/sites-available/default dans Ubuntu).

Bogue 35256 : %2F sera décodé dans PATH_INFO (la documentation de AllowEncodedSlashes indique qu'aucun décodage ne sera effectué)

Bogue 468 : Si AllowEncodedSlashes On est défini dans le contexte global, il n'est pas hérité par les hôtes virtuels. Vous devez explicitement définir AllowEncodedSlashes On dans chaque <VirtalHost> récipient.

La documentation sur la façon dont les différentes sections de configuration sont fusionnées indique:

Sections à l'intérieur <VirtualHost> les sections sont appliquées après les sections correspondantes en dehors de la définition d'hôte virtuel. Cela permet aux hôtes virtuels de remplacer la configuration du serveur principal.

56
Roger Dahl

Je n'arrêtais pas de tomber sur ce post pour un autre problème. Permettez-moi de vous expliquer très rapidement.

J'avais la même URL de style et j'essayais également de la proxy.

Exemple: requêtes proxy de /example/ vers un autre serveur.

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

Problème 1: Apache pense qu'il s'agit d'une URL non valide

Solution: AllowEncodedSlashes On dans httpd.conf

Problème 2: Apache décode les barres obliques codées

Solution: AllowEncodedSlashes NoDecode dans httpd.conf (nécessite Apache 2.3.12+)

Problème 3: mod_proxy tente de ré-encoder (double encoder) l'URL en changeant %2F à %252F (par exemple. /example/http:%252F%252Fwww.someurl.com/)

Solution: dans httpd.conf utilisez le mot clé ProxyPassnocanon pour transmettre l'URL brute via le proxy.

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

fichier httpd.conf:

AllowEncodedSlashes NoDecode

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

Référence:

76
technocrat

J'ai aussi perdu beaucoup d'heures sur ce problème. Je suis un peu en retard à la fête, mais il semble qu'il y ait une solution maintenant.

Selon ce fil , il y a (était) un bogue dans Apache tel que si vous avez AllowEncodedSlashes On, il empêche le 404, mais il décode par erreur les barres obliques, ce qui est incorrect selon la RFC.

Ce commentaire propose une solution, à savoir utiliser:

AllowEncodedSlashes NoDecode
31
George Armhold

à la lumière de tous les tracas, j'ai opté pour base64_encoding suivi par urlencoding. Il fonctionne sans avoir à jouer avec les paramètres du serveur Apache ou à consulter les rapports de bogues. Il fonctionne également sans avoir à mettre l'URL dans la section de requête.

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

et pour le récupérer

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

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

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

5
Kinjal Dixit

Après un bon nombre de tests et après avoir examiné le bogue d'Apache, j'ai conclu qu'en dépit des solutions proposées dans différents forums, il s'agit d'un problème non résolu dans Apache. Voir le bug: https://issues.Apache.org/bugzilla/show_bug.cgi?id=35256

La solution de contournement qui fonctionne pour moi consiste à refactoriser l'URI afin que l'élément pouvant contenir les barres obliques échappées se trouve dans la section de requête de l'URI, au lieu du chemin d'accès. Mes tests montrent que lorsqu'ils sont là, ils ne sont pas filtrés par Apache, quels que soient les paramètres AllowEncodedSlashes et AcceptPathInfo.

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

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

au lieu de: http://test.com/url/http%3A%2F%2Fwww.url2.com

Cela signifie un changement d'architecture pour notre projet, mais cela semble inévitable. J'espère que vous avez trouvé une solution.

2
abq_rob

Remplacer %2F avec %252F côté client.

Il s'agit de la forme à double codage de la barre oblique.

Donc, quand il atteint le serveur et est décodé prématurément, il le décode en% 2F, ce qui est exactement ce que vous voulez.

0
Amy Neville

J'obtiens le même problème avec "AllowEncodedSlashes On", et j'ai essayé de placer la directive à deux endroits différents: Apache2.conf, httpd.conf, et à l'intérieur d'une section, comme par exemple à http://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-Apache.html .

Si vous ne l'avez pas déjà fait, vous souhaiterez peut-être définir votre niveau de journalisation pour déboguer (une autre directive) et voir si vous obtenez l'erreur:

trouvé% 2f (encodé '/') dans l'URI (décodé = '/ url/http: //www.url2.com'), renvoyant 404

d'autres erreurs non trouvées ne fournissent pas ces informations dans les journaux. Juste un autre diagnostic ...

Bonne chance (à nous deux)!

0
abq_rob