Джек М. Жермен
22 июля 2021 г., 4:00 по тихоокеанскому времени
Любой, кто заинтересован в Опережая кибербезопасные атаки и вторжения в корпоративную сеть через уязвимости интерфейса прикладного программирования (API), теперь можно использовать экспертные заключения и отчеты о безопасности.
14 июля Salt Security объявила о запуске Salt Labs, теперь общедоступного форума для публикации исследований уязвимостей API. Благодаря исследованиям уязвимостей и угроз, а также отраслевым отчетам Salt Labs станет ресурсом для предприятий, стремящихся защитить инфраструктуру от рисков API.
Компания стремится заполнить пробел в доступной информации о рисках API и основных исследованиях уязвимостей. Salt Labs была создана как ресурс для клиентов Salt Security, а также для всей отрасли, чтобы повысить осведомленность общественности об угрозах безопасности API, защитить инфраструктуру от рисков API и ускорить бизнес-инновации, сделав API-интерфейсы защищенными от атак и отказоустойчивыми.
Проблемы безопасности API стали серьезным препятствием для бизнес-инноваций, по словам Солта.
Salt также выпустила свой первый исследовательский отчет с подробным описанием четырех недавно обнаруженных уязвимостей API, влияющих на компании, предоставляющие финансовые услуги. Этот первый отчет об исследовании угроз, «Подробные финансовые отчеты, опубликованные на платформе финансовых услуг», служит ярким примером для такой торговой точки
. Команда обнаружила несколько уязвимостей API, которые могут позволить злоумышленникам просматривать финансовые отчеты клиентов, удалять клиентов. учетные записи, выполнить захват учетной записи (ATO) или создать условие отказа в обслуживании, которое сделало бы все приложения недоступными.
API — это программные коды, которые позволяют компьютерным приложениям получать доступ к данным и взаимодействовать с внешними программными компонентами, операционными системами или микросервисами. Процесс доставляет ответы пользователя системе и отправляет ответ системы пользователю.
«С ростом количества API-интерфейсов и той центральной роли, которую они играют в современных средах приложений, необходимость в объективных, актуальных и надежных исследованиях побудила нас поделиться новаторскими исследованиями безопасности API, которые наша команда проводила в течение многих лет», сказал Рой Элияху, соучредитель и генеральный директор Salt Security.
Содержание статьи
Пример из практики
Согласно отчету Salt Security State of API Security Report, 66 процентов организаций отложили развертывание нового приложения из-за проблем с безопасностью API. Чтобы противостоять этим опасениям, исследования и отчеты Salt Labs позволят организациям улучшить свою безопасность API и уменьшить угрозы, влияющие на предприятия, ориентированные на API.
Используя глубокое техническое понимание угроз API, пробелов в безопасности и неправильной конфигурации, Salt Labs фокусируется на трех задачах. Он нацелен на проведение масштабных исследований угроз, выявление новейших векторов атак API и предоставление передовых методов исправления, чтобы сделать программы безопасности API более гибкими и действенными.
Исследователи Salt Labs исследовали онлайн-платформу крупного финансового учреждения, которая предоставляет услуги API тысячам банков-партнеров и финансовых консультантов. В результате наличия множества уязвимостей API, исследователи обнаружили, что злоумышленники могут запускать атаки, при которых:
- Любой пользователь может читать финансовые отчеты любого клиента.
- Любой пользователь может удалить любые учетные записи клиентов в системе.
- Любой пользователь может получить доступ к любой учетной записи.
- Любой пользователь мог создать условие отказа в обслуживании, которое сделало бы все приложения недоступными.
Исследователи Salt использовали следующие уязвимости безопасности API высокой степени серьезности в платформе финансовых услуг:
- Авторизация на уровне сломанных объектов (BOLA)
- Авторизация на уровне нарушенных функций (BFLA )
- Восприимчивость к изменению параметров
- Неправильная проверка вводимых данных
Стратегии отчетности
Исследователи анонимизировали любые технические детали уязвимости, которые могли идентифицировать организацию чтобы не подвергать финансовую организацию дополнительному риску. Должностные лица Salt Lab ознакомились с этими выводами с организацией и поделились информацией публично, чтобы повысить осведомленность о безопасности API, подробно описав соответствующие шаблоны атак, технические детали и методы устранения каждой уязвимости.
Многие проблемы с API проявляются только тогда, когда API работают в рамках полностью интегрированного приложения, системы и архитектуры, по словам Майкла Исбитски, технического евангелиста Salt Security. Сам по себе анализ кода не покрывает вас, и он также невозможен в случае использования кода третьей стороной или интеграции внешних сервисов.
«Тщательное тестирование API во время выполнения без помощи машин — сложное и трудоемкое мероприятие. Трудно найти соответствующий опыт в предметной области, чтобы запустить все необходимые инструменты и понять результаты того, что обнаруживается, поскольку проблемы API пересекаются ряд областей технологий и безопасности ", — сказал он TechNewsWorld.
Скрытая проблема кибербезопасности
API-интерфейсы не всегда называются по имени как аспект кибербезопасности. Но API-интерфейсы лежат в основе большинства современных систем и цепочек поставок программного обеспечения.
«Многие инциденты, которые мы наблюдаем в промышленности, в том числе атаки на цепочки поставок, происходят из-за того, что API-интерфейсы остаются незащищенными или API-интерфейсы используются в качестве критического этапа цепочки атак», — сказал Исбицкий.
На самом деле, организации, обеспокоенные рисками безопасности API, должны искать специальные предложения по безопасности API, разработанные как платформы, добавил он. Такие решения предоставляют ряд возможностей для защиты API-интерфейсов на протяжении всего жизненного цикла.
Расходящиеся траектории
Распространение API и безопасность API, к сожалению, идут по расходящимся траекториям, согласно Сету Кулкарни, вице-президенту по стратегии NTT Application Security. API-интерфейсы распространяются экспоненциально быстрее, чем тестирование безопасности этих самых API. Между тем создание и развертывание API стало проще, чем когда-либо.
«Изучение метаданных и анализ трафика в реальном времени становятся лучшим способом обнаружения API, чем просто их привлечение на основе отзывов разработчиков», — сказал он TechNewsWorld.
Тестирование безопасности API соответствует шаблону функционального тестирования API. То есть использование базовой структуры, предоставляемой инструментами функционального тестирования, для организации последовательности вызовов API, чтобы гарантировать, что тесты безопасности выполняются в этих последовательностях вызовов, пояснил Кулкарни.
«Динамическое тестирование оказывается наиболее надежным способом проверки API на предмет безопасности. Динамическое тестирование адаптируется к использованию разработчиками», — добавил он.
Общие бизнес-модели
API быстро становятся технической основой бизнес-моделей B2B и B2C. Таким образом, по словам Кулкарни, при разработке и развертывании API-интерфейсов действительно невозможно оценить все возможные места, в которых они будут использоваться.
«API-интерфейсы незаметно, но быстро становятся одним из наиболее важных звеньев в цепочке поставок программного обеспечения. Организации теперь находятся на расстоянии одного уязвимого вызова API-интерфейсов от потенциального серьезного нарушения», — предупредил он.
Основная проблема, которая становится запутанной, заключается в том, что сегодня API-интерфейсы являются фасадом к устаревшим системам, которые никогда не были предназначены для работы в сети или использования в интегрированной среде B2B или B2C, заметил Кулкарни.
«Создав уровень API, эти устаревшие транзакционные системы получают возможность участвовать в инициативах цифровой трансформации», — сказал он.
Этот шаблон включения API унаследованных систем создает проблемы с безопасностью. В противном случае у них не было бы проблем в контролируемых доверенных зонах, для работы в которых были разработаны устаревшие системы.
Исправление безопасности API
Когда дело доходит до приложений на основе API и микросервисов, есть не уделяется должного внимания безопасности, что часто не является документированным или измеренным требованием.
«Более того, даже если бы безопасность была требованием, группы разработчиков не знают, как выглядят хорошие безопасные API-интерфейсы», — отметил Кулкарни.
Он предложил следующие стратегии для решения этих проблем:
- Всегда спрашивайте, какие меры безопасности были приняты для защиты API-интерфейсов, которые вы планируете использовать, от партнера или третьей стороны (внутренней или внешней) . Если вы спросите, вы узнаете. В противном случае вы просто предположите.
- Протестируйте свои API в производственной среде — будь то API-оболочки для устаревших систем или новые приложения, ориентированные на API. В производстве нет альтернативы тестированию.
- Убедитесь, что ваша группа управления продуктом документирует случаи злоупотреблений, связанных с безопасностью, в качестве требований во время разработки. Сделайте безопасность критерием выхода.
Группа безопасности должна включить вопросы групп разработчиков о мерах безопасности API в качестве пункта контрольного списка в свои критерии приемки, предложил Кулкарни.
Кроме того, необходимо целенаправленное обучение разработчиков, чтобы гарантировать, что у разработчиков будет достаточно обучения, чтобы сделать их эффективными и не перегружать их, добавил он. 
