TL, д-р
В большинстве случаев утечки данных через API связаны с некорректной авторизацией, а не с экзотическими эксплойтами. Три из пяти самых распространенных категорий в рейтинге OWASP API Security Top 10 — это ошибки авторизации, в первую очередь, это... BOLA.
Невозможно обеспечить безопасность того, о существовании чего вы не знаете. Неправильное управление запасами Это отдельная категория риска по OWASP, и она является основой для всех остальных мер контроля.
Необходимо выявлять случаи заражения до начала развертывания, а не после. Статический анализ кода и спецификаций API выявляет неработающую конечную точку в pull requestза стоимость одного commitТестирование во время выполнения выявляет ту же проблему в реальных условиях, что приводит к возникновению инцидента.
Это контрольный список, который необходимо постоянно выполнять. На каждом pull requestЭто не предварительный обзор перед запуском: 10 практикот инвентаризации и авторизации до ограничения скорости запросов, раскрытия данных ответов и доверия к третьим сторонам.
Поверхность атаки вашего API растет с каждым pull requestБольшинство команд узнают о том, что конечная точка открыта, только когда она запущена и принимает трафик, а это значит, что исправление, которое раньше обходилось бы в определенную сумму, теперь будет невозможным. commit Теперь проверка стоит как отчет об инциденте. Это руководство описывает лучшие практики обеспечения безопасности API, которые действительно работают в производственной среде, и организовано в виде контрольного списка, который вы можете запустить в своей собственной кодовой базе уже сегодня, а не списка абстрактных принципов, которые никто не внедряет.
Почему лучшие практики обеспечения безопасности API сейчас выглядят иначе?
Раньше API были связующим звеном между системами. Теперь они являются основным интерфейсом практически для всего: мобильных приложений, интеграций с партнерами, агентов искусственного интеллекта, внутренних микросервисов. Этот сдвиг изменил то, что должны охватывать лучшие практики защиты API. Уже недостаточно защитить задокументированный API; необходимо учитывать и те API, которые ваши команды разработали, но забыли задокументировать.
Два числа объясняют, почему это важно. Топ-10 безопасности API OWASP В трех из пяти основных категорий проблем с авторизацией это означает, что большинство реальных инцидентов с API связаны с несколькими предотвратимыми схемами, а не с экзотическими уязвимостями нулевого дня. Неправильное управление инвентаризацией также входит в этот список как отдельная категория риска: команды подвергаются взлому через API, о работе которых они не знали.
Эта тема проходит красной нитью через каждый пункт ниже. Передовые методы управления API начинаются с понимания того, что у вас есть, а не просто с защиты того, что вы вспомнили задокументировать.
Рекомендации по обеспечению безопасности API: краткий обзор
Прежде чем перейти к подробному контрольному списку, вот краткая версия: что нужно внедрить, от чего это действительно защищает и насколько срочно это необходимо.
Рассматривайте строку «Обязательно» как незыблемый базовый параметр для любого API, внутреннего или внешнего. Элементы с «высоким» приоритетом отличают программу от других, позволяя выявлять проблемы. pull request от того, кто узнает об этом из протокола об инциденте.
Контрольный список лучших практик обеспечения безопасности API
1. Соберите полный инвентарь, прежде чем строить оборону.
Вы не можете защитить конечную точку, о существовании которой не знаете. Начинайте любые усилия по внедрению лучших практик защиты API с реального учета: каждая конечная точка, ее метод, путь, сервис и модуль, к которым она принадлежит, и требуется ли аутентификация. Собирайте эту информацию из исходного кода и из спецификаций вашего API (OpenAPI, Swagger), а не только из документации, потому что именно в этом пробеле скрываются забытые и «осиротевшие» конечные точки.
Где находится Xygeni: Безопасность API Xygeni Эта функция формирует данный список непосредственно из исходного кода вашего приложения и спецификаций API, отображая конечные точки, задокументированные вашей командой, и те, которые никто не задокументировал, еще до того, как они попадут в производственную среду.
2. Обеспечьте авторизацию на уровне объектов и функций.
Некорректная авторизация на уровне объектов и функций неизменно занимает первое место в списке 10 самых распространенных проблем безопасности API по версии OWASP. Лучшая практика заключается не в «добавлении аутентификации», а в проверке в каждом запросе, является ли... этот конкретный пользователь разрешен доступ этот конкретный объектРечь идёт не только о том, вошли ли они вообще в систему. Аутентификация определяет, кто этот человек. Авторизация определяет, к чему ему разрешено прикасаться, и это необходимо проверять каждый раз, а не предполагать на основе действительного токена.
3. Проверяйте и очищайте все данные, получаемые API.
Каждый параметр, заголовок и поле тела запроса считаются недостоверными входными данными, пока не будет доказано обратное. Внедрите строгую проверку схемы, отклоняйте неожиданные поля (это ваша защита от массового назначения) и никогда не доверяйте данным, предоставленным клиентом, при определении области доступа или логики ценообразования.
4. Ограничение скорости и регулирование трафика должны быть предусмотрены изначально, а не добавлены позже.
Неограниченное потребление ресурсов позволяет одному клиенту исчерпать вашу инфраструктуру или увеличить расходы на платные бэкэнд-сервисы. Установите лимиты для каждой конечной точки, каждого пользователя и каждого ключа API и убедитесь, что лимиты масштабируются в соответствии с фактической стоимостью операции, а не являются фиксированным числом, применяемым повсеместно.
5. Рассматривайте каждый ответ как потенциальную утечку данных.
Чрезмерное раскрытие данных происходит, когда API возвращает больше данных, чем нужно клиенту, и полагается на фильтрацию этих данных на стороне фронтенда. Это скорее привычка, чем редкая ошибка, и это одно из наиболее распространенных нарушений лучших практик защиты API, поскольку оно остается незаметным, пока кто-то не проверит необработанные ответы, а не отобразившийся пользовательский интерфейс.
Где находится Xygeni: Xygeni API Security выявляет утечку персональных данных непосредственно в ответах API, обнаруживая чрезмерное предоставление информации до отправки запроса, а не после того, как это заметит клиент или регулирующий орган.
6. Ведите точный и актуальный учет API, включая устаревшие.
неподходящий инвентаризация Управление API неслучайно выделено в отдельную категорию в списке OWASP: устаревшие версии API и недокументированные среды тестирования часто остаются доступными и уязвимыми даже после того, как кто-либо вспомнит об их существовании. Программа передовых методов управления API должна включать в себя не только обнаружение, но и вывод из эксплуатации.
7. Тщательно изучите, чему доверяет ваш API от третьих сторон.
Небезопасное использование сторонних API — это недооцененный риск. Разработчики, как правило, больше доверяют данным, поступающим из чужих API, чем пользовательскому вводу, что прямо противоположно действительности; интеграция со сторонним сервисом по-прежнему является внешним, непроверенным источником и должна проверяться аналогичным образом.
8. Предоставляйте разработчикам доказательства, а не просто оповещения.
Сообщение об ошибке «нарушение авторизации на этом эндпоинте» — это заявка, которую необходимо расследовать, прежде чем приступать к исправлению. Сообщение об ошибке, указывающее на конкретный файл, класс, метод и строку кода, позволяет разработчику действовать немедленно. Это лучшая практика для самой программы безопасности, а не только для API: сообщения об ошибках, требующие расследования перед устранением проблемы, замедляют весь процесс.
Где находится Xygeni: Каждая обнаруженная уязвимость в Xygeni API Security указывает на конкретный обработчик, файл, класс, метод и строку кода, которая привела к её появлению, поэтому исправление начинается сразу же после обнаружения уязвимости.
9. Выявляйте уязвимости до развертывания, а не после.
Тестирование API во время выполнения показывает, что конечная точка становится доступной, как только она начинает обрабатывать трафик. Статический анализ кода и спецификаций API обнаруживает ту же уязвимость, даже когда точка еще находится в процессе обработки трафика. pull requestкогда ремонт обходится в один commit Вместо реагирования на инциденты. В лучших практиках управления API статическое обнаружение рассматривается как первый уровень, а тестирование во время выполнения — как вторая, дополнительная проверка уже работающего приложения.
Где находится Xygeni: Xygeni API Security по своей сути является статическим решением, анализирующим код и спецификации перед выпуском, и работает параллельно с ними. Xygeni DAST для анализа покрытия кода во время выполнения приложений, уже находящихся в эксплуатации.
10. Риски, связанные с API, следует размещать на том же уровне, что и остальные риски вашего приложения.
API не выходят из строя изолированно. Уязвимость API часто возникает из-за проблем с зависимостями или неправильной конфигурации. pipelineили утечка секретной информации. Рассмотрение безопасности API как отдельного инструмента со своей собственной консолью означает потерю этого контекста именно тогда, когда он наиболее важен.
Где находится Xygeni: Безопасность API находится рядом с SAST, SCA, Секреты, IaCи DAST на единой платформе Xygeni, так что обнаруженная ошибка API видна рядом с кодом и риском зависимостей, которые ее привели, а не в отдельном файле. login.
Превращение контрольного списка в привычку
Рекомендации по обеспечению безопасности API эффективны только на постоянной основе, а не в качестве проверки перед запуском. Проводите инвентаризацию и статический анализ каждого API. pull requestНе раз в квартал. Относитесь к новой, недокументированной конечной точке так же, как к новой, недокументированной зависимости: как к чему-то, что нужно исследовать немедленно, а не позже. И оценивайте эффективность ваших лучших практик защиты API так же, как и любую другую часть системы. SDLCДело не только в том, обнаружили ли вы проблему вообще, а в том, насколько рано вы ее обнаружили.
Быстрые ответы: Вопросы и ответы по лучшим практикам обеспечения безопасности API
Основные выводы
- Инвентаризация важнее обороны. Нельзя применять авторизацию, ограничения скорости или контроль данных к конечной точке, о существовании которой вы не знаете, а ненадлежащее управление инвентаризацией само по себе является отдельным риском, включенным в список 10 самых распространенных рисков в области безопасности API OWASP.
- Чаще всего утечки данных происходят не только при аутентификации, но и при авторизации. Три из пяти главных рисков безопасности API по версии OWASP связаны с ошибками авторизации. Проверка личности пользователя — это не то же самое, что проверка того, к чему ему разрешено прикасаться.
- Статический анализ выявляет то, что тестирование во время выполнения обнаруживает слишком поздно. Поиск возможностей для самовыражения в pull request затраты один commitОбнаружение этого дефекта в процессе производства приводит к возникновению инцидента.
- Каждый ответ — это потенциальная утечка данных. Чрезмерное раскрытие данных — это привычка, а не редкая ошибка, и она остается незаметной, пока кто-то не проверит необработанные ответы API, а не отобразившийся пользовательский интерфейс.
- Передовые методы обеспечения безопасности API эффективны только при постоянном совершенствовании.запускается на каждом pull requestЭто не ежеквартальный обзор и не контрольный список перед запуском.
- Риски, связанные с API, не должны храниться в отдельном инструменте. Наиболее эффективные передовые методы защиты API рассматривают выявленные проблемы с API как часть той же картины рисков, что и риски, связанные с кодом, зависимостями и т.д. pipeline securityЭто не изолированная консоль.
FAQ
Какие наиболее важные рекомендации по обеспечению безопасности API следует применять в первую очередь?
Начните с инвентаризации. Вы не можете применять проверки авторизации, ограничения скорости или средства контроля доступа к данным к конечной точке, о существовании которой вы не знаете, поэтому полная и точная инвентаризация каждой конечной точки API является основой, от которой зависит все остальное в этом контрольном списке.
В чём разница между лучшими практиками обеспечения безопасности API и лучшими практиками обеспечения безопасности общих приложений?
API создают риски, которые общие практики безопасности приложений не охватывают в полной мере: авторизация на уровне объектов и функций в масштабе, специфическая опасность доверия ответам сторонних API и проблема отслеживания устаревших или недокументированных конечных точек. Лучшие практики безопасности API — это лучшие практики безопасности приложений, применяемые к тем частям поверхности атаки, о которых легче всего забыть.
Следует ли проводить тестирование безопасности API до или после развертывания?
И то, и другое, но наиболее эффективный момент — это до. Статический анализ кода и спецификаций API позволяет выявить уязвимость на ранней стадии. pull requestТестирование во время выполнения (DAST) затем проверяет, что действительно достижимо после запуска приложения. Полагаться только на тестирование во время выполнения означает, что каждое исправление обходится дороже, чем должно быть.
Как часто следует обновлять список доступных API-интерфейсов?
Непрерывно, в идеале, каждый раз pull requestИнвентаризация, составленная один раз и пересматриваемая ежеквартально, устаревает уже в момент поставки нового конечного устройства, и именно этой уязвимостью злоупотребляет неправильное управление инвентаризацией.
Применимы ли лучшие практики управления API к внутренним API, а не только к публичным?
Да. К внутренним API часто предъявляются более низкие требования безопасности, поскольку они «не доступны из интернета», но они по-прежнему обрабатывают конфиденциальные данные и доступны любому, кто имеет доступ к внутренней сети, включая взломанную учетную запись или сотрудника, работающего внутри компании.
