5111 подписчиков
Ваш Salesforce открыт прямо сейчас — и вы об этом не знаете
Апрель 2026-го. McGraw Hill подтверждает утечку 13,5 млн записей — имена, email, адреса, телефоны. Три дня спустя — Amtrak, 2,1 млн записей. Оба инцидента объединяет одно: никакого zero-day, никакой сложной эксплуатации. Просто мисконфигурации Salesforce, которые годами висели в продакшне.
🔍 Как это работает на практике
В каждом Experience Cloud есть Guest User — специальный профиль для анонимных посетителей. Ловушка в том, что он существует даже когда в настройках стоит галочка «гостевой доступ отключён». Этот пользователь всё равно дёргает API через фреймворк Aura. На заборе написано «закрыто», а дверь открыта.
Атакующий отправляет POST-запрос на эндпоинт /s/sfsites/aura с токеном undefined — это сигнатура анонимного вызова. Дальше последовательность простая:
1. getConfigData — получить список доступных объектов
2. getObjectInfo — узнать поля Contact, Account, Case
3. getItems — перечислить все записи
4. getRecord — вытащить конкретные данные
Модифицированная версия AuraInspector, которую использовали в кампании 2026 года, шла ещё дальше — через GraphQL-эндпоинт без ограничения в 2000 записей. Собранные данные шли прямо в vishing-кампании: атакующие звонили жертвам, представлялись IT-службой и выманивали MFA-коды.
⚠️ Где конкретно прячутся дыры
По данным Reco.ai, четыре мисконфигурации встречаются чаще всего — в том числе в компаниях из Fortune 500:
• API Enabled на Guest User Profile — разрешает программно вытягивать данные
• Sharing Rules без ограничений — открывают все записи объекта, а не конкретные
• Отсутствие Field-Level Security — поля Phone, Email, Address доступны даже при оправданном доступе к объекту
• Apex-методы с директивой without sharing — полностью игнорируют Sharing Rules
🛡 Три шага, которые закрывают основные векторы
Первое и главное — снять API Enabled с Guest User Profile. Это единственное разрешение, которое превращает анонимного посетителя в полноценный инструмент разведки.
Второе — пройтись по всем Sharing Rules и убедиться, что они ограничены конкретными критериями, а не открывают весь объект. Особое внимание — Contact и Case.
Третье — аудит кастомных Apex-классов на наличие without sharing. Такой метод обходит даже корректно настроенные правила доступа.
💡 Главный контринтуитивный вывод всей этой истории: проблема не в Salesforce как платформе. Платформа работает по модели разделённой ответственности — за конфигурацию отвечаете вы. И атакующие это прекрасно знают.
В полной статье — детальная цепочка атаки с примерами запросов, пошаговый аудит и hardening-чек-лист для закрытия каждого вектора.
2 минуты
27 апреля