Порушена авторизація на рівні об'єктів

Що таке Порушена авторизація на рівні об'єктів?

Порушена авторизація на рівні об'єктів, також відома як BOLA або IDOR, — найпоширеніша вразливість API. Ендпоінт повертає об'єкт, названий ідентифікатором у запиті, не перевіряючи, чи належить він тому, хто викликає. Токен при цьому справжній. Змінивши в URL єдине число-ідентифікатор, ви прочитаєте чужий запис, а потім переберете послідовні ідентифікатори й масово зберете дані. Виправлення порівнює власника запису з автентифікованою сесією й повертає 404, а не 403, щоб відхилений ідентифікатор не можна було підтвердити як наявний.

Що ви дізнаєтесь у Порушена авторизація на рівні об'єктів

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

Порушена авторизація на рівні об'єктів — Кроки навчання

1. Звичайний пасажир

   Larkway — застосунок для виклику таксі, і будь-який пасажир може ввімкнути в ньому особистий Trips API, щоб експортувати квитанції про власні поїздки для звітів про витрати. Боб зареєструвався як звичайний пасажир, під вигаданим іменем, і ввімкнув його. Обліковий запис у нього звичайнісінький: пасажирський, з токеном, який читає лише його власні поїздки. Щоб побачити, що йому дає API, він відкриває консоль розробника.

2. Ідентифікатори поїздок — просто числа

   Власні поїздки Боба показано разом з ідентифікаторами, а довідник API пояснює, як отримати квитанцію будь-якої окремої поїздки за її ідентифікатором. У цих ідентифікаторах впадають в око дві речі.

3. Отримайте його власну поїздку

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

4. Його поїздка, як і очікувалося

   Сервер повертає саме те, що має: власну поїздку Боба, бо ідентифікатор у його запиті належить йому.

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

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

6. Чужа поїздка

   Сервер відповів. Власний токен пасажира Боба щойно витягнув поїздку, яка не має до нього жодного стосунку.

7. Пройдіть послідовність

   Один чужий запис — просто цікавинка. Боб іде далі по послідовності, і кожне значення повертає справжню квитанцію. Щоб підтвердити закономірність, він пробує 50315.

8. Усі пасажири, масово

   Ідентифікатори йдуть підряд, і кожен відповідає. Так один витік перетворюється на масове збирання даних.

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

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

    Ви відповідаєте за Trips API для пасажирів у Larkway. Уночі моніторинг помітив, що один токен пасажира витягує тисячі поїздок, які йому не належать. Центр моніторингу безпеки надіслав вам подробиці листом.