SQL - В чем реальная опасность внедрения SQL?

Question

ПРИМЕЧАНИЕ: Это не вопрос о том, что является SQL-инъекцией , а скорее вопрос, чтобы выяснить, что является реальной уязвимостью, особенноприведены некоторые конкретные контрольные примеры.

Справочная информация: Пожалуйста, посмотрите это видео от группы под названием Modern Rouge .Или вы можете проигнорировать это, поскольку это упрощенно для людей, которые не имеют технических навыков и не знакомы с SQL-инъекцией .Я укажу нашу важную часть, когда это необходимо.

Итак, для тех, кто не знает, что такое SQL-инъекция (я просто добавляю это для полноты и чтобы дать справку по моему конкретному вопросу) Допустим, у меня есть PHP-код, подобный следующему:

$query = "SELECT * FROM users WHERE username='$username'";

Этот код уязвим, потому что, скажем, злоумышленник вводит свое имя пользователя как ' or 1=1;--, это может сделать окончательный запрос

SELECT * FROM users WHERE username='' or 1=1;--'

Который не имеет ожидаемого эффекта.

Итак, теперь посмотрите видео около отметка 4:00 .

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

Вот что я не получаю. В реальной жизни я бы не стал проверять пароль в PHP вместо этого, делая этот конкретный пример бесполезным?Например:

if($userRecordFromDB["pwd"] == $pwd) { // User authenticated.

Прав ли я, что SQL-инъекция не может обойти мою аутентификацию PHP?В чем здесь уязвимость?Если я не связываю проверку пароля с моим запросом (который, я признаю, можно было бы сделать для примера), даже если у меня есть уязвимый запрос, мой сайт не должен быть уязвимым.

Второй связанныйвопрос: видео продолжает указывать, что одна уязвимость может позволить злоумышленнику получить доступ ко всей моей базе данных!Я предполагаю, что они подразумевают, что злоумышленник может сделать что-то вроде этого:

SELECT * FROM users WHERE username='' or 1=1; SELECT * FROM creditInformationTable where 1=1--'

$username, конечно, будет ' or 1=1; SELECT * FROM creditInformationTable where 1=1--

Однако, это также смущает меня.Если бы я не поместил эти данные в симпатичную таблицу или что-то для них, разве эти данные никогда не покинут бэкэнд, даже если запрос был уязвим?Как они могли получить эту информацию, если я не передам ее непреднамеренно?

Что приводит меня к большему вопросу: в чем опасность внедрения SQL-кода?Это чисто теоретически, или есть реальные случаи, когда злоумышленник может сделать что-то вроде входа в систему или получить доступ ко всем таблицам в вашей БД с помощью чисто SQL-инъекции?

Редактировать: Поцарапать все это.Позвольте мне немного сузиться.

Как это покинуть сервер?Даже если что-то спросит не то, как мой злоумышленник получит это?API БД, такие как PDO и SQLI, возвращают информацию в PHP, NOT полученную страницу.Разве не должен хорошо написанный PHP-скрипт улавливать наличие неправильных данных или, по крайней мере, не выводить все это пользователю?

Answer 1

SQL-инъекция не является теоретической.Есть новостные сообщения о реальных взломах данных, совершаемых с использованием SQL-инъекций практически каждый месяц.Есть отличный сайт, который собирает их: https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/

Вот хороший пример с прошлого месяца:

https://motherboard.vice.com/en_us/article/vba5nb/fornite-login-hack-epic-games-website

Ошибки в Epic GamesСайт позволял хакерам входить в любой аккаунт игрока «Fortnite»

...

На этой странице, которая в настоящее время недоступна, содержались две уязвимости, которые часто встречаются на веб-сайтах: SQLИнъекция (или SQLi) и межсайтовый скриптинг (или XSS), по словам исследователей Check Point.

Что касается приведенных вами примеров, я рекомендую подтвердить пароль в коде приложения.Затем вы можете провести различие между «не найден аккаунт» и «аккаунт найден, но пароль неверный» (вы не хотите сообщать об этом пользователю, но вы можете зарегистрировать ошибку и, возможно, заблокировать аккаунт, если онислишком много неудачных попыток ввода пароля).

Но независимо от этого оператор SQL уязвим для внедрения SQL.Не только с показанным трюком «OR 1 = 1», но и с тем, что вы можете обмануть запрос для выполнения SQL-запросов на основе UNION:

$query = "SELECT * FROM users WHERE username='' UNION ALL SELECT * FROM INFORMATION_SCHEMA.TABLES -- '";
                                              ^^ $username ...

Если злоумышленник может найти SQL-запрос в вашемприложение (не обязательно поиск по имени учетной записи), они могут использовать эту технику для запроса всех ваших таблиц.Затем они могут использовать методы UNION для запроса данных во всех таблицах, как только узнают их имена.

---

Относительно вашего последующего вопроса:

"Какданные покидают серверную часть? "

Подумайте, выглядит ли ваш код проверки пароля (для запроса выше) следующим образом:

$query = "SELECT id, username, password_hashed FROM users WHERE username='$username'";

$stmt = $pdo->query($query);
while ($row = $stmt->fetch(PDO::FETCH_NUM)) {
  if (!password_verify($password, $row['password_hashed'])) {
    die("Invalid login for user {$row['username']}");
  }
}

Видите?Результат запроса SQL выводится пользователю.Разработчику этого кода кажется очевидным, что, поскольку они просто запросили $username, то это значение будет возвращено запросом.Они считают, что $row['username'] безопасно использовать.

Но это не так - это некоторые данные из другой части UNION.Используя CONCAT () и GROUP_CONCAT (), злоумышленник может даже собрать несколько столбцов из нескольких строк. И они это делают. Им может потребоваться несколько попыток, чтобы получить в своем атакующем запросе нужное количество столбцов в правильных позициях, но, очевидно, у них нет ничего лучше.