В январе этого года была запущена социальная сеть под названием «Moltbook».
Это была необычная социальная сеть, где публиковать сообщения могли только AI-агенты, и она была почти полностью создана с помощью ИИ. Это то, что можно назвать вайб-кодингом.
В течение трех дней после запуска исследователь безопасности заметил кое-что:
«Любой может прочитать и перезаписать содержимое базы данных этого приложения».
В результате утечки было скомпрометировано около 1,5 миллиона токенов аутентификации, около 35 000 адресов электронной почты и тысячи личных сообщений.
Руководство сразу же устранило проблему, но до этого момента в течение нескольких дней любой мог забрать все, что хотел.
Моя работа заключается в поддержке внутренней разработки AI-инструментов и проведении проверок безопасности.
Этот инцидент на самом деле продемонстрировал ту же самую уязвимость, которую я чаще всего вижу в компаниях, создавших внутренние инструменты с помощью ИИ.
Вот что произошло и пять моментов, на которые следует обратить внимание, чтобы предотвратить это у вас.
====
Что произошло
Было всего две причины.
Первая. В базе данных не было правила, гласящего: «вы можете видеть только свои собственные данные».
Вторая. Ключ, используемый для подключения к базе данных, был записан непосредственно в код на стороне браузера.
Любой может увидеть ключ, записанный в браузере, просто открыв инструменты разработчика.
Если подключиться к базе данных с этим ключом, будут возвращены все данные, поскольку нет правил, ограничивающих доступ.
Другими словами, все было видно через черный ход, даже не заходя в интерфейс приложения.
ИИ успешно создал «работающее приложение».
Однако он не создал часть «скрыть это от других», потому что его об этом не попросили.
Это самая большая ловушка при создании с помощью ИИ.
====
1. «Возможность войти в систему» и «Не видеть чужие данные» — это две разные вещи
При разработке приложения функция входа в систему почти всегда включена.
Люди склонны думать: «Я добавил функцию входа, так что все в порядке», но это неверно.
Вход в систему — это функция для проверки того, «кто» является пользователем.
То, «что этому человеку разрешено видеть», должно быть создано отдельно.
У Moltbook тоже была система входа.
Однако после входа в систему пользователи могли получить доступ к данным других людей.
Проверка проста.
Создайте две тестовые учетные записи, войдите в систему под учетной записью A и попробуйте открыть URL-адрес данных учетной записи B напрямую.
Если вы можете их увидеть, значит, вы уязвимы.
Вот промпт для ИИ:
«Убедитесь, что пользователи могут получить доступ только к своим собственным данным. Убедитесь, что даже если они откроют URL-адрес чужих данных, они не смогут их увидеть».
====
2. Установите правило «Видеть только свою часть» также на стороне базы данных
Первый пункт касался стороны приложения.
Однако, как и в случае с Moltbook, кто-то может подключиться напрямую к базе данных через черный ход, минуя приложение.
Поэтому вам следует установить правило в самой базе данных, гласящее: «этот человек может видеть только эту строку».
С этим правилом, даже если ключ утечет, данные других людей не могут быть получены.
Сервисы баз данных, часто используемые в современной разработке ИИ, имеют такую функцию.
Однако она часто отключена по умолчанию. ИИ не включит ее, если его не попросить.
Вот промпт:
«Включите правило для всех таблиц базы данных, чтобы пользователи могли читать только свои собственные строки».
====
3. Не размещайте ключи на стороне браузера
Другой причиной инцидента с Moltbook было то, что ключ был записан в браузере.
У приложения есть «код, который выполняется на стороне сервера» и «код, который выполняется на стороне браузера».
Сторона браузера полностью отправляется на ПК пользователя. Другими словами, запись ключа там — это то же самое, что распространять его среди всех.
Как проверить: откройте инструменты разработчика и выполните поиск по словам «key», «token» или «secret».
Если появляется длинная строка, похожая на одну из них, вам нужно быть осторожным.
Вот промпт:
«Храните ключи и пароли строго на стороне сервера. Никогда не включайте их в код на стороне браузера».
====
4. Перед релизом попросите «другой ИИ» сыграть роль злоумышленника
Если вы спросите ИИ, который создал приложение: «Это безопасно?», он ответит «Да». Потому что он сам его создал.
Поэтому вам следует попросить другой ИИ, отличный от того, который использовался для разработки, просмотреть его с точки зрения атакующего.
Спросите его: «Если бы вы взламывали это приложение, откуда бы вы вошли?»
Когда я делаю это с инструментами клиентов, vulnerabilities, которые они не заметили, выявляются в большом количестве.
Две уязвимости в Moltbook находятся на том уровне, который обычно обнаруживается с помощью этого вопроса.
Вот промпт:
«Вы — атакующий. Перечислите все способы просмотра чужих данных в этом приложении. Если найдете какие-либо, также предоставьте исправления».
====
5. После запуска записывайте «кто что просматривал» и проверяйте это ежедневно в течение первой недели
Moltbook был исправлен, потому что внешний исследователь нашел уязвимость и связался с разработчиками.
Они сами этого не заметили.
С внутренними инструментами никто не будет с вами связываться.
Поэтому ведите запись того, «кто когда вошел в систему и какие данные просматривал».
Затем проверяйте эту запись каждый день в течение первой недели после запуска.
Неизвестный источник доступа, массовый доступ среди ночи или один человек, открывающий данные всех пользователей.
Вы можете сразу же определить это, просматривая записи.
Вот промпт:
«Ведите журнал того, кто и когда получал доступ к каким данным. Однако не записывайте пароли или личную информацию в журналы».
====
Резюме
Если подвести итог инциденту с Moltbook одной строкой:
«ИИ строит то, что его просят построить, но он не строит то, что его не просят построить».
При создании внутренних инструментов мы сообщаем: «Я хочу такую функцию».
Но мы не говорим: «Не показывай это другим» или «Не помещай ключ в браузер».
Поскольку мы этого не говорим, это не включается.
И наоборот, все эти пять пунктов могут быть включены, просто добавив одно предложение к промпту для ИИ.
Во-первых, попробуйте создать две тестовые учетные записи с помощью вашего текущего инструмента и откройте URL-адрес чужих данных.
Просто сделав это, вы узнаете, есть ли у вас та же уязвимость, что и у Moltbook.
====
Наконец, объявление.
Наша компания предлагает услугу по разработке специализированных AI-агентов для вашей компании с нуля.
Вместо обучения или знакомства с инструментами мы проводим интервью о вашем реальном бизнес-процессе и предоставляем нечто «готовое к использованию с завтрашнего дня» как есть. Мы обеспечиваем постоянную поддержку вплоть до улучшений после внедрения и внутренней разработки.
Мы также предлагаем услугу, в рамках которой инженеры сопровождают вас для проверки безопасности и работы внутренних AI-инструментов, а также занимаются последующим обслуживанием и модификациями. Ключевая особенность в том, что мы не просто заканчиваем работу после создания, а устанавливаем «систему непрерывной защиты» с учетом пяти пунктов, описанных в этой статье.
Если вы владелец бизнеса или руководитель, который думает: «Наш инструмент может показывать данные, если кто-то откроет URL другого человека», пожалуйста, дайте нам возможность поговорить с вами.
Первичная консультация бесплатна, и мы можем прямо на месте продемонстрировать проверку с точки зрения атакующего, описанную в этой статье. Поскольку мы можем начать с совместного определения уязвимых мест вашей системы, пожалуйста, свяжитесь с нами через DM или LINE.
Просто напишите «AI» — этого достаточно↓
