SQL Injection: Second-Order

# SQL-инъекция второго порядка ## Сценарий «Фрегат Маркет» — маркетплейс снаряжения для яхтинга. Разработчик недавно прошёл корпоративный курс по SQL-инъекциям и на радостях перевёл все формы записи на параметризованные запросы. Вас позвали на повторный аудит: убедиться, что дыр не осталось. Искать нужно не там, где ввод принимают, а там, где сохранённые данные читают. ## Цель 1. Найдите обработчик, который подставляет логин, сохранённый при регистрации, в другой SQL-запрос через строковую интерполяцию. 2. Зарегистрируйте аккаунт с таким логином, чтобы при последующем чтении условие отбора стало всегда истинным и запрос вернул записи всех пользователей. 3. Откройте страницу профиля: среди заказов окажется чужой заказ с товаром «CTF Flag», и флаг отобразится на странице. ## Теория Инъекция второго порядка срабатывает не в момент ввода, а позже: значение безопасно сохраняется в базу через параметризованный запрос, но затем читается и вклеивается в другой запрос уже как текст. Ошибка мышления — «данные из базы доверенные, мы сами их туда положили». Для парсера SQL сохранённая строка ничем не отличается от свежего ввода: спецсимволы в ней так же меняют структуру запроса. **Уязвимый паттерн:** ```python query = f"SELECT id, product_name, price FROM orders WHERE user_id IN (SELECT id FROM users WHERE username = '{user['username']}')" ``` Логин достаётся из базы через сессию и интерполяцией попадает в новый запрос. Зарегистрировав аккаунт с логином-ловушкой, атакующий при первом же открытии профиля получает выборку чужих заказов: всегда истинное условие превращает «мои заказы» в «все заказы», включая заказ администратора с флагом. ## Точка входа атаки `POST /register` — форма регистрации с полями `username`, `password`, `fullname`; затем вход через `POST /login` и просмотр `GET /profile`. * **Обычный пользователь:** `demo` / `demo` * **Аккаунт для атаки:** создайте сами — логин и есть инструмент