Аудит чужого кода перед покупкой: закладки, телеметрия, ключи

Аудит чужого кода перед покупкой или приёмкой нужен, чтобы до подписания акта выяснить, нет ли в системе удалённого входа для прежнего разработчика, скрытой отправки данных на сторонние серверы, забытых паролей и лишних прав. Это инженерная проверка на копии проекта. Она не гарантирует отсутствие любых проблем, но снимает самые неприятные сюрпризы и даёт вам документ для переговоров.

Зачем проверять код, который уже работает

Работающий сайт или бот показывает только то, что видит пользователь. Всё остальное происходит за кулисами: куда уходят заявки, кто может войти в админку, какие задачи запускаются ночью. Покупатель готового проекта и заказчик, принимающий работу от подрядчика, в этот момент забирают ещё и чужие решения, договорённости и долги.

Про сам порядок приёмки я уже писал в статье как принимать работу подрядчика, а про доступы и документацию в материале как не стать заложником подрядчика. Здесь только одна часть: что именно искать в самом коде и на сервере.

Что я ищу: шесть групп находок

1. Скрытые доступы и чёрные ходы

Это учётные записи, ключи и участки кода, о которых не знает владелец. Типичные признаки: пользователь с неочевидным именем в списке администраторов, вход по фиксированному паролю или секретной ссылке, чужой публичный ключ на сервере, отладочный маршрут, который открывает админку без проверки. Международный каталог слабостей MITRE описывает такой класс как скрытую функциональность (CWE-912): функция не задокументирована, не входит в спецификацию и недоступна через очевидные для пользователей и администраторов интерфейсы. Я не утверждаю, что она есть в каждом проекте. Я проверяю, что её нет.

2. Скрытая телеметрия и отправка данных наружу

Сайт или бот может отправлять заявки, адреса и содержимое форм не только в вашу почту. Я составляю список всех внешних адресов, к которым обращается система, и сверяю его с тем, что вам заявлено. Счётчик аналитики, платёжный сервис, SMS-шлюз ожидаемы. Неизвестный домен, на который уходят данные клиентов, это находка высокой важности. Тот же приём я применял в кейсе про аудит сайта по закону о персональных данных: читал журнал сетевых запросов и фиксировал, что и когда реально уходит, а документы только сверял с ним.

3. Забытые ключи и пароли в коде

Ключ платёжной системы, пароль от базы, токен бота могут лежать прямо в файлах и в старых коммитах. MITRE называет это использованием жёстко заданных учётных данных (CWE-798). Искать их вручную по всей истории бессмысленно, для этого есть сканеры. Как работает один из них, я разобрал в статье про TruffleHog.

4. Подозрительные зависимости

Современный проект почти всегда собран из чужих библиотек. Смотрю, что подключено, нет ли лишних и забытых пакетов, нет ли пакетов с подозрительными названиями и нет ли в них скриптов, которые запускаются при установке. Например, по документации npm при обычной установке автоматически выполняются скрипты preinstall, install, postinstall и prepare, поэтому просто «поставить зависимости» на рабочей машине нельзя. Известные уязвимости помогают найти штатные инструменты: npm audit сверяет зависимости с базой уязвимостей, а OSV-Scanner использует открытую базу osv.dev.

5. Лишние права

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

6. Расписания и фоновые задачи

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

Как проверять безопасно

Чужой код нельзя запускать на рабочем компьютере и тем более рядом с боевыми данными. Мои правила:

• Работаю только с копией: архив проекта, копия репозитория, снимок сервера. Оригинал не трогаю.
• Среда изолирована: отдельная виртуальная машина или контейнер, при необходимости без выхода в сеть.
• База заполнена выдуманными данными. Боевые клиентские данные в проверку не попадают.
• Боевые ключи не подставляю. Если проекту нужен ключ платёжной системы или SMS, ставлю тестовый или заглушку.
• Сначала читаю, потом запускаю. Установочные скрипты зависимостей просматриваю до установки.
• Найденные ключи не использую. Проверку работоспособности ключей у сканеров отключаю: у TruffleHog для этого есть флаг --no-verification, иначе сканер сам обращается к сервисам, которым ключ принадлежит. Ключ из чужого проекта отдаю владельцу на перевыпуск.

Если проект собирается сложно и у вас есть свой сервер, часть разбора кода можно отдать локальному ИИ-ревью: как это устроено, я описал в статье про review_ducktective. Код при этом остаётся на вашем сервере. Решение по находкам всё равно принимает человек.

Как я это делаю

Мой порядок из пяти шагов:

1. Получаю копию кода и описание того, как проект живёт сейчас: где хостинг, какие сервисы подключены, что вам обещали. Это даёт список ожиданий, с которым я потом сверяюсь.
2. Поднимаю проект в изолированной среде с выдуманными данными и записываю журнал сетевых запросов: куда обращается система при обычной работе.
3. Прохожу шесть групп из этой статьи: доступы, внешние адреса, ключи, зависимости, права, расписания. Для каждой находки сохраняю доказательство: строку кода, скриншот или запись из журнала.
4. Делю находки на три уровня и пишу, что делать с каждой.
5. Отдельным разделом перечисляю, что не проверил и почему.

Про работу на чужом сервере у меня есть живой пример: в проекте бронирования боксов для склада я поднимал старые сайты заказчика из резервных копий на его же сервере. Чужие настройки я меняю только с разрешения владельца и перед правкой сохраняю копию. Один из сбоев в том проекте мой сторож не заметил, потому что проверял только изнутри сервера, а снаружи сертификат был неверным. Вывод для аудита: проверять надо по пути посетителя, и логи самой системы тут недостаточны.

Если вам нужна такая проверка перед покупкой проекта или подписанием акта, посмотрите мою страницу про ИТ-аудит. Я пришлю отчёт, который можно показать продавцу, подрядчику или юристу.

Как оформить отчёт: находки по важности

Отчёт читает владелец бизнеса, поэтому я строю его по важности находок, и список инструментов остаётся в приложении.

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

Когда сразу отказываться

Есть ситуации, где продолжать нет смысла:

• Продавец или подрядчик не даёт полный код, а только готовую сборку, и не объясняет почему.
• Не разрешает работать на копии и не позволяет проверить сервер.
• В коде найден скрытый доступ или отправка данных на неизвестный адрес, и по этому поводу нет внятного объяснения.
• Боевые пароли и ключи лежат в открытом виде, а прежние владельцы отказываются их заменить.
• Нет ни одного человека, который может объяснить, как система устроена, и нет документации.

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

Сколько это стоит

Цены по моему прайсу: технический аудит от 50 000 ₽, срок от 1 недели. Если нужны исправления после аудита, считаю по часам от 3 000 ₽/час. Дальнейшее сопровождение (исправления, доработки, обновления, мониторинг) от 20 000 ₽/мес. Точная цена зависит от размера проекта и числа подключённых сервисов, поэтому сначала смотрю объём и называю цифру до начала работы. Подробнее на странице цен.

Частые вопросы

Можно ли найти все закладки автоматически?

Нет. Сканеры хорошо ловят ключи и известные уязвимости, но намеренно спрятанную логику находит только чтение кода и наблюдение за поведением системы. Поэтому я совмещаю инструменты и ручной разбор и пишу в отчёте, что осталось непроверенным.

Нужен ли мне исходный код, если сайт уже работает?

Да. Без исходников можно проверить только внешнее поведение: куда идут запросы и что видно в браузере. Скрытые входы, права и задачи по расписанию внутри сервера по такой проверке не видны.

Что делать, если продавец не даёт копию?

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

Это юридическая проверка?

Нет. Я фиксирую технические факты. Права на код, ответственность сторон и последствия находок оценивает юрист.

Коротко о главном

Перед покупкой или приёмкой чужого проекта проверьте шесть вещей: скрытые доступы, отправку данных наружу, забытые ключи, зависимости, права и расписания. Делайте это на копии, в изолированной среде и без боевых данных. Находки записывайте по важности, с доказательствами и отдельной строкой о том, что не проверено. Если продавец не даёт код или не позволяет проверить сервер, это причина остановиться.

Если вы собираетесь купить или принять проект и хотите знать, что в нём на самом деле, напишите мне в Telegram со словом «ПРОВЕРКА». Я посмотрю объём и назову срок и цену до начала работы.