Насколько безопасны собственные функции php для использования с нефильтрованным вводом?

Question

Может быть, я немного параноик, но когда я переписываю контактный модуль, на ум пришел следующий вопрос:

Могу ли я использовать нефильтрованный ввод в собственных функциях php?

Легко санировать вещи, помещать их в базу данных, выводить на экран и т. Д., Но мне было интересно, если, например, следующее утверждение может быть опасным:

    if (file_exists($_POST['brochure'])) {
        // do some stuff
    }

Если кому-то удастся опубликовать на этой странице, можно ли использовать приведенный выше код?

Приведенный выше код является лишь примером, я могу вспомнить другие функции, которые я использую при обработке формы.

Редактировать: Спасибо всем, file_exists в примере на самом деле является частью санитарной функции, но при очистке используются функции php, поэтому он быстро превращается в историю о курице и яйце: использование функций Я должен очистить, но для очистки я должен использовать функции.

В любом случае, у меня сейчас есть свежие идеи.

Answer 1

Да. Все, что мне нужно сделать, это опубликовать "/ etc / passwd" или "includes / dbconnection.php" (или что-нибудь еще) на вашей странице, и в зависимости от того, что на самом деле является //do some stuff, я мог бы удалить, изменить или прочитать конфиденциальная информация. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Функция file_exists сама по себе не сделает ничего, чего вы не ожидаете, но вы можете ожидать, что злоумышленники воспользуются вашей логикой.

Всегда дезинфицировать ваш пользовательский ввод. Всегда. Если вы планируете захватывать файлы только из одной конкретной папки, не разрешайте .. или / во входных данных

Answer 2

Само по себе это выглядит достаточно безопасно, но его можно использовать для раскрытия информации. Это может позволить атаке проверить наличие (или отсутствие) определенных файлов (например, /etc/passwd, /proc/* и т. Д.).

Таким образом, в этом примере вы должны убедиться, что $_POST['brochure'] сначала очищается, чтобы принимать только те входные данные, которые соответствуют потенциально допустимым именам файлов. Отбросьте любой ввод, содержащий .. или начинающийся с /.

Другие функции могут иметь потенциально гораздо худшие побочные эффекты ...

Answer 3

Встроенные PHP не будут делать «неожиданные» вещи при неправильном вводе (например, file_exists("foo; rm -r /") скажет «нет, файл 'foo; rm -r /' не существует») ... И если они это сделают Это ошибка, которую вы можете подать против Zend.

Конечно, это не не останавливает людей от использования вашего кода (например, file_exists("../hidden/shell.php")), поэтому вы все равно должны (на самом деле, вы должны всегда *) 1010 *) будьте осторожны при передаче введенного пользователем ввода.

Answer 4

может 'брошюра' = '../../../../.htaccess'

это интересный вопрос.

Apache на моем компьютере запрещает вывод или просмотр файлов .ht * и .ini и .php.inc, но вы меня сейчас беспокоите.

Answer 5

То, что вы должны спросить, это ваш ответ. Это не безопасно.

file_exists() не так плохо, как другие, но если вы не видите исходный код функции, в которую вы передаете данные, и не знаете, как она обрабатывает пользовательский ввод, тогда вы рискуете.

Не стоит передавать нефильтрованные пользовательские данные в любую команду файловой системы php. Ключ к безопасности в том, что вы никогда не разрешаете ввод для переключения контекста. В этом случае минимальная очистка должна состоять в удалении символов пути.

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

Answer 6

У вас действительно должна быть привычка отфильтровывать все входные данные, но вы можете проверить http://www.hardened -php.net / , который распространяет патч на закаливание и Suhosin, который во многих бинарные дистрибутивы по умолчанию (OpenSUSE, Mandriva и Debian / Ubuntu)

Answer 7

Я бы вообще не доверял этим функциям.

Это может звучать определенно поразительно, однако, когда я внимательно слежу за людьми и их качеством С-кода в коммитах, возвратах и ​​т. Д. В течение последних восьми лет, я просто в постоянном страхе.

Answer 8

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

Answer 9

За прошедшие годы в самом источнике PHP были обнаружены уязвимости безопасности, так что функции были приемлемы для атак в стиле буферного потока. Suhosin был / был проектом, который исправил PHP, чтобы устранить часть риска. 1003 *