Интерфейсы прикладного программирования (API) привлекательны для разработчиков программного обеспечения, поскольку они сокращают объем компьютерного кода, который необходимо писать с нуля. Они позволяют легко заменять и отключать сервисы без внесения изменений в конечное приложение.
API обеспечили скорость и конкурентное преимущество компаниям всех размеров с исследование IDC подсчитав, что от 10 до 50 процентов доходов предприятия приходится на них.
Однако эта универсальность не лишена своей цены. API-интерфейсы в равной степени привлекательны для злоумышленников, поскольку они обеспечивают быстрый доступ к серверным системам, содержащим конфиденциальные данные. По мере роста распространения появляются и атаки API, потенциально создавая бомбу замедленного действия из-за плохой безопасности, предоставляемой этим посредникам.
|
“);
|
По данным Enterprise Strategy Group (ESG), среды приложений претерпят существенные изменения в течение следующих двух лет. Хотя в настоящее время 35 % организаций запускают свои приложения в общедоступном облаке, этот показатель почти удвоится до 67 %, а сегодня 39 % используют эти приложения в микросервисах, и этот показатель вырастет до 71 %.
Та же история и с внедрением API. Сегодня 28% веб-приложений и веб-сайтов используют API, но эта цифра вырастет до 57%. Но, к сожалению, служба безопасности не успевает.
Проблема обеспечения эффективной безопасности API
API-интерфейсы по своей природе не имеют состояния и включают в себя команду, полезную нагрузку и контент, что затрудняет их защиту. Обычно разрабатываемые итеративно, они развиваются с течением времени, и это может привести к колебаниям их следа или сохранению предыдущих итераций.
Обновления, как правило, выполняются еженедельно или даже ежедневно, в результате чего появляется несколько более ранних версий, и если они не удаляются или не отслеживаются с помощью автоматизированной инвентаризации, они могут стать теневыми или зомби-API и возможными целями для атак.
Защита API — непростая задача, поэтому многие группы безопасности адаптировали существующие решения, такие как системы предотвращения вторжений (IPS), брандмауэры нового поколения или инструменты безопасности приложений, такие как брандмауэр веб-приложений (WAF). Тем не менее, эти инструменты вряд ли обнаружат и пометят вредоносную активность, потому что, хотя некоторые из них могут содержать небезопасный код, подавляющее большинство не будет, но все же может быть перехвачено.
Обычно называемые атаками «жить за счет земли» (LotL), против них используются собственные функции API. Поскольку атака LotL не связана с использованием сигнатур и нарушением каких-либо правил, такая активность вряд ли будет обнаружена.
Если вы посмотрите на лучший метод атаки согласно рейтингу OWASP Top 10 — Broken Object Level Authorization (BOLA ранее IDOR) — злоумышленник просто должен понимать бизнес-логику API, чтобы получить законный доступ к данным. Это означает, что реверс-инжиниринг API может дать необходимую информацию; нет необходимости использовать уязвимость, поэтому можно утверждать, что это не атака в традиционном смысле.
Чрезмерная зависимость от существующих инструментов
Что касается, так это то, что многие люди даже не знают, что эти инструменты работают плохо. Тот же опрос ESG показал, что 46 % используют несколько инструментов, потому что считают, что это увеличивает предлагаемую защиту, а 38 % предпочли добавить дополнительные инструменты, если они не работали должным образом, добавляя к стеку технологий и усложняя мониторинг, а также поддержание этого. Более трети считают, что их решения предлагают полную защиту, даже если они не предназначены для обеспечения безопасности API.
Существует множество примеров, когда компании становились жертвами атак API, таких как захват аккаунта (ATO), например, и по мере того, как API все больше укоренялись в цепочках поставок, проблема усугублялась. Недавняя атака на MailChimp должна служить предупреждением о том, насколько далеко может зайти хорошо спланированная атака. Он увидел компрометацию ключей API, используемых для предоставления доступа к учетной записи, и затем злоумышленники активно искали финансовые и крипто-клиенты. Одним из них был Trezor, производитель криптокошельков. Затем клиентам Trezor было разослано фишинговое электронное письмо, которым было предложено сбросить свои учетные записи с помощью клонированного приложения Trezor.
Растущий вектор атаки
Такие атаки свидетельствуют о том, что современные сервисы, построенные на инфраструктуре API, недостаточно защищены. Это только вопрос времени, когда мы начнем наблюдать рост злоупотреблений API, поэтому Gartner уже предупредил, что API станут наиболее частым вектором атак.
Чтобы противостоять этому, нам нужно переосмыслить наш подход к защите API, пока не стало слишком поздно. Для начала необходимо обнаружить и создать точную инвентаризацию API во время выполнения, которая документирует, когда они развертываются, обновляются или выводятся из эксплуатации. Это не только обеспечивает видимость, но и средства для отслеживания API, чтобы убедиться, что они соответствуют передовой практике.
Упомянутые выше инструменты могут помочь здесь, если атака основана на известных угрозах или включает атаку грубой силы, но, скорее всего, она будет более тонкой в подходе, требующей поведенческого анализа. Сравнение количества успешных и неудачных входов в учетные записи, например, и их сравнительный анализ в вашей отрасли может помочь определить атаки ATO.
Конечно, некоторые API-интерфейсы будут содержать небезопасный код, поэтому до сих пор основное внимание уделялось «сдвигу влево» и необходимости обеспечения безопасности на этапе разработки. Именно на этом сосредоточено большинство инструментов безопасности API, но при этом они не учитывают тот факт, что идеально закодированные API все еще могут быть уязвимы для атак.
Поскольку бизнес-использование API-интерфейсов будет продолжать расти, повышение безопасности, связанное с ними, как никогда важно. Изучая используемые инструменты и думая о безопасности на этапе разработки, можно усилить защиту и свести к минимуму успешные атаки.
Читать полную новость на сайте
