🔐 Альтернативные способы защиты от SQL-инъекций без prepared statements
1. Экранирование пользовательского ввода
Для MySQL можно использовать функцию
mysqli_real_escape_string(), которая экранирует специальные символы в строке, делая её безопасной для использования в SQL-запросах.$login = mysqli_real_escape_string($conn, $_POST['login']);
$query = «SELECT * FROM users WHERE login = '$login'»;
Однако этот метод не защищает от всех видов атак и может быть недостаточно эффективным, особенно если не учитывать кодировку и типы данных.
2. Приведение типов и валидация данных
Если ожидается, что пользовательский ввод должен быть определённого типа (например, целое число), следует явно приводить его к этому типу и проверять допустимость значения.
$id = (int)$_GET['id'];
$query = «SELECT * FROM products WHERE id = $id»;
Это предотвращает внедрение вредоносного кода через параметры, ожидающие числовые значения.
3. Белые списки допустимых значений
Для параметров, которые могут принимать ограниченный набор значений (например, порядок сортировки), следует использовать белые списки и проверять, что введённое значение входит в допустимый набор.
$order = $_GET['order'];
if (!in_array($order, ['ASC', 'DESC'])) {
$order = 'ASC';
}
$query = «SELECT * FROM products ORDER BY price $order»;
Это предотвращает возможность внедрения произвольного SQL-кода через параметры.
4. Использование хранимых процедур
Хранимые процедуры, определённые на стороне базы данных, могут помочь изолировать SQL-логику от пользовательского ввода. Однако они также могут быть уязвимы, если параметры не обрабатываются должным образом.
⚠️ Почему эти методы менее надёжны
🔸 Экранирование и валидация требуют тщательной реализации и могут быть легко нарушены при изменении кода.
🔸 Ошибки в логике проверки или упущенные случаи могут открыть путь для атак.
🔸 Эти методы не обеспечивают такой же уровень защиты, как подготовленные выражения, особенно при работе с различными типами данных и кодировками.