Полный цикл безопасности для мессенджера Twitblit

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

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

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

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

Что нашли

Всего мы зафиксировали 11 находок, от критической до косметических, объединённых одной темой: публичная поверхность отдаёт лишнее.

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

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

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

Что оказалось в порядке

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

Где была дыра

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

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

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

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

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