кавычки вокруг значений int в запросах mysql

#php #mysql

#php #mysql

Вопрос:

У меня вошло в привычку фильтровать отправленную пользователем переменную через мою функцию int, которая проверяет, что это число (если не возвращает 0), и не заключает переменную в кавычки в запросах mysql.

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

Пример:

 if($perpage != $user['perpage']){
if($perpage == 50 || $perpage == 100 || $perpage == 200 ){
$DB->query("UPDATE users SET perpage=$perpage WHERE id=$user[id]", __FILE__, __LINE__);
}
}
  

Комментарии:

1. Мне интересно узнать, получу ли я что-нибудь с точки зрения производительности, делая это. Очевидно, я чувствовал бы себя намного безопаснее, заключая их в кавычки.

2. кажется, вы используете какой-то древний способ получения файла и строки ошибки. В настоящее время нет необходимости устанавливать его вручную. trigger_error() или debug_backtrace() сделают это за вас

3. что касается производительности. У вас возникают какие-либо проблемы с этим прямо сейчас?

4. @Col Сайт еще не запущен… Я перекодирую старый скрипт. Раньше он использовал 100% памяти mysql (на сервере было 4 ГБ оперативной памяти), и 200 человек были онлайн одновременно. Я рассмотрю функции, которые вы назвали. Похоже, я проделал много избыточной работы.

5. Что ж, если у вас есть устаревший код с проблемами производительности, разумным выбором было бы не бороться с некоторыми несущественными проблемами случайным образом, а профилировать ваше приложение и найти реальную причину (ы).

Ответ №1:

ага! интересный случай здесь!

  1. В целом вы правы. Всегда лучше рассматривать числа как числа, а не строки

    • это делает ваш код более разумным и последовательным
    • strict_mode настройка в mysql, которая не позволит вам маскировать число как строку, если она включена.
  2. Но ваша реализация фактически допускает внедрение! Давайте оставим это для вашей домашней работы, чтобы найти это 🙂

Вот ссылка для вас, объясняющая эту инъекцию:http://php.net/language.types.type-juggling

итак, я бы сделал ваш код таким

 $perpage = intval($perpage);
if($perpage != $user['perpage'] amp;amp; in_array($perpage,array(50,100,200) { 
  $DB->query("UPDATE users SET perpage=$perpage WHERE id=$user[id]"); 
} 
  

Комментарии:

1. Я думаю, вы пропустили второе «если». Значение может быть только 50, 100 или 200. Нет места для инъекций. 😉

2. Я не понимаю. Если бы в запрос передавалось что-либо, кроме этих трех чисел, то это было бы уязвимо. $perpage в любом случае не может быть ничем иным, кроме числа.

3. кажется, вы еще не знакомы с PHP 🙂 как простой $ perpage "50 inject anything here" пройдет вашу проверку. Вы должны приводить свои числа, а не просто сравнивать.

4. Боже, я не понимаю, почему или как, но вы, похоже, правы. Что также означает, что у меня сайт, полный дыр в безопасности. Это совсем не хороший день. Итак, под приведением вы подразумеваете, что я должен заключать их в кавычки и использовать их как строки? Совершенно нелогично.

5. нет. под приведением я подразумеваю явное приведение к желаемому типу. как предложил Мэтт, используйте intval() для целых чисел, и это было бы довольно безопасно.

Ответ №2:

До тех пор, пока значения правильно проверяются с помощью метода intval PHP перед их использованием, я не вижу в этом проблемы. Вы могли бы оказать себе некоторую услугу в будущем, сделав это, если вам когда-нибудь придется взаимодействовать с базой данных, которая считает кавычки вокруг значений int синтаксической ошибкой. (Я полагаю, что MS SQL Server делает это.)