Любой, кто заинтересован в опережении атак кибербезопасности и вторжений в корпоративную сеть через уязвимости интерфейса прикладного программирования (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 от потенциальной серьезной уязвимости», — предупредил он.
Основная проблема, которая становится запутанной, заключается в том, что сегодня API-интерфейсы являются фасадом к устаревшим системам, которые никогда не были предназначены для работы в сети или использования в интегрированной среде B2B или B2C, заметил Кулкарни.
«Благодаря созданию уровня API эти устаревшие транзакционные системы получают возможность участвовать в инициативах цифровой трансформации», — сказал он.
Этот шаблон включения API унаследованных систем создает проблемы безопасности. В противном случае у них не было бы проблем в контролируемых доверенных зонах, для работы в которых предназначались унаследованные системы.
Исправление безопасности API
Когда дело доходит до приложений на основе API и микросервисов, безопасности не уделяется должного внимания, что часто не является документированным или измеренным требованием.
«Более того, даже если бы безопасность была требованием, группы разработчиков не знают, как выглядят хорошие безопасные API-интерфейсы», — отметил Кулкарни.
Он предложил следующие стратегии для решения этих проблем:
- Всегда спрашивайте, какие меры безопасности были приняты для защиты API-интерфейсов, которые вы планируете использовать, от партнера или третьей стороны (внутренней или внешней) . Если вы спросите, вы узнаете. В противном случае вы просто предположите.
- Протестируйте свои API в производственной среде — будь то API-оболочки для устаревших систем или новые приложения, ориентированные на API. В производстве нет альтернативы тестированию.
- Убедитесь, что ваша группа управления продуктом документирует случаи злоупотреблений, связанных с безопасностью, в качестве требований во время разработки. Сделайте безопасность критерием выхода.
Группа безопасности должна включить вопросы групп разработчиков о мерах безопасности API в качестве пункта контрольного списка в свои критерии приемки, предложил Кулкарни.
Кроме того, необходимо целенаправленное обучение разработчиков, чтобы гарантировать, что у разработчиков будет достаточно обучения, чтобы сделать их эффективными и не перегружать их, добавил он.
