filter_input и mysqli_real_escape_string для целых чисел - PullRequest
Новая
       35

filter_input и mysqli_real_escape_string для целых чисел

2 голосов
/ 11 марта 2012

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

В настоящее время я использую $num = filter_input(INPUT_GET, 'num', FILTER_VALIDATE_INT, $num_options); с указанными минимальными и максимальными значениями.Отсюда я выхожу с сообщением об ошибке, если $num == false

Нужно ли также использовать $mysqli->real_escape_string($num);

В настоящее время я не беспокоюсь, потому что я думаю, что довольно сложно сделать SQL-инъекциюиспользуя целое число ...

Спасибо,

Кевин

ОБНОВЛЕНИЕ: Чтобы уточнить запрос, который я делаю, выглядит следующим образом 

$sql = "SELECT employeeID, concat(FirstName, ' ', LastName) as Name FROM employee WHERE employeeID='$num'";

Ответы [ 2 ]

4 голосов
/ 11 марта 2012

Я вижу, что вы используете mysqli, ваш лучший вариант для безопасности - изучить подготовленные операторы.

PHP mysqli Подготовленные операторы

Это немного сложный пример, но вышеприведенная ссылка имеет подробные примеры.Как только вы освоитесь с этим и создадите свой класс.Это действительно только обычный SQL-запрос, но вместо того, чтобы включать ваши значения, которые вы используете? 

"SELECT * FROM account WHERE username = ? AND password = ?"

, и вы связываете свои значения с утверждением: 

array("bradley", "Passw0rd");

Безопасность исходиткороткий ответ - это тот факт, что вы сами не объединяете значения в строку запроса.Делая это менее склонным к инъекции sql.

0 голосов
/ 11 марта 2012

Как и многие другие пользователи PHP, вы ошибаетесь.Вы воспринимаете это как своего рода волшебную палочку, которая делает некоторые «злые персонажи» «безопасными».
Это неправильная идея.
хотя подготовленные высказывания могут быть восприняты как своего рода волшебная палочка, побег - это несиноним для «защиты от SQL-инъекций».Это просто правило строкового синтаксиса - не больше, не меньше.

Необходимо ли также использовать $ mysqli-> real_escape_string ($ num);

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

1012 *real_escape_string() необходимо использовать для строки sql , то есть части запроса, заключенные в кавычки.Должны использоваться безоговорочно, несмотря на любые предыдущие манипуляции. Поскольку любая другая часть запроса real_escape_string() является полностью бесполезной.

Объяснение:
Можно изменить правила проверки данных.
При этом правила построения SQL должны быть явными и безусловными. Чтобы разработчик никогда не задавал себе такой вопрос .
На самом деле, это совершенно разные вопросы: проверка данных и построение запросов.Зачем иметь в виду такие детали и строить запрос соответственно?Почему бы не построить запрос, основанный на некотором наборе правил общего назначения, вообще не относящихся к природе данных?

Итак, к вашему вопросу еще раз:

  • , если вы добавляете данные в запрос как есть, без кавычек, real_escape_string () в этом случае будет совершенно бесполезным, нокастинг / проверка становятся необходимостью.
  • если вы добавляете свои данные в запрос с использованием подготовленного оператора, real_escape_string () будет совершенно бесполезным и даже вредным.
  • если вы добавляете свои данные в запрос в кавычках - вы должны сделать real_escape_string () в этом случае.
  • также стоит упомянуть, что если вы добавляете свои данные в запрос как часть языка SQL - в качестве идентификатора или ключевого слова SQL - real_escape_string () также совершенно бесполезен, так же как и подготовленный оператор,Белый список - ваш единственный друг здесь
...