SQL-инъекции, являясь одной из наиболее известных уязвимостей, за последние 20 лет, вероятно, нанесли ущерб в миллионы (если не миллиарды) долларов тысячам компаний. Уязвимость была впервые задокументирована в 1998 году сотрудником Phrack и исследователем безопасности Джеффом Форристалом. Интернет так и не восстановился.
Так что это?
Чтобы понять, что такое атака с использованием SQL-инъекции, нам нужно иметь краткое руководство о том, как пользовательские интерфейсы обычно взаимодействуют с серверной частью или базой данных:
Когда пользователь отправляет форму или выполняет какое-либо другое действие, требующее обратной связи с серверной частью, эти данные передаются либо с помощью API, либо с помощью такого языка, как PHP, который взаимодействует на уровне сервера, но запускается в браузере.
В случае API браузер отправляет запрос конечной точке, который содержит все данные, необходимые для выполнения запроса. Затем API отправляет ответ, и код на веб-странице обрабатывает полученные данные. В PHP код, который обращается к серверу, загружается самим веб-сервером и запускается путем вызова имени файла из браузера. Например, чтобы отправить форму, файл с именем «submit.php» может быть объявлен как «действие» в HTML-коде формы. Когда пользователь нажимает кнопку для отправки, затем вызывается этот файл, и параметры отправляются либо через данные POST, либо как параметры URL-адреса в запросе GET.
Предположим, что данные на сервере используются для запроса базы данных. Небезопасный способ сделать это, открывающий приложение для атаки путем внедрения, - это просто интерполировать предоставленные данные в запрос к базе данных (чаще всего в запросе SQL).
Простой пример
Вот пример кода на стороне сервера, который может обрабатывать запрос:
Вы можете видеть, что переменная $ size, поступающая из запроса, по существу помещается в запрос без какого-либо преобразования содержащихся данных. Это означает, что злоумышленник может поместить в запрос любые данные, которые ему нужны. Обратите внимание, что переменная $ size в запросе заключена в одинарные кавычки. Запрос ожидает строку, заключенную в эти кавычки, и примет все, что предоставлено, если это правильный синтаксис. Вы также можете заметить, что SQL-запрос явно не закрывается точкой с запятой, что также является плохой практикой.
Давайте использовать это!
С этим кодом ничто не мешает злоумышленнику отправить что-то с запросом:
размер = ’ИЛИ 1 = 1; -
который преобразовал бы запрос в это:
ВЫБЕРИТЕ идентификатор, имя, вставку, размер ИЗ продуктов, ГДЕ размер = ’’ ИЛИ 1 = 1; -
Это превращает предполагаемый запрос во что-то непреднамеренное; запрос теперь возвращает каждую запись, потому что оператор OR говорит: «Если размер такой, или 1 = 1». Ну, 1 действительно равно 1, поэтому все записи соответствуют этому запросу. Двойные дефисы комментируют все, что следует за ними, по сути блокируя их включение в запрос.
Что-то более злонамеренное может принять форму этого запроса:
size = ’; Продукты DROP TABLE;
Что будет выполнять запрос на удаление таблицы продуктов после выполнения первого запроса.
Возможности безграничны. Злоумышленник может запросить такие таблицы, как information_schema.tables, чтобы увидеть, какие таблицы находятся в базе данных, а затем начать перечисление этих таблиц, не имея каких-либо предварительных знаний о том, как настроена база данных. Так происходит кража пользовательских данных и манипулирование данными.
Профилактика
Так как же предотвратить подобное? Очистите вводимые пользователем данные и не вставляйте данные напрямую в SQL-запросы. Санитизация просто означает удаление или «экранирование» символов, которые могут мешать запросу (например, кавычек, дефисов и точек с запятой). Вы можете избежать включения данных непосредственно в запрос, используя в своем коде библиотеку ORM или объектно-реляционное сопоставление, которое обеспечивает уровень абстракции от необработанных запросов и часто имеет встроенную защиту от атак с использованием инъекций и других уязвимостей.
Заключение
Вот и все. В дикой природе эти точки инъекции часто труднодоступны, и для их обнаружения требуется много проб и ошибок и специальных инструментов из-за возраста и подверженности уязвимости. Но они все еще существуют, и их могут использовать те, у кого есть время и знания.
