Слабая Парольная Политика

## Сценарий **DevStore** — интернет-магазин товаров для разработчиков. Команда только что выпустила MVP: регистрация, вход, каталог, профиль — и руководство пригласило вас как security-инженера проверить подсистему паролей до открытия площадки для широкой аудитории. Опыт подсказывает: если при регистрации сервер не проверяет сложность пароля, то и встроенные привилегированные учётные записи, скорее всего, создавались без ограничений. Эту гипотезу и предстоит проверить на практике. ## Цель 1. Зарегистрируйте тестовый аккаунт и определите, какую парольную политику применяет сервер. 2. Опираясь на сделанный вывод, войдите в учётную запись администратора. 3. Оформите заказ на товар «CTF Flag» и получите флаг в профиле. ## Теория Уязвимость складывается из двух связанных слабостей. Первая: обработчик регистрации отвергает только пустое поле пароля — ни длины, ни требований к классам символов. Пользователи вправе выбирать односимвольные и словарные пароли, взламываемые по общедоступным словарям за мгновения. Вторая: пароль встроенной привилегированной учётной записи задаётся при инициализации базы предсказуемым значением. **Уязвимый паттерн:** ```python admin_pass = "admin" # предсказуемый дефолт для привилегированной учётки ``` Имя администратора совпадает с его ролью, и пароль выбран в том же «удобном» духе: по классике таких инцидентов он повторяет имя самой учётной записи. Атакующему не нужен эксплойт — достаточно двух верных значений в форме входа. Класс проблемы — недостатки парольной политики (OWASP A07:2021, Identification and Authentication Failures). ## Точка входа атаки `POST /register` — форма регистрации с полями `username`, `password`, `fullname`; `POST /login` — форма входа с полями `username` и `password`. * **Известный аккаунт:** `demo` / `demo` * **Целевая учётная запись:** `admin` / пароль неизвестен, но предсказуем