Commit Graph

2 Commits

Author SHA1 Message Date
zuevav 3bb5e79272 Безопасность: остаток аудита — L2b, L3, L6, L7, L8, L10, L11, M4
- L2b: CSRF для изменяющих запросов админки — проверка Origin (иначе Referer)
  против Host на всех не-GET под /admin (sameOriginRequest в authMiddleware);
  за loopback-прокси учитывается X-Forwarded-Host. Второй слой поверх
  SameSite=Lax, без правки десятков форм настроек.
- L3: /back-to-admin меняет состояние — только POST + csrfOK (форма уже с токеном,
  проверки в обработчике не было).
- L6: EXEC процедуры DEPO по имени из настроек — через execProc с проверкой
  идентификатора (sqlident.go, см. коммит строчных событий).
- L7: сессия просмотра (impersonate) снимает IsAdmin цели — сотрудник не действует
  от имени другого администратора; свои действия — из своей сессии.
- L8: bootstrap администратора кабинета под замком lkBootstrapMu — два
  параллельных запроса не заведут двух админов (TOCTOU).
- L10: allowlist перезапуска служб не пропускает пустое имя.
- L11: ретранслятор — лимит тела проверяется по Content-Length до чтения и
  чтение ограничено RELAY_MAX_BODY+1.
- M4: .htaccess дополнительно запрещает *.lock (код установки), если данные
  оказались в веб-корне; nginx-запрет /data уже в README.

L4 (привязка сессии к сети по умолчанию выкл.) и L9 (косметическая cookie
bj_lk_admin, арбитр — ядро) оставлены как есть, отмечены в отчёте.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4YVo4UMopqT5DzicqpPjL
2026-09-22 16:28:14 +03:00
zuevav 2a7442c935 Кабинет клиента: документы и корпоративные действия, дистрибутив, обратный канал, защита
Данные
- корпоративные действия по бумагам клиента (U_CA_ACTS), готовые выписки (U_OP_INF_EXTRACT),
  заявки клиента на документ (lk.doc_requests) с оповещением сотрудникам; страница «Документы»
- дистрибутив кабинета из настроек ядра: архив с программой, службой, настройками,
  установщиком и инструкцией; ключ доступа на странице показан замаскированным

Связь без публичного адреса у ядра
- режим ожидания (BJ_MODE=agent): кабинет копит запросы, ядро само подключается к нему,
  выполняет их обработчиком /api/lk/* и возвращает ответы; 4 параллельных подключения,
  тот же ключ модуля в обе стороны, состояние канала в настройках
- сквозной тест: настоящий кабинет + настоящий цикл ядра

Защита (по итогам аудита)
- вход: лимит попыток по адресу и логину, одинаковое время ответа для несуществующего логина,
  пароль от 10 символов
- сессии ядра: на диске отпечаток токена и ссылка на учётную запись, без персональных данных;
  карточка клиента читается из БД на каждый запрос (блокировка действует сразу); абсолютный
  срок 24 ч; привязка к браузеру, к сети — по настройке
- вход сотрудника в кабинет клиента пишется в lk.audit и поднимает оповещение
- кабинет: CSRF на всех формах, /impersonate только POST, куки HttpOnly+Secure+SameSite=Strict,
  выход гасит все сессии, заголовки CSP/X-Frame-Options/nosniff/HSTS, no-store, таймауты сервера,
  ограничение тела, recover; сообщения через куку вместо адреса; /health наружу без подробностей
- шрифты вшиты в программу: страница не обращается к сторонним сайтам
- экранирование LIKE в выборках по номеру договора; ключ и токен без суррогата при отказе rand
- исправлено: ошибка входа не показывалась клиенту (шаблон ждал Error, приходил Flash)

Тесты: lksecurity_test, lkagent_test, lkdist_test, modules/lk (CSRF, заголовки, режим ожидания),
живые lkcoverage/lkunpriced, scripts/lk-sec-smoke.sh — проверка работающего кабинета снаружи.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 23:47:10 +03:00