Bridge-and-Join-s

Files

T

zuevav d975957335 Безопасность: fail-closed auth (H1), доверенный прокси для IP (H2), CSRF на /order (M2)

По результатам security-аудита (docs, run-1). Три верифицированные находки.

H1 (HIGH) — fail-open аутентификация. loadUsers() при ошибке чтения/парсинга
users.json молча возвращал пустой стор → authOpen() считал это первичной
настройкой → после удаления first-run файла весь /admin отдавался без входа.
Теперь: постоянный маркер configured (пишется при создании первого админа и
бэкфиллится при загрузке валидного стора); authOpen() открыт только на реально
свежей системе; при пустом/битом сторе на настроенной системе — 503 и блокировка
до восстановления файла (authLockedOut). Тест TestAuthFailClosed (4 сценария).

H2 (HIGH) — интернет-слой доверял клиентскому X-Forwarded-For/X-Real-IP, что
позволяло обойти лимит входа по IP и травить аудит. Теперь заголовкам доверяем
только от доверенного прокси (по умолчанию loopback; расширяется
BJ_TRUSTED_PROXIES), из XFF берём правый элемент. Исправлено и в Go-модуле
(modules/lk/security.go), и в PHP-ретрансляторе. Тесты TestClientIPTrust (Go) и
прогон логики PHP.

M2 (MEDIUM) — POST /order (поручение на списание бумаг) не проверял CSRF, в
отличие от /login и /impersonate. Добавлен csrfOK (форма уже несла токен).
Тест TestOrderCSRF.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q4YVo4UMopqT5DzicqpPjL

2026-09-18 21:25:35 +03:00

.htaccess

Кабинет: страницы собирает ядро, на хостинге — ретранслятор (Go и PHP)

2026-09-18 11:15:29 +03:00

index.php

Безопасность: fail-closed auth (H1), доверенный прокси для IP (H2), CSRF на /order (M2)

2026-09-18 21:25:35 +03:00

README.txt

Инструкции: раздел настроек называется «Кабинет клиента»

2026-09-18 14:46:45 +03:00

README.txt

Личный кабинет клиента депозитария — версия для обычного хостинга (PHP)
=========================================================================

Что это. Кабинет ничего не рисует и не хранит сам: страницы собирает ядро bj-server
депозитария, а этот файл только передаёт запросы браузера ядру и ответы обратно.
Поэтому на хостинге нет ни базы данных, ни данных клиентов — только способ связи с ядром.

Что нужно от хостинга: PHP 8.1 или новее, расширения curl и sqlite (pdo_sqlite),
возможность создать домен/поддомен с сертификатом (Let's Encrypt в панели хостинга).

Установка:
  1. Создайте в панели хостинга домен, например lk.депозитарий.ru, и включите https.
  2. Скопируйте в каталог домена файлы index.php и .htaccess (например, по FTP или через
     файловый менеджер панели).
  3. Откройте https://lk.депозитарий.ru — запустится установщик: проверит сервер, спросит
     способ связи с ядром и ключ доступа, проверит связь и предложит завести
     администратора кабинета.

Способы связи с ядром:
  • Кабинет обращается к ядру — если у ядра есть адрес, доступный с хостинга (https).
  • Ядро подключается к кабинету — если у ядра нет адреса в интернете. Тогда в настройках
    ядра («Кабинет клиента») выберите «Ядро подключается к кабинету» и укажите адрес сайта.
    Ядро само дозвонится и заберёт запросы; входящих портов не нужно. Нужно расширение
    sqlite — очередь запросов лежит в файле.

Где лежат настройки: каталог bj-lk-data рядом с каталогом сайта (если хостинг разрешает
писать туда), иначе подкаталог data внутри сайта, закрытый правилами .htaccess. Файл
config.php содержит ключ доступа; чтобы пройти установку заново — удалите его.

Если у хостинга nginx без поддержки .htaccess: направьте все адреса на index.php
(try_files $uri /index.php?$query_string;) и закройте каталог data (location /data { deny all; }).
Лучше создать каталог bj-lk-data рядом с сайтом — тогда внутри сайта данных не будет.

Безопасность: заголовки защиты, куки и правила форм выставляет ядро — ретранслятор
передаёт их без изменений и ничего не пишет в журнал. Клиентам публикуйте кабинет только
по https.