181 874 встречи нараспашку: разбор дыры в tl;dv и чек-лист по Firestore Rules

Есть класс уязвимостей, у которого нет ни CVE, ни эксплойта, ни патча. Просто где-то в проекте не написали пять строк. История с сервисом расшифровки встреч tl;dv — образцовый экземпляр, и заодно повод посмотреть на собственный Firebase-проект.

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

28 января: отчёт уходит в компанию

Исследователь под ником BobDaHacker пишет сооснователю tl;dv Рафаэлю Альштадту в LinkedIn и, отдельно, техническому директору. Суть отчёта: коллекция meetings в Firestore отдаётся любому аутентифицированному пользователю сервиса, без разделения по клиентам.

29–30 января Альштадт отвечает, что CTO свяжется немедленно. CTO не связывается.

Что именно было открыто

По публикации исследователя, доступными оказались:

• 181 874 записи о встречах;
• 84 312 уникальных пользователей;
• 35 003 почтовых домена, включая государственные из 23 стран;
• около 1 000 встреч в статусе recording — то есть идущих прямо сейчас;
• более 1 000 публично доступных записей, где вскрылись 715 адресов приглашённых из 228 доменов.

В полях записи лежали почта создателя встречи, платформа конференции, метки времени, статус записи и — это ключевое — идентификатор конференции. То есть строка, по которой в комнату Google Meet или Teams можно просто зайти. Исследователь это проверил: подключился к двум чужим звонкам, включая совещание Министерства образования Малайзии на 157+ участников.

Как это работало технически

Механика на удивление скучная, и в этом всё дело.

Клиент tl;dv логинится, получает JWT, обменивает его на Firebase-токен через gw.tldv.io/v1/users/firebase/token — и дальше ходит напрямую в Firestore, в проект lmi-store. Никакого промежуточного API, который проверял бы «а твоя ли это встреча», в этой цепочке нет вообще.

Именно в этом главная ловушка Firebase-архитектуры. В классической трёхзвенке между клиентом и базой стоит ваш сервер, и «забыть проверить tenant_id» надо в конкретном обработчике. В Firebase сервера посередине нет: Security Rules — это и есть весь бэкенд по части авторизации. Пропущенное правило на одной коллекции означает, что коллекция открыта целиком.

14 февраля — 22 июля: тишина

Дальше в хронологии почти нет событий, и это самая неприятная её часть.

На странице безопасности tl;dv заявлено время реакции на сообщения об уязвимостях — 24 часа. Публичного заявления компании по существу на момент подготовки этого текста найти не удалось.

Что проверить в своём проекте сегодня

Если у вас есть хоть что-то на Firebase — вот минимальный прогон.

1. Найдите коллекции без правил. Правило по умолчанию в «тестовом режиме» выглядит так и живёт ровно 30 дней, после чего часто заменяется на что-нибудь «временное»:

allow read, write: if request.time < timestamp.date(2026, 9, 1);

Ищите в firestore.rules любые if request.auth != null без дополнительных условий — это и есть уязвимая форма.

2. Привяжите доступ к владельцу, а не к факту логина.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    match /meetings/{meetingId} {
      allow get: if request.auth != null
                 && resource.data.ownerId == request.auth.uid;

      allow list: if request.auth != null
                  && request.query.limit <= 100;

      allow create: if request.auth != null
                    && request.resource.data.ownerId == request.auth.uid;

      allow update, delete: if request.auth != null
                            && resource.data.ownerId == request.auth.uid;
    }
  }
}

3. Помните, что правила — не фильтр. Документация Firebase формулирует это прямо: «Вы не можете написать запрос на все документы коллекции и ожидать, что Cloud Firestore вернёт только те документы, к которым у клиента есть доступ». Если правило требует совпадения ownerId, то и сам клиентский запрос обязан содержать соответствующий where — иначе он просто упадёт. Многих это удивляет, и в этот момент рождается соблазн «пока ослаблю правило, потом верну». Не возвращают.

Источники

• tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open — первичное исследование, все цифры отсюда
• Inside the tl;dv Flaw That Exposed Live Government and Corporate Meetings — пересказ публикации Dark Reading от 4 августа 2026, независимое подтверждение цифр
• Firebase: Writing conditions for Cloud Firestore Security Rules — про request.auth, get/list и «правила — не фильтры»