#security #practice
SQL-инъекцияВ одном из
постов ранее мы рассматривали одну из популярных атак на пользователя под названием XSS-атака. Сегодня давайте рассмотрим уязвимость «внедрение операторов SQL» или SQL-инъекцию, возникающую как следствие недостаточной проверки принятых от пользователя значений, что позволяет модифицировать запросы к базам данных (БД). Несмотря на то, что на сайте
была рассмотрена эта тема, стоит остановиться поподробнее на ней.
Итак, вы знаете, что для работы с БД был разработан специальный язык SQL-запросов. В качестве примера, рассмотрим приложение, которое обращается к базе данных со следующим запросом:
SELECT name FROM members WHERE name = 'user' AND password ='123456'.
Запрос означает следующее: выбрать (SELECT) поле name из (FROM) таблицы members где (WHERE) значение поля name равно user (name = 'user') и (AND) значение поля password равно 123456 (password ='123456'). Этот запрос вызывает обход таблицы, в результате которого делается сравнение с каждой строкой, и если наше условие является для какой-либо строки истиной, то она попадает в результаты.
При этом значения «user» и «123456» приложение получает от пользователя — например, в рамках страницы входа на сайт. Предположим, что вместо user пользователь ввёл такую строку:
user' --.
Тогда запрос к базе данных будет иметь вид:
SELECT name FROM members WHERE name = 'user' -- ' AND password ='123456'.
Две чёрточки (--) означают комментарий до конца строки, т.е. всё, что за ними, больше не учитывается. Следовательно, из выражения условия «исчезает» часть ' AND password ='123456'. Поскольку в комментарии осталась закрывающая кавычка, то она также была введена с именем пользователя, чтобы не сломать синтаксис и не вызвать ошибку, в результате, фактически, к базе данных делался следующий запрос:
SELECT name FROM members WHERE name = 'user'.
В нём была нарушена логика работы программы, заложенная разработчиками. Т.е. теперь поиск в таблице производится только по имени. И если имя совпало, то строка попадает в результаты независимо от введённого пароля. Данным примером мы хотели показать вам простоту эксплуатации SQL-инъекции. Более серьезные варианты эксплуатации вы можете посмотреть в лабораториях по ссылке ниже. В реальной ситуации, такая ошибка может быть использована на веб-сайте для входа под учётной записью администратора, для которой достаточно знать только имя, а пароль становится ненужным. Кроме обхода аутентификации, SQL-инъекция используется для извлечения информации из баз данных, вызова отказа в обслуживании (DoS), эксплуатации других уязвимостей и многого другого.
Стоит отметить, что в настоящее время подобные уязвимости встречаются довольного редко в связи с появлением различного рода фреймворков и библиотек, которые предусматривают защиту от SQL-инъекций. В рамках нашего поста был рассмотрен пример SQL-инъекции в реляционной СУБД MySQL (существуют также Oracle, Microsoft SQL Server, PostgreSQL, MariaDB). А возможны ли NoSQL-инъекции? Да! Redis, MongoDB, memcached — все эти программные продукты относятся к классу нереляционных СУБД. Интерес к перечисленным базам данных в последнее время значительно возрос и ходит миф, что нереляционные СУБД безопасны, так как они не используют SQL и злоумышленник не может провести на них атаки типа SQL-инъекция. Если в систему невозможно внедрить SQL-код, это еще не значит, что она безопасна. NoSQL закрывает одну потенциальную уязвимость, при этом открывая с десяток других, которые позволяют совершать разнообразные вредоносные действия.
Попрактиковаться в эксплуатации SQL-инъекций можно здесь:
https://proglib.io/w/6682ab1c
