Недавно был представлен GitFut. Это бесплатный сервис для генерации карточек футбольной статистики на основе данных из профиля на гитхабе. Кидайте свои результаты в комментариях к посту 👇

Всем привет! 👋

Недавно я решил провести аудит защищенности и анализ архитектуры в известной open-source платформе Dokploy. Это классный self-hosted инструмент для деплоя, и с недавнего времени в нем есть платные Enterprise-фичи. Доступ к ним закрывается проверкой лицензионного ключа.

Мне стало интересно посмотреть, как разработчики спроектировали этот валидатор. В итоге мне удалось полностью обойти проверку и активировать платный функционал исключительно средствами сетевого уровня.

⚡️ В чем фундаментальный провал архитектуры

Проблема кроется в слепом доверии бэкенда к внешнему API. В обычном веб-приложении схема с отправкой ключа на внешний сервис выглядит нормально. Но в self-hosted среде пользователь полностью контролирует железо, Docker-сеть и локальный DNS.

Логика валидации в Dokploy завязана на пару уязвимых мест:

- Бэкенд на Node.js отправляет POST-запрос на licenses-api.dokploy.com (эндпоинты /licenses/activate и /licenses/validate).

- Сервер ждет в ответ самый обычный JSON вида {"valid": true}.

- Локальное состояние лицензии дополнительно дублируется флагами в PostgreSQL в таблице user (колонки enableEnterpriseFeatures и isValidEnterpriseLicense).

☠️ Как сработала концепция обхода (Network Spoofing + MitM)

Вся защита рухнула за счет комбинации подмены сетевого трафика и ослабления TLS-стека:

- Bypass TLS Validation: В Swarm-сервис Dokploy прокидывается переменная окружения NODE_TLS_REJECT_UNAUTHORIZED=0. Это заставляет Node.js проглатывать ошибки вадидации кастомного SSL-сертификата.

- Mock Infrastructure: В той же Docker-сети поднимается контейнер Nginx с SSL-сертификатом, сгенерированным через OpenSSL под домен licenses-api.dokploy.com. Nginx принимает HTTPS-трафик на 443 порту и перенаправляет его на Python-контроллер, который на любые POST-запросы возвращает HTTP status 200 и payload {"valid": true}.

- DNS Poisoning внутри контейнера: В файле /etc/hosts внутри целевого контейнера Dokploy домен licenses-api.dokploy.com перенаправляется на локальный IP-адрес нашего Nginx-прокси внутри Docker-сети.

Как только бэкенд совершает очередной запрос к "своему" API, он получает фейковый ответ, принимает его за чистую монету и разблокирует платные фичи.

💡 Как строить такую защиту правильно?

Для коммерческого Self-Hosted софта простой fetch() и незащищенный JSON не работают.

Ответ сервера лицензий должен быть токеном (например, JWT), подписанным приватным ключом компании. Бэкенд валидирует этот токен зашитым публичным ключом. Без приватного ключа сгенерировать подпись на фейковом сервере просто не получится.

Вдобавок внедряйте Certificate Pinning. Если приложение ходит во внешний API, валидируйте отпечаток SSL-сертификата напрямую, а не полагайтесь на системный TLS-стек, который легко глушится переменными окружения.

Разбор проведен исключительно в образовательных целях.

Всем удачного кодинга и грамотного проектирования! 🚀

✍️ 10 правил работы с логами

1. Логируйте бизнес-события, а не трассировку кода

Логи вида «функция отработала» никому не помогают. Гораздо полезнее фиксировать результат: «создан заказ», «оплата не прошла», «внешний сервис не ответил».

2. Исключите персональные и конфиденциальные данные

Пароли, токены и платежные реквизиты не должны попадать в системы агрегации (Sentry, Datadog), к которым есть доступ у широкого круга сотрудников.

3. Соблюдайте семантику уровней логирования

Используйте debug для локальной отладки. На уровне info фиксируйте ключевые бизнес-события. Уровень warn применяйте для отклонений от нормы, не остановивших работу, а error - для сбоев, требующих срочной реакции.

4. Используйте только структурированный формат (JSON)

Склеивание строк делает невозможной автоматическую фильтрацию. Передача данных объектом позволяет системам аналитики (допустим, Grafana) индексировать поля и находить корреляции.

5. Включайте сквозной контекст (Trace/Request ID)

Каждая запись должна содержать идентификаторы пользователя, запроса или операции. Это единственная возможность отследить цепочку событий при сбое.

6. Агрегируйте логи при пакетной обработке

Запись каждого элемента в циклах на тысячи итераций переполняет диски и израсходует лимиты сервисов мониторинга. Логируйте итоговый результат пакета: количество обработанных записей и ошибки.

7. Фиксируйте ошибки в месте их возникновения

Логирование на верхнем уровне (в глобальных перехватчиках) теряет локальный контекст операции. Перехватывайте и логируйте исключение там, где известны детали выполнения.

8. Удаляйте отладочные логи

Временные записи, добавленные в процессе разработки, засоряют продакшен. Они должны вычищаться на этапе самопроверки и код-ревью.

9. Избегайте дублирования одной ошибки

Не логируйте одно исключение на каждом слое архитектуры (сервис —> контроллер —> глобальный хендлер). Одно событие должно порождать ровно одну запись в логе.

10. Единый стандарт логов на уровне всей системы

Все сервисы и модули проекта должны использовать единую схему (обязательные поля timestamp, level, service, context). Иначе ни одна система агрегации логов не сможет их нормально распарсить и связать в единую картину.

#ПолезностиДляКодера

Поздравляю вас с днем программиста! 🥳

Знаю, что давно сюда ничего не постил и это надо исправлять. И первое, что скажу: скоро начну снимать новый монументальный курс! 🫡