Безопасность API: OWASP API Top 10

OWASP API Security Top 10 #

Open Web Application Security Project (OWASP) поддерживает список наиболее критичных рисков безопасности API. Версия 2023 года отражает текущий ландшафт угроз для API. Как QA-инженеру, понимание этих уязвимостей поможет вам проектировать тест-кейсы, которые выявляют дефекты безопасности до попадания в production.

API — основная поверхность атаки современных приложений. В отличие от веб-приложений, где браузер обеспечивает определённую безопасность, клиенты API могут отправлять любые запросы — что делает API особенно уязвимыми при слабой серверной валидации.

API1:2023 — Broken Object Level Authorization (BOLA) #

BOLA — самая распространённая уязвимость API. Она возникает, когда API не проверяет, имеет ли аутентифицированный пользователь разрешение на доступ к конкретному ресурсу.

Как это работает:

# User A аутентифицирован и просматривает свой заказ
GET /api/orders/1001
Authorization: Bearer <user-A-token>
→ 200 OK (Заказ принадлежит User A)

# User A меняет ID для доступа к заказу User B
GET /api/orders/1002
Authorization: Bearer <user-A-token>
→ 200 OK (Заказ принадлежит User B — уязвимость BOLA!)

Подход к тестированию:

1. Аутентифицируйтесь как User A и запишите ID его ресурсов.
2. Аутентифицируйтесь как User B.
3. Используя токен User B, попробуйте получить доступ к ресурсам User A по ID.
4. Если API возвращает данные — BOLA существует.

Тестируйте это на каждом endpoint, принимающем ID объекта: заказы, профили, документы, сообщения, платежи.

API2:2023 — Broken Authentication #

Механизмы аутентификации в API часто содержат уязвимости: слабая генерация токенов, отсутствие срока действия, токены в URL, отсутствие rate limiting на попытки входа.

Типичные тест-кейсы:

• Отправьте запросы без заголовка Authorization — API возвращает данные или корректный 401?
• Используйте просроченный JWT — API его отклоняет?
• Измените payload JWT без повторной подписи — API проверяет подпись?
• Проведите brute-force endpoint входа — есть ли rate limiting?
• Проверьте, нет ли токенов в параметрах URL (они попадают в серверные логи).

# Тест отсутствия auth
curl -X GET https://api.example.com/users/me
# Ожидается: 401 Unauthorized

# Тест просроченного токена
curl -X GET https://api.example.com/users/me \
  -H "Authorization: Bearer <expired-token>"
# Ожидается: 401 Unauthorized

API3:2023 — Broken Object Property Level Authorization #

Объединяет два старых риска: избыточная выдача данных и mass assignment. API возвращает больше данных, чем нужно клиенту, или принимает больше, чем должна.

Пример избыточной выдачи данных:

GET /api/users/123
{
  "id": 123,
  "name": "John",
  "email": "john@example.com",
  "ssn": "123-45-6789",
  "salary": 85000,
  "role": "admin",
  "password_hash": "abc123..."
}

Пример mass assignment:

# Обычное обновление пользователя
PUT /api/users/123
{ "name": "John Обновлённый" }

# Злоумышленник добавляет лишние поля
PUT /api/users/123
{ "name": "John Обновлённый", "role": "admin", "is_verified": true }

Подход к тестированию: Для каждого endpoint сравните поля ответа с тем, что клиенту реально нужно. Для endpoint-ов записи отправьте лишние поля и проверьте, обрабатывает ли их API.

API4:2023 — Unrestricted Resource Consumption #

API без ограничения потребления ресурсов уязвимы для отказа в обслуживании. Сюда входят отсутствие rate limiting, отсутствие лимитов пагинации и разрешение загрузки файлов без ограничений размера.

Тест-кейсы:

• Запросите endpoint списка без пагинации — вернёт ли он миллионы записей?
• Отправьте upload с огромным файлом — есть ли лимит размера?
• Сделайте быстрые последовательные запросы — включается ли rate limiting?
• Отправьте GraphQL-запрос с глубокой вложенностью — ограничивает ли сервер сложность запроса?

API5:2023 — Broken Function Level Authorization #

Пользователи могут получить доступ к административным функциям, угадав паттерн URL endpoint-а.

# Endpoint обычного пользователя
GET /api/users/123

# Административные endpoint-ы, к которым обычные пользователи не должны иметь доступ
DELETE /api/users/123
GET /api/admin/users
POST /api/admin/config

Подход к тестированию: Составьте карту всех endpoint-ов, включая административные (из документации или путём фаззинга). Попробуйте обратиться к admin-endpoint-ам с токенами обычных пользователей.

API6:2023 — Unrestricted Access to Sensitive Business Flows #

Автоматизированное злоупотребление легитимными бизнес-процессами: скальпинг билетов, массовое создание аккаунтов, злоупотребление купонами. API не предоставляет механизма для отличия легитимных пользователей от ботов.

API7:2023 — Server Side Request Forgery (SSRF) #

API обращается по URL, предоставленному пользователем, без валидации, что позволяет злоумышленникам сканировать внутренние сети.

# Обычный запрос
POST /api/fetch-preview
{ "url": "https://example.com/article" }

# Атака SSRF
POST /api/fetch-preview
{ "url": "http://169.254.169.254/latest/meta-data/" }

API8:2023 — Security Misconfiguration #

Отсутствие заголовков безопасности, подробные сообщения об ошибках, включённые лишние HTTP-методы, неправильная конфигурация CORS.

Быстрые проверки:

• Присутствуют ли заголовки X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security?
• Возвращает ли API stack trace в ответах об ошибках?
• Настроен ли CORS на разрешение * в origins?
• Включены ли OPTIONS, TRACE и другие ненужные методы?

API9:2023 — Improper Inventory Management #

Старые, не обновлённые версии API остаются доступными. Теневые API и beta-endpoint-ы не документированы и не мониторятся.

API10:2023 — Unsafe Consumption of APIs #

API доверяет данным от сторонних API без валидации. Если сторонний сервис скомпрометирован, уязвимость распространяется.

Упражнение: Пошаговое тестирование безопасности API #

Проведите оценку безопасности образцовой API, используя OWASP API Top 10 как фреймворк.

Подготовка #

Используйте намеренно уязвимые API от OWASP для безопасной практики:

• crAPI (Completely Ridiculous API): https://github.com/OWASP/crAPI
• VAmPI (Vulnerable API): https://github.com/erev0s/VAmPI

Установите crAPI локально:

docker compose -f docker-compose.yml up -d

Часть 1: Тестирование BOLA #

1. Создайте две учётные записи (User A и User B).
2. Под User A создайте ресурс (например, транспортное средство или заказ).
3. Запишите ID ресурса.
4. Аутентифицируйтесь как User B и попробуйте получить доступ к ресурсу User A:

curl -X GET http://localhost:8888/api/v2/vehicle/<user-a-vehicle-id> \
  -H "Authorization: Bearer <user-b-token>"

5. Задокументируйте, возвращает ли API данные User A или отказывает в доступе.

Часть 2: Тестирование аутентификации #

Протестируйте поток аутентификации:

# 1. Попробуйте обратиться к защищённому endpoint без токена
curl -X GET http://localhost:8888/api/v2/user/dashboard

# 2. Попробуйте с невалидным токеном
curl -X GET http://localhost:8888/api/v2/user/dashboard \
  -H "Authorization: Bearer invalid-token"

# 3. Попробуйте brute force на login (10 быстрых попыток)
for i in {1..10}; do
  curl -s -X POST http://localhost:8888/api/auth/login \
    -H "Content-Type: application/json" \
    -d '{"email":"test@test.com","password":"wrong'$i'"}'
done

Часть 3: Тестирование раскрытия данных #

Для каждого endpoint API:

1. Сделайте легитимный запрос и изучите каждое поле в ответе.
2. Перечислите поля, которые не должны быть доступны клиенту.
3. Для endpoint-ов записи отправьте дополнительные поля и проверьте, принимаются ли они.

Часть 4: Составьте чек-лист тестирования безопасности #

Создайте многоразовый чек-лист на основе ваших находок:

Результаты #

После выполнения упражнения:

1. Отчёт о тестировании безопасности со списком каждой найденной уязвимости, её категорией OWASP, критичностью (Критическая/Высокая/Средняя/Низкая) и шагами воспроизведения.
2. Многоразовый чек-лист тестирования безопасности, адаптированный для вашей API.
3. Рекомендации по исправлению каждой найденной уязвимости.

Интеграция тестирования безопасности в CI/CD #

Автоматизируйте проверки безопасности в вашем pipeline:

• OWASP ZAP — Запускайте автоматические сканирования API в CI.
• Nuclei — Сканер на основе шаблонов для известных уязвимостей API.
• Кастомные скрипты — Закодируйте тесты BOLA и аутентификации как автоматические тест-кейсы, запускаемые при каждом deployment-е.

Тестирование безопасности — это не разовая активность. Каждый новый endpoint, параметр или изменение аутентификации требует проверки безопасности.