Почему безопасность API — дело каждого

Aug 20, 2023

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

Число API-интерфейсов растет в геометрической прогрессии по мере распространения мобильных, веб- и облачных приложений. Немного отраслевой статистики:

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

В зависимости от вашей точки зрения, то, что около 50% используемых API-интерфейсов являются неуправляемыми, либо очень удивительно, либо очень неудивительно.

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

Постоянно расширяющаяся и плохо патрулируемая поверхность атаки: это мечта хакера.

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

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

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

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

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