У меня есть ситуация, когда я хочу закодированные косые черты в 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) должен быть проверен перед его использованием в любой функции базы данных или файловой системы.
Я бы подумал, что использовать экранированные косые черты в любом месте URL-адреса, если оправдано экранирование. Например, пример, приведенный в следующем (соответствующем) вопросе, является очень разумным:
Является косой чертой ("/"), эквивалентной закодированной косой чертой ("% 2F") в части пути HTTP-URL
Что касается того, почему он по умолчанию отключается … эта запись в блоге с 2003 года предполагает, что она должна «защищать хромовые скрипты CGI от себя»:
http://ken.coar.org/burrow/Apache_2f_encoding_decoding_and_security
Некоторые неосторожные практики, вероятно, приводят некоторых людей к тому, чтобы оказаться в кодовой базе со строкой, в которой они не уверены, стоит ли игнорировать или нет. Поэтому они освобождают его «просто для того, чтобы быть в безопасности». Но это может произойти после того, как предполагается, что символов пути нет … и он передается в некоторый исполняемый контекст, который полагал, что он выполнил всю проверку, в которой это необходимо.
Поэтому, если вы используете рекомендуемые методы большинства современных веб-фреймворков, я сомневаюсь, что это серьезная проблема, и вы можете без проблем использовать AllowEncodedSlashes.
Честно говоря, я не вижу никаких проблем с безопасностью, но я должен признать, что я не работал в этой области. Тем не менее, это правило все еще неверно.
Вы должны перенаправить на файл обработчика (php script), который анализирует $_SERVER['REQUEST_URI'] вместо передачи через $_GET . Это главным образом, чтобы избежать проблем, которые вы обычно получаете с некодированным контентом.
С другой стороны, вы можете запустить брандмауэр веб-приложений с правилом против передачи косой черты через URI. Это связано с тем, что это поведение часто связано с удаленным выполнением кода , локальным доступом к файлам и обращением к каталогам . Это, однако, является мерой предосторожности, которую вы действительно не должны полагаться в первую очередь.
Пример использования PoC:
include 'languages/'.$_GET['lang']; // hacker may pass ../ to move around.