Уязвимости API - растущий риск для организаций

11 ноября 2020 г. 10:32
 7857

Модели безопасности для API не соответствуют требованиям мира без IT-периметров, заявляет «Forrester».

Модели безопасности для API не соответствуют требованиям мира без IT-периметров, заявляет «Forrester».

Интерфейсы прикладного программирования (API), которые соединяют корпоративные приложения и данные с Интернетом, подвержены тем же уязвимостям, что и обычные веб-приложения, и должны защищаться, по крайней мере, с тем же усердием.

Предоставляемый интерфейсами API прямой внешний доступ к актуальным транзакциям и массивам данных подвергает их дополнительным угрозам, с которыми веб-приложения редко сталкиваются, по мнению Forrester Research.

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

«Если организации защищают свои веб-приложения, то им не стоит забывать и о своих API», - сообщает аналитик «Forrester» Сэнди Кариелли. «Профессионалы в области безопасности должны тщательно выстроить защиту API и не предполагать, что она будет внедрена в их существующие средства защиты веб-приложений».

API, по сути, позволяет приложениям или компонентам приложений взаимодействовать друг с другом через Интернет или частную сеть. Изначально большинство организаций использовали их в VPN-сети или обращались к ним по защищенным каналам связи. Но все чаще организации стали использовать API для того, чтобы открыть доступ к внутренним приложениям и данным партнерам, поставщикам, клиентам и другим лицам. Многие считают API основополагающими для реализации инициатив по преобразованию цифровых технологий и создания нового поколения мобильных приложений.

Опрос 1500 разработчиков, архитекторов, специалистов по контролю качества и других специалистов, проведенный ранее в этом году компанией «SmartBear», показал что 77% организаций, представленных в опросе, как разрабатывают свои, так и используют API партнеров. Самым распространенным вариантом использования API остается взаимодействие между внутренними инструментами, командами и системами, а также сокращение времени и затрат на разработку. К другим популярным случаям использования относятся партнерские отношения с внешней организацией, расширение функциональности продукта или услуги, а также поглощение данных и функций из внешних продуктов.

По мнению «Forrester», многие из связанных с API проблем безопасности создавались годами и связаны с переходом от ранних API, основанных на протоколах обмена сообщениями SOAP, к сегодняшним REST API.

Ранее SOAP API, как правило, имели безопасный доступ через VPN или двусторонние зашифрованные соединения. REST API, с другой стороны, предназначены для доступа через браузеры и мобильные приложения. Когда мобильный пользователь совершает бронирование авиабилетов на своем телефоне, например, REST API передает инструкции пользователя внутренним приложениям авиакомпании или поставщика туристических услуг и доставляет ответ обратно пользователю.

REST API открыты для использования с помощью общедоступных инструментов осмотра и взлома со стороны клиента, так же как и веб-приложения, если они не защищены. Поэтому, по заявлению «Forrester», для API так же важны такие методы обеспечения безопасности, как принцип «наименьших привилегий» при доступе к данным и проверка данных на стороне сервера.

Инструменты для использования API не сложны, заявляет Сэнди Кариелли.

«Основные прокси, которые злоумышленники используют для манипулирования HTTP и HTTPS запросами, будут применяться и здесь», - говорит она. «Иногда это так же просто, как изменить параметр в HTTP-запросе».

Вредоносные клиенты

REST API могут обеспечить прямой доступ к обновлениям транзакций и другим важным данным о внутренних системах. Это происходит потому, что фирмы часто не могут отследить все конечные точки API, погруженные глубоко в их мобильные приложения или веб-приложения, или установить адекватный контроль для аутентификации и проверки вызовов API. Такие неавторизованные конечные точки могут подвергать их повышенному риску несанкционированного доступа и компрометации данных, сообщает «Forrester».

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

«Помните, что API служат для того, чтобы сделать различные данные и функциональность приложений доступными для разработчиков за пределами организации», - говорит Сэнди Кариелли. «Так как конечные точки API могут быть доступны любому внешнему пользователю, который вызывает API, неавторизованная конечная точка, которая возвращает конфиденциальную информацию, представляет собой высокий риск». 

Одним из распространенных результатов использования неаутентифицированных конечных точек API является то, что пользовательские данные подвергаются риску. Например, если API для доступа к данным о клиентских транзакциях будет случайно развернут без надлежащей проверки подлинности и авторизации, любой, кто воспользовался API, может увидеть много конфиденциальной клиентской информации, заявляет «Forrester».

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

Например, при разработке API, организациям необходимо обращать внимание на меры безопасности, такие как отказ соединения «по умолчанию» и проверка любых данных, предоставляемых клиентом. Организации должны гарантировать, что весь трафик API, как и трафик веб-приложений, зашифрован, но таким образом, чтобы не влиять на производительность. Также критически важным является необходимость аутентифицировать вызовы API на каждом уровне и перестать думать об API просто как об уровне интерфейса между приложениями.

«Независимо от того, задействует ли API конфиденциальные данные, старые или современные архитектуры приложений, или даже аппаратное или микропрограммное обеспечение, работайте через эти точки соприкосновения совместно с ответственными по безопасности соответствующих систем», - советуют аналитики.

 

Перевод сделан со статьи: https://www.darkreading.com