Как взломать no-code приложение с инвестициями $1.8 млн
Количество no-code стартапов неуклонно растет, многие из них получают миллионные инвестиции, имея огромные дыры в безопасности. Cегодня мы с вами залезем в эти дыры и получим полезную информацию для лидогенерации и продуктовые инсайты.
Немного контекста
Чтобы взломать ноукодера, надо думать как ноукодер, поэтому я вас сразу огорчу — я сам из “этих”.
Так сложилось, что выйдя из ИТ класса я не захотел становиться технарем, как мои одноклассники устроившиеся в Яндекс и Google, и я решил остаться около бизнеса. No-code как раз лежит между бизнесом и простыми техническими решениями, которые решают проблемы здесь и сейчас.
Этим компаниям мы сегодня и заглянем под капот.
Теоретически решения на Bubble соответствуют различным стандартам безопасности, но как и в коде, само решение зависит от разработчика, квалификация которого разнится от проекта к проекту. Тут то и появляются дыры в системах, через которые можно засунуть голову внутрь.
Я не люблю, когда что-то делается тяп-ляп, поэтому решил подрубить этот сук, на котором сижу, чтобы он зарос и стал еще прочнее.
Куда жать, чтобы сломать этот ваш ноукод?
Для начала нам нужно найти само приложение и вытянуть его ID.
Многие проекты реализуют landing page на более подходящих сервисах по типу Webflow или Framer, а само приложение зачастую прячется за кнопкой Login. Со временем я начал узнавать проекты на Bubble на глаз, но чтобы быть уверенным наверняка вам достаточно открыть DevTools в браузере (F12) на интересующей вас странице и увидеть в названии классов "bubble-element".
Далее есть 2 пути в зависимости от раздолбайства разработчика.
Первый очень простой — вам нужно дописать к URL путь /api/1.1/meta/swagger. json (живой пример). Дело в том, что из коробки Bubble приложение имеет сгенерированную Swagger документацию к каждому проекту, которая доступна публично, если не убрать специальную галочку. В ней мы находим на третьей строке значение ключа title, которое является искомым ID.
Второй способ со звездочкой — нам нужно выудить header X-Bubble-Appname из запросов. Открываем DevTool (F12), заходим в вкладку Network, жмем CTRL+F (сбоку откроется отдельный поиск по внутренностям запросов — не путать с фильтром по названию запросов) и перезагружаем страницу. После перезагрузки мы вписываем в поиске X-Bubble-Appname и достаем значение header.
Мы получили нужный ключик, осталось открыть дверку - заходим на сайт проверки безопасности Bubble приложений от одной из топовых no-code студий и вписываем найденный ID.
Изучаем улов
Что мы можем узнать из отчета:
- Pages - карта сайта со всеми страницами. Иногда страницы для внутреннего использования остаются открытыми, на них вы можете найти интересную информацию и даже понажимать кнопочки.
- Data API - открытые базы данных. К сожалению, в обычном тарифе Bubble выдает по API только первые 50к записей, поэтому чтобы посмотреть последние данные нужно добавить сортировку в URL - ?sort_field=Created%20Date&descending=true. Также, иногда в таблицах с 0 данных на самом деле могут быть данные и наоборот.
- Workflow endpoint - список внутренних функций приложения. Те, что со статусом Open не нуждаются в аутентификации и вы можете спокойно дернуть их POST запросом и в ответ получить список нужных для запроса параметров. А так как в Bubble вы платите за любые операции, то теоретически простеньким скриптом через открытый endpoint вы можете положить проект на лопатки.
- API keys - к сожалению я не знаю, как именно находятся все эти ключи, но видимо они также выковыриваются наружу из запросов приложения.
- Option lists - технические списки, в которых могут хранится списки статусов, категорий и прочие штуки. Их можно поймать при загрузке страницы - они подгружаются в виде JSON на сторону клиента и Bubble просит не хранить там ничего важного.
- Plugins - плагины Bubble, используемые в приложении. По ним можно понять внутренний функционал приложения и интеграции со сторонними сервисами.
По сути чувствительными являются только первые 4 пункта и для каждого из них в документации Bubble описаны правила, которые позволяют защитить данные на 100%. Но давайте посмотрим, пользуются ли этими правилами реальные компании.
"Зал славы"
Я проанализировал почти все Showcases на сайте Bubble и представляю вам 4 приложения с наибольшими дырами.
Betterlegal
Это приложение было первым, внутрь которого я заглянул полгода назад. На тот момент они хранили всю информацию об организациях и своих affiliates (чтобы это не значило) в открытом формате включая адреса, почты и имена.
Когда я увидел пост в Twitter от основателя о том, что они достигли $10 млн. общей выручки, я написал ему об этом баге. Он ответил мне в DM и через некоторое время часть данных стала скрытой, но не вся.
До сих пор из данных можно выудить информацию об агентах, обрывистые данные о создаваемых организациях (и к примеру понять объемы услуг компании) или изучить отзывы, если вы являетесь конкурентом.
Synthflow
Я видел этот стартап до его пивота в голосовых агентов и тогда безопасность была вроде получше. Сейчас же мы можем почитать транскрибацию звонков лидам, полистать список самих лидов с телефонами и именами, а также изучить настройки запускаемых кампаний. Также я находил таблицу с API ключами от Twilio, но делиться ею пожалуй не буду.
Flexiple
Тут все просто - одна доступная база, которая содержит почту и имена клиентов (не известно это соискатели или работодатели).
Much
Тут тоже все просто - компания имеет доступ к банковским транзакциям клиентов через интеграцию с Plaid и хранит эти данные в открытом доступе. Они хоть и старые (до 2022 года), но могут быть хорошим датасетом.
Этическая сторона вопроса
Я узнал о возможности такой проверки приложений из статьи Ryan Kulp. Из нее вы можете увидеть, что ряд компаний отказываются вносить изменения даже узнав о дырах в системе. Тоже самое мы видим и на примере Betterlegal, у которой было полгода на изменение системы.
На основе своего опыта взаимодействия с различными клиентами и разработчиками, я знаю что зачастую причиной возникновения таких дыр является обыкновенная халатность и безразличие к качеству предоставляемого решения.
Я знаю, что по-хорошему нужно было сообщить этим компаниям об утечке до публикации статьи, но я решил сделать показательную порку, чтобы подтолкнуть no-code сообщество к повышению стандартов разработки и показать остальным, что no-code подходит для создания больших и сложных продуктов.
Подписывайтесь на мой Телеграм-канал про no-code. Там я рассказываю, как быстро создавать качественные продукты с помощью no-code инструментов → @lowcodingdev