Apache возвращает 404, если pathinfo содержит частично URI-кодированный URL

2228
Dave Sherohman

(Ух ты, этот заголовок - отстой ... Не стесняйтесь вносить предложения в комментарии или редактировать его, если у вас есть лучший вариант.)

У меня есть сервер с программой CGI, который получает URL-адрес в виде pathinfo, проверяет IP-адрес пользователя и перенаправляет его либо на прямой переход к этому URL-адресу (если они являются внутренними для нашей организации), либо отправляет их на URL-адрес через прокси-сервер. (если они внешние). Сам CGI прекрасно работает, но есть некоторые URL, для которых apache возвращает ошибку 404 Not Found вместо вызова скрипта. Похоже, что это связано с целевым URL, содержащим путь в кодировке URI. например,

http://myserver.org/cgi-bin/ipchk/http://other.server.org/10.1007%2F3-540-28519-9_8

возвращает 404, а

http://myserver.org/cgi-bin/ipchk/http://other.server.org/10.1007/3-540-28519-9_8

(тот же URL, но с %2Fрасшифровкой в /) работает правильно.

Я проверил (выводя error_logпри запуске), что, когда возвращается 404, ipchkскрипт вообще не запускается. Эти ошибки определенно происходят от самого Apache, а не от сценария, перенаправляющего пользователей на несуществующий URL.

Почему кодировка URL-адреса pathinfo влияет на способность apache найти сценарий ipchk и что мне нужно сделать, чтобы он передавал все /cgi-bin/ipchk/ URI ipchkнезависимо от того, что может последовать?

1

1 ответ на вопрос

3
Dave Sherohman

В рамках попытки защитить пользователей от кода CGI, который неправильно проверяет данные перед проверкой входящих путей, apache отклоняет (как 404 не найдено) URL-адреса, содержащие URI-закодированные формы прямой косой черты ( %2F) или обратной косой черты ( %5C), как объяснено в этой статье .

Чтобы обойти эту проверку, вы должны использовать apache 2.0.46 или новее и включить AllowEncodedSlashesдирективу в конфигурации apache. (Эта директива не работает .htaccess; она разрешена только в контексте сервера или виртуального хоста.)