# Отчёт по ошибкам и рискам проекта Magistr Дата проверки: 2026-07-03 Проверено вручную: backend Spring Boot, мультитенантность, авторизация, генерация расписания, основные frontend JS-файлы. Автотесты не запущены: в окружении нет `mvn` и `./mvnw`. ## Нужно исправить в первую очередь ### 1. Высокая — JWT имеет небезопасные production-дефолты **Файлы:** - `backend/src/main/java/com/magistr/app/config/auth/JwtProperties.java:13-17` - `backend/src/main/resources/application.properties:18-22` - `backend/src/main/java/com/magistr/app/controller/AuthController.java:162-168` **Проблема:** если на проде не задан `JWT_SECRET`, приложение использует известный дефолтный секрет `dev-only-change-this-jwt-secret-32-bytes-minimum`. При этом `JWT_REFRESH_COOKIE_SECURE` по умолчанию `false`, и refresh-cookie может уходить без флага `Secure`. **Риск:** подделка access-токенов при известном секрете; утечка refresh-cookie при ошибочной HTTP/прокси-конфигурации. **Как исправить:** - На production-профиле падать при отсутствии `JWT_SECRET` и при секрете короче требуемой длины. - Для production сделать `app.jwt.refresh-cookie-secure=true` обязательным. - Разделить dev/prod профили: дефолтный секрет оставить только в `application-dev.properties`. --- ### 2. Высокая — race condition при ротации refresh-токена **Файл:** `backend/src/main/java/com/magistr/app/config/auth/RefreshTokenService.java:50-78` **Проблема:** `rotate()` читает refresh-токен через `findByTokenHash()`, проверяет активность, затем отзывает старый и создаёт новый. Нет блокировки строки или атомарного `UPDATE ... WHERE revoked_at IS NULL`. Два параллельных запроса с одним refresh-токеном могут оба пройти проверку и создать две активные сессии. **Риск:** повторное использование одного refresh-токена, раздвоение сессий, некорректная ротация `rotatedToTokenHash`. **Как исправить:** - Добавить pessimistic lock в репозиторий (`@Lock(PESSIMISTIC_WRITE)` для поиска по `tokenHash`) внутри транзакции. - Либо сделать атомарное обновление: `UPDATE auth_refresh_tokens SET revoked_at = now, rotated_to_token_hash = :newHash WHERE token_hash = :hash AND revoked_at IS NULL AND expires_at > now` и создавать новый токен только если обновлена 1 строка. - Добавить тест на два параллельных refresh-запроса. --- ### 3. Высокая — `AuthContext` может протечь между запросами при `403` **Файл:** `backend/src/main/java/com/magistr/app/config/auth/AuthorizationInterceptor.java:35-49` **Проблема:** пользователь кладётся в `AuthContext` на строке 45, а при нехватке роли метод возвращает `false` на строке 49. В таком сценарии `afterCompletion()` текущего interceptor'а может не выполниться, и `ThreadLocal` останется в потоке до следующей очистки. **Риск:** утечка контекста пользователя между запросами в servlet thread pool. Сейчас это в основном риск безопасности и будущих багов, но его лучше устранить сразу. **Как исправить:** перед каждым `return false` после `AuthContext.setCurrentUser(user)` вызывать `AuthContext.clear()`. Ещё лучше — не устанавливать `AuthContext`, пока не пройдена ролевая проверка, или обернуть обработку отказов в безопасный helper. --- ### 4. Высокая — точечные изменения расписания не проверяются на конфликты **Файл:** `backend/src/main/java/com/magistr/app/controller/ScheduleOverrideController.java:71-127` **Проблема:** при `MOVE`/`REPLACE` валидируется только существование нового преподавателя, аудитории и слота. Не проверяется, свободны ли преподаватель/аудитория/группа в выбранную дату и пару. **Риск:** учебный отдел может создать override, который назначит преподавателя или аудиторию на две пары одновременно. Основные правила расписания конфликты проверяют, а override — нет. **Как исправить:** - Перед сохранением override построить расписание на `lessonDate` и проверить занятость нового `timeSlot`, `teacher`, `classroom`, групп/подгрупп базового слота. - Переиспользовать/вынести конфликтную логику из `ScheduleRuleAdminController` в сервис. - Вернуть `409 Conflict` с описанием конфликтующего занятия. --- ### 5. Средняя/высокая — расписание преподавателя не показывает пары, где он назначен через override **Файлы:** - `backend/src/main/java/com/magistr/app/service/ScheduleQueryService.java:47-58` - `backend/src/main/java/com/magistr/app/repository/ScheduleRuleRepository.java:36-54` **Проблема:** если поиск выполняется только по `teacherId`, сервис строит расписание через `buildScheduleForTeacher(teacherId)`, то есть берёт только базовые правила, где преподаватель указан в слоте. Если override заменил преподавателя на этого teacherId, базовое правило в выборку не попадёт, и после `applyOverrides()` такая пара не появится. **Риск:** преподаватель не увидит замену/переназначенную ему пару в своём расписании. **Как исправить:** - При поиске по `teacherId` дополнительно учитывать overrides с `newTeacher.id = teacherId` за период. - Либо строить расписание по группам для затронутых override-слотов и после применения override фильтровать по преподавателю. - Добавить тест: базовый преподаватель A, override `newTeacher=B`, поиск по `teacherId=B` должен вернуть пару. --- ### 6. Средняя — обновление существующего тенанта может удалить рабочее подключение и сохранить нерабочее **Файлы:** - `backend/src/main/java/com/magistr/app/controller/DatabaseController.java:104-116` - `backend/src/main/java/com/magistr/app/config/tenant/TenantRoutingDataSource.java:135-148` - `backend/src/main/java/com/magistr/app/config/tenant/TenantConfigWatcher.java:147-158` **Проблема:** при добавлении тенанта с уже существующим доменом старый DataSource сначала удаляется и закрывается (`removeTenant()`), затем добавляется новый. Hikari настроен с `setInitializationFailTimeout(-1)`, поэтому невалидная БД может быть добавлена без ошибки. `initDatabaseForTenant()` ловит исключения Flyway и не пробрасывает их наружу, поэтому API может вернуть успех и записать нерабочий конфиг. **Риск:** админ одной ошибкой в JDBC URL/пароле может выключить рабочий tenant и разнести нерабочую конфигурацию через ConfigMap. **Как исправить:** - Сначала создать и проверить новый DataSource во временном объекте (`testConnection`, Flyway migrate) и только после успеха атомарно заменить старый. - `initDatabaseForTenant()` должен возвращать результат или бросать исключение, чтобы `DatabaseController` не писал невалидный ConfigMap. - При ошибке оставлять старое подключение активным. --- ### 7. Средняя — watcher не применяет изменения URL/логина/пароля существующего тенанта **Файл:** `backend/src/main/java/com/magistr/app/config/tenant/TenantConfigWatcher.java:102-125` **Проблема:** `syncTenants()` добавляет только новые домены и удаляет исчезнувшие. Если в `tenants.json` изменились `url`, `username` или `password` для уже существующего `domain`, текущий DataSource не заменяется. **Риск:** после обновления ConfigMap часть pod'ов продолжит ходить в старую БД/со старыми credentials до рестарта. **Как исправить:** сравнивать весь `TenantConfig` для существующих доменов. При отличии — безопасно пересоздавать DataSource после успешной проверки нового подключения. --- ### 8. Средняя — отключена проверка TLS-сертификата Kubernetes API **Файл:** `backend/src/main/java/com/magistr/app/config/tenant/ConfigMapUpdater.java:74-76,104-119` **Проблема:** `createInsecureClient()` доверяет любому сертификату (`checkServerTrusted` пустой). Комментарий объясняет это self-signed CA, но в Kubernetes правильный CA доступен в serviceaccount volume. **Риск:** MITM внутри сети кластера может подменить Kubernetes API и получить serviceaccount token/подменить ConfigMap. **Как исправить:** использовать CA из `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` и стандартную проверку hostname/cert chain. Не использовать trust-all клиент. --- ### 9. Средняя — кабинет кафедры может перезаписать дисциплину другой кафедры при импорте **Файл:** `backend/src/main/java/com/magistr/app/controller/DepartmentWorkspaceController.java:80-90` **Проблема:** импорт ищет дисциплину только по глобальному имени (`findByName`) и затем без проверки меняет `departmentId` на кафедру текущего пользователя. Если дисциплина с таким названием уже принадлежит другой кафедре, она будет переназначена. **Риск:** потеря принадлежности дисциплины и связей расписания/календарей у другой кафедры. **Как исправить:** - Не менять `departmentId` существующей дисциплины другой кафедры. - Сделать уникальность по `(department_id, lower(name))`, если одинаковые названия допустимы у разных кафедр. - При конфликте возвращать понятную ошибку или создавать отдельную запись в рамках кафедры. --- ### 10. Средняя — кафедра может смотреть workload по чужим кафедрам **Файл:** `backend/src/main/java/com/magistr/app/controller/WorkloadController.java:43-130` **Проблема:** endpoints `/api/workload/*` доступны роли `DEPARTMENT` и принимают произвольный `departmentId`, но не сверяют его с `AuthContext.departmentId`. Также при `departmentId` отсутствующем запрос строится по всем группам/кафедрам. **Риск:** оператор кафедры может получить загруженность преподавателей/аудиторий/кафедр за другие подразделения, если это не было задумано бизнес-правилами. **Как исправить:** для роли `DEPARTMENT` принудительно использовать `AuthContext.getCurrentUser().departmentId()` и игнорировать/запрещать чужой `departmentId`. Аналогично проверить `ScheduleSearchController`, если расписание не должно быть глобально видимым. --- ### 11. Средняя — семестры можно создать вне учебного года или с пересечениями **Файлы:** - `backend/src/main/java/com/magistr/app/controller/AcademicCalendarAdminController.java:95-129,201-211` - `backend/src/main/java/com/magistr/app/service/AcademicDateService.java:32-34` - `backend/src/main/java/com/magistr/app/repository/SemesterRepository.java:13` **Проблема:** при создании/обновлении семестра проверяется только `endDate >= startDate`. Нет проверки, что семестр лежит внутри своего учебного года и не пересекается с другим семестром. При этом расписание ищет `findFirstByStartDateLessThanEqualAndEndDateGreaterThanEqual()`, то есть при пересечении дата будет сопоставляться с произвольным первым семестром. **Риск:** генерация расписания и чётность недель будут работать некорректно на пересекающихся датах. **Как исправить:** - Валидировать границы семестра относительно `AcademicYear.startDate/endDate`. - Запрещать пересечение семестров в рамках учебного года. - Желательно добавить DB-level exclusion constraint/range constraint или хотя бы сервисную проверку и тест. --- ### 12. Низкая/средняя — access-токен хранится в `localStorage` **Файл:** `frontend/admin/js/api.js:5-7,155-163` **Проблема:** access JWT хранится в `localStorage`, откуда его может украсть любой XSS в админке. Refresh-токен уже вынесен в HttpOnly cookie, но access-токен остаётся доступным JS. **Риск:** при XSS злоумышленник получает Bearer token и может выполнять API-запросы до истечения TTL. **Как исправить:** - По возможности держать access token в памяти и обновлять через HttpOnly refresh cookie. - Усилить CSP (`script-src` без inline), запретить небезопасные вставки HTML. - Провести отдельный XSS-аудит всех `innerHTML`. --- ### 13. Низкая — frontend местами вставляет текст ошибки через `innerHTML` без экранирования **Файл:** `frontend/admin/settings/js/views/database.js:37-49` **Проблема:** `e.message` вставляется в `innerHTML` без `escapeHtml()`. Сейчас большинство серверных ошибок фиксированные, но часть ошибок может включать текст из внешних систем/драйверов. **Риск:** потенциальный XSS в настройках БД при попадании HTML в сообщение ошибки. **Как исправить:** заменить на `textContent` или оборачивать `escapeHtml(e.message)`. --- ### 14. Низкая — backend image скачивает OpenTelemetry javaagent по `latest` **Файл:** `backend/Dockerfile:7` **Проблема:** сборка всегда скачивает `latest` javaagent с GitHub без pin версии/checksum. **Риск:** невоспроизводимые сборки; внезапные несовместимости; supply-chain риск. **Как исправить:** закрепить конкретную версию javaagent и проверять checksum. ## Дополнительно проверить после исправлений 1. Добавить Maven Wrapper (`mvnw`), чтобы проверки запускались одинаково в CI и локально. 2. Прогнать `mvn test` и добавить тесты на: - параллельную ротацию refresh-токена; - override с конфликтом преподавателя/аудитории; - расписание преподавателя, назначенного через override; - обновление существующего tenant config; - запрет чужого `departmentId` для роли `DEPARTMENT`. 3. Не изменять существующие Flyway-миграции. Если нужны DB constraints/indexes — добавлять новую миграцию `V3__...sql`.