Besoin d'autoriser les slashs encodés 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 suis conscient que je dois encoder L'URL, ce que j'ai fait, mais maintenant je reçois une erreur 404 de retour du serveur plutôt que mon application. Je pense que mon problème réside dans apache et peut être résolu avec la directive AllowEncodedSlashes On .

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

60
demandé sur MrWhite 2010-12-08 20:32:25

7 réponses

ce problème n'est pas lié au bogue 35256 D'Apache. 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 d'Ubuntu. La solution consiste à ajouter le paramètre AllowEncodedSlashes à L'intérieur d'un conteneur <VirtualHost> ( /etc/apache2/sites-available/default dans Ubuntu).

bogue 35256 : %2F sera décodé dans PATH_INFO (Documentation vers AllowEncodedSlashes dit pas de décodage)

Bug 46830 : si AllowEncodedSlashes On est placé dans le contexte global, il n'est pas hérité par les hôtes virtuels. Vous devez définir explicitement AllowEncodedSlashes On dans chaque conteneur <VirtalHost> .

la documentation sur la fusion des différentes sections de configuration dit:

Les Sections

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

47
répondu Roger Dahl 2018-07-13 16:50:10

j'ai continué à venir à travers 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 aussi de le proxy.

exemple: requêtes Proxy de /example/ vers un autre serveur. 

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

Issue 1: Apache estime que c'est une url invalide

Solution: AllowEncodedSlashes On dans httpd.conf

Question 2: Apache décode les slashes codés

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

Question 3: mod_proxy les tentatives de ré-encoder (double encodage) l'URL de changer %2F à %252F (eg. /example/http:%252F%252Fwww.someurl.com/ )

Solution: dans httpd.conf utilisez le ProxyPass mot-clé nocanon pour passer L'URL brute par le proxy. 

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

httpd.fichier conf: 

AllowEncodedSlashes NoDecode

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

référence:

66
répondu technocrat 2017-05-23 11:55:03

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

comme pour ce thread , il y a (était) un bug dans Apache tel que si vous avez AllowEncodedSlashes On , il empêche le 404, mais il décode par erreur 151980920" les slashs, ce qui est incorrect selon le RFC.

Ce commentaire propose une solution, à savoir use: 

AllowEncodedSlashes NoDecode
30
répondu George Armhold 2011-06-17 15:05:09

à la lumière de tous les tracas, j'ai opté pour base64_encoding suivi de urlencoding. Il fonctionne sans avoir à jouer avec les paramètres du serveur apache ou à regarder les rapports de bogues. Il fonctionne également sans avoir à mettre l'url dans la section 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
répondu Kinjal Dixit 2012-02-16 09:08:34

après quelques tests, et en regardant le bug dans Apache, j'ai conclu que malgré les 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

le contournement qui fonctionne pour moi est de reformuler L'URI de sorte que l'élément qui peut contenir les barres obliques échappées se trouve dans la section de requête de l'URI, au lieu du chemin. Mes tests montrent que lorsque ils sont là, ils ne sont pas filtrés par Apache, peu importe les paramètres Allowencodedslashs et AcceptPathInfo.

: 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. Espérons que vous avez trouvé une solution.

2
répondu abq_rob 2010-12-10 22:02:08

j'ai 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 dans un 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 pouvez configurer votre niveau de journalisation pour déboguer (une autre directive) et voir si vous obtenez l'erreur:

trouvés %2f (codée '/') URI (décodé='/url/http://www.url2.com'), de retour 404

autres erreurs non trouvées ne fournissez pas cette information dans les journaux. Juste un autre diagnostic...

Bonne chance (pour nous deux)!

0
répondu abq_rob 2010-12-09 22:46:31

remplacer %2F par %252F du côté du client.

C'est la forme à double codage de la barre oblique avant.

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

0
répondu Amy Neville 2015-12-08 09:34:53