Аудит безопасности перед масштабированием Ordify

С чего всё началось

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

Что насторожило

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

Что нашли

Мы зафиксировали находки разного уровня, от критической до незначительных.

Критическая. Пароль администратора магазина хранился и отдавался в открытом виде. Получив его, можно было войти в админку магазина и получить полный доступ к заказам, покупателям и статистике. Цепочку мы подтвердили на тестовом магазине, не трогая реальные данные клиентов. Здесь же лежал риск по 152-ФЗ, потому что под угрозой оказывались персональные данные покупателей, их телефоны, адреса и заказы.

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

Среднего уровня. Раскрытие деталей внутренней инфраструктуры в ответах API, доступ к части загруженных файлов без проверки прав и отсутствие надёжной проверки типа загружаемых файлов.

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

Что мы проверили и что оказалось в порядке. Не всё было плохо, и это важно сказать честно. Доступ к чужим магазинам был корректно защищён проверкой владельца. Ряд классических атак, которые мы пробовали, не сработал. Это значит, что фундамент у платформы здоровый, а проблемы точечные и устранимые.

Где была дыра

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

Что забрать себе

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

Важная оговорка

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