Хакеры идут туда, где есть деньги, и сейчас для кражи конфиденциальной информации они находят богатый источник в уязвимостях прикладных программных интерфейсов (API), говорит Джонатан Кэр, известный эксперт по кибербезопасности, ранее старший директор по исследованиям Gartner, а ныне советник консалтинговой компании Lionfish Tech Advisors. Портал The New Stack приводит его соображения о том, как разработчики могут помешать злоумышленникам проводить атаки на API.

«Почему безопасность API должна быть в центре вашего внимания? Потому что 80% интернет-трафика проходит через API, — поясняет Кэр. — И, конечно, если трафик растет, то за ним следуют и злоумышленники. Это вполне логично: как говорил [легендарный грабитель банков] Вилли Саттон, „я атакую банки, потому что там деньги“».

По его словам, наборы эксплойтов стоят недорого: один такой набор можно арендовать примерно за 1400 долл. в месяц. Смесь эксплойтов — распространенная тактика, с помощью которой злоумышленник получает доступ к конфиденциальному серверу, крадет данные, а затем загружает вымогательское ПО, добавляет он.

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

Переход к защите, ориентированной на API

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

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

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

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

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

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

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

Два основных типа атак на API

Кэр приводит два основных способа атаки на API или использования теневых API:

  1. Broken Object Property Level Authorization (BOPLA) — уязвимость, которая возникает, когда API не обеспечивает надлежащее управление авторизацией на уровне свойств объекта. Если API предоставляет больше информации, чем было в рамках дополнительного запроса, это позволяет злоумышленникам извлечь нужную им информацию. Это новое дополнение к списку OWASP, которое фокусируется на авторизации отдельных свойств внутри объекта. Злоумышленник может воспользоваться этим, чтобы получить доступ к неавторизованным свойствам или манипулировать ими.
  2. Broken Object Level Authorization (BOLA) — уязвимость которая возникает, когда приложение или API предоставляет доступ к объектам данных на основе роли пользователя, но не проверяет, имеет ли пользователь разрешение на доступ к этим конкретным объектам. Это когда злоумышленник меняет идентификационный номер на один и получает доступ к данным других клиентов.

«Таким образом, бот для скриптового агента может очень легко и просто добывать информацию, что и имело место в кейсе фитнесс-компании, — говорит Кэр. — Если бы у нас была система обнаружения, мы бы сами нашли эти открытые конечные точки и мы бы сами сказали: „Эй, смотрите, вот что тут нужно сделать. Если манипулировать URL-адресами, можно выявить теневые API“».

Что могут сделать разработчики

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

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

Все это можно легко исправить после обнаружения; но, опять же, многие компании не обнаруживают недостатки безопасности API, потому что не следят за ними.

«Большинство ритейлеров не по своей воле узнают, что их хакнули, что их платежные системы были взломаны злоумышленниками. Им сообщает об этом их банк, — говорит Кэр. — Когда ваши оповещения безопасности приходят извне, это, поверьте мне, не очень приятно».

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

Такие инструменты, как продукты для инвентаризации API и обеспечения соответствия API, могут помочь выявить и оценить API в рамках организации, интегрировав их в конвейер CI/CD. И организациям стоит использовать решения для обнаружения угроз API, которые могут блокировать атаки на API в режиме реального времени.