… это несанкционированный SQL запрос к вашей базе данных, который может привести к утечке или потере данных. Ча­ще все­го такие уяз­вимос­ти воз­ника­ют в функционале, который читает информацию из базы данных. Например поис­к, ком­мента­рии и т.п.  Давайте на примере. Допустим, Петя зашел на сайт магазина автозапчастей, который никак не защищен от SQL инъекций.  — Петя вводит в поисковую строку слово «бампер» и нажимает «Найти».  — Браузер отправляет на сервер запрос со строкой «бампер».  — Сервер формирует запрос к базе данных для поиска информации. Этот SQL запрос заранее сформирован и в него подставляется слово «бампер».  — База данных ищет строки в таблице товаров, которые соответствуют заданным условиям, и отправляет результаты обратно.  — Сервер объединяет результаты поиска и выводит результат в браузер Пети. Петя видит красиво оформленную страницу с изображением бамперов, ценами и прочей информацией.  Но что, если передать не слово «бампер», а SQL инъекцию?  Например, у нас есть запрос, который мы делаем к базе данных при поиске бамперов. Выглядит он так:  SELECT * FROM goods WHERE name LIKE '%$user_input%'  Здесь $user_input - то, что напишет пользователь в строке поиска._

Давайте введем в строку поиска E' or 1=1 -- SELECT * FROM goods WHERE name LIKE 'E' or 1=1 --'  После такого запроса мы получим в ответ все данные из таблицы goods.  Но товары мы и так можем получить. А что если получить другую информацию из базы данных?  Давайте так же введем в строку поиска 1' UNION SELECT * FROM users--  _SELECT * FROM goods WHERE name LIKE '1' UNION SELECT * FROM users--  В результате получим данные о товарах и пользователях сайта. Этот запрос выглядит уже поопасней, не так ли?  Как защищаться от этой атаки?  — Использовать параметризованные запросы — это самый эффективный способ предотвратить инъекции, так как данные передаются отдельно от SQL-запроса, что исключает возможность их исполнения как части SQL-кода.  — Использовать ORM  — современные фреймворки и библиотеки для работы с базами данных автоматически защищают от инъекций.  — Фильтровать и валидировать вводимые данные — проверять пользовательские данные на корректность (не допускать специальных символов, таких как ', --, ;).  — Ограничить права доступа к базе данных — выдавать только минимальные права SQL, чтобы нельзя было выполнять нежелательные операции (например, удаления таблиц).  — Использовать веб-фреймворки с встроенной защитой — большинство современных фреймворков (например, Django, Laravel, Ruby on Rails) уже включают защиту от инъекций по умолчанию.  —  Тема защиты от SQL инъекций уже много раз обсуждалась, но каждый раз мы встаем на одни и те же грабли. 27 ноября 2024 выявлена уязвимость в системе мониторинга Zabbix, которая позволяет атакующему выполнить произвольные SQL-запросы. Уязвимость может быть использована для полной компрометации инфраструктуры, находящейся под мониторингом Zabbix.  Мой телеграм @katimvprod