Вопросы с собеседований по PHP и ответы на них.
По рекламе: @tproger_sales_bot
Учиться у нас: clc.to/5JWKxA
Для обратной связи: @proglibrary_feeedback_bot
Post #1175
932
Как защититься от SQL-инъекций без prepared statements?
🔐 Альтернативные способы защиты от SQL-инъекций без prepared statements
1. Экранирование пользовательского ввода
Для MySQL можно использовать функцию
Однако этот метод не защищает от всех видов атак и может быть недостаточно эффективным, особенно если не учитывать кодировку и типы данных.
2. Приведение типов и валидация данных
Если ожидается, что пользовательский ввод должен быть определённого типа (например, целое число), следует явно приводить его к этому типу и проверять допустимость значения.
Это предотвращает внедрение вредоносного кода через параметры, ожидающие числовые значения.
3. Белые списки допустимых значений
Для параметров, которые могут принимать ограниченный набор значений (например, порядок сортировки), следует использовать белые списки и проверять, что введённое значение входит в допустимый набор.
Это предотвращает возможность внедрения произвольного SQL-кода через параметры.
4. Использование хранимых процедур
Хранимые процедуры, определённые на стороне базы данных, могут помочь изолировать SQL-логику от пользовательского ввода. Однако они также могут быть уязвимы, если параметры не обрабатываются должным образом.
⚠️ Почему эти методы менее надёжны
🔸 Экранирование и валидация требуют тщательной реализации и могут быть легко нарушены при изменении кода.
🔸 Ошибки в логике проверки или упущенные случаи могут открыть путь для атак.
🔸 Эти методы не обеспечивают такой же уровень защиты, как подготовленные выражения, особенно при работе с различными типами данных и кодировками.
🔐 Альтернативные способы защиты от 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-логику от пользовательского ввода. Однако они также могут быть уязвимы, если параметры не обрабатываются должным образом.
⚠️ Почему эти методы менее надёжны
🔸 Экранирование и валидация требуют тщательной реализации и могут быть легко нарушены при изменении кода.
🔸 Ошибки в логике проверки или упущенные случаи могут открыть путь для атак.
🔸 Эти методы не обеспечивают такой же уровень защиты, как подготовленные выражения, особенно при работе с различными типами данных и кодировками.
- ❤ 1
- 👍 1
- 🤔 1
- 😢 1
