Почему безопасность допускает использование закодированных косых черт в URI? - PullRequest
Новая
       3

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

20 голосов
/ 10 мая 2011

У меня есть ситуация, когда я хочу закодированные косые черты в 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) должен быть проверен перед использованием его в любой функции базы данных или файловой системы.

Ответы [ 2 ]

10 голосов
/ 10 мая 2011

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

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

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

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

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

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

0 голосов
/ 10 мая 2011

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

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

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

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

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