Как APISIX защищает от 10 основных угроз безопасности API по версии OWASP

С увеличением использования и зависимости от API в современном цифровом ландшафте, угрозы безопасности, направленные на них, также растут с каждым годом. В 2023 году проект Open Web Application Security Project (OWASP) определил новые Топ-10 угроз для безопасности API. В этом блоге мы рассмотрим каждую угрозу и узнаем, как APISIX может защитить от них с примерами.

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

Вот список угроз безопасности, упомянутых OWASP:

1. Нарушение авторизации на уровне объектов
2. Нарушение аутентификации
3. Нарушение авторизации на уровне свойств объектов
4. Неограниченное потребление ресурсов
5. Нарушение авторизации на уровне функций
6. Неограниченный доступ к чувствительным бизнес-процессам
7. Подделка запросов на стороне сервера (SSRF)
8. Неправильная настройка безопасности
9. Неправильное управление инвентаризацией
10. Небезопасное использование API

1. Нарушение авторизации на уровне объектов

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

Пример: Медицинское учреждение предлагает онлайн-портал для пациентов. Из-за ошибки в дизайне портала, после аутентификации пациента, он может изменить URL или параметры запроса для доступа к медицинским записям, связанным с другим идентификатором пациента. Например, пациент Стив входит в портал для просмотра своих медицинских записей. Его записи доступны по URL https://healthportal.com/patient/123. Из любопытства Стив изменяет URL на https://healthportal.com/patient/124 и обнаруживает, что теперь может просматривать медицинские записи другого пациента. Это приводит к серьезному нарушению конфиденциальности и нарушению таких нормативных актов, как Закон о переносимости и подотчетности медицинского страхования (HIPAA).

Рекомендация: Реализуйте правильный механизм авторизации, который зависит от политик пользователей и иерархии. Шлюз APISIX поддерживает потоки авторизации на основе OAuth2 или JWT с помощью плагинов. Вы можете использовать политику OAuth2 для проверки токена при каждом запросе.

Используйте детализированный контроль доступа через систему Role-Based Access Control (RBAC) APISIX, интегрируя её с Open Policy Agent (OPA). Настроив определенные роли и разрешения в APISIX и связав эти роли с конкретными пользователями или токенами, вы можете гарантировать, что запросы к чувствительным конечным точкам будут должным образом авторизованы.

2. Нарушение аутентификации

Угроза: Неправильно реализованные механизмы аутентификации могут позволить злоумышленникам скомпрометировать токены аутентификации или просто атаковать конечные точки входа методом перебора, если отсутствует ограничение скорости.

Пример: Банковская система реализовала собственный механизм аутентификации. Однако из-за отсутствия должного анализа безопасности и тестирования в процессе аутентификации была обнаружена уязвимость. В частности, после ввода имени пользователя и пароля система генерировала предсказуемый токен сессии, например, комбинацию имени пользователя и временной метки. Злоумышленник, зная об этом дефекте, мог легко предсказать токен сессии другого пользователя.

Рекомендация: Во-первых, изучите все возможные потоки аутентификации для API и не изобретайте велосипед в аутентификации! APISIX поддерживает стандартный поток авторизации OpenID Connect (OIDC). Вместо предсказуемых токенов сессии APISIX может интегрироваться с внешними провайдерами идентификации, такими как Keycloak, или системами управления сессиями с использованием плагинов, чтобы гарантировать, что токены сессии являются случайными, зашифрованными и имеют ограниченный срок действия.

Для предотвращения атак методом перебора на учетные записи пользователей можно использовать плагин ограничения скорости APISIX. Это гарантирует, что если в течение короткого периода времени происходит несколько неудачных попыток входа, IP-адрес или пользователь временно блокируются. Для обеспечения конфиденциальности и целостности данных APISIX поддерживает шифрование SSL/TLS. Это гарантирует, что учетные данные пользователя и другие чувствительные данные шифруются во время передачи.

3. Нарушение авторизации на уровне свойств объектов

Угроза: Эта угроза возникает из-за отсутствия или неправильной проверки авторизации на уровне свойств объектов, что приводит к несанкционированному раскрытию или изменению информации.

Пример: API онлайн-платформы для покупок позволяет зарегистрированным пользователям обновлять свои профильные данные, такие как имя, электронная почта, адрес доставки и платежные данные. Кроме того, каждый профиль пользователя имеет свойство userType, которое может быть либо regular, либо admin. Из-за ошибки в дизайне API пользователи также могут изменять свойство userType в своих запросах на обновление профиля. Предположим, что Алиса, обычный пользователь, обнаруживает этот дефект, когда изучает запросы API с помощью инструментов разработчика в браузере. Она замечает, что при обновлении профиля на сервер отправляется JSON-запрос. Алиса изменяет значение userType на admin и отправляет запрос. К её удивлению, её профиль обновляется, и теперь она имеет административные привилегии на платформе, что позволяет ей получать доступ к чувствительным данным, изменять списки продуктов и даже просматривать историю заказов других пользователей.

Рекомендация: Убедитесь, что свойства объектов, доступные пользователю, соответствуют его правам, и минимизируйте возвращаемые структуры данных в соответствии с бизнес-требованиями. Для этого можно использовать плагин валидации запросов APISIX, который может проверять входящие запросы на соответствие предопределенной схеме. Или используйте систему RBAC APISIX для настройки ролей для обычных пользователей и администраторов. Чтобы удалить ненужные данные, которые раскрываются клиенту, APISIX предоставляет плагин перезаписи ответа, который может изменять ответ API на лету.

4. Неограниченное потребление ресурсов

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

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

Рекомендация:

• Определите и установите максимальные размеры данных для всех входящих параметров и полезных нагрузок. Используйте плагин управления клиентом, чтобы установить максимальный размер тела запроса, чтобы пользователи не могли загружать чрезмерно большие файлы. Или используйте плагин валидации запросов для проверки строк запроса, особенно тех, которые контролируют количество возвращаемых записей. Чтобы заблокировать бота, скрипт или пользовательский агент от отправки нежелательных данных, можно использовать плагин ограничения по пользовательскому агенту.
• Реализуйте ограничение скорости в соответствии с бизнес-потребностями. APISIX предоставляет плагины ограничения запросов, ограничения соединений и ограничения количества, которые могут ограничивать скорость, с которой отдельный пользователь или IP-адрес может делать запросы. Это гарантирует, что пользователи не могут перегрузить систему большим количеством быстрых запросов.

5. Нарушение авторизации на уровне функций

Угроза: Политики контроля доступа иногда слишком сложны, с различными уровнями, группами и ролями, и размытым различием между административными и стандартными функциями, что часто приводит к уязвимостям в разрешениях. Злоумышленники могут воспользоваться этими слабостями для доступа к ресурсам других пользователей или административным функциям.

Пример: Онлайн-платформа для обучения предлагает различные курсы для студентов. Из-за проблем с дизайном платформы студенты могут получить доступ к функциям, предназначенным только для преподавателей, манипулируя URL или конечными точками API. Например, студент может обнаружить, что, изменив URL с /student/dashboard на /instructor/dashboard, он может получить доступ к панели управления преподавателя, что позволяет ему изменять содержание курса, оценивать задания или даже добавлять/удалять курсы.

Рекомендация:

• Запретите весь доступ по умолчанию и требуйте явного предоставления прав для конкретных ролей. С APISIX вы можете создать потребителя или группу потребителей, чтобы предоставить различный контроль доступа для пользователей. Затем плагин аутентификации JWT можно настроить для включения информации о роли в токен JWT. Когда пользователь входит в систему, токен JWT, который он получает, будет содержать его роль (student или instructor). APISIX может затем проверить роль пользователя из токена JWT перед предоставлением доступа к конкретным функциям.
• Убедитесь, что административные контроллеры наследуются от контроллера, который реализует проверку авторизации на основе ролей пользователей. Если вы используете API7 Enterprise, это позволяет администраторам ограничивать доступ к API для определенных пользователей/групп и настраивать доступ на основе каждого запроса и каждого пользователя.

6. Неограниченный доступ к чувствительным бизнес-процессам

Угроза: Чувствительные бизнес-процессы раскрываются без оценки рисков того, как функциональность может навредить бизнесу, если используется автоматизированно и чрезмерно.

Пример: Используя комбинацию прокси и автоматизированных скриптов (ботов), злоумышленник имитирует нескольких реальных пользователей, совершающих покупки. Скрипт быстро добавляет продукт в корзину и завершает процесс оформления заказа, исчерпывая запас до того, как реальные клиенты успевают сделать покупку. Злоумышленник затем перепродает эти продукты по более высокой цене на других платформах. Платформа продавца теряет потенциальный доход, так как не может продать продукты реальным клиентам по задуманной цене.

Рекомендация:

• Реализуйте идентификацию устройств, чтобы запретить обслуживание неожиданных клиентских устройств. APISIX может быть интегрирован с платформами управления идентификацией и доступом, такими как Auth0, Authgear и другими, чтобы включить различные механизмы аутентификации, включая функции биометрического входа на устройствах.
• Используйте механизмы обнаружения людей, такие как капчи или продвинутые биометрические решения. То же самое, что и выше.
• Анализируйте поток пользователей для обнаружения нечеловеческих паттернов. Вы можете использовать API7 Enterprise для применения дополнительных факторов аутентификации, когда запрос связан с нечеловеческими паттернами, такими как высокая скорость между различными местами входа или обнаружение ботов.
• Блокируйте IP-адреса известных вредоносных источников. APISIX имеет плагин ограничения по IP для блокировки доступа с одного или нескольких IP-адресов.

7. Подделка запросов на стороне сервера (SSRF)

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

Пример: Конечная точка API принимает URL для извлечения изображения из интернета. Злоумышленник отправляет URL, например http://169.254.169.254/latest/meta-data/ (типичная конечная точка метаданных в облачных средах). Сервис извлекает URL, думая, что это изображение, но вместо этого получает чувствительные данные, такие как роли IAM, секретные ключи или другие внутренние конфигурационные данные. Злоумышленник затем использует эту информацию для дальнейших атак, таких как повышение привилегий или утечки данных.

Рекомендация:

• Проверка входных данных - Всегда проверяйте и очищайте входные данные. Избегайте принятия полных URL из ненадежных источников. С APISIX вы можете настроить плагин блокировки URI для применения правил блокировки к внутренним ресурсам.
• Белый список - Разрешайте соединения только с известными и доверенными доменами или IP-адресами. То же самое можно использовать плагин ограничения по IP APISIX или включить ограничение по рефереру для белого списка допустимых доменов или шаблонов URL. Любой URL, не соответствующий белому списку, отклоняется.
• Сегментация сети - Убедитесь, что ваши серверы сегментированы, и чувствительные внутренние ресурсы не доступны напрямую.

8. Неправильная настройка безопасности

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

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

Рекомендация:

• Регулярные аудиты - Регулярно проверяйте и обновляйте конфигурации. Используйте автоматизированные инструменты для сканирования на предмет распространенных ошибок конфигурации. С плагинами логирования APISIX все действия доступа и системные активности логируются. Любая необычная активность, такая как повторяющиеся неудачные попытки входа или доступ к ограниченным конечным точкам, может быть отмечена для проверки.
• Принцип наименьших привилегий - Предоставляйте только необходимые разрешения и избегайте использования излишне разрешительных настроек.
• Заголовки безопасности по умолчанию - APISIX обеспечивает безопасные настройки по умолчанию с необходимыми заголовками безопасности, такими как Content Security Policy (CSP) и HTTP Strict Transport Security (HSTS), которые установлены. Это снижает риск определенных веб-атак.
• Маскирование ошибок - Убедитесь, что сообщения об ошибках являются общими и не раскрывают чувствительную информацию. APISIX может быть настроен для маскирования подробных сообщений об ошибках с использованием плагина перезаписи ответа или пользовательского плагина маскирования данных.

9. Неправильное управление инвентаризацией

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

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

Рекомендация: Используйте Admin API APISIX для регулярного просмотра и деактивации маршрутов, которые больше не нужны, и для отслеживания всех версий API без нарушения работы клиентских приложений. API7 Portal предоставляет централизованную панель управления, где все API могут быть отслеживаемы и управляемы. Старая версия API может все еще работать, но она больше не используется. Через панель управления этот API может быть идентифицирован и отключен без изменения кода в самом сервисе.

10. Небезопасное использование API

Угроза: При интеграции сторонних API или даже использовании внутренних API, если это делается небезопасно, это может подвергнуть приложение уязвимостям, присутствующим в вышестоящих API.

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

Рекомендация: Перед интеграцией стороннего API убедитесь, что он от надежного источника и прошел проверку безопасности.

• Обработка ошибок - Обрабатывайте неожиданные ответы или поведение от используемых API без раскрытия уязвимостей.
• Проверка данных - Всегда проверяйте и очищайте данные, полученные от сторонних API. APISIX может быть интегрирован с Web Application Firewalls (WAF) для проверки и фильтрации входящих данных от сторонних API. Это может обнаруживать и блокировать известные вредоносные паттерны или полезные нагрузки. Также возможно активировать TLS/mTLS для вышестоящих сервисов, чтобы гарантировать безопасность трафика во время его передачи через внутреннюю сеть.

Итог

Применение предложенных рекомендаций по безопасности от OWASP API 2023 предоставляет основу для защиты API. Использование функций шлюза APISIX упрощает этот процесс и значительно снижает затраты на реализацию механизмов предотвращения, рекомендованных OWASP.

Связанные ресурсы

• Защита API в API Gateway
• Аутентификация в API Gateway
• Предотвращение утечки чувствительных данных в API Gateway