SQL Injection: Second-Order через сохранённый username профиля

# SQL-инъекция второго порядка: сохранённый логин ## Сценарий Геймдев-студия **«Артель-Софт»** после рефакторинга регистрации просит вас перепроверить магазин мерча на Express и SQLite. Привычные уязвимые места разработчик закрыл: форма регистрации пишет данные в базу параметризованно, и «в лоб» инъекция там не проходит. Ваша гипотеза — где-то позже эти же данные читаются и снова попадают в SQL, уже без параметров. ## Цель 1. Убедитесь, что момент записи защищён и прямая инъекция в форме регистрации не работает. 2. Найдите обработчик чтения, где сохранённый при регистрации логин попадает в другой SQL-запрос сборкой строки. 3. Зарегистрируйтесь со специальным значением логина, войдите и добейтесь, чтобы страница профиля показала заказы всех пользователей — и флаг вместе с ними. ## Теория Инъекция второго порядка срабатывает не в момент ввода, а позже: пользовательские данные безопасно сохраняются в базе, а затем читаются и подставляются в другой запрос уже как «доверенные». Логика «мы сами это записали — проверять не нужно» и есть корень ошибки: сохранённое значение — тот же недоверенный ввод. **Уязвимый паттерн:** ```js const query = `SELECT id 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` * **Ваша учётная запись:** создаётся самостоятельно при регистрации