Несмотря на всю свою полезность, списки OWASP Top 10 достаточно трудно понять и прочитать. В этой статье попробуем подробнее разобрать каждую категорию рисков API.
API1:2023 Нарушена авторизация на уровне объектов (также известная как BOLA и IDOR) (Broken Object-Level Authorization (aka BOLA aka IDOR))
Суть API заключается в том, чтобы обеспечить автоматизированный доступ к данным и функциональности приложения. Настроить API интерфейс для получения данных об учетной записи клиента очень просто – главная проблема заключается в том, чтобы убедиться, что данные доступны только авторизованным пользователям и системам. Если к чему-то («объекту») в приложении любой может получить свободный доступ, просто зная, как запросить правильный URL-адрес и идентификатор объекта (например, номер клиента), произойдет утечка данных. Примером является взлом сервиса Optus.
API2:2023 Нарушена аутентификация (Broken Authentication)
Первое, что нужно сделать перед важной работой в API, это подтвердить личность исполнителя. Если механизм аутентификации слабый или его легко обойти, злоумышленники могут легко проникнуть в систему. Как только они получают доступ, остальные 9 рисков становятся реальностью.
API3:2023 Нарушение авторизации на уровне свойств объектов (Broken Object Property-Level Authorization)
В большинстве бизнес-приложений разным пользователям требуются разные уровни доступа к данным. Например, приложение имеет учетную запись клиента в системе. Некоторым сотрудникам понадобится только контактная информация, другим будут доверять финансовые данные, тогда как пользователь с правами администратора может иметь доступ ко всему, а также управлять учетными данными. Обеспечить такие разные доступы для API особенно сложно, что приводит к ситуациям, когда злоумышленник, который получает доступ к объекту учетной записи клиента, также получает доступ ко всем данным этой учетной записи.
API4:2023 Неограниченное потребление ресурсов (Unrestricted Resource Consumption)
Утечки данных не редко попадают в заголовки новостей, но злоумышленникам часто достаточно вывести API из строя вместе со всем приложением.
Атаки на отказ в обслуживании (DoS-атаки) являются одним из самых простых, но наиболее распространенных способов атаки на API, что облегчается тем, что API специально разработаны для автоматизированного доступа. Принятие и обработка каждого входящего запроса без применения каких-либо ограничений делает API уязвимым к истощению ресурсов, а его владельца – к чрезмерным операционным расходам.
API5:2023 Нарушена авторизация на уровне функций (Broken Function-Level Authorization)
API интерфейсы предоставляют не только данные, но и операции над ними. Хотя риск №3 был связан с получением злоумышленниками доступа к объектам данных по принципу «все или ничего», то же самое касается и разрешенных операций.
В частности, REST API, как правило, содержат методы, содержащие GET, PUT и DELETE. Если любой, кто может прочитать данные с помощью обычного GET-запроса, может также удалить их, просто вручную изменив GET на DELETE в заголовке запроса, это настоящий риск. То же самое касается незащищенного доступа к таким сферам, как операции администратора.
API6:2023 Неограниченный доступ к чувствительным бизнес-потокам (Unrestricted Access to Sensitive Business Flows)
Злоупотребление автоматизированным доступом к определенным операциям может иметь серьезные последствия для бизнеса, даже если технически это не представляет угрозы безопасности. Распространенными примерами являются автоматические аукционные торги, выкуп и последующая перепродажа товаров с высоким спросом, таких как билеты, или переполнение системы бронирования запросами на отказ в доступе к ней законным пользователям. Следовательно, это может вызвать перебои в работе и материальный ущерб.
API7:2023 Подделка запросов на стороне сервера (SSRF) ( Server-Side Request Forgery (SSRF))
Распространенной практикой в веб-разработке является получение ресурсов с внешнего сайта. При работе через API так же часто можно получить конкретный адрес ресурса (URL) из входящего запроса. Без тщательной проверки на наличие каких-либо неожиданных данных в этом URL-адресе злоумышленник может прислать URL-адрес вредоносного внешнего ресурса, содержащего вредоносный код. Что еще хуже, также может запросить конфиденциальный внутренний ресурс – и поскольку запрос поступает с сервера API пользователя, злоумышленник может косвенно получить доступ к внутренним системам через API.
API8:2023 Неправильная конфигурация безопасности (Security Misconfiguration)
Даже одна неправильная конфигурация безопасности в любом API может предоставить злоумышленникам возможность получить доступ к данным или операциям API. Примерами могут быть неисправленные продукты или программные компоненты в любом месте технологического стека (tech stack), чрезмерные разрешения на любом уровне этого стека (особенно разрешения на облачное хранилище) и слабая защита (например, пробелы в шифровании) на любом этапе обработки запросов к API.
API9:2023 Неправильное управление запасами (Improper Inventory Management)
Когда API меняется, общепринятой практикой является установка новой версии параллельно со старой, чтобы убедиться, что существующие системы, которые полагаются на этот API, продолжают работать до завершения перехода. Без тщательного управления инвентаризацией старые API можно легко не заметить и забыть. В таком случае они останутся доступными для злоумышленников. Также они с меньшей вероятностью содержат последние обновления безопасности и могут не контролироваться и не быть защищенными на том же уровне, что и производственные API, что дает злоумышленникам достаточно времени и возможностей для проникновения в систему. Именно поэтому обнаружение API имеет такое большое значение.
API10:2023 Небезпечне використання API (Unsafe Consumption of APIs)
В основном API взаимодействуют не с людьми, а с другими API – и те, по идее, должны вести себя в соответствии со спецификацией.
Это может создать ощущение неявного доверия, которое побуждает разработчиков беспрекословно принимать и передавать данные из знакомого стороннего API без проверки, особенно если он используется известной компанией. Если злоумышленники скомпрометируют этот API или смогут встроить вредоносные данные в один из его источников данных, доверие к результатам, полученным из этого API, может сделать приложение уязвимым или скомпрометированным.
Вывод
Многие из 10 самых больших рисков безопасности, связанных с API, могут показаться простыми, ведь по большей части это различные способы предоставления злоумышленникам доступа к данным.
Проблема с API заключается в том, что они действуют как обходные пути для доступа к внутренним компонентам приложения. Если эти обходные пути не будут тщательно спланированы на ранних стадиях проектирования и разработки приложения, они могут обойти средства контроля доступа, которые могут присутствовать в приложении.
Часто можно ошибочно рассматривать любой OWASP Top 10 как контрольный список безопасности, но цель API Security Top 10 четко сформулирована во введении: «обучать тех, кто занимается разработкой и поддержкой API, например, разработчиков, дизайнеров, архитекторов, менеджеров или организаций». Именно поэтому специалисты по безопасности не включены в список – потому что безопасность API начинается задолго до того, как они начинают заниматься тестированием и защитой.
Основной вывод из Топ 10 безопасности API OWASP заключается в том, что безопасные API всегда должны начинаться с безопасного дизайна приложений. Однако в реальности API редко бывают идеально спроектированы, реализованы или отслеживаемы, поэтому инструменты для обнаружения API и тестирования безопасности API являются важной частью любого набора инструментов для обеспечения безопасности приложений.
