Вопросы о атаках второго порядка MYSQL

#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» включает, но не ограничивается, любым таким оператором, который не использует заполнители для всех [переменных] данных.)

Счастливого кодирования.


* Это предполагает, конечно, отсутствие ошибок / уязвимостей в драйвере поддержки / базы данных-заполнителей. Но это уже другая история…