#php #mysqli #sql-injection #prepared-statement
#php #mysqli #sql-инъекция #подготовленное заявление
Вопрос:
прямо сейчас я использую подготовленные инструкции для выбора / вставки данных в mysql. Хорошо, мой вопрос, я узнал об атаках второго порядка. Итак, пользователь, например, регистрируется на моем сайте. И использует в качестве адреса электронной почты или имени пользователя что-то вроде этого
"username '; DELETE Orders;--"
это приводит к вставкам в таблицу mysql
Поэтому, когда я снова получаю данные с помощью подготовленного оператора и снова вставляю / делаю что-то с ним в подготовленном операторе.
Я был бы в безопасности, потому что я использую подготовленные операторы?
Пример:
Get Bad Data:
$sql = "SELECT * FROM USERS where USERID = 1";
...
$stmt->bind_result($username);
...
Next Query:
INSERT or do other things:
$SQL = "SELECT * FROM email WHERE USERNAME = ?";
....
$stmt->bind_param('s', $username);
...
После того, как я подумал, я был бы в безопасности, если бы я сделал это так? Или возможна утечка?
Но я был бы атакован, если бы я это сделал:
$sql = "SELECT * FROM email WHERE username = $username";
$stmt = $mysqli->prepare($sql);
$stmt->execute();
Спасибо 🙂
Комментарии:
1. Почему бы вам никогда не использовать подготовленный оператор, если у вас есть его поддержка? 🙂
2. да, ваше право, я уже делаю, но просто любопытно … если я все еще атакуемый, только что изучил кодирование: P
3. @Marcus: подготовленные операторы не могут обрабатывать все типы запросов. Иногда вам приходится использовать baremetal и не использовать их, даже когда они доступны и желательны.
4. @MarcB Когда нельзя использовать подготовленные операторы? Любая ссылка или описание будут оценены 🙂
5. @Marc B Конечно… и вы все равно можете сделать это с помощью генерации запросов с заполнителями и значениями. Нет причин становиться неаккуратным и начинать вставлять данные в саму строку SQL 🙂
Ответ №1:
До тех пор, пока заполнители последовательно используются (везде!) Для всех [переменных] данных, все атаки с использованием SQL-инъекций * предотвращаются, второго порядка или иным образом.
Это не означает, что нет уязвимостей или других векторов атаки, но это означает, что кто-то с «умным именем пользователя» не сможет отправить неожиданное «УДАЛЕНИЕ» в базу данных. Как указывалось, если где-либо используется «небезопасный оператор SQL», тогда, бам!гарантии отключены.
(Набор «небезопасных операторов SQL» включает, но не ограничивается, любым таким оператором, который не использует заполнители для всех [переменных] данных.)
Счастливого кодирования.
* Это предполагает, конечно, отсутствие ошибок / уязвимостей в драйвере поддержки / базы данных-заполнителей. Но это уже другая история…