SQLI — не просто абстрактная уязвимость из учебника, а классика, которая до сих пор регулярно приводит к громким взломам. Это история про то, как отсутствие одной функции mysqli_real_escape_string() может стоить миллионов долларов. Рассмотрим как это работает подробнее...
Вместо логина передаём в поле ввода гениальную строчку:
' OR '1'='1' --И вот уже запрос:
SELECT * FROM users WHERE login = '$login' AND password = '$pass' Превращается в запрос:
SELECT * FROM users WHERE login = '' OR '1'='1' --' AND password = '$pass'-- комментирует всё после, а '1'='1' всегда истинно. Добро пожаловать в систему.🖥 Более высокий уровень: UNION-based атака
' UNION SELECT username, password FROM users --
Если колонки совпадают, вы получите всю базу логинов и хешей.
Из истории эпичных взломов:
1. Heartland Payment Systems (2008) — через SQLI хакеры установили малварь на сервера процессинговой компании, скомпрометировав 130+ миллионов кредитных карт. Ущерб — сотни миллионов долларов.
2. Yahoo (2012) — атака через union-based инъекцию привела к утечке 453 тысяч логинов и паролей в открытый доступ. Пароли хранились в plain text — отдельный позор.
3. TalkTalk (2015) — подростки взломали телеком-гиганта через элементарную SQLI, получив доступ к данным 157 тысяч клиентов. Компания потеряла £60 млн и репутацию.
▪️«Невозможный» взлом Lamo и Th3j35t3r — в 2001-2002 годах хакер Адриан Ламо использовал SQLI (среди других методов) для проникновения в сети NYT и Yahoo, просто вводя payload-ы в формы поиска на сайтах.
▪️Группа «D33D Company» — в 2012 году через SQLI выкачали и слили в открытый доступ 1 миллион Apple UDID-ов. Заявление хакеров: «Мы сделали это, чтобы поднять вопрос о безопасности».
Даже в 2024 году OWASP включает Injection в Top-3 угроз. Защита — это не только prepared statements, но и:
▫️ Валидация и эскейпинг входных данных
▫️ Принцип минимальных привилегий для DB-пользователя
▫️ Регулярный аудит и тесты (например, sqlmap в умелых руках)
🔐 Prepared Statements — или как перестать конкатенировать и начать жить. Если вы до сих пор собираете SQL-запросы склейкой строк, у нас для вас плохие новости. Prepared Statements (подготовленные выражения) — это единственный цивилизованный способ обезопасить запросы к БД. Это не просто «рекомендация», а обязательный паттерн.
Представьте, что вы даёте инструкцию сварщику:
❌ Конкатенация (уязвимо): «Свари мне конструкцию вот по такому чертежу {user_input}» — где user_input может быть "а потом разбери соседний танк".
✅ Prepared Statement: «Вот держатель (шаблон), а вот отдельно деталь, которую нужно вставить в держатель. Свари только так». Деталь физически не может стать инструкцией.
Раньше (плохо):
$query = "SELECT * FROM users WHERE login = '$login' AND password = '$pass'";
$result = mysqli_query($conn, $query);
Теперь (как надо):
// 1. Шаблон с плейсхолдерами (?)
$stmt = $conn->prepare("SELECT * FROM users WHERE login = ? AND password = ?");
// 2. Привязываем переменные к плейсхолдерам (типизация!)
$stmt->bind_param("ss", $login, $pass);
// 3. Выполняем
$stmt->execute();
Или для PostgreSQL:
$stmt = $pdo->prepare("SELECT * FROM users WHERE login = :login AND password = :pass");
$stmt->execute(['login' => $login, 'pass' => $pass]);Что происходит на самом деле?
1. Компиляция шаблона: DB-сервер заранее анализирует структуру запроса, понимает, где WHERE, что такое login, и запоминает план выполнения.
2. Отдельная передача данных: Ваши $login и $pass передаются после компиляции шаблона.
3. Безопасность: Даже если в $login передать ' OR '1'='1', это будет интерпретировано не как команда SQL, а просто как строка для сравнения с полем login. Инъекция невозможна в принципе.
Если в вашей кодовой базе до сих пор есть строки типа "SELECT * FROM " . $table . " WHERE id = " . $id, остановите разработку и проведите рефакторинг. Прямо сейчас. Время, сэкономленное на написании «быстрого костыля», вы потратите в сотни раз больше на расследование инцидента.
💡 Physics.Math.Code // @physics_lib