Как я могу убедиться, что я защищен от относительных путей, например:
Я недавно получал их в своих журналах, и хотя я знаю, что этот не будет эффективным, меня интересует, как защититься от этого класса угроз.
(с использованием php5, apache2, debian)
Множество разных вариантов;
1) Какое-то выражение preg_replace для удаления таких вещей, как двойные точки, волнистый дефис (я не могу вспомнить, что там называлось, но они выглядят как ~), пути, начинающиеся с / и т. Д.
2) Создайте набор разрешенных URL-адресов / путей, которые можно открыть эфиром с помощью reg-exps или in_array и т. Д.
3) Включите безопасный режим PHP и установите open_basedir или chroot PHP / Apache, чтобы они не могли открывать файлы за пределами этого дерева.
Я бы предложил использовать chroot:
http://www.howtoforge.com/chrooting-apache2-mod-chroot-debian-etch
P.S: Очистка параметров GET / POST / ... и ввода в целом, конечно, тоже помогает;)
Единственный ответ, который на 100% защищен от атак этого типа, - никогда не позволять пользователю вводить сенсорные команды, которые обращаются к файловой системе. Не надо fopen($_GET['foo'])не надо include($_POST['bar']), даже не mkdir($_COOKIE['baz']). Никогда. Период. Никаких оправданий.
Если вы должны использовать ввод данных пользователем для выбора файла из файловой системы, либо используйте ввод пользователя при поиске в базе данных (после дезинфекции запроса к базе данных, конечно, для защиты от внедрения SQL), либо запустите его через switch заявление; в обоих случаях вы должны использовать жесткий или программный код и заведомо безопасный значения для фактических имен файлов, никогда любой вариант самого ввода пользователя.
Все в $ _POST, $ _GET, $ _COOKIES, $ _REQUEST и даже $ _FILES (кроме 'tmp_name' и 'error' - да, 'type' - это пользовательский ввод!) - это пользовательский ввод, который у вас точно есть нуль контроль за. Так что не верь этому никогда. Даже некоторые значения в $СЕРВЕР (например, HTTP* 'значения) вводятся пользователем! Не позволяйте никаким из этих значений приближаться к вашей файловой системе и не позволяйте им находиться где-либо рядом с вашей базой данных, предварительно не экранировав их (например, mysql_real_escape_string()) или привязать их к подготовленным операторам (если вы используете PDO).
Да, вы можете дезинфицировать ввод, но что, если вы что-то забудете? Что, если вы забудете, что символ тильды (~) имеет особое значение в системе * nix? Или что, если вы выполните идеальную очистку своего веб-сервера Linux, но позже перейдете на сервер Windows? Или что, если что-то, чего вы никогда не предвидели, изменится в вашем окружении - например, новый особый персонаж? И так и так далее. Самый безопасный вариант, наиболее перспективный - просто не позволять пользователю вводить данные рядом с вашей файловой системой.
Однако следует иметь в виду, что существует множество веб-приложений, уязвимых для атак, которые вы видите в своих журналах. Это не значит, что на ваш Тем не менее, сервер есть: довольно часто скриптовые дети просто указывают свою последнюю находку на любые серверы, которые они могут найти, не беспокоясь сначала о том, могут ли они вообще быть уязвимы. Если вы не уязвимы, вам не о чем беспокоиться из-за этого фонового шума.