Необходимо разрешить кодированные косые черты на Apache

В настоящее время я пытаюсь поместить URL-адрес в URL-адрес. Например:

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

Я знаю, что мне нужно закодировать URL-адрес, который я сделал, но теперь я получаю ошибку 404 с сервера, а не с моим приложением. Я думаю, что моя проблема связана с apache и может быть исправлена ​​с помощью директивы AllowEncodedSlashes On.

Я пробовал поставить директиву внизу httpd.conf, и не уверен, что делать дальше. Я помещаю его в нужное место? Если да, есть ли у кого-нибудь другие решения?

Ответы

Ответ 1

Эта проблема не связана с ошибкой Apache 35256. Скорее, она связана с ошибкой 46830. Параметр AllowEncodedSlashes не наследуется виртуальными хостами, и виртуальные хосты используются во многих конфигурациях Apache по умолчанию, например в Ubuntu. Обходной путь - добавить параметр AllowEncodedSlashes внутри контейнера <VirtualHost> (/etc/apache2/sites-available/default в Ubuntu).

Ошибка 35256: %2F будет декодирован в PATH_INFO (в документации к AllowEncodedSlashes сказано, что декодирование не будет выполнено)

Ошибка 46830: Если AllowEncodedSlashes On установлен в глобальном контексте, он не наследуется виртуальными хостами. Вы должны явно установить AllowEncodedSlashes On в каждом контейнере <VirtalHost>.

Документация о том, как объединяются различные разделы конфигурации, гласит:

Разделы внутри <VirtualHost> разделов применяются после соответствующих разделов вне определения виртуального хоста. Это позволяет виртуальным хостам переопределять конфигурацию основного сервера.

Ответ 2

Я продолжал сталкиваться с этим сообщением для другого вопроса. Позвольте мне просто объяснить, как быстро.

У меня был тот же URL-адрес стиля, который также пытался проксировать его.

Пример: запросы прокси от /example/ на другой сервер.

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

Проблема 1: Apache считает, что неверный URL

Решение: AllowEncodedSlashes On в httpd.conf

Проблема 2: Apache декодирует закодированные косые черты

Решение: AllowEncodedSlashes NoDecode в httpd.conf(требуется Apache 2.3.12 +)

Проблема 3: mod_proxy пытается перекодировать (с двойной кодировкой) изменение URL %2F на %252F (например, /example/http:%252F%252Fwww.someurl.com/)

В httpd.conf используйте ключевое слово ProxyPass nocanon для передачи необработанного URL через прокси.

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

Файл httpd.conf:

AllowEncodedSlashes NoDecode

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

Ссылка:

Ответ 3

Я потратил немало времени на эту проблему. Я немного опаздываю на вечеринку, но теперь кажется, что есть решение.

В соответствии с этот поток, есть (была) ошибка в Apache, так что если у вас есть AllowEncodedSlashes On, она предотвращает 404, но ошибочно декодирует косые черты, что неверно в соответствии с RFC.

Этот комментарий предлагает решение, а именно:

AllowEncodedSlashes NoDecode

Ответ 4

в свете всех проблем, я выбрал base64_encoding, за которым следует urlencoding. Он работает без необходимости обманывать настройками сервера Apache или просматривать отчеты об ошибках. Он также работает без необходимости вставлять url в раздел запроса.

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

и вернуть его

$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

После честного тестирования и поиска ошибок в Apache я пришел к выводу, что, несмотря на предлагаемые решения на разных форумах, это нерешенная проблема в Apache. Смотрите ошибку: https://issues.apache.org/bugzilla/show_bug.cgi?id=35256

Обходной путь, который работает для меня, состоит в том, чтобы реорганизовать URI, чтобы элемент, который мог содержать экранированные косые черты, находится в секции запроса URI, а не пути. Мои тесты показывают, что когда они есть, они не отфильтровываются Apache, независимо от параметров AllowEncodedSlashes и AcceptPathInfo.

Итак: http://test.com/url?http%3A%2F%2Fwww.url2.com

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

вместо: http://test.com/url/http%3A%2F%2Fwww.url2.com

Это означает изменение архитектуры для нашего проекта, но это кажется неизбежным. Надеюсь, вы нашли решение.

Ответ 6

Я получаю ту же проблему с "AllowEncodedSlashes On" и попытался разместить директиву в нескольких разных местах: apache2.conf, httpd.conf и внутри раздела, в соответствии с примером в http://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-apache.html.

Если вы еще этого не сделали, вы можете настроить уровень ведения журнала для отладки (другая директива) и посмотреть, есть ли у вас ошибка:

найдено% 2f (закодировано '/') в URI (decoded = '/url/http://www.url2.com'), возвращая 404

другие не найденные ошибки не предоставляют эту информацию в журналах. Еще один диагностический...

Удачи (для нас обоих)!

Ответ 7

Замените %2F на %252F на стороне клиента.

Это двойная кодировка формы косой черты.

Поэтому, когда он доходит до сервера и досрочно декодируется, он будет декодировать его на% 2F, который именно вы хотите.

Ответ 8

В дополнение к fooobar.com/info/109582/...: Если вы используете RewriteRule вместо ProxyPass вы должны добавить флаг NE чтобы избежать декодирования.