Стандартные запросы Sql против подготовленных операторов в фреймворке php и codeigniter

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

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

Но с точки зрения безопасности мне было интересно, в чем разница между этими тремя примерами запросов.

Я знаю, что первый запрос ($ запрос) с параметрами привязки является самым безопасным и наиболее идеальным для использования, но безопасны ли два других примера запросов ($ query2 и $ query3) при использовании фреймворка CodeIgniter?

И если мы просто используем php, безопасен ли $ query3, потому что переменная данных цитируется?

Запрос 1

$query = "SELECT * FROM users WHERE id = ?";

$bind  = array($id);
$query = $this->db->query($query, $bind);

Запрос 2

$query2 = "SELECT * FROM users WHERE id = '" . $this->db->escape_str($id) . "'";

Запрос 3

$query3 = "SELECT * FROM users WHERE id = '" . $id . "' ";  

1) такая же, как и любая другая привязка, которую вы когда-либо использовали; 2) правильный способ экранирования элемента из входных данных без привязки; 3) плохой; ничего не ускользнуло

Alex 19.07.2018 06:39

просто используйте первый

Kevin 19.07.2018 06:40

@Alex Спасибо :) так что, если бы я использовал второй, это совершенно безопасно при работе с данными из ввода, или это не так безопасно, как привязка? Бывают случаи, когда привязку труднее использовать, вот и все

Mason 19.07.2018 06:42

@Mason использует escape() вместо escape_str() Чтение - stackoverflow.com/a/48575820/4595675

Abdulla Nilam 19.07.2018 06:46

Я не могу сказать, насколько это безопасно. Я могу сказать, что способ, которым я это делаю (который автоматически сбегает), использует построитель запросов, например. $this->db->get_where('users', $id);

Alex 19.07.2018 06:48

также обратите внимание, что если вы используете escape() вместо escape_str(), он добавляет 'var' (одинарные кавычки), что не очень хорошо для многих вещей, таких как SHOW COLUMNS FROM 'projects' (ошибка sql)

Alex 19.07.2018 06:54

Большое спасибо @Alex и @Abdulla Nilam. Что касается escape() и escape_st(), в документах CI упоминается, что $this->db->escape_str() экранирует передаваемые ему данные, независимо от типа, тогда как escape() определяет тип данных, так что он может экранировать только строковые данные. Значит ли это, что не строковые данные не нужно экранировать? Спасибо

Mason 19.07.2018 07:07

@Alex - Спасибо, классные ответы!

Mason 19.07.2018 07:18
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
1
9
64
0

Другие вопросы по теме