Как выглядит наш отчёт по оценке защищённости
Обезличенный демонстрационный фрагмент отчёта, который вы получаете по итогам работ. Все находки ниже синтетические и относятся к вымышленной системе. Реальных данных клиентов здесь нет.
- Тип работ
- Тест на проникновение веб-приложения и API
- Цель
- Acme Cloud Platform (демонстрационная)
- Период оценки
- Двухнедельные работы (относительный срок, без конкретных дат)
- Гриф
- Конфиденциально (демонстрационный образец)
- Версия отчёта
- Образец v1.0
Краткое резюме
Vexaro провела оценку доступного извне веб-приложения и обслуживающего его API платформы Acme Cloud Platform в рамках двухнедельных работ в режиме grey-box. Тестирование велось по OWASP Web Security Testing Guide и проверялось вручную, а не только автоматическими инструментами.
Общий уровень риска: повышенный. Приложение корректно требует аутентификацию и защищает транспорт, однако авторизация на уровне объектов применяется непоследовательно. Две находки эксплуатируются по отдельности: небезопасная прямая ссылка на объект (IDOR) в биллинговом API и подделка запроса на стороне сервера (SSRF) при импорте документов. В связке они позволяют аутентифицированному пользователю с минимальными правами читать счета чужих организаций и добраться до внутренних метаданных облака. Исправление слоя контроля доступа и ограничение исходящих запросов снимают большую часть остаточного риска.
8 находок, оценка по CVSS 3.1
Границы и методология
Работы охватывали продакшен-приложение, его REST API, облачный аккаунт, где они размещены, и доступный извне сетевой периметр. Тестирование было ограничено по времени и проводилось из аутентифицированной учётной записи с минимальными правами, а также из неаутентифицированного базового состояния.
- Веб-приложение: app.acme.example (аутентифицированные и анонимные сценарии)
- REST API: api.acme.example (эндпоинты v1 и v2)
- Облачный аккаунт: объектное хранилище, метаданные вычислительных ресурсов и проверка IAM
- Внешний сетевой периметр: открытые сервисы и конфигурация TLS
- Отказ в обслуживании и нагрузочное тестирование
- Социальная инженерия и физический доступ
- Сторонние SaaS-сервисы, не управляемые целью
Методология и стандарты
Тестирование велось прежде всего вручную и опиралось на признанные отраслевые стандарты, чтобы находки воспроизводились, а покрытие можно было проверить.
Web Security Testing Guide: тест-кейсы, по которым строилось покрытие приложения.
Application Security Verification Standard: базовый набор проверок на уровне средств защиты.
Тактики и техники атакующих, на которых строятся реалистичные сценарии атаки.
Penetration Testing Execution Standard: общий порядок проведения работ.
Каждая находка оценивается по CVSS 3.1 и переводится в рейтинг бизнес-риска. Уровень отражает эксплуатируемость и влияние в контексте этой среды, а не только базовый балл.
Находки
Восемь показательных находок из работ, отсортированных по уровню риска. Первая раскрыта полностью ниже, чтобы показать глубину проработки каждой записи в отчёте.
| ID | Находка | Риск | CVSS | Статус |
|---|---|---|---|---|
| ACME-2024-001 | IDOR в биллинговом API раскрывает счета чужих организаций | Высокий | 8.1 | Открыта |
| ACME-2024-002 | Подделка запроса на стороне сервера (SSRF) в импорте документов | Высокий | 7.7 | Открыта |
| ACME-2024-003 | Нарушение авторизации на уровне функций в админ-эндпоинтах | Средний | 6.5 | Исправлено, проверено повторно |
| ACME-2024-004 | Хранимый XSS в поле темы тикета поддержки | Средний | 5.4 | Открыта |
| ACME-2024-005 | Слабая парольная политика допускает тривиальные пароли | Низкий | 3.7 | Открыта |
| ACME-2024-006 | Подробные ошибки API раскрывают трассировки стека и версии библиотек | Низкий | 3.1 | Риск принят |
| ACME-2024-007 | Отсутствуют заголовки безопасности (HSTS, CSP, frame-ancestors) | Инфо | 2.4 | Исправлено, проверено повторно |
| ACME-2024-008 | Сессионная cookie выдаётся без атрибута Secure | Инфо | 2.0 | Открыта |
Пример находки целиком
Одна находка, разобранная так же подробно, как каждая запись в настоящем отчёте: описание, влияние, доказательства, воспроизведение, исправление и ссылки.
IDOR в биллинговом API раскрывает счета чужих организаций
- ID находки
- ACME-2024-001
- CVSS 3.1
- 8.1 (Высокий)
- Вектор
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE
- CWE-639: Authorization Bypass Through User-Controlled Key
Описание
Биллинговый API возвращает документы счетов по последовательному числовому идентификатору, переданному в пути запроса. Эндпоинт аутентифицирует вызывающего, но не проверяет, что запрошенный счёт принадлежит его организации. В результате любой аутентифицированный пользователь может перебирать идентификатор и получать счета других организаций, включая имена контактных лиц по оплате, суммы и позиции.
Влияние
Это межарендаторное нарушение конфиденциальности. Аутентифицированный пользователь с минимальными правами из любой организации может читать финансовые записи всех остальных, просто увеличивая одно целое число. Раскрываются коммерческие условия и персональные контактные данные, а это риск и для приватности, и для конкурентной позиции. Идентификаторы идут подряд, поэтому весь массив счетов можно выгрузить программно за считаные минуты.
Доказательства
Демонстрационные запрос и ответ. Хост, токен и значения синтетические и обезличены.
GET /v2/invoices/10428 HTTP/1.1
Host: api.acme.example
Authorization: Bearer eyJhbGciOi...REDACTED.SAMPLE.TOKEN
Accept: application/jsonHTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 10428,
"tenant_id": 3304,
"bill_to": "[ОБЕЗЛИЧЕНО], Northwind Trading",
"amount_due": "14 920.00 USD",
"status": "unpaid"
}'Шаги воспроизведения
- 1Войдите в приложение под любой валидной учётной записью с минимальными правами и перехватите bearer-токен.
- 2Запросите свой собственный счёт, например GET /v2/invoices/10427, и убедитесь в ответе 200.
- 3Уменьшите или увеличьте числовой идентификатор (.../10428, .../10429) и повторите запрос со своим токеном.
- 4Убедитесь, что возвращаются счета с другими значениями tenant_id. Это подтверждает, что проверки авторизации на уровне объекта нет.
Исправление
Применяйте авторизацию на уровне объекта к каждому запросу: получите счёт, затем сверьте его tenant_id с организацией аутентифицированного субъекта, прежде чем возвращать данные, иначе отвечайте 404. Реализуйте проверку централизованно (например, в слое политик или в области запроса), а не в каждом обработчике, и добавьте регрессионный тест, проверяющий отклонение межарендаторного запроса. Замена последовательных идентификаторов на непредсказуемые снижает перебор, но это глубокая защита, а не замена проверки авторизации.