Смерть от тысячи утечек данных: как API подавляют безопасность

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

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

Что такое API?

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

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

Agile и API: двойная проблема безопасности

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

Хотя это постоянное исправление кажется фантастическим для безопасности (постоянная поддержка программного обеспечения? Хорошо!) Экономическая реальность производства программного обеспечения означает, что количество API быстро становится громоздким.

Поскольку команды разработчиков развиваются быстро, API редко полностью задокументированы. Из-за этого невероятно сложно заглянуть во внутренние механизмы приложения и понять, какие API за что отвечают. Это также значительно усложняет безопасность, поскольку сами команды разработчиков не знают истинного размера своего инвентаря API. Это отводит кибербезопасности низкий приоритет; всегда реактивный и никогда не активный.

Пропущенные API

Когда упоминается безопасность приложений, первое, что приходит на ум, — это тяжеловесы безопасности. Атаки, такие как межсайтовый скриптинг; SQL-инъекция и DDoS-атаки невероятно хорошо известны. Сами приложения часто хорошо защищены решениями типа plug-and-play, такими как брандмауэры веб-приложений, патрулирующие периметр.

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

Когда водитель Uber присоединяется к Uber по реферальной ссылке, он запускает приложение и вводит реферальный код. После нажатия кнопки ввода браузер приложения связывается с хостом API «bonjour.uber.com». Оттуда bonjour.uber получает параметр идентификатора пользователя и возвращает сведения о водителе обратно в приложение пользователя, готовое к вводу на следующем экране согласия.

Однако этот API был признан виновным в двух серьезных нарушениях безопасности. Первым была авторизация на уровне сломанных объектов (BOLA). API не проверял, соответствует ли идентификатор пользователя его параметру идентификатора; поэтому можно было получить доступ к данным других пользователей, просто изменив идентификатор пользователя.

Второй проблемой было чрезмерное раскрытие данных. Ответ API — возврат сведений о пользователе — объединил всю эту информацию в один пакет, содержащий все сведения о пользователе. Это означало, что API возвращал информацию, которая явно не нужна клиенту, нарушая один из основных принципов передовой практики кибербезопасности.

Теперь учтите, что средняя организация использует более 15 500 API, и начинает проявляться шкала риска. К счастью, Uber API был подключен до того, как произошло какое-либо серьезное повреждение; следующей компании повезло меньше.

Проблема пелотона

У бренда домашнего фитнеса Peloton более 3 миллионов подписчиков. Занятия фитнесом в прямом эфире являются основным аргументом в пользу продажи, хотя, если вы не хотите делиться своими медицинскими данными с другими участниками занятий, вы можете сделать свою учетную запись пелотона частной.

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

API уже много лет являются причиной громких утечек данных. Постоянные скандалы с данными Facebook в течение 2018 и 2019 годов привели к тому, что одно нарушение происходило за другим, в основном через API сторонних разработчиков. Одним из примеров был API групп; разработчики, работающие над приложением для управления социальными сетями B2B, могли свободно получать доступ к именам и другим личным данным членов группы. Хотя это приложение для управления социальными сетями должно было помочь администраторам групп более эффективно управлять своими группами, Facebook пришлось удалить его и его API.

Эти скандалы с данными достигли кульминации в 2021 году, когда из базы данных черного рынка, содержащей более 533 миллионов пользователей Facebook, просочились их имена, номера телефонов и идентификаторы пользователей Facebook.

Предотвращение утечки API

Проект Open Web Application Security Project (OWASP) регулярно публикует самые серьезные и широко распространенные уязвимости веб-приложений, за которыми нужно следить. Растущая угроза безопасности, представляемая API-интерфейсами, достаточно серьезна, чтобы гарантировать создание собственного списка OWASP первой десятки, который неизменно возглавляет авторизация на уровне сломанных объектов.

К счастью, защита ваших API — помимо требования более медленного цикла разработки — тесно связана с защитой вашей организации в целом. Ваша первая точка вызова будет достойным брандмауэром веб-приложений (WAF). Это решение отслеживает периметры ваших приложений, предотвращая использование шлюзов API с помощью серьезных уязвимостей.

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

В то время как WAAP является защитной системой на уровне конечной точки, решения для самозащиты приложений во время выполнения (RASP) охватывают определенные веб-приложения. Решение RASP, отличное от WAF, также имеет представление о внутренней работе и поведении своего приложения. Таким образом, если API используется в качестве плацдарма для атаки и запрашивается больше информации, чем это возможно, RASP может заблаговременно остановить атаку.

Благодаря множеству доступных вариантов защиты API защита ваших приложений и вашей организации никогда не была проще.