Improper Inventory Management

Особливості цієї вразливості

Хакери зазвичай отримують несанкціонований доступ через старі версії API або кінцеві точки, які працюють без виправлень і використовують слабкіші вимоги безпеки. У деяких випадках доступні експлойти. Крім того, вони можуть отримати доступ до конфіденційних даних через третю сторону, з якою немає причин ділитися даними.

Поширеність

Застаріла документація ускладнює пошук і/або усунення вразливостей. Відсутність інвентаризації активів і стратегій виходу з експлуатації призводить до роботи систем без виправлень, що призводить до витоку конфіденційних даних. Через сучасні концепції, такі як мікросервіси, які роблять додатки легкими для розгортання та незалежними (наприклад, хмарні обчислення, K8S), часто можна знайти непотрібно відкриті хости API. Для виявлення цілей достатньо простого Google Dorking, перерахування DNS або використання спеціалізованих пошукових систем для різних типів серверів (веб-камер, маршрутизаторів, серверів тощо), підключених до Інтернету.

Впливи

Зловмисники можуть отримати доступ до конфіденційних даних або навіть захопити сервер. Іноді різні версії/розгортання API підключаються до однієї бази даних із реальними даними. Хакери можуть використовувати застарілі кінцеві точки, доступні в старих версіях API, щоб отримати доступ до адміністративних функцій або використовувати відомі вразливості.

Як зрозуміти що API вразлива?

Розгалужена та пов’язана природа API і сучасних програм створює нові виклики. Організаціям важливо не лише добре розуміти та бачити свої власні API, а й те, як API зберігають або обмінюються даними із зовнішніми третіми сторонами.

Запуск кількох версій API вимагає додаткових ресурсів керування від постачальника API та розширює поверхню атаки.

API має "сліпу пляму в документації" якщо:

У якому середовищі працює API (наприклад, прод, тестове, локальне)?
Хто повинен мати мережевий доступ до API (наприклад, публічний, внутрішній, партнери)?
Яка версія API працює?
Документація відсутня або існуюча документація не оновлена.
Для кожної версії API немає плану виходу на пенсію.
Інвентар хоста відсутній або застарілий.

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

API має "сліпу пляму в потоці даних" якщо:

Існує «потік конфіденційних даних», коли API передає конфіденційні дані третім особам
Немає бізнес-обґрунтування чи схвалення потоку
Немає інвентаризації чи документованості потоку
Немає глибокої документованості того, який тип конфіденційних даних надається

Приклади сценаріїв атак

Сценарій №1

Соціальна мережа реалізувала механізм обмеження швидкості, який блокує зловмисників від використання брутфорсу для вгадування токенів на скиданні пароля. Цей механізм реалізовано не як частина самого коду API, а в окремому компоненті між клієнтом API ( api.socialnetwork.owasp.org). Дослідник знайшов бета-версію хоста API ( beta.api.socialnetwork.owasp.org), який запускає той самий API, включаючи механізм скидання пароля, але механізм обмеження швидкості не був реалізован в цьому місці. Дослідник зміг скинути пароль будь-якого користувача за допомогою простого брутфорса, щоб вгадати 6-значний маркер.

Сценарій №2

Соціальна мережа дозволяє розробникам незалежних програм інтегруватися з нею. У рамках цього процесу від кінцевого користувача запитується згода, щоб соціальна мережа могла поділитися особистою інформацією користувача з незалежною програмою.

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

Консалтингова фірма створює шкідливий додаток і отримує згоду 270 000 користувачів. Завдяки недоліку консалтинговій фірмі вдається отримати доступ до приватної інформації 50 000 000 користувачів. Пізніше консалтингова фірма продає інформацію в зловмисних цілях.

Як запобігти

Задокументуйте важливі всі аспекти API, зосереджуючись на кожному середовищі API (наприклад, прод, тестове, локальне), хто повинен мати мережевий доступ до хоста (наприклад, публічний, внутрішній, партнери) і врахуйте всі версії API.
Задокументуйте важливі аспекти, такі як ролі у системі, якими даними обмінюються (потік даних) і їх чутливість.
Задокументуйте всі аспекти вашого API, такі як автентифікація, помилки, перенаправлення, обмеження швидкості, політика спільного використання ресурсів між джерелами (CORS) і кінцеві точки, включаючи їхні параметри, запити та відповіді.
Створюйте документацію автоматично за допомогою відкритих стандартів. Включіть збірку документації у свій конвеєр CI/CD.
Зробіть документацію API доступною лише для тих, хто має право використовувати API.
Використовуйте зовнішні засоби захисту, такі як спеціальні рішення безпеки API, для всіх відкритих версій ваших API, а не лише для поточної робочої версії.
Уникайте використання робочих даних із тестового середовища API. Якщо цього не уникнути, ці кінцеві точки мають отримати такий самий захист, як і робочі.
Якщо новіші версії API включають покращення безпеки, проведіть аналіз ризиків в старій версії API, щоб впевнитись на скільки легко перейти на нову версію. Наприклад, чи можна провести вдосконалення, не порушуючи сумісністі API, чи потрібно швидко видалити стару версію та змусити всіх клієнтів перейти на останню версію.