Прежде чем начать разбор темы API TOP 10 давайте разберем сначала что такое API, для чего и с чем его едят. Начнем с определения, которое дает нам интернет:

API (Application Programming Interface) — программный интерфейс приложений, набор правил и протоколов, который позволяет разным программам взаимодействовать друг с другом и обмениваться данными. API выполняет роль посредника, передавая данные между клиентом и сервером через установленный интерфейс.

Профессионалы поймут, но люди без опыта, в том числе и я, не осознают всю мысль происходящего. Давайте я осмелюсь взять на себя ответственность, что объяснить большинству новичков, что же этот ваш API?

Представим, что API (Application Programming Interface) – это как официант в ресторане. Ты (клиент) приходишь и делаешь заказ по меню. Официант (API) принимает твой заказ, передаёт его на кухню (сервис), а потом приносит готовое блюдо обратно. Ты не лазаешь на кухню и не готовишь сам — ты просто знаешь, что скажи «дай стейк средней прожарки» и через некоторое время получишь стейк.

А теперь объясню на реальном рабочем примере:

Погода в приложении

Что нужно: показать прогноз погоды в твоём приложении.

Решение: использовать публичное Weather API (например, OpenWeatherMap).

Как это совершить:

1.    Регистрируешься и получаешь API‑ключ.

2.    Делаешь запрос:

GET https://api.openweathermap.org/data/2.5/weather?q=Moscow&appid=YOUR_KEY

3.    Получаешь JSON‑ответ с температурой, влажностью и описанием погоды

Приступим к нашей основной теме. Проведем эксплуатацию API в веб-версии “Vulnerable Bank”.

Предварительная установка

Для начала нам необходимо провести reverse engineering API, чтобы упростить нашу работу в Postman. Для этого скопируем содержимое файла с расширением .yaml и вставим в swagger editor. (см. Рисунок 1)

Импортируем наш файл из swagger, чтобы добавить в Postman.

API 1: Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA) (ранее известна как Insecure Direct Object Reference (IDOR)) — уязвимость безопасности в API, которая позволяет злоумышленникам получать доступ к данным, изменяя идентификатор объекта в запросе.

Принцип работы

Злоумышленники анализируют запросы и ответы API, ищут шаблоны в том, как объекты упоминаются в запросах (например, /users/{userID} или /orders/{orderID}). Затем они меняют значение идентификаторов объектов в своих запросах, пытаясь получить доступ к данным, принадлежащим другим пользователям или ресурсам.

Эксплуатация:

Давайте начнём с использования BOLA из конечной точки API.

 

Как обычно, зарегистрируем 2 аккаунта, как мы тестируем для IDOR. Назовем их Acount A и Account B соответственно. На Postman, установите ваш baseurl в коллекции http://localhost:5000. Войдите.

Для того чтобы протестировать ID параметр или уникальный номер, в нашем случае тестируем API/transfer. Нам необходимо провести транзакцию из Account A в Account B, чтобы получить непустую историю транзакций. (см. Рисунок 2)

Наш баланс обновился, так как мы перевели 100$ на Account B.

Для просмотра транзакций Account A нам необходимо зайти в endpoint /transaction Account B. (см. Рисунок 3, 4)

На Рисунке 4 заметно, что есть наличие уязвимости API (BOLA), т.к. мы можем просматривать историю транзакций Account A будучи авторизованным под Account B.

Здесь API не в силах обеспечить авторизацию на уровне объекта. Он рассуждал, что любой пользователь может получить доступ к транзакциям любого аккаунта, если есть валидный токен и если он знает идентификатор другой аккаунта.

Исправления: Всесторонняя проверка прав доступа на уровне пользователя

1. Проверять, что ID аутентифицированного пользователя совпадает с запрашиваемым ресурсом

Пример реализации: в middleware перед выполнением контроллера извлекаем userId из JWT-токена и сравниваем его с accountId в URL:

2. Никогда не полагаться на клиентский ввод для определения прав доступа

Всегда берём userId из безопасного источника — JWT-токена или сессии, но не из тела запроса или заголовков:

const userId = req.user.id; // только из проверенного токена

3. Внедрить серверные проверки для каждого CRUD-оператора

 

Итог: централизованная и строгая проверка userId ↔ resourceId в каждом эндпоинте гарантирует, что пользователь сможет работать только со своими данными и полностью исключает object-level authorization bypass.

 

API2: Broken Authentication

Broken authentication — это уязвимость в процессе аутентификации или управлении сессиями веб-приложения, которая позволяет неавторизованным пользователям получать доступ к защищённым данным и ресурсам.

Инициируем запрос сброса пароля. Для этого аутентифицируемся как Account B и отправляем запрос на сброс пароля для Account A (см. Рисунок 5).

В безопасных реалиях, flow должен сначала проверить, что токен соответствует тому же пользователю, чей пароль сбрасывается, или же отправить на почту одноразовый токен. Мы убедились, что это небезопасные реалии.

Пофаззим PIN-код.

Подставляем в поле reset_pin все трехзначные комбинации, чтобы найти валидный.

Можно использовать следующую команду:

1)    wfuzz -d ‘{“username”:”test”, “reset_pin”:”FUZZ”, “new_password”:” reset@021”}’ -H ‘Content-type: application/json’ -z file,/usr/share/wordlists/wfuzz/digits-000-999.txt -u http://127.0.0.1:5000/api/v2/reset-password –hc 400

2)    Либо BurpSuite

Результат: входим в Account A с новым паролем. Получаем валидный токен и полный контроль на УЗ.

Fix:

1)    Всегда проверяйте, что операции (сброс, изменение профиля и т.п.) выполняются самим владельцем учетки или по email подтверждению.

2)    Никогда не принимайте в одном запросе email + новый пароль без предварительной email-верификации.

3)    Ограничивайте число попыток ввода PIN/кодов и логируйте неудачные запросы, чтобы обнаружить фуззинг.

API3: BOPLA (Broken Object Property Level Authorization)

Broken Object Property Level Authorization (BOPLA) - менее известная, но опасная уязвимость API, в которой пользователи могут изменять конкретные поля или свойства объекта, к которым они не должны иметь доступа, даже если им разрешен доступ к самому объекту.

Две существенные уязвимости составляют BOPLA:

Чрезмерное воздействие данных

Эта уязвимость возникает, когда API раскрывает клиенту больше данных, чем необходимо. Обычно API возвращают только данные, необходимые для функциональности пользователя для выполнения его задачи. Однако, в случае чрезмерного воздействия данных, API может вернуть конфиденциальную информацию, такую как:

Admin status (is_admin: true)

 Массовое назначение

Массовое назначение - это уязвимость, которая возникает, когда API или сервер неправильно доверяют данные, отправляемые с клиентской стороны. В типичном API, пользователи могут отправлять запросы с данными, а сервер должен принимать и обрабатывать только определенные поля (например, имя пользователя, электронная почта или пароль). Однако при массовом назначении злоумышленник может отправлять дополнительные параметры, которым сервер ошибочно доверяет и обрабатывает.

Например:

Злоумышленник может отправлять такие параметры, как баланс, is_admin или другие внутренние свойства, к которым он не должен иметь доступа.

Мы будем использовать эту уязвимость (Mass Assignment) для изменения сессии в главе API6.

Эксплуатация:

Идентифицируем уязвимое поле (Excessive Data Exposure).

При регистрации пользователя API возвращает не только общедоступные поля, но чувствительные, например is_admin (см Рисунок 7).

Зарегистрируем нового пользователя (Account C) и дадим ему права администратора. Мы можем сделать это, введя is_admin: true в конечную точку API (см. Рисунок 8).

В веб интерфейсе появился пункт, Admin Panel, где мы можем создавать/удалять пользователей и управлять балансом (см. Рисунок 9).

Excessive Data Exposure позволила узнать о существовании поля is_admin. Mass Assignment — отсутствие фильтрации полей на стороне сервера дало возможность передать и применить is_admin: true. В результате новый аккаунт получил полный административный контроль.

Fix: Рекомендации по устранению BOPLA

1. Whitelist полей: на стороне сервера явно перечислять допустимые атрибуты (username, email, password) и отбросить всё остальное.

2. Игнорировать или валидировать посторонние поля: любые поля вне списка игнорировать или возвращать ошибку.

3. Управление «чувствительными» свойствами только на сервере: флаги is_admin, role, balance и т. п. должны устанавливаться бизнес-логикой, а не клиентским вводом.

4. Логирование и мониторинг: фиксировать попытки передачи запрещённых полей и оповещать администраторов о подозрительной активности.

API4: Unrestricted Resource Consumption

Unrestricted Resource Consumption — ситуация, когда API не накладывает ограничения на потребление ресурсов (число запросов, объём данных, время выполнения операций, количество параллельных соединений и т.п.). Это позволяет злоумышленникам или случайным пользователям исчерпать CPU, память, пропускную способность сети или нагрузить базу данных настолько, что сервис упадёт или будет серьёзно деградировать (DoS).

Этап 1. Поиск «горячих» точек API

1. Анализируем все эндпоинты, которые могут выполнять тяжёлые операции:

Логин/фозготы пароля (привязывают email, отправляют SMS)

Запросы с большими выборками (например, выгрузка логов, истории транзакций)

CRUD-операции над большими наборами данных

Пример

Эндпоинт: GET /api/v4/transactions?start=0&limit=10000

Почему важно: отсутствие лимита limit позволит запросить десятки и сотни тысяч записей за один вызов.

Этап 2. Запуск атаки и наблюдение за ресурсами

Сервер начинает обрабатывать поток тяжёлых запросов:

·       большие выборки из БД

·       формирование больших JSON-ответов

Мониторинг на стороне администратора покажет пик CPU, рост задержек и падение свободной памяти.

Этап 3. Эскалация — отказ в обслуживании (DoS)

Пользователи не могут войти, отправить данные, получить ответ. В худшем случае контейнер/VM перестаёт отвечать и требует перезапуска.

Параллельно вы можете смешать «запросы фозгота пароля» (отправка SMS/email) и «экспорт всей истории» — так вы «съедите» не только CPU и память, но и пропускную способность почтового/SMS-сервиса.

Рекомендации по защите

 

API5: BFLA (Broken Function Level Authorization)

 

Рассмотрим три определения, которые затрагивают эту уязвимость.

1. BFLA (Broken Function Level Authorization)

Ошибка авторизации на уровне функций или эндпоинтов API. Приложение проверяет, что пользователь аутентифицирован, но не проверяет, имеет ли он право вызывать конкретную функцию (например, удаление пользователя, одобрение займов и т.п.).

2. RBAC (Role-Based Access Control)

Модель управления доступом, при которой правами на функции управляет роль пользователя (админ, менеджер, клиент и т.д.).

3. JWT Forging

Взлом JWT-токена путём изменения его полезной нагрузки (payload) и подписи, если сервер не проверяет подпись должным образом.

Пошаговая эксплуатация BFLA

Шаг 1. Регистрация и поиск админ-эндпоинтов

Создаём обычный аккаунт (Account B) и изучаем Swagger/OpenAPI-документацию.

Находим: энтпоинты вроде DELETE /api/v5/users/{id} или POST /api/v5/loans/{id}/approve, помеченные только для админов.

Шаг 2. Проверка без форжа JWT

Попытка без подделки токена (см. Рисунок 10)

Шаг 3. Форжинг JWT для повышения роли

Извлекаем токен: копируем JWT из браузера. Декодируем через jwt.io: получаем header и payload. Меняем is_admin: false → true и сохраняем:

Если сервер НИЧЕГО не проверяет кроме подписи, подделка пройдёт. Полученный новый токен: вставляем закодированные header+payload, оставляем оригинальную подпись (сервер её не валидирует). Обращаемся к защищённому эндпоинту с поддельным токеном. Детали отражены на рисунках ниже.

Сервер проверил только наличие токена и поле is_admin из payload, но не валидировал подпись и не обращался к базе за реальной ролью.

 

Рекомендации по защите

Соблюдение этих правил надёжно защитит от BFLA-уязвимостей и обеспечит корректную авторизацию на уровне функций. 

API6: Unrestricted Access to Sensitive Business Flows

API6: Unrestricted Access to Sensitive Business Flows

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

1. Описание уязвимости

Unrestricted Access to Sensitive Business Flows — ситуация, когда API не ограничивает доступ к критическим бизнес-функциям (создание транзакций, изменение балансов, одобрение кредитов и т.п.) на основе ролей или прав пользователя.

Где проявляется:

Регистрационные и профильные эндпоинты, куда можно добавить «лишние» поля (mass assignment).

Управляющие операции (добавление средств, изменение статусов заявок) без проверок роли.

2. Эксплуатация

Я рекомендую всегда проверять, нет ли «дыр» по цепочке уязвимостей. В этом примере мы используем существующую Mass Assignment (BOPLA) для получения неограниченного баланса:

1. Регистрация злоумышленника

Я часто видел, как разработчики забывают жёстко фильтровать список полей, получаемых от клиента.

2. Проверка результата

3. Манипуляция бизнес-потоком

Теперь с таким балансом можно:

Переводить виртуальные средства другим пользователям

Взламывать лимиты кредитного API

Поддельные отчёты по кассовым операциям

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

Контрмеры

Я рекомендую следовать нескольким уровням защиты:

API7: SSRF (Server Side Request Forgery) 

Серверный обман: Суть и масштаб угрозы

SSRF превращает благонамеренные API в оружие против их же инфраструктуры. Server-Side Request Forgery (SSRF) — это когда злоумышленник заставляет сервер делать запросы к внутренним ресурсам, которые никогда не должны быть доступны извне.

Где кроется опасность? В любом API, который:

Загружает файлы по URL /api/upload?url=...)

Интегрируется с веб-хуками (/api/webhook?endpoint=...)

Выполняет сканирование (/api/scan?target=...)

2. Механика атаки: Реальные сценарии эксплуатации

Расскажу на примере из практики — инцидента с платежным шлюзом, где SSRF привел к компрометации всей сети.

Сценарий: Атака на внутренние системы

Уязвимый ответ:

Последствие: Утечка IAM-ключей и доступ к S3-бакетам.

Архитектурные изменения:

·       Выделенные прокси-сервисы: Все исходящие запросы через изолированный микросервис с белым списком доменов

·       Zero Trust для внутренних коммуникаций: Требуйте mTLS даже для localhost-запросов

Middleware-решения:

·       Строгая валидация URL:

·       Блокировка опасных схем: Отклоняйте file://, gopher://, dict://

Best practices:

1.    Сетевой сегментация: Отделите worker-ноды от систем управления

2.    Sandbox для рендеринга: Запускайте процессы в изолированных контейнерах

3.    Глубокий инспектинг: Используйте WAF с SSRF-правилами (например, блокировка запросов к RFC1918)

4.    Харденинг облака: Отключите метаданные IMDSv1, используйте IMDSv2

SRF остаётся “тихим убийцей” — 34% компаний обнаруживают его только после утечки данных

Чеклист для разработчиков:

1.    Все URL-параметры проходят allow-list валидацию

2.    Заблокированы запросы к приватным IP (10.0.0.0/8, 192.168.0.0/16)

3.    Реализован IDOR-контроль для ресурсных URL

4.    Внедрены лимиты на редиректы (max 2)

Любой endpoint, принимающий URL — потенциальная дыра в периметре.

API8: Security Misconfiguration

1. Тихий убийца в вашем стеке: Суть проблемы  

В банковской безопасности происходит больше взломов из-за забытых настроек, чем из-за сложных эксплойтов. Security Misconfiguration (OWASP API8) — это когда система уязвима из-за незащищённых дефолтных настроек, открытых функций или ошибок окружения.

Где искать бомбы замедленного действия?

Стек технологий: Серверы, СУБД, облачные сервисы

Критические точки:

1.    Открытый HTTP вместо HTTPS

2.    Продакшн-логи с debug-режимом

3.    Публичная документация Swagger/Redoc

4.    CORS с Access-Control-Allow-Origin:

5.    Предсказуемые сессии (Base64 без подписи)

6.    Личный пример: В 2019 году через незакрытый эндпоинт /actuator/health хакеры получили топологию всей нашей сети.

2. Как эксплуатируют дыры в настройках: Сценарии из практики  

Расскажу на реальном кейсе из финтеха, где misconfiguration привёл к штрафу $2M от регулятора.  

Сценарий: Кража данных через HTTP + предсказуемые куки

Уязвимый ответ:

Последствие: MITM-атака в публичном Wi-Fi → перехват сессий 5000 клиентов.

Цепочка последствий:

1. Утечка PII данных через незащищённый эндпоинт

2. Инъекция в СУБД через включённый H2 Console

3. Полная компрометация кластера Kubernetes

4. Жёсткий харденинг: Контрмеры для параноиков

Архитектурные изменения:

·       Строгая сегментация: Отдельные VPC для prod/staging/dev

·       Immutable-инфраструктура: Пересборка окружений при любых изменениях настроек

·       "Тёмные" API: Автоматическое отключение неиспользуемых эндпоинтов через IaC

Middleware-защита:

Единый security-gateway:

Конфиг Nginx для банковских стандартов

1.    add_header Strict-Transport-Security "max-age=63072000" always;

2.    add_header X-Content-Type-Options "nosniff";

3.    add_header Content-Security-Policy "default-src 'self'";

4.    add_header Access-Control-Allow-Origin "trusted-domain.com";

5.    server_tokens off; # Убираем версию сервера

WAF с кастомными правилами: Блокировка запросов к /actuator/, /phpmyadmin, /console

Best practices для разработки:

1. HTTPS-only enforcement: HSTS-preload + 307 redirect

2. Zero-trust CORS: Белые списки доменов вместо

3. Безопасность сессий:

Подписанные/шифрованные куки (SameSite=Strict)

JWT с коротким TTL (max 15 мин для критичных операций)

4. Документация под замком:

Пример блокировки Swagger в Spring

·       springdoc.swagger-ui.enabled=false

·       springdoc.api-docs.enabled=false

5. Secret-менеджмент: Ротация ключей через HashiCorp Vault

Чеклист для экстренного аудита:

1.    Все окружения идентичны (config-as-code)

2.    Debug-режим отключён в prod (уберите ?debug=true)

3.    Нет дефолтных учёток admin/admin

4.    Заголовки безопасности включены (XSS, HSTS, CSP)

5.    Пароли хешируются с солью (bcrypt/scrypt)

Помните моё правило как CISO: Дефолтные настройки безопасны ровно до момента запуска системы

API9: Improper Inventory Management

Уязвимость API9: Когда забытые эндпоинты становятся вратами для хакеров

1. Слепые зоны API: Почему инвентаризация — ваша первая линия обороны

Банковской безопасности забытые эндпоинты взрывают системы. Improper Inventory Management (API9) — это критический пробел в контроле и документировании API. Без чёткого учёта:

·       Теряется видимость всех конечных точек

·       Растёт поверхность атаки из-за "теневых" API

·       Старые версии и dev-эндпоинты остаются доступными

2. Типичный сценарий взлома: Три шага через забытый эндпоинт

Реконструирую атаку:

Шаг 1: Запрос сброса пароля через текущую версию (v2)

Шаг 2: Обход защиты через старую версию (v1)

Шаг 3: Компрометация аккаунта

Результат: Полный контроль над учётной записью через deprecated-функционал.

3. Контрмеры: Как закрыть бреши учёта

Архитектурные решения:

1.    Полный инвентарь API Шлюз для маршрутизации

2.    Политики версионирования

3.    Сканирование теневых API

4.    Блокировка non-prod сред

Тактические меры:

1.    Ведите реестр API: Фиксируйте все эндпоинты (продакшн, тест, сторонние)

2.    Централизуйте через API-шлюз: Единая точка контроля трафика

3.    Чёткое версионирование: Помечайте устаревшие версии и отключайте их по графику

4.    Регулярное сканирование: Поиск забытых эндпоинтов в сети  

5.    Изолируйте non-prod: Запретите доступ к dev/staging из интернета

6.    Стандартизируйте документацию: Единые шаблоны для всех команд

7.    Метки для метаданных: Версия, среда, ответственный, назначение

8.    Мониторинг активности: Алёрты на использование deprecated-путей

Экстренный чеклист:

1.    Все ли эндпоинты задокументированы?

2.    Есть ли доступ к dev-версиям извне?

3.    Отключены ли старые пути (/v1, /legacy)?

4.    Ведутся ли логи использования deprecated-API?

Неучтённый API — это мина замедленного действия

API10: Unsafe Consumption of APIs

В банковской безопасности доверие к сторонним сервисам взрывает системы изнутри. Unsafe Consumption of APIs (API10) — это практика безоговорочного доверия к данным внешних API без проверки или санации. Как следствие: 

1.    Внедрение вредоносных нагрузок через цепочки интеграций 

2.    Эксплуатация уязвимостей в сторонних сервисах 

3.    Критические инциденты из-за неожиданных данных или форматов 

2. Цепная реакция уязвимостей: Три шага эксплуатации 

Шаг 1: Подготовка вредоносной нагрузки

Шаг 2: Обход аутентификации через уязвимый API

Процесс безопасной интеграции:

1.    Внешний API

2.    Валидация схемы

3.    Санация данных

4.    HTTPS + OAuth

5.    Лимитирование

6.    Мониторинг

Ключевые практики:

 

Экстренный чеклист: 

Все ли внешние данные проходят валидацию? 

Реализована ли санация для потенциально опасных полей? 

Используется ли HTTPS для всех интеграций? 

Есть ли таймауты для внешних вызовов? 

 

Доверяй, но проверяй — особенно когда речь о сторонних API