Руководство по безопасности NocoBase

NocoBase уделяет особое внимание безопасности данных и приложений, начиная с функционального проектирования и заканчивая системной реализацией. Платформа включает в себя множество встроенных функций безопасности, таких как аутентификация пользователей, контроль доступа и шифрование данных, а также позволяет гибко настраивать политики безопасности в соответствии с вашими потребностями. Будь то защита пользовательских данных, управление правами доступа или изоляция сред разработки и продакшена, NocoBase предлагает практичные инструменты и решения. Это руководство призвано помочь вам безопасно использовать NocoBase, защитить ваши данные, приложения и среду, а также обеспечить эффективное использование функций системы при соблюдении всех мер безопасности.

Аутентификация пользователей

Аутентификация пользователей используется для подтверждения личности пользователя, предотвращения несанкционированного доступа к системе и защиты от неправомерного использования учетных данных.

Ключ токена

По умолчанию NocoBase использует JWT (JSON Web Token) для аутентификации API на стороне сервера. Вы можете установить ключ токена через системную переменную окружения APP_KEY. Пожалуйста, надлежащим образом управляйте ключом токена вашего приложения, чтобы предотвратить его утечку. Обратите внимание: если APP_KEY будет изменен, старые токены станут недействительными.

Политика токенов

NocoBase поддерживает следующие политики безопасности для пользовательских токенов:

| Параметр конфигурации | Описание

Безопасность данных

Хранение файлов

Если необходимо хранить конфиденциальные файлы, рекомендуется использовать облачное хранилище, совместимое с протоколом S3, и коммерческий плагин File storage: S3 (Pro), чтобы обеспечить приватное чтение и запись файлов.

Для локального хранилища или другого public-хранилища, доступного напрямую по URL того же источника, что и приложение, также необходимо учитывать риски, связанные с файлами с активным содержимым. Такие файлы, как html, xhtml и svg, могут быть напрямую интерпретированы и выполнены браузером. Если злоумышленник сможет загрузить такой файл и убедить пользователя открыть его, он сможет использовать доверенный домен приложения для размещения вредоносной страницы или скрипта.

Проверка загрузок в NocoBase не доверяет Content-Type, отправленному в запросе. Она предпочитает MIME type, определенный на стороне сервера. Расширение файла описывает только имя файла и не должно считаться авторитетным типом содержимого. Поэтому при раздаче public-загрузок также необходимо убедиться, что путь доступа к файлам задает корректные защитные HTTP-заголовки.

Если вы развертываете NocoBase через Docker или используете nginx-конфигурацию, сгенерированную NocoBase, каталог загрузок уже содержит эту защиту: все загруженные файлы возвращают X-Content-Type-Options: nosniff, а файлы с активным содержимым, такие как html, xhtml, svg, svgz и pdf, отдаются как скачиваемые файлы через Content-Disposition: attachment.

Если вы используете собственный proxy, CDN, объектное хранилище или напрямую публикуете локальный каталог загрузок, убедитесь, что эти правила нельзя обойти. В качестве ориентира можно использовать следующую конфигурацию nginx:

location ~* ^/storage/uploads/(.*\.(?:htm|html|svg|svgz|xhtml|pdf))$ {
    alias /path/to/nocobase/storage/uploads/$1;
    add_header Content-Disposition "attachment" always;
    add_header X-Content-Type-Options "nosniff" always;
    autoindex off;
}

location /storage/uploads/ {
    alias /path/to/nocobase/storage/uploads/;
    add_header X-Content-Type-Options "nosniff" always;
    autoindex off;
}

Если ваше приложение NocoBase использует APP_PUBLIC_PATH, замените /storage/uploads/ фактическим префиксом доступа, например /nocobase/storage/uploads/.

Обычно мы рекомендуем администраторам:

По возможности использовать приватное хранилище, подписанные URL или отдельный домен для файлов, чтобы пользовательские загрузки не отдавались напрямую с того же origin, что и основное приложение.
Применять строгий allowlist MIME-типов для загрузки и разрешать только те типы файлов, которые действительно нужны для бизнеса.
С осторожностью разрешать типы активного содержимого, такие как text/html, application/xhtml+xml и image/svg+xml. Даже если система старается отдавать такие файлы только как скачивание, это не является полноценной заменой ограничениям на загрузку и изоляции origin.
Настраивать reverse proxy, CDN, объектное хранилище и другие слои раздачи статических файлов единообразно, чтобы опасные файлы не возвращались inline в обход защит на уровне приложения.
Не использовать локальное/public-хранилище для размещения недоверенного веб-контента. Если такая необходимость все же есть, следует использовать изолированный домен и отдельно оценивать CSP, стратегию скачивания и контроль доступа.

Если администратор явно разрешает загрузку опасных типов файлов, он должен самостоятельно оценить риски фишинга, выполнения скриптов в том же origin и утечки чувствительной информации, а также убедиться, что Web Server, gateway, CDN и сервисы хранения применяют согласованные ограничения по всей цепочке развертывания.

8.7 KiB Raw Blame History