Перейти к содержимому
🐙 BunSqStat

Agent security

Анализ безопасности

Данный документ содержит анализ кодовой базы BunSqStat с точки зрения безопасности и потенциальных уязвимостей.

Backend (Server)

  1. Отсутствие валидации входящих UDP данных

Файл: apps/server/src/modules/log-server/index.ts:35-66

Проблема: • Входящие UDP пакеты обрабатываются без проверки размера • Нет валидации формата данных перед парсингом • Отсутствует защита от malformed UTF-8 последовательностей

Риски: • DoS атака через отправку огромных пакетов или миллионов строк • Memory exhaustion при обработке бесконечных строк • Крах приложения при обработке некорректных данных

Рекомендация: Добавить проверки размера пакета (макс. 64KB), ограничение на количество строк (макс. 1000), валидацию длины каждой строки.

  1. Redis Search Injection

Файл: apps/server/src/modules/access-logs/service.ts:106-134

Проблема: • Параметр search передается в Redis команду без санитизации • Параметр sortBy принимает пользовательский ввод без валидации • Возможна инъекция произвольных Redis команд

Риски: • Data leakage через доступ к другим индексам • Command injection для выполнения произвольных команд Redis • Data manipulation или удаление данных

Рекомендация: Использовать whitelist для валидации параметров поиска, экранировать спецсимволы Redis Search, проверять sortBy по списку разрешенных колонок.

  1. ReDoS (Regular Expression Denial of Service)

Файл: apps/server/src/consts.ts:1-32

Проблема: • Сложные регулярные выражения без timeout • Потенциально опасные паттерны с catastrophic backtracking • Применяются к непроверенным данным из UDP

Риски: • CPU exhaustion при специально подобранном вводе • Зависание event loop на долгое время • DoS всего сервиса

Рекомендация: Установить timeout на выполнение regex (max 100ms), упростить регулярки, добавить предварительную проверку формата строки.

  1. Отсутствие аутентификации для критичных операций

Файл: apps/server/src/modules/access-logs/index.ts:34-45

Проблема: • DELETE endpoint /stats/access-logs доступен без аутентификации • Любой может удалить все логи одним запросом • Swagger UI открыт публично и показывает все endpoints

Риски: • Data loss через несанкционированное удаление • Информационная утечка через Swagger документацию • Злоупотребление API без контроля доступа

Рекомендация: Добавить middleware для аутентификации, использовать API ключи или JWT токены, ограничить доступ к Swagger в production.

  1. CORS настроен слишком permissive

Файл: apps/server/src/index.ts:38

Проблема: • .use(cors()) без параметров разрешает все origins • Нет ограничений на методы и заголовки • Возможны CSRF атаки

Риски: • CSRF атаки с произвольных сайтов • Кража данных через XSS на других доменах • Несанкционированный доступ к API

Рекомендация: Указать конкретные allowed origins, ограничить методы (GET, POST, DELETE), добавить CSRF токены для мутирующих операций.

  1. Отсутствие rate limiting на критичных endpoints

Файл: apps/server/src/index.ts:40

Проблема: • Rate limit настроен глобально, но без специфичных правил • Критичные операции (DELETE, поиск) не имеют отдельных лимитов • WebSocket соединения не лимитированы

Риски: • DoS атака через флуд запросами • Brute force при будущем добавлении аутентификации • Resource exhaustion Redis и CPU

Рекомендация: Настроить строгий rate limit для DELETE (1 req/min), поиска (10 req/sec), WebSocket соединений (100 на IP).

  1. Небезопасное логирование

Файл: apps/server/src/libs/logger.ts:22-78

Проблема: • Логи записываются в ./logs/ без шифрования • Могут содержать чувствительные данные (IP, user agents) • Ротация настроена только по размеру, без учета sensitive data

Риски: • Privacy violation при утечке логов • GDPR нарушения при хранении персональных данных • Информационная утечка при несанкционированном доступе к файлам

Рекомендация: Анонимизировать IP адреса (маскировать последний октет), добавить опцию шифрования логов, настроить автоматическое удаление старых логов.

  1. Уязвимость к timing attacks

Файл: apps/server/src/modules/parser/service.ts:29-31

Проблема: • Проверка существования ключей через exists() раскрывает информацию • Отсутствие константного времени при проверках • Потенциальная утечка информации о структуре данных

Риски: • Information disclosure о существующих origins • Enumeration атаки для поиска валидных ключей • Timing side-channel для извлечения данных

Рекомендация: Использовать константное время для всех проверок, не раскрывать в ответах информацию о существовании ресурсов.

  1. Отсутствие валидации WebSocket сообщений

Файл: apps/server/src/modules/ws/index.ts:55-71

Проблема: • WebSocket сообщения обрабатываются без схемы валидации • Нет проверки типа и структуры данных • Отсутствует защита от oversized messages

Риски: • DoS через WebSocket отправкой огромных сообщений • Protocol confusion при некорректных данных • Memory leak при обработке malformed JSON

Рекомендация: Добавить валидацию через JSON Schema, ограничить размер сообщений (max 1KB), использовать TypeBox для runtime проверок.

  1. Environment variables без валидации

Файл: apps/server/src/config.ts:34-44

Проблема: • Отсутствует обязательная валидация критичных переменных • REDIS_PASSWORD опциональный, но должен быть обязательным • Нет проверки на дефолтные/слабые значения

Риски: • Использование дефолтных паролей в production • Misconfiguration приводящий к уязвимостям • Незащищенный Redis доступный без пароля

Рекомендация: Сделать REDIS_PASSWORD обязательным, добавить проверку на слабые пароли, валидировать формат всех переменных при старте.

  1. Отсутствие Content Security Policy

Файл: Отсутствует middleware для CSP

Проблема: • Нет заголовков CSP в HTTP ответах • Swagger UI и frontend могут загружать внешние скрипты • Отсутствует защита от XSS

Риски: • XSS атаки через injection в DOM • Clickjacking через iframe embedding • Data exfiltration через внешние ресурсы

Рекомендация: Добавить CSP middleware с строгой политикой, запретить inline scripts, ограничить источники загрузки ресурсов.

  1. Небезопасное хранение данных в Redis

Файл: apps/server/src/modules/access-logs/service.ts:89-90

Проблема: • Данные хранятся в Redis без шифрования • TTL установлен на 7 дней, но нет проверки соответствия retention policy • Sensitive данные (IP, user) не анонимизированы

Риски: • Data breach при компрометации Redis • GDPR нарушения при долгом хранении персональных данных • Privacy violation без consent пользователей

Рекомендация: Шифровать чувствительные поля, анонимизировать IP адреса, настроить автоматическую очистку по регуляциям.

Frontend (Web)

  1. Небезопасное хранение настроек

Файл: apps/web/src/stores/access.ts:87-91

Проблема: • Использование sessionStorage без шифрования • Потенциальное хранение sensitive данных в localStorage • Доступность данных для XSS атак

Риски: • XSS data theft при injection атаках • Session hijacking через stolen storage • Privacy breach при доступе к локальным данным

Рекомендация: Не хранить чувствительные данные в storage, использовать httpOnly cookies, валидировать все данные из storage перед использованием.

  1. Отсутствие валидации WebSocket URL

Файл: apps/web/src/stores/access.ts:42

Проблема: • URL для WebSocket берется из константы WS_URL без валидации • Возможность подмены через модификацию кода • Нет проверки origin при подключении

Риски: • MITM атаки при connection hijacking • Data interception через поддельный WS сервер • Protocol downgrade с WSS на WS

Рекомендация: Жестко закодировать разрешенные WS origins, использовать только WSS в production, валидировать сертификаты.

  1. Двойной JSON.parse без try-catch

Файл: apps/web/src/stores/access.ts:26-27

Проблема: • Парсинг данных без обработки ошибок может привести к краху • Нет валидации структуры после парсинга • Возможна injection через malformed JSON

Риски: • Application crash при некорректных данных • Prototype pollution через JSON injection • XSS если данные рендерятся в DOM

Рекомендация: Обернуть парсинг в try-catch, валидировать структуру объекта, санитизировать данные перед рендерингом.

Общие рекомендации

Критические (требуют немедленного исправления):

  1. Добавить аутентификацию для всех мутирующих операций (#4)
  2. Валидация UDP входных данных с ограничением размера (#1)
  3. Санитизация Redis Search параметров (#2)
  4. Настроить CORS с конкретными origins (#5)

Высокий приоритет:

  1. Redis password обязательным в конфигурации (#10)
  2. Rate limiting для критичных endpoints (#6)
  3. ReDoS защита через timeout на regex (#3)
  4. WebSocket message validation (#9)

Средний приоритет:

  1. CSP заголовки для защиты от XSS (#11)
  2. Логирование с анонимизацией данных (#7)
  3. Шифрование чувствительных данных в Redis (#12)
  4. Валидация данных из storage (#13, #15)
  5. Timing attacks защита (#8)
  6. WebSocket URL валидация (#14)

Security Best Practices:

• Регулярный аудит зависимостей (bun update, проверка CVE) • Использование HTTPS/WSS в production • Настройка Security Headers (HSTS, X-Frame-Options, etc.) • Логирование security events (failed auth, suspicious activity) • Regular penetration testing • Implement WAF (Web Application Firewall) • Мониторинг anomalous behavior (spike in requests, unusual patterns)

Compliance:

• GDPR: Анонимизация IP, право на удаление данных, consent • Retention Policy: Автоматическое удаление старых логов • Data Encryption: At rest и in transit • Audit Trail: Логирование всех доступов к данным