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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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