Злоупотребление внутренними и сторонними API в веб-приложениях

ВАЖНАЯ ИНФОРМАЦИЯ

​

​

спойлер

это перевод

​

Хочу поднять тему, которая часто остается незамеченной, но становится всё более актуальной в веб-хакинге — злоупотребление внутренними и сторонними API. Современные приложения всё больше зависят от API, и эта поверхность атаки быстро растёт. Многие не осознают, насколько опасно, если эти API плохо защищены.​

• ​

В чём суть злоупотребления API?​

api это

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

API — будь то внутренние или сторонние — повсюду. Они связывают сервисы, обрабатывают данные и выполняют важную бизнес-логику. Но зачастую эти API плохо учтены и защищены. Особенно сторонние API могут быть «призрачными» — работать вне обычных циклов разработки и без должных мер безопасности.
Атакующие могут использовать слабую аутентификацию, неправильные проверки авторизации или ошибки в бизнес-логике, чтобы:​

• 
  
• Получить доступ к конфиденциальным данным, которые им не положены
• Манипулировать или удалять информацию
• Повысить свои привилегии
• Автоматизировать атаки или массово сливать данные
• Вызывать отказ в обслуживании, злоупотребляя лимитами запросов
• Как обычно злоупотребляют API?​
• Основываясь на реальных кейсах и исследованиях, процесс примерно такой:
  
  
  Разведка

  собирают информацию об эндпоинтах API через документацию, анализ трафика или fuzzing.​

Обход аутентификации

пытаются обойти проверки аутентификации или авторизации, используя слабые токены или ошибки в логике.​

Перечисление эндпоинтов

составляют карту всех доступных эндпоинтов и параметров.​

Манипуляция параметрами

изменяют входные данные, чтобы внедрить вредоносные payload’ы или получить несанкционированный доступ (IDOR, SQLi, JSON-инъекции).​

***** force

перебирают слабые учётные данные или токены для доступа.​

Отказ в обслуживании

перегружают API запросами, чтобы вывести сервис из строя.​

Экспфильтрация данных

тайно выносят ценные данные.​

Сокрытие следов

удаляют **** или маскируют активность под нормальный трафик.​

Примеры уязвимостей и payload’ов​

1. IDOR (Insecure Direct Object Reference)​

Предположим, есть API-запрос для получения данных пользователя:​

такой

GET /api/user/profile?id=12345​

Если сервер не проверяет, что текущий пользователь имеет право смотреть профиль с id=12345, злоумышленник может подставить id другого пользователя:​

лингангули

GET /api/user/profile?id=67890​

И получить чужие данные.
​

2. Пример JSON-инъекции​

Некорректная обработка JSON-параметров может позволить внедрить вредоносные данные:​

код

POST /api/update
{
"user": {
"id": "12345",
"role": "admin" // если сервер не проверяет роль, можно повысить привилегии
}
}​

Если API не валидирует роль, можно изменить её на "admin" и получить права администратора.

​

3. Пример обхода аутентификации через уязвимость в токенах​

Иногда токены слабо защищены или предсказуемы. Злоумышленник может перебрать токены или использовать украденный токен:​

кэкэшки

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...​

Если нет проверки срока действия или контроля сессии, можно получить доступ к чужому аккаунту.
​

Как защититься?​

Вести полный учёт всех API, включая сторонние.​

• 
  
• Внедрять строгую валидацию и проверки авторизации на каждом эндпоинте.
• Использовать надёжную аутентификацию (OAuth, mTLS) и регулярно менять ключи.
• Настроить ограничение частоты запросов (rate limiting) для предотвращения злоупотреблений и DoS.
• Мониторить трафик API на аномалии и подозрительную активность.
• Регулярно тестировать API на распространённые уязвимости — IDOR, инъекции, ошибки аутентификации.
• Минимизировать раскрытие данных — выдавать только необходимое.
  
  
  фото не связанное со статьей