Как работает sql инъекция?

Короткий вывод: инъекция работает, потому что программист склеивает SQL-запрос из строк, а пользовательский ввод в этой склейке ничем не отделён от самого кода запроса. Причина в деталях: если запрос собран через прямую склейку с переменной login, а $login \text{взят} \text{прямо} \text{из} \text{формы}, \text{то} \text{пользователь} \text{может} \text{вписать} \text{туда} \text{не} \text{имя}, \text{а} \text{кусок} SQL, \text{вроде} \text{условия} OR 1=1, \text{и} \text{тогда} \text{условие} \text{в} \text{запросе} \text{становится} \text{всегда} \text{истинным}, \text{база} \text{отдаёт} \text{данные}, \text{которые} \text{отдавать} \text{не} \text{должна} \text{была}.$ Почему так вообще возможно: SQL не отличает текст, который ввёл человек, от части кода запроса, для базы это просто одна строка символов, и если её не подготовить правильно, опасный кусок выполнится как обычная часть команды. Лечится это одним способом: подготовленные выражения через PDO или mysqli, где значения передаются отдельно от текста запроса и физически не могут превратиться в код.

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

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

Шаг | Что происходит

1. Уязвимый код | Запрос собирается так: SELECT * FROM users WHERE login равен $login AND password \text{равен}$password, где $login \text{и}$password берутся прямо из формы без обработки.
2. Обычный ввод | Пользователь вводит admin и 123, запрос превращается в поиск строки с логином admin и паролем 123, всё как задумано.
3. Вредный ввод | Вместо пароля пишут что-то вроде OR 1=1, запрос превращается в условие, где password либо равен странной строке, либо 1=1, а 1=1 всегда истина.
4. Результат | База находит первую попавшуюся запись пользователя, потому что условие после OR выполняется всегда, и вход происходит без знания настоящего пароля.
5. Что дальше | Через похожий приём можно не только обходить вход, но и вытаскивать чужие данные, менять их или удалять таблицы, если в запросе используется что-то вроде UNION SELECT.

Чтобы понять, уязвим ли у вас вход, посмотрите в код: если логин и пароль подставляются прямо в текст SQL-запроса через точку или переменную внутри строки, а не через подготовленные выражения с плейсхолдерами, то да, дыра есть. Лечится это переходом на PDO или mysqli с параметризованными запросами, где значения передаются отдельно от текста запроса и база сама не даёт им превратиться в код.