fix: safeReturn для всех редиректов (security)

- ui/routes/auth.js: safeReturn() для returnTo в POST /login и /login-token - src/routes/oidc.js: safeLocal() для oidcReturnTo в /callback
2026-06-04 15:26:26 +03:00
parent 6edef60ed8
commit 8cbbe52316
3 changed files with 79 additions and 3 deletions
@@ -0,0 +1,64 @@
+# Production Audit: ipwhitelist-app
+
+Дата ревью: 2026-06-04
+Основа: `prompt-review.txt`
+
+## Общее заключение
+
+В production отдавать нельзя без доработок. Код в целом собран аккуратно, но есть критичные риски по доступу к `/export`, redirect-логике и IAM fallback-пути. Документация частично актуальна, но для DevOps сейчас недостаточно согласована и содержит противоречия между старым и новым описанием аутентификации.
+
+## Найденные проблемы
+
+### Critical
+
+1. Публичный `/export` в `server.js` открыт без авторизации и без сетевого allowlist. Это противоречит безопасной production-модели и делает выдачу whitelist доступной любому, кто достучится до приложения.
+2. Логика `returnTo`/redirect допускает open redirect. Значение берётся из запроса и дальше уходит в `res.redirect()` без нормализации. Это нужно закрывать через `safeReturn()` или эквивалентный allowlist локальных путей.
+
+### Major
+
+1. IAM fallback работает слишком мягко: при ошибке `fetchIamUser()` приложение silently переходит на JWT claims. Это может привести к неверному определению компании, роли администратора или активного профиля.
+2. Документация не сведена в один актуальный источник. `README.md`, `docs/devops-deploy.md`, `docs/ТЗ-реализация.md`, `docs/keycloak-auth-reference.md` и `docs/iam-integration.md` частично дублируют и частично противоречат друг другу.
+3. Описание `/export` в документации и в коде расходится. В одном месте маршрут показан как публичный, в другом — как Bearer-protected. Для DevOps это опасно: можно ошибиться на этапе деплоя.
+
+### Minor
+
+1. CSP сейчас рабочий, но ослаблен `unsafe-inline` для скриптов и стилей. Для текущего inline-heavy UI это ожидаемо, но защита от XSS ограниченная.
+2. Есть устаревшие или лишние пояснения вокруг mock-режима и IAM, из-за чего сложно понять, какой путь является production и какой — fallback для тестов.
+
+## Понятность DevOps
+
+Оценка: 4/10
+
+Почему так низко:
+
+- есть хороший стартовый deploy guide, но он смешан с историческими и legacy-документами;
+- не все переменные окружения и режимы описаны в одном месте;
+- есть расхождения по IAM, роли администратора, multi-company и `/export`.
+
+## Чистота кода
+
+Оценка: 6/10
+
+Плюсы:
+
+- логика разделена на слои: auth, API, UI, queries, validators;
+- есть нормализация CIDR, защита от дубликатов и пересечений, soft delete, аудит;
+- middleware и роутизация читаются достаточно последовательно.
+
+Минусы:
+
+- fallback-пути слишком терпимые и могут скрыть проблемы интеграции;
+- redirect-логика требует жёсткой нормализации;
+- часть безопасности опирается на inline-механики и не доведена до строгого production-профиля.
+
+## Что исправить перед продом
+
+1. Закрыть `/export` по умолчанию и включать его только через явную production-политику доступа.
+2. Нормализовать все `returnTo`/redirect-цели через `safeReturn()` или аналогичный allowlist.
+3. Перевести IAM fallback на fail-closed поведение либо явно документировать, при каких условиях он допустим.
+4. Свести документацию в один актуальный production runbook и пометить старые документы как legacy.
+5. Добавить тесты на open redirect, IAM-fallback и доступ к `/export`.
+
+## Краткий итог
+
+Код готов к дальнейшей доводке, но до production не дотягивает из-за вопросов безопасности и несогласованной документации. Если нужен рабочий контур для DevOps, сначала надо закрыть доступ к `/export`, убрать open redirect и привести IAM-путь к предсказуемой модели.