Что такое OWASP Top 10 API
OWASP Top 10 API Security Risks — это топ-10 рисков кибербезопасности, связанных с прикладными программными интерфейсами в компаниях.
Роль OWASP в стандартах безопасности
Open Worldwide Application Security Project (OWASP) — это открытый проект обеспечения безопасности веб-приложений. Организация публикует:
- OWASP Top Ten — топ уязвимостей веб-приложений, программных интерфейсов (API), больших языковых моделей (LLM);
- OWASP Development Guide — набор практик для безопасной веб-разработки;
- OWASP Testing Guide, Web Security Testing Guide Project / WSTG — руководство по тестированию безопасности веб-приложений и другие тематические материалы.
Эволюция рейтинга уязвимостей API
В 2019 году организация представила OWASP API Security Top 10 — The Ten Most Critical Security Risks с описанием 10 угроз безопасности прикладных программных интерфейсов. В 2023-м рейтинг обновили.
Обзор OWASP Top 10 API 2023
Рейтинг 2023 года, в отличие от топ-10 угроз 2019-го, смещает акценты на атаки с подделкой запросов на стороне сервера (SSRF), уязвимости бизнес-логики и риски «забытых» («старых», «зомби») API.
Наиболее критичные уязвимости API
Проблемы аутентификации и авторизации
Уязвимости приводят к несанкционированному доступу, утечкам данных, финансовым и репутационным рискам. Среди них OWASP выделяет:
- нарушение контроля доступа на уровне объекта (API1:2023 Broken Object Level Authorization (BOLA));
- нарушение аутентификации (API2:2023 Broken Authentication);
- нарушение контроля доступа к свойствам объекта (API3:2023 Broken Object Property Level Authorization).
Примеры проблем: слабые пароли, отсутствие защиты от перебора паролей (брутфорса), небезопасное восстановление паролей, отображение ID сеанса в URL-адресе.
Один из самых частых сценариев — когда пароль администратора утекает в сеть и становится доступным злоумышленникам. Это открывает доступ к бизнес-информации, коммерческой тайне, персональным данным.
Ошибки конфигурации
Такие ошибки становятся причиной атак типа «отказ в обслуживании» (DdoS), повышенного расхода ресурсов (счета за инфраструктуру), утечек данных, заражения вирусами. Среди них OWASP перечисляет:
- небезопасную конфигурацию (API8:2023 Security Misconfiguration);
- неограниченное потребление ресурсов (API4:2023 Unrestricted Resource Consumption).
Уязвимости возникают из-за неправильной, неполной или небезопасной настройки приложений, серверов, БД. Примеры: доступность служебных файлов для внешних пользователей, отсутствие протокола TLS, включенные режимы отладки на рабочем сервере.
Сценарий атаки может предусматривать, что злоумышленник находит незадокументированные точки входа API и получает такой же доступ к данным, что и DevOps. Это открывает возможности для взлома и компрометации систем (в том числе в цепочке поставок), несанкционированного изменения информации или кражи данных.
Уязвимости интеграций
Данные уязвимости компрометируют сервисы, становятся причиной потенциальных утечек и несанкционированного доступа. К ним можно отнести угрозы по OWASP:
- некорректное (ненадлежащее) управление ресурсами (API9:2023 Improper Inventory Management);
- небезопасное использование (потребление) API (API10:2023 Unsafe Consumption of APIs).
Примерами могут выступать:
- подключение в проект сторонних библиотек с небезопасным кодом;
- токены и ключи доступа, которые могут перехватить злоумышленники;
- передача через API избыточных данных.
Частый сценарий — разработчики добавляют в проект стороннюю библиотеку из публичного репозитория. В ней содержится вредоносный код, который позволяет злоумышленнику сканировать внутреннюю сеть компании.
Атаки приводят к компрометации учетных записей, сканированию сети , сканированию сети и составлению карты закрытой инфраструктуры компании, захвату ресурсов.
Как защитить API от уязвимостей
Защита программных интерфейсов требует комплексного подхода на всех этапах: проектирования, разработки, тестирования, эксплуатации. Хассен Бельгасем в публикации «Лучшие практики защиты прикладных программных интерфейсов» (API Security Best Practices) рекомендует внедрить контроль доступа, аутентификацию, авторизацию, валидацию входных данных, а также иные меры. В гайде WSTG представлены доступные способы обеспечения безопасности.
Использование протоколов авторизации Oauth 2.0 и OpenID Connect
OAuth, OpenID Connect (OIDC), SAML — это протоколы для безопасного доступа и единого входа (SSO, Single Sign-On). Они нужны для управления доступами и аутентификации пользователей. OAuth 2.0 позволяет клиентскому приложению получить ограниченный доступ к ресурсам от имени пользователя — в зависимости от сценария. Область доступа задаётся правами (scopes) и политиками сервера авторизации. OpenID Connect добавляет поверх OAuth 2.0 уровень идентификации: клиент может проверить личность пользователя. SAML используется для обмена утверждениями об аутентификации и авторизации, в том числе в сценариях SSO. OpenID Connect проверяет, кто вошёл в систему. SAML используется для обмена данными авторизации и аутентификации. Пользователь входит в систему поставщика удостоверений, а затем получает доступ к подключенным приложениям и сервисам без ввода авторизационных данных.
Проверка авторизации на уровне объектов
Бэкэнд не должен слепо доверять идентификатору ресурса (ID), переданному пользователем. Для защиты от киберугрозы №1 в рейтинге OWASP Top 10 API Security Risks стоит внедрить:
- проверку идентификаторов;
- использование произвольных ID (GUID/UUID);
- сценарии тестирования с подменой идентификаторов.
Если бэкенд не проверяет право пользователя на чтение или изменение идентификатора объекта, злоумышленник может подставить чужой ID и получить доступ к конфиденциальным данным: например, к профилю пользователя /api/users/12345/profile. Чтобы затруднить перебор идентификаторов, используют рандомные UUID.
Ограничение скорости запросов (Rate Limiting)
Позволяет контролировать входящий трафик, устанавливая лимит запросов пользователя за 1 секунду / 1 минуту или иной промежуток времени.
Если не ограничивать количество и скорость запросов, возникают проблемы:
- DDoS-атаки;
- перебор паролей (брутфорс);
- перерасход ресурсов сервера и иные.
Rate Limiting может выглядеть как 100 запросов в час на пользователя, 1000 запросов в час на IP-адрес, пять запросов в минуту на конечную точку. При срабатывании рейт-лимита сервер отклоняет новые запросы пользователя или приложения, возвращает ошибку.
Валидация входящих данных
Подразумевает ограничение размера данных и расширения сущностей, проверку пользовательского ввода на признаки инъекции, а также проверку заголовка Content-Type и формата отправленных данных.
Валидировать входящие данные нужно, чтобы снизить риск XSS-атак и SQL-инъекций, переполнения буфера программы. Это приводит к компрометации БД, обходу авторизации, выполнению произвольного кода на сервере и иным угрозам. Простой сценарий — внедрение SQL-инъекции в поле формы. Более сложный — атака данных из доверенного источника: например, стороннего API.
Валидация входных данных подразумевает сопоставление входящих запросов со схемами данных. Если структура нарушается, запрос блокируется и не доходит до внутренних систем. Для поиска потенциальных инъекций используют сигнатурный и / или поведенческий анализ. Эти и другие функции защиты могут выполнять шлюзы безопасности API или фаерволы WAF.
Архитектурные методы защиты API
Чтобы повысить безопасность прикладных программных интерфейсов, используют такие инструменты:
- фаервол веб-приложений (WAF, Web Application Firewall), WAAP (Web Application and API Protection);
- шлюз API Gateway, единую точку входа;
- сервисную сетку (Service Mesh) для API микросервисов.
Межсетевой экран WAF, как правило, анализирует HTTP-трафик и блокирует известные угрозы (сигнатурный анализ). API Gateway может проверять токены и права доступа, ограничивать количество запросов. Service Mesh контролирует передачу данных между частями программы, микросервисами.
API Gateway
Шлюз безопасности — это единая точка входа, поддерживающая следующие функции:
- маршрутизацию (Routing);
- аутентификацию, авторизацию;
- балансировку нагрузки;
- ограничение нагрузки (Rate Limiting).
API Gateway может проверить, есть ли у пользователя права на доступ к ресурсу. Это снижает риск несанкционированных действий в системе. При превышении лимита запросы отклоняются. Это снижает риск злоупотреблений и исчерпания ресурсов на уровне приложения, а также помогает в отдельных DoS/DDoS-сценариях. Для комплексной защиты от DDoS требуются дополнительные сетевые и инфраструктурные механизмы.
Web Application Firewall (WAF)
Фаервол веб-приложений — инструмент защиты прикладного уровня, который выполняет следующие функции:
- фильтрацию трафика;
- снижение риска SQL-инъекций, межсайтового скриптинга (XSS), ботов, подбора паролей (брутфорса);
- аналитику аномалий.
Например, в WAF может храниться база сигнатур с известными типами атак. Фаервол анализирует трафик и блокирует запрос с признаками вредоносной активности.
Политика нулевого доверия (Zero Trust-подход)
Zero Trust (нулевое доверие) означает отсутствие неявного доверия по местоположению в сети или владению активом. Доступ к каждому ресурсу предоставляется после аутентификации и авторизации в соответствии с политиками. Для API это означает проверку каждого запроса, минимально необходимые права, контроль межсервисных взаимодействий и постоянную оценку контекста доступа.
Архитектура ZT снижает риск утечек данных через внутренние интеграции и авторизованные API. Например, без Zero Trust сотрудник входит во внутреннюю сеть и получает доступ ко многим ресурсам: банкингу, CRM-системе. Если реализован архитектурный подход ZT, внедряются дополнительные инструменты. Они проверяют права пользователя (Identity Provider), политики доступа и другие. Сотрудник получает доступ не ко всей сети, а к конкретному сервису.
Безопасная разработка (DevSecOps) и безопасность API
Подход DevSecOps подразумевает интеграцию мер безопасности в каждый этап жизненного цикла разработки ПО от непрерывной интеграции до развёртывания (CI/CD). Среди них:
- автоматизация статического (SAST) и динамического (DAST) сканирования кода;
- композиционный анализ ПО (SCA) для проверки зависимостей;
- контроль привилегий, доступов.
В гайде WSTG OWASP представила раздел Configuration_and_Deployment_Management_Testing с информацией для администраторов, DevSecOps, специалистов по кибербезопасности.
SAST и DAST-сканирование
Для комплексной защиты систем используют два метода анализа безопасности:
- статическое сканирование, изучение кода изнутри (white-box) — SAST (Static Application Security Testing);
- динамическое сканирование работающего приложения с имитацией внешних атак (black-box) — DAST (Dynamic Application Security Testing).
Например, статический анализатор кода содержит базу встроенных правил, шаблонов и сигнатур известных багов. Он сканирует исходный код программы без её запуска, а затем предупреждает разработчика об обнаруженных ошибках. Для этого используются специальные инструменты: Platform V Works::CodeScanner, SonarQube, Codacy или JetBrains Qodana для статического анализа кода.
DAST (Dynamic Application Security Testing) — динамическое тестирование безопасности работающего приложения. Инструмент взаимодействует с ним снаружи, отправляет запросы и анализирует ответы. Так выявляются ошибки аутентификации, конфигурации, SQL-инъекции, XSS и другие уязвимости, проявляющиеся во время выполнения.
Проверка зависимостей (SCA)
Открытое свободно распространяемое ПО может содержать уязвимости, которые приводят к хищению токенов, перехвату управления целевым сервером или удалённому выполнению кода. Анализ состава ПО (Software Composition Analysis) нужен для проверки устаревших библиотек, проблем с лицензиями и правами доступа.
Анализатор может:
- найти уязвимые библиотеки (базы CVE, NVD);
- построить карту зависимостей;
- проверить лицензии открытого ПО;
- оценить критичность CVSS.
Таким образом, SCA-инструменты проверяют чужой код в проекте и предотвращают потенциальные уязвимости (вплоть до блокировки выпуска новой версии ПО).
Тестирование безопасности API
Тестирование API — это проверка интерфейсов на уязвимости для защиты от утечек, взлома и иных рисков. Может включать проверки:
- аутентификации;
- авторизации;
- шифрования;
- защиты от инъекций.
Например, при fuzz-тестировании (фаззинг, тестирование мусорными данными) инженеры отправляют в систему большие некорректные или случайные данные. Это позволяет понять, когда начинаются сбои и как защититься от рисков. Для проверки защиты от инъекций в поля ввода вписывают вредоносный код, а затем отслеживают реакцию системы.
OWASP представила гайд Web Security Testing Guide (WSTG) с принципами и инструментами проверки безопасности. Первую версию WSTG выпустили в 2004 году, затем дополняли, чтобы соответствовать новым вызовам кибербезопасности. В руководстве Information Gathering test WSTG уделяют внимание тестам на проникновение (пентестам).
Инструменты для защиты API
Среди инструментов для защиты прикладных программных интерфейсов:
- шлюз безопасности прикладных интерфейсов и защиты ИИ-трафика — IBM DataPower, Platform V SOWA;
- межсетевые экраны WAF — Cloudflare WAF, AWS WAF;
- инструмент управления API — Platform V Synapse API Mesh, IBM API Connect
- Gravitee;
- системы контроля доступа — IBM Security Identity Manager (ISIM), IBM Security Access Manager (ISAM), Platform V IAM SE или Platform V IDM и другие ИТ-решения.
Platform V обеспечивает комплексный подход к безопасности. Платформа предоставляет набор инструментов для работы с API.
Итоги и ключевые выводы
Распространение API, внедрение ИИ-агентов, цифровизация создают новые угрозы кибербезопасности. Чтобы минимизировать риск угроз, важно внедрять инструменты защиты, тестирования, контроля доступов, управления версиями API. Platform V предоставляет ПО для построения безопасной ИТ-инфраструктуры.
