Почему существует риск безопасности для кодирования косой черты в URI?

У меня есть ситуация, когда я хочу кодированные косые черты в URI (%2F), но мои правила .htaccess игнорируются, когда я делаю запрос, отправляя вместо этого на страницу 404. Я быстро нашел директиву Apache AllowEncodedSlashes, который я планирую включить, но я до сих пор не понимаю, почему это риск безопасности в первое место. Не могли ли кто-либо вручную преобразовать закодированные косые черты в реальные косые черты, если они пытались быть гнусными? (Хотя я не вижу, какой вред они могут сделать...)

Приложение, которое я тестирую, написано на PHP, а правило mod_rewrite, которое взаимодействует с ним, выглядит так:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^test/(.*)$ /test.php?_escaped_fragment_=$1 [NE,QSA,L]

Я просто хочу убедиться, что понимаю риски перед тем, как продолжить.

Чтобы уточнить: Apache не разрешает кодированные косые черты в пути, но они разрешены в строке запроса. Строка запроса так же восприимчива к эксплоитам, перечисленным ниже Кристианом ( "Удаленное выполнение кода, доступ к локальному файлу и обход каталога" ).

Итак, почему ASF зашел так далеко, что создал специальную директиву, чтобы позволить это поведение? Я не пытаюсь быть трудным, я просто не понимаю. Я думаю, само собой разумеется, что любой пользовательский ввод (включая URI) должен быть проверен перед его использованием в любой функции базы данных или файловой системы.

Ответ 1

Я бы подумал, что использовать экранированные косые черты в любом месте URL-адреса, если оправдано экранирование. Например, пример, приведенный в следующем (актуальном) вопросе, является очень разумным:

Это косая черта ( "/" ), эквивалентная закодированной косой чертой ( "% 2F" ) в части пути HTTP-URL

Что касается причин, по которым он был бы отключен по умолчанию... эта запись в блоге еще в 2003 году предполагает, что она должна "защищать хромовые скрипты CGI от себя":

http://ken.coar.org/burrow/Apache_2f_encoding_decoding_and_security

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

Итак, если вы используете рекомендуемые методы большинства современных веб-фреймворков, я сомневаюсь, что это серьезная проблема, и вы можете без проблем использовать AllowEncodedSlashes.

Ответ 2

Честно говоря, я не вижу никаких проблем с безопасностью, но я должен признать, что я не работал в этой области. Тем не менее, это правило все еще не правильно.

Вы должны перенаправить файл обработчика (php script), который анализирует $_SERVER['REQUEST_URI'] вместо передачи через $_GET. Это в основном для того, чтобы избежать проблем, которые обычно возникают с некодированным контентом.

С другой стороны, вы можете запустить брандмауэр веб-приложений с правилом против передачи косой черты через URI. Это связано с тем, что это поведение часто связано с Удаленным выполнением кода, Доступ к локальному файлу и Обход каталога. Это, однако, является мерой предосторожности, которую вы действительно не должны полагаться в первую очередь.

Пример использования PoC:

include 'languages/'.$_GET['lang']; // hacker may pass ../ to move around.