Неправильне керування інвентаризацією API

Що таке Неправильне керування інвентаризацією API?

Захід захисту охоплює лише ті ендпоінти, про які ви знаєте, що вони працюють. Старі версії API, незадокументовані ендпоінти й забуті хости лишаються розгорнутими поза цим переліком і далі виконують той самий незахищений код, що й завжди. Ви отримаєте 401 від поточної версії, змінете один сегмент URL з v2 на v1 і отримаєте 200 з іменем, електронною адресою та домашньою адресою клієнта, а потім переберете ідентифікатори облікових записів і зберете масовий список. Виправлення виводить стару версію з експлуатації, і кожен шлях під нею повертає 410 Gone. Позначити версію застарілою в документації — не означає вивести її з експлуатації.

Що ви дізнаєтесь у Неправильне керування інвентаризацією API

• Розпізнавайте неправильне керування інвентаризацією: версії й хости API — старі, незадокументовані чи призначені не для продакшну — лишаються розгорнутими й доступними поза заходами захисту, які забезпечує поточна версія
• Розумійте, що новий захід захисту (шлюз автентифікації, перевірка) охоплює лише версії, які стоять за ним, тож стара версія, залишена в продакшні, працює без жодного захисту, на коді, написаному до появи цього заходу
• Побачте, як зміна одного сегмента URL з поточної версії на застарілу веде до забутої збірки і як ендпоінт без автентифікації через простий перебір перетворюється на масове розкриття даних
• Відрізняйте цю проблему від порушеної авторизації на рівні об'єктів (немає перевірки власника кожного запису всередині автентифікованого ендпоінта) і від надмірного розкриття даних (повернення зайвих полів); тут уся версія працює без автентифікації, бо її так і не вивели з експлуатації
• Застосовуйте виправлення: виводьте непідтримувані версії з експлуатації, щоб вони повертали 410 Gone і зникали з продакшну, і ведіть інвентаризацію кожної розгорнутої версії, середовища й хоста, щоб ніщо не працювало без нагляду

Неправильне керування інвентаризацією API — Кроки навчання

1. Стара версія, яка досі є в документації

   Emberline — застосунок для домашньої сонячної енергетики: клієнти під'єднують до нього сонячні панелі та акумулятор, а застосунок читає дані їхніх облікових записів через API Emberline. Сьогодні Боб націлився на Emberline. Облікового запису й токена в нього немає; йому потрібен лише список клієнтів і місць, де вони живуть, щоб його перепродати. Він починає з публічної документації для розробників Emberline, щоб розібратися в API.

2. Застаріла, але не вимкнена

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

3. Зверніться до поточної версії

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

4. Шлюз відмовляє

   Поточна версія зробила саме те, що мала.

5. Змініть один сегмент

   Боб надсилає той самий запит, так само без токена, і змінює лише одне: версію в URL — з v2 на v1 , застарілу збірку. Усе інше однакове. Якщо стара версія справді зникла, запит не має нікуди дійти.

6. Забута версія відповідає

   Той самий запит, який щойно відхилив шлюз, повернувся з даними.

7. Переберіть облікові записи

   Один запис — це попередження. Оскільки v1 узагалі не вимагає токена, ніщо не заважає Бобові перебирати ідентифікатори облікових записів. Він залишає версію v1 і змінює ідентифікатор на наступного клієнта.

8. Усі клієнти, масово

   Інший ідентифікатор — інший справжній клієнт.

9. Перевірка знань

10. Надходить сповіщення

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