Внедрение кода с помощью PHP

Я знаю, как защититься от SQL-инъекций и прочее и проверить ввод пользователя... но мне было интересно, берете ли вы данные из поля ввода пользователя, и данные представляют собой строку, насколько безопасно использовать эти данные внутри вашего кода для такие вещи, как:

if ($i == $_POST['userinput']) {
    ....
}

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

Очевидно, что в приведенном выше примере это не сработает, но я просто пытаюсь помешать людям делать что-то вроде include('whatever.php'); и т.п.


php code-injection
person Brett    schedule 16.03.2011    source источник

Ответы (5)


arrow_upward
4
arrow_downward

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

Пользовательский ввод становится потенциально опасным, когда используется, в операторе включения, в запросе к базе данных, в имени файла, в вызове eval(), на HTML-странице и т. д. Каждое из этих применений имеет один правильный метод санитарии.

person Pekka    schedule 16.03.2011

arrow_upward
1
arrow_downward

сравнение с пользовательскими переменными в порядке, они просто обрабатываются как строки. Что касается вашего примера include('whatever.php'), используйте белый список для защиты от него:

if(!in_array($userinput, array('libs.php', 'my.php'))) {
  die('sorry pal');
}
person knittl    schedule 16.03.2011
comment
Спасибо... Я так и думал, просто хотел убедиться :) - person Brett; 16.03.2011

arrow_upward
1
arrow_downward

Если вы не вызываете eval или аналогичные функции, которые создают и запускают фактический PHP-код из строки типа create_function, вам, как правило, не нужно беспокоиться о реальном внедрении кода.

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

person Charles    schedule 16.03.2011

arrow_upward
1
arrow_downward

Данные, поступающие от пользователей, потенциально опасны, но это не означает, что они опасны всегда — это зависит от того, что вы с ними делаете.

В то время как фильтрация/внесение в белый список/очистка данных всегда является хорошей практикой, абсолютный минимум, который вы должны сделать, это избегать использования их напрямую для действий, которые активно взаимодействуют со средой: работа с файловой системой (включая, fopen, file_(get|put)_contents, д.), база данных, генерация вывода в формате HTML и так далее.

Конечно, разные случаи требуют разных мер: например, нет смысла использовать (как я часто вижу) htmlspecialchars() при построении запросов к базе данных — цель этой функции — избежать внедрения кода в вывод браузера, поэтому ее следует использовать для что.

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

person Matteo Riva    schedule 16.03.2011

arrow_upward
-1
arrow_downward

Как строка сама по себе, это нормально. Еще безопаснее добавлять косые черты, чтобы такие символы, как ' и ", не конфликтовали. В основном это опасность для баз данных SQL.

person rollin340    schedule 16.03.2011
comment
пожалуйста, не советуйте использовать addslashes! - person knittl; 16.03.2011
comment
Addlash сами по себе не добавляют никакой безопасности. - person Pekka; 16.03.2011
comment
addslashes() равнозначно использованию переваренных спагетти в качестве ремня безопасности в автомобиле. - person Marc B; 16.03.2011