SQL-инъекция SQLi
Атака на сайт, при которой человек вводит команды для базы данных в форму или веб-адрес. Сайт выполняет их и раскрывает, меняет или удаляет данные, которые должен защищать.
Другие названия SQLi SQL injection SQL-внедрение атака SQL-инъекцией внедрение SQL-кода инъекция в базу данных
Определение
Что такое SQL-инъекция
У вас интернет-магазин. Посетитель вводит в строку поиска что-то странное, нажимает Enter, и страница показывает ему имена, телефоны и историю заказов всех ваших клиентов. Никто не крал пароль. Он ввёл нужные слова не в то место, а остальное сделал ваш сайт. Это и есть SQL-инъекция.
Большинство сайтов хранят информацию в базе данных: упорядоченном хранилище таблиц, немного похожем на набор электронных таблиц. Чтобы прочитать или изменить эту информацию, сайт говорит на языке SQL (Structured Query Language). Каждая просьба, которую он отправляет, называется запросом, например «найди клиента с этим адресом почты».
SQL-инъекция случается, когда сайт берёт то, что ввёл посетитель, и вставляет это прямо в один из таких запросов. Если посетитель вместо обычного текста напишет SQL, база данных не увидит разницы и выполнит команду злоумышленника так, будто её написал сам сайт. Часто название сокращают до SQLi.
Как работает атака через SQL-инъекцию
Представьте банковского служащего, который передаёт сотрудникам хранилища любую записку клиента слово в слово. Обычная записка говорит «покажите мой баланс». Хитрая говорит «покажите мой баланс, а заодно откройте все сейфы». Если служащий никогда не читает записку заранее, сотрудники хранилища подчиняются.
На сайте шаги обычно выглядят так:
- Злоумышленник ищет место, которое отправляет текст в базу данных: форму входа, строку поиска, форму обратной связи или сам веб-адрес, например страницу товара, которая заканчивается на «?id=25».
- Он вводит небольшой кусок SQL вместо обычного текста. Известный пример: ввести ' OR '1'='1 в поле пароля на форме входа.
- Сайт без проверки присоединяет этот текст к своему запросу. Теперь запрос звучит примерно так: «впусти этого человека, если пароль верный или если 1 равно 1».
- Раз 1 всегда равно 1, база данных отвечает «да», и злоумышленник входит, не зная никакого пароля.
Некоторые атаки проходят тише. При слепой SQL-инъекции страница вообще не показывает данных, поэтому злоумышленник задаёт базе вопросы с ответом да или нет и следит, как реагирует страница или как долго она загружается. Вручную это медленная работа, поэтому злоумышленники поручают её бесплатным автоматическим программам.
Что может сделать злоумышленник
Когда база данных начинает выполнять его команды, ущерб зависит от того, что разрешено учётной записи сайта в базе данных. Часто это гораздо больше, чем нужно сайту. Злоумышленник может:
- читать личные данные, например имена, адреса, почту и историю заказов клиентов, медицинские записи или сохранённые пароли
- входить под другим пользователем, в том числе под администратором
- менять данные, например цены, балансы или статусы заказов
- удалять целые таблицы или всю базу данных
- в некоторых системах добраться до самого сервера и оставить на нём вредные файлы
Почему это важно для вашего бизнеса
SQL-инъекция одна из самых старых атак в интернете, и она никуда не делась. OWASP, открытое сообщество, которое публикует известный список OWASP Top 10 рисков веб-приложений, уже много лет держит инъекции в этом списке. Атаку легко попробовать, а на многих сайтах до сих пор есть какая-нибудь забытая форма, которая её пропускает.
Для владельца бизнеса настоящие потери редко бывают техническими. Это утёкший список клиентов, магазин, который продаёт по неверной цене, система бронирования, потерявшая неделю записей, или письмо, в котором вам приходится сообщать клиентам, что их данные раскрыты. Во многих странах законы о защите данных, такие как GDPR, к тому же требуют защищать персональные данные и сообщать об утечках.
Каждую ли форму на вашем сайте делали с учётом этого риска? Сайты, наспех собранные из старых плагинов или переделанные многими руками за годы, чаще прячут слабое место.
Как защитить сайт от SQL-инъекций
Главное решение хорошо известно, и оно работает. Основная часть защиты заложена в том, как построен сайт, так что это хорошие вопросы для ваших разработчиков или подрядчика.
- Подготовленные запросы. Их ещё называют параметризованными запросами. Сайт отправляет запрос и текст посетителя по отдельности, поэтому база данных всегда считает этот текст просто данными и никогда не выполняет его как команду. Это главная защита. Современные фреймворки, например Laravel, делают так по умолчанию, когда разработчики пользуются их встроенными инструментами для работы с базой данных.
- Проверка ввода. Поле для номера телефона должно принимать только цифры, а поле для даты только даты. Если сразу отклонять странный ввод, многие двери закроются.
- Минимальные права. Учётная запись, через которую сайт обращается к базе, должна иметь только те права, которые ей нужны. Публичной странице поиска незачем удалять таблицы.
- Сдержанные сообщения об ошибках. Подробная ошибка базы данных на экране даёт злоумышленнику карту. Показывайте посетителям короткое простое сообщение, а подробности храните в закрытых журналах.
- Обновления. Вовремя обновляйте платформу, плагины и библиотеки, потому что в старых версиях часто есть известные дыры.
- Файрвол веб-приложений. Это фильтр перед сайтом, который блокирует многие известные схемы атак ещё до того, как они дойдут до вашего кода. Он помогает, но небезопасный код не чинит.
- Регулярные проверки. Тест на проникновение (безопасная, заранее спланированная атака, которую проводят специалисты) и сканирование уязвимостей находят слабые места раньше злоумышленника.
Вот как выглядят привычные подходы в сравнении:
| Рискованная привычка | Более безопасная привычка |
|---|---|
| Вставлять текст посетителя прямо в запрос | Использовать подготовленные запросы везде |
| Одна учётная запись базы данных с полными правами на всё | Ограниченная учётная запись для каждой части сайта |
| Показывать полные ошибки базы данных на странице | Короткое сообщение для посетителей, подробности в закрытых журналах |
| Плагины, которые месяцами не обновлялись | Регулярные обновления и понятный список всего установленного |
| Проверять только то, что функции работают | Проверять также, что будет, если кто-то введёт что-то вредное |
Частые ошибки
- Доверять проверкам в браузере. Проверки, которые работают на устройстве самого посетителя, легко обойти, поэтому сервер должен проверять всё ещё раз.
- Думать, что маленький сайт в безопасности. Автоматические программы проверяют огромное число сайтов, не глядя на их размер.
- Исправить одну форму и забыть про остальные. Строке поиска, фильтрам, веб-адресу и API за мобильным приложением нужно одинаковое внимание.
- Хранить пароли открытым текстом. Если данные утекут, пароли, сохранённые с надёжным хешированием (превращённые в перемешанный код, который нельзя прочитать обратно), использовать гораздо труднее.
- Полагаться только на файрвол. Фильтр даёт выиграть время. Небезопасный запрос за ним всё равно нужно исправить.
Чем мы можем помочь
В Linkysoft проверка на SQL-инъекции входит в наши услуги по кибербезопасности. Мы проводим безопасные имитации атак на ваш сайт, приложение и API, проверяем код и даём понятный список того, что нашли, и того, как это исправить. После исправлений мы проверяем снова. Это подходит и для сайтов, которые делали другие команды, а бесплатная проверка безопасности станет лёгким первым шагом.
Планируете новую систему? Наши веб-приложения и системы управления защищены с самого начала: усиление по OWASP Top 10 и тест на проникновение перед запуском.
Частые вопросы о SQL-инъекция
Что такое SQL-инъекция простыми словами?
Может ли SQL-инъекция угрожать маленькому сайту?
Как узнать, уязвим ли мой сайт для SQL-инъекций?
Как лучше всего защититься от SQL-инъекций?
Остановит ли SQL-инъекцию файрвол?
Что такое слепая SQL-инъекция?
Что делать, если мой сайт атаковали через SQL-инъекцию?
SQL-инъекция это проблема только сайтов?
Всё ещё не уверены, как это относится к вашему проекту?
Расскажите, что вы планируете создать, и мы объясним всё простыми словами.