Исследования Akamai показывают, что на сегодняшний день 83% всего трафика в Интернете составляют вызовы API (JSON / XML). Во многих случаях этот быстрый рост может быть объяснен принятием и популярностью мобильных устройств и экосистемы мобильных приложений, а также злоупотреблениями со стороны действующих лиц, использующих ботов для автоматизации своих процессов ручной атаки. Было установлено, что злоумышленники нацелены на общедоступные API-интерфейсы, которые легко обнаружить, но есть и другая поверхность атаки, которой уделяется мало внимания.

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

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

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

Но как злоумышленники проводят разведку против этих непубличных сред API? Ну, для тех API, которые не работают через частный туннель, это обычно довольно просто.

В приведенном примере (пример 1) вы видите, что запрос к xyzcorp.com возвращает интересное имя хоста с именем api.xyzcorp.com. Это пример того, как эти имена хостов могут быть раскрыты. Но есть и другой способ определения поверхности атаки - использование журналов прозрачности сертификатов.

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

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

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

В этом примере (пример 2) мы видим фрагмент кода, который был размещен на GitHub, который показывает жестко закодированную информацию о токене OAuth, которая, в случае компрометации, представляет риск для вызовов аутентификации, которым доверяют хосты в этом процессе.

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

Простой поиск «api type:» webapps на shodan.io показывает пару сотен уязвимых сервисов, работающих на момент написания этой статьи (Пример 3).

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

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