Анализ защищенности перед запуском AlpacaBag

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

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

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

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

Что нашли

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

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

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

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

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

Где была дыра в соответствии закону

Отдельный пласт касался 152-ФЗ. Данные пользователей фактически уходили на обработку за рубеж через цепочку сторонних сервисов, тогда как публичная политика конфиденциальности это отрицала. Для российского сервиса это значимый регуляторный риск. Закон требует честно указывать трансграничную передачу, называть страну и получателя и брать на это отдельное согласие. Радикальный способ снять весь этот пласт сразу, перенести обработку на провайдера, который держит данные внутри страны. Мы дали клиенту оба варианта, юридический и технический.

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

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

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

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