ВАЖНАЯ ИНФОРМАЦИЯ спойлер это перевод Хочу поднять тему, которая часто остается незамеченной, но становится всё более актуальной в веб-хакинге — злоупотребление внутренними и сторонними 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, инъекции, ошибки аутентификации. Минимизировать раскрытие данных — выдавать только необходимое. фото не связанное со статьей
Созависимость твоей апки и внешнего апи ничего хорошего, но иногда по другому никак. А поводу абуза апи, пишешь ssr приложение и всё, также с помощью фингер принта и mtls проверяешь что чел не бот ебанный, вот и все