Демонстрационный сценарий
Доступ к данным другой организации
Идентификатор: DEMO-01
01 Суть и возможные последствия
В вымышленном SaaS-приложении пользователь одной организации может получить объект, принадлежащий другой организации. В этом сценарии приложение проверяет наличие входа, но не проверяет право пользователя на конкретный объект.
Для реального продукта такая ошибка могла бы привести к раскрытию клиентских данных. Значимость зависела бы от состава данных, доступных операций и масштаба затронутых объектов. Числовая оценка риска в этом примере не назначена.
02 Контекст и условия
Предполагаемая среда
- Несколько организаций используют одно приложение.
- Данные каждой организации должны быть изолированы.
- У пользователя есть обычная учётная запись без административных прав.
Что нужно подтвердить при проверке
- Принадлежность объекта другой организации.
- Отсутствие разрешения на доступ к нему.
- Фактическое раскрытие данных, а не только различие в ответе.
03 Формат фиксации доказательств
Материал: иллюстрация, не журнал проверки Система: app.example Пользователь: [DEMO_USER_A] Организация: [DEMO_TENANT_A] Роль: [DEMO_READ_ONLY] Условный объект:[DEMO_OBJECT_B] Владелец: [DEMO_TENANT_B] Ожидается: доступ к объекту другой организации запрещён. Вымышленное наблюдение: приложение возвращает чужой объект. Содержимое: [REDACTED — ВЫМЫШЛЕННЫЕ ДАННЫЕ] Фактическое выполнение: отсутствует.
В реальном отчёте доказательства связываются с конкретной проверкой и согласованным объёмом. Чувствительные значения скрываются; доступ к полным материалам определяется отдельно.
04 Направления исправления
- Проверять право на конкретный объект на стороне сервера при каждом обращении.
- Связывать доступ с доверенным контекстом пользователя и его организации.
- Применять отказ в доступе, если необходимое разрешение не установлено.
- Проверить аналогичные операции и каналы доступа к тому же типу данных.
- Добавить регрессионные проверки для границ между организациями и ролями.
Это общие рекомендации для вымышленного сценария. Конкретное исправление определяется архитектурой реального приложения.
05 Критерии повторной проверки
Ниже показан шаблон критериев. Ни один из них в рамках этого примера не проверялся.
- Доступ к чужому объекту отклоняетсяДанные другой организации не возвращаются. Статус примера: ретест не выполнялся.
- Разрешённый доступ продолжает работатьВладелец объекта получает предусмотренный функционал. Статус примера: ретест не выполнялся.
- Проверены согласованные роли и операцииИсправление покрывает связанные сценарии в пределах объёма. Статус примера: ретест не выполнялся.
- Добавлена проверка на повторное появление ошибкиРегрессионный сценарий связан с исходной проблемой. Статус примера: не подтверждено.
06 Объём и ограничения
В рабочем отчёте разделяются статусы «проверено», «не проверено» и «проверка заблокирована». В демонстрации ниже фактические проверки отсутствуют.
| Область | Статус этого примера | Пояснение |
|---|---|---|
| Изоляция двух организаций | Не проверено | Вымышленный сценарий для демонстрации структуры находки. |
| Права разных ролей | Не проверено | В реальном проекте набор ролей согласуется до старта. |
| Связанные операции API | Не проверено | Покрытие фиксируется отдельно для каждой согласованной операции. |
| Сеть и облачная инфраструктура | Вне примера | Этот материал посвящён разграничению доступа в приложении. |
| Нагрузочные проверки и социальная инженерия | Вне примера | Не рассматриваются в демонстрационном сценарии. |
Демонстрационный материал. Здесь нет данных клиентов, реальных результатов, подтверждённой уязвимости или оценки защищённости какой-либо системы. Полный состав отчёта и критерии приёмки согласуются для конкретного проекта.