|
https://forum.antichat.xyz/attachmen...12a34f3cdc.png
Когда берёшь в работу очередной API-пентест, первый вопрос должен быть - не «какой сканер запустить», а «как устроена логика этого сервиса». Сканер DAST найдёт отсутствие заголовков безопасности и открытый debug-эндпоинт. Но он не поймёт, что Код:
GET /api/v1/orders/1337Разбираю каждый пункт списка через конкретные векторы атак, HTTP-запросы и инструменты. Без теории ради теории - только то, что реально эксплуатируется на пентестах и в bug bounty. Что изменилось в OWASP API Top 10 между 2019 и 2023 Прежде чем лезть в тестирование, стоит понять логику обновления. Список 2023 года - не косметическая правка. Три категории добавлены с нуля, две объединены, а фокус сместился с классических инъекций на уязвимости бизнес-логики. Ключевые изменения, которые влияют на методику API пентеста:
Методика тестирования: от разведки к эксплуатации Цепочка атаки на API повторяет классическую kill chain, но с нюансами, характерными для API-контекста: Разведка - сбор эндпоинтов, анализ документации (Swagger/OpenAPI), перехват трафика мобильного приложения через mitmproxy. На этом этапе работают Postman для импорта коллекций и Код:
ffufТестирование аутентификации и авторизации - подмена токенов, перебор идентификаторов объектов, проверка разграничения ролей. Это ядро API-пентеста, и оно съедает 60-70% времени. У меня бывало - иногда и все 80%, если API сложный. Эксплуатация - цепочка из нескольких слабостей. Например, Improper Inventory Management (забытый v1 API без авторизации) + BOLA = полный доступ к чужим данным. Маппинг: Data from Information Repositories (T1213, Collection) - доступ к данным через логические дефекты авторизации. Закрепление и извлечение данных - использование полученного доступа для эксфильтрации или модификации. Маппинг: Data Manipulation (T1565, Impact). Теперь - каждый пункт OWASP API Top 10 с позиции атакующего. API1:2023 - BOLA уязвимость API (Broken Object Level Authorization) BOLA сидит на первом месте не просто так - это самый распространённый и самый тривиальный в эксплуатации класс уязвимостей API. Суть: сервер доверяет идентификатору объекта в запросе клиента и не проверяет, принадлежит ли объект текущему пользователю. Замени один ID на другой - и получи чужие данные. Вот и весь «эксплойт». Как тестировать. Авторизуешься как пользователь A, находишь запрос вида Код:
GET /api/v2/invoices/4521Код:
4521Код:
4522Нюанс, который часто упускают: BOLA бывает не только в GET-запросах. Проверяйте Код:
PUT /api/users/1338Код:
DELETE /api/comments/9921Среди известных прецедентов - уязвимость USPS Informed Visibility API (2018, доступ к данным 60 млн пользователей через подмену идентификаторов) и баги в API Bumble (2020, доступ к произвольным профилям через перебор ID). BOLA регулярно приводит к раскрытию персональных данных миллионов пользователей. ATT&CK маппинг: Прямого маппинга BOLA на MITRE ATT&CK нет - ATT&CK описывает тактики атакующего на уровне инфраструктуры, а не логические баги приложения. Ближайшая техника по результату: Data from Information Repositories (T1213, Collection). T1210 (Exploitation of Remote Services) не подходит - это про lateral movement между системами, а не про IDOR в веб-приложении. API2:2023 - Broken Authentication Сломанная аутентификация - это не только слабые пароли. В контексте REST API безопасности это JWT без проверки подписи, токены без срока действия, API-ключи как единственный механизм аутентификации (и да, такое до сих пор встречается в 2025-м). Что проверять на пентесте:
По данным ISACA, среди корневых причин - хранение паролей в открытом виде, отсутствие проверки подлинности токенов, смена пароля без верификации личности. API3:2023 - Broken Object Property Level Authorization Эта категория объединила две проблемы 2019 года: избыточную выдачу данных (Excessive Data Exposure) и mass assignment уязвимость. Корень один - нет контроля на уровне отдельных полей объекта. Excessive Data Exposure на практике. Отправляю Код:
GET /api/users/meКод:
password_hashКод:
internal_idКод:
roleКод:
ssnMass assignment на практике. Регистрируюсь как обычный пользователь, затем повторяю запрос обновления профиля, добавляя в тело Код:
"role": "admin"Код:
"is_premium": trueКод:
roleКод:
PUT /usersДля обнаружения скрытых параметров использую Arjun: Код:
arjun -u https://target/api/users/me -m JSONAPI4:2023 - Unrestricted Resource Consumption Отсутствие ограничений на потребление ресурсов. В 2019 году это называлось «Lack of Resources & Rate Limiting», теперь название точнее - проблема в неограниченном потреблении. Что тестировать: отправить Код:
GET /api/products?page_size=999999ATT&CK маппинг: Application Exhaustion Flood (T1499.003, Impact) - DoS через исчерпание ресурсов легитимными, но чрезмерными запросами. По данным ISACA, типичные корневые причины: отсутствие таймаутов выполнения, отсутствие лимита на размер загружаемых файлов, неограниченное число записей в одном ответе. API5:2023 - Broken Function Level Authorization (BFLA) Если BOLA - горизонтальная эскалация (доступ к чужим объектам того же уровня), то BFLA - вертикальная (доступ к функциям другого уровня привилегий). Практический тест. Захватываю запрос обычного пользователя и меняю путь: Код:
/api/users/profileКод:
/api/admin/usersКод:
GET /api/orders/123Код:
DELETE /api/orders/123Код:
/admin/Код:
/management/Код:
/internal/Код:
ffuf -w api-endpoints.txt -u https://target/api/FUZZ -H "Authorization: Bearer "Код:
/api/internal/export-all-usersAPI6:2023 - Unrestricted Access to Sensitive Business Flows Новый пункт в списке 2023 года, и его нельзя найти сканером. Это не баг реализации - это отсутствие защиты бизнес-логики от автоматизированного злоупотребления. Примеры: массовая скупка лимитированных товаров ботами через API, автоматическая регистрация аккаунтов для спама, массовое использование купонов. По данным APIsec, атакующие пишут скрипты, распределённые по разным IP, которые скупают весь товар быстрее реальных покупателей. Как тестировать. Определите критические бизнес-потоки (покупка, бронирование, отправка сообщений). Автоматизируйте их простым скриптом и проверьте: есть ли CAPTCHA, fingerprinting, лимиты на частоту операций. Если можно отправить 1000 заказов за минуту с одного токена - это уязвимость. Тут никакой Burp не поможет - нужно понимать бизнес-логику. API7:2023 - Server Side Request Forgery (SSRF) SSRF - новинка в API Top 10, но старая знакомая для пентестеров веб-приложений. API особенно подвержены SSRF, потому что часто принимают URL как параметр - для webhook-ов, импорта, preview. Тест: находишь параметр вроде Код:
"callback_url": "https://example.com"Код:
"image_url": "..."Код:
http://169.254.169.254/latest/meta-data/Как отмечают в блоге OWASP, REST API управления облаком, Kubernetes и Docker делают эксплуатацию SSRF особенно опасной - через неё можно добраться до секретов оркестратора. Одна SSRF в облаке - и ты уже читаешь IAM-креды. API8:2023 - Security Misconfiguration Широкая категория, покрывающая всё: от verbose-ошибок со стектрейсами до отсутствия CORS-политик и включённых HTTP-методов TRACE/OPTIONS. Чеклист для DAST API сканирования и ручной проверки:
Код:
nuclei -u https://target -t exposures/ -t misconfiguration/API9:2023 - Improper Inventory Management Забытые эндпоинты, старые версии API без патчей, debug-пути на production - всё это Improper Inventory Management. Для пентестера это значит: всегда проверяй, существует ли Код:
/api/v1/Код:
/api/v3/Практика: перехватываю трафик мобильного приложения через mitmproxy, экспортирую все вызванные URL и сравниваю со Swagger-документацией. Расхождения - потенциальные shadow-эндпоинты. Дополнительно прогоняю Код:
ffufКод:
api-endpoints-v2.txtAPI10:2023 - Unsafe Consumption of APIs Разработчики доверяют данным от сторонних API больше, чем пользовательскому вводу. Если приложение забирает данные из внешнего сервиса и вставляет их без валидации - атакующий может скомпрометировать внешний сервис и через него ударить по целевому приложению. Маппинг ATT&CK: Trusted Relationship (T1199, Initial Access) - атакующий компрометирует внешний сервис, с которым у целевого приложения установлены доверительные отношения, и через него доставляет вредоносные данные. На пентесте проверяю: если приложение интегрируется с внешним API, что произойдёт при подмене ответа этого API (через mitmproxy)? Обрабатывается ли HTML/JS в данных? Есть ли таймауты и circuit breaker? Часто ответ - «нет, нет и нет». Инструментарий для API пентеста Стек, который использую на каждом проекте: ЗадачаИнструментПрименени еПерехват трафикаBurp Suite + AutorizeВсе запросы через прокси, автоматическая проверка BOLA/BFLAМобильный трафикmitmproxyПерехват API-вызовов мобильных приложенийФаззинг параметровArjun, ffufОбнаружение скрытых параметров и эндпоинтовJWT-атакиjwt_toolПодмена алгоритмов, brute-force секретаАвтоматизация проверокnuclei + кастомные темплейтыМассовые проверки misconfigurations и известных CVEРеверс логикиPostmanИмпорт OpenAPI, построение цепочек запросовGraphQLInQL (Burp extension)Интроспекция, обнаружение мутаций, batch-атаки GraphQL security: отдельное направление тестирования GraphQL-эндпоинты подвержены тем же категориям OWASP API Top 10, но со своими причудами. Интроспекция (запрос Код:
{__schema{types{name,fields{name}}}}Batch-запросы в GraphQL позволяют отправить сотни мутаций в одном HTTP-запросе, обходя rate limiting - прямой путь к API4 (Unrestricted Resource Consumption). Вложенные запросы с глубиной 15-20 уровней вызывают DoS на сервере. Для тестирования GraphQL security использую InQL для Burp Suite: он парсит схему, генерирует все возможные запросы и мутации, позволяя быстро найти чувствительные операции. Пошаговая методика: систематический API пентест Когда получаешь scope на API-пентест, работай по структуре, а не хаотично тыкай в эндпоинты: 📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше Получить доступ просто — достаточно проявить активность на форуме Эта последовательность покрывает все десять пунктов OWASP API Top 10 и даёт структуру для отчёта. Заключение OWASP API Top 10 2023 - не теоретический список для презентаций. Это рабочая карта для тестирования безопасности API, где каждая категория транслируется в конкретные проверки. Главный тренд - смещение от инъекций к логическим уязвимостям: BOLA, BFLA, business logic abuse. Эти баги не найдёт ни один DAST-сканер - они требуют понимания контекста приложения и ручного тестирования. Если строите методику API пентеста - начните с авторизации. API1, API3, API5 - три пункта из десяти, и все про контроль доступа. Затем аутентификация и логика. Автоматизируйте рутину через Autorize, nuclei и ffuf, но не полагайтесь только на инструменты. Самые критичные баги в API находятся руками - в Burp Repeater, при замене одного ID на другой. Попробуйте прямо сейчас: возьмите любой API, с которым работаете, и подмените ID в паре запросов. Результат может неприятно удивить. |
| Время: 00:45 |