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

Question

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

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

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

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

Спасибо,

Kevin

UPDATE: Для уточнения запроса я делаю вид, как этот

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

PHP mysqli Prepared Statements

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

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

и вы связываете ваши ценности заявление:

array("bradley", "Passw0rd"); 

Безопасность приходит, как короткий ответ, является тот факт, вы не Concat значения в строку запроса самостоятельно. Сделать его менее склонным к SQL-инъекции.