Безпека API: OWASP API Top 10 на практиці

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

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

Ця одна відсутня перевірка є пунктом API1 в OWASP API Security Top 10 і досі залишається найпоширенішим способом витоку даних із реальних API. Вона ж показує, чому практики безпеки API читаються інакше, ніж практики безпеки вебзастосунків.

Уразливість тут не в payload, не в помилці кодування і не у відсутньому заголовку. Це бізнес-правило, яке ніхто не записав.

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

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

Помилка в тому, що сервер підтвердив особу і пропустив питання про дозвіл. Саме тому OWASP API Security Top 10 виглядає так несхоже на вебсписок: дві найвищі позиції — це зламаний контроль доступу, розділений за тим, до чого дістається виклик, до чужого об’єкта чи до функції, яку його роль не має викликати.

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

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

Це змінює те, що можна вважати даністю. Відповідь і є API, а не екран, і тіло запиту повністю контролює зловмисник, включно з полями, яких ваша форма ніколи не показувала.

Ідентифікатор у шляху — це параметр, а не факт. Усе, що надсилає клієнт, може відредагувати той, хто тримає токен.

Редакція 2023 року легше лягає в навчання, якщо згрупувати її за питанням, яке сервер забув поставити.

Broken object level authorization, API1, це саме той випадок із початку статті. Сервер завантажує названий у запиті об’єкт і повертає його без порівняння власності, тож будь-який автентифікований виклик може перебирати ідентифікатори та збирати записи. Наша вправа з BOLA ставить вас по обидва боки: підмініть ідентифікатор і прочитайте чужу поїздку, а потім додайте перевірку власності, яка це зупиняє.

Broken function level authorization, API5, це рольова версія тієї самої прогалини. Адмінські маршрути живуть у тому самому API, що й користувацькі, елементи керування сховані в інтерфейсі, а самі ендпоінти не мають перевірки ролі, тож до них дістається будь-який дійсний токен. У вправі з BFLA ви викликаєте службові ендпоінти з облікового запису аналітика лише для читання, а потім виправляєте це на рівні роутера, а не обробника.

Broken authentication, API2, рідко означає зламану перевірку облікових даних. Зазвичай це коректна перевірка без жодного захисту від автоматизації, і це стає вирішальним, коли обліковий елемент короткий.

Шестизначний код з листа має мільйон варіантів. Без обмеження частоти чи блокування зловмисник, який знає лише адресу пошти, здатний пройти весь простір. Вправа зі зламаної автентифікації проводить цю атаку проти ендпоінта без лімітів, а потім обмежує частоту на акаунт і повертає 429.

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

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

Масове призначення — та сама проблема, спрямована в інший бік. Коли ендпоінт оновлення прив’язує кожне поле з тіла запиту до моделі, клієнт може додати role чи balance до PATCH і записати атрибути, яких форма ніколи не показувала. Вправа з масового призначення створює бонусний баланс двома зайвими ключами, а потім прив’язує лише редаговані поля.

Unrestricted resource consumption, API4, охоплює ендпоінти без серверного обмеження на обсяг одного запиту. Розмір сторінки, взятий просто з рядка запиту, перетворює звичайну пагінацію на повний експорт таблиці. Подивіться, як це працює, у вправі з необмеженого споживання ресурсів.

Improper inventory management, API9, це версія, яку не полагодити в коді, на який ви дивитесь. Застаріла v1, задокументована як виведена з експлуатації, але ніколи не вимкнена, досі відповідає, і без жодного контролю, який додала v2. Вправа з інвентаризації API читає записи через стару версію, а потім коректно закриває її статусом 410 Gone.

Security misconfiguration, API8, завершує набір. Політика CORS, яка відображає будь-який Origin і дозволяє облікові дані, дає можливість будь-якому сайту прочитати авторизований акаунт, і жодної помилки в застосунку для цього не потрібно.

Порядок нижче визначений тим, скільки ймовірності зламу знімає кожен крок на годину роботи інженера, а не тим, як вони йдуть у стандарті.

1. Перевіряйте власність на рівні даних, а не обробника. Запит із фільтром за ідентифікатором того, хто викликає, неможливо забути так, як умовний оператор. Обробники копіюють, методи репозиторію перевикористовують.
2. Ставте перевірки ролей на роутері. Захист, застосований на маршруті, аудиюється в одному файлі. Захист усередині кожного обробника аудиюється лише читанням їх усіх.
3. Серіалізуйте за білим списком. Опишіть поля, які може містити відповідь. Усе, що додадуть до моделі пізніше, лишається приватним, доки хтось свідомо його не опублікує.
4. Прив’язуйте теж за білим списком. Приймайте з тіла запиту названий набір записуваних полів і відкидайте решту, щоб нова колонка ніколи не стала випадково доступною для запису з клієнта.
5. Обмежуйте розмір сторінки та частоту на сервері. Задайте жорсткий максимум, який не підніме жоден параметр запиту, і обмежуйте частоту на акаунт, а не на IP.
6. Логуйте читання, а не лише записи. Авторизований доступ — єдина категорія зловживань, яка не порушує жодного контролю, тож журнал аудиту є єдиним механізмом виявлення. Вправа з недостатнього логування та моніторингу показує агента підтримки, який дістає профіль клієнта без тікета й не лишає слідів.
7. Ведіть інвентар і дотримуйтеся дат виведення з експлуатації. Застаріла версія, яка досі відповідає, це продакшн, що б не писала документація.
8. Параметризуйте кожен запит. Ін’єкції старші за REST і досі виходять у реліз. Вправа з ін’єкцій в API перетворює пошук у каталозі на повне читання бази, а потім параметризує запит так, щоб введення лишалося даними.

Читання OWASP API Security Top 10 дає словник. Воно не дає рефлексу, бо впізнати BOLA на слайді і помітити, що щойно написаний метод репозиторію приймає ідентифікатор і не приймає користувача, це різні навички.

Переноситься в роботу інша схема: спочатку атака, потім виправлення, на коді, який поводиться як код вашої команди. Розробник, який особисто перебрав ідентифікатори на ендпоінті й побачив чужі записи, більше не пише запити без фільтра. Той, хто бачив лише схему, зазвичай пише.

Саме так побудовані наші вправи з безпеки API. Кожна запускає робочу атаку проти реалістичного сервісу, а потім вимагає випустити виправлення й довести, що атака більше не працює. Той самий підхід покриває вебрівень у каталозі з безпеки застосунків, тож команда може рухатися вебсписком і API-списком OWASP, не змінюючи спосіб навчання.

Ширше порівняння платформ за мовним покриттям, мапуванням на OWASP і ціною є в нашому огляді платформ навчання безпечного коду.

Відсоток проходження вимірює відвідуваність. Поведінку вимірюють три сигнали.

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

Усі три рахуються із систем, які у вас уже працюють. Жоден не потребує опитування.

Яка вразливість API найпоширеніша?

Broken object level authorization, пункт API1 в OWASP API Security Top 10. API підтверджує, що виклик має дійсну сесію, а потім повертає будь-який названий у запиті об’єкт без перевірки, що той належить саме цьому користувачеві. Вона поширена, бо перевірку треба свідомо написати для кожного маршруту з ідентифікатором, а зелені тести ніяк не вказують на її відсутність.

Чи відрізняється OWASP API Security Top 10 від OWASP Top 10?

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

Як часто проводити навчання з безпеки API?

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

Чи можна закрити безпеку API шлюзом або WAF?

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

Що розробнику виправити першим у наявному API?

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

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

Далі дайте розробникам на чому потренуватися. Наші вправи з безпеки API безкоштовні, а про впровадження в інженерній команді можна поговорити з нами.