Попри всю свою корисність, списки OWASP Top 10 достатньо важко зрозуміти та прочитати. В цій статті спробуємо детальніше розібрати кожну категорію ризиків API.
API1:2023 Порушена авторизація на рівні об’єктів (також відома як BOLA та IDOR) (Broken Object-Level Authorization (aka BOLA aka IDOR))
Суть API полягає в тому, щоб забезпечити автоматизований доступ до даних і функціональності програми. Налаштувати API інтерфейс для отримання даних про обліковий запис клієнта дуже просто – головна проблема полягає в тому, щоб переконатися, що дані доступні лише авторизованим користувачам і системам. Якщо до чогось («об’єкта») у додатку будь-хто може отримати вільний доступ, просто знаючи, як запросити правильну URL-адресу та ідентифікатор об’єкта (наприклад, номер клієнта), відбудеться витік даних. Прикладом є злом сервісу Optus.
API2:2023 Порушена автентифікація (Broken Authentication)
Перше, що мають зробити перед важливою роботою в API, це підтвердити особу виконавця.Якщо механізм автентифікації слабкий або його легко обійти, зловмисники можуть легко проникнути в систему. Як тільки вони отримують доступ, решта 9 ризиків стають реальністю.
API3:2023 Порушення авторизації на рівні властивостей об’єктів (Broken Object Property-Level Authorization)
У більшості бізнес-додатків різні користувачі потребують різних рівнів доступу до даних. Наприклад, програма має обліковий запис клієнта в системі. Деяким співробітникам знадобиться лише контактна інформація, іншим довірятимуть фінансові дані, тоді як користувач з правами адміністратора може мати доступ до всього, а також керувати обліковими даними. Забезпечити такі різні доступи для API особливо складно, що призводить до ситуацій, коли зловмисник, який отримує доступ до об’єкта облікового запису клієнта, також отримує доступ до всіх даних цього облікового запису.
API4:2023 Необмежене споживання ресурсів (Unrestricted Resource Consumption)
Витоки даних не рідко потрапляють у заголовки новин, але зловмисникам часто достатньо вивести API з ладу разом з усім додатком.
Атаки на відмову в обслуговуванні (DoS-атаки) є одними з найпростіших, але найпоширеніших способів атакувати API, що полегшується тим, що API спеціально розроблені для автоматизованого доступу. Прийняття та обробка кожного вхідного запиту без застосування будь-яких обмежень робить API вразливим до вичерпання ресурсів, а його власника – до надмірних операційних витрат.
API5:2023 Порушена авторизація на рівні функцій (Broken Function-Level Authorization)
API інтерфейси надають не тільки дані, але й операції над ними. Хоча ризик №3 був пов’язаний з отриманням зловмисниками доступу до об’єктів даних за принципом «все або нічого», те саме стосується і дозволених операцій.
Зокрема, REST API, як правило, містять методи, що містять GET, PUT і DELETE.Якщо будь-хто, хто може прочитати дані за допомогою звичайного GET-запиту, може також видалити їх, просто вручну змінивши GET на DELETE в заголовку запиту, це справжній ризик.Те ж саме стосується незахищеного доступу до таких сфер, як операції адміністратора.
API6:2023 Необмежений доступ до чутливих бізнес-потоків (Unrestricted Access to Sensitive Business Flows)
Зловживання автоматизованим доступом до певних операцій може мати серйозні наслідки для бізнесу, навіть якщо технічно це не становить загрози безпеці. Поширеними прикладами є автоматичні аукціонні торги, викуп і подальший перепродаж товарів з високим попитом, таких як квитки, або переповнення системи бронювання запитами на відмову в доступі до неї законним користувачам. Отже, це може спричинити перебої в роботі та матеріальні збитки.
API7:2023 Підробка запитів на стороні сервера (SSRF) (Server-Side Request Forgery (SSRF))
Поширеною практикою у веброзробці є отримання ресурсів із зовнішнього сайту. При роботі через API так само часто можна отримати конкретну адресу ресурсу (URL) з вхідного запиту. Без ретельної перевірки на наявність будь-яких неочікуваних даних у цій URL-адресі зловмисник може надіслати URL-адресу шкідливого зовнішнього ресурсу, що містить шкідливий код. Що ще гірше, також може запросити конфіденційний внутрішній ресурс – і оскільки запит надходить з сервера API користувача, зловмисник може опосередковано отримати доступ до внутрішніх систем через API.
API8:2023 Неправильна конфігурація безпеки (Security Misconfiguration)
Навіть одна неправильна конфігурація безпеки в будь-якому API може надати зловмисникам можливість отримати доступ до даних або операцій API. Прикладами можуть бути невиправлені продукти або програмні компоненти в будь-якому місці технологічного стека (tech stack), надмірні дозволи на будь-якому рівні цього стеку (особливо дозволи на хмарне сховище) та слабкий захист (наприклад, прогалини в шифруванні) на будь-якому етапі обробки запитів до API.
API9:2023 Неправильне управління запасами (Improper Inventory Management)
Коли API змінюється, загальноприйнятою практикою є встановлення нової версії паралельно зі старою, щоб переконатися, що наявні системи, які покладаються на цей API, продовжують працювати до завершення переходу. Без ретельного управління інвентаризацією старі API можна легко не помітити та забути. В такому разі вони залишаться доступними для зловмисників. Також вони з меншою ймовірністю містять останні оновлення безпеки та можуть не контролюватися і не бути захищеними на тому ж рівні, що і виробничі API, що дає зловмисникам достатньо часу і можливостей для проникнення в систему. Саме тому виявлення API має таке велике значення.
API10:2023 Небезпечне використання API (Unsafe Consumption of APIs)
Здебільшого API взаємодіють не з людьми, а з іншими API – і ті, за задумом, мають поводитися відповідно до специфікації.
Це може створити відчуття неявної довіри, що спонукає розробників беззаперечно приймати та передавати дані зі знайомого стороннього API без перевірки, особливо якщо він використовується відомою компанією. Якщо зловмисники скомпрометують цей API або зможуть вбудувати шкідливі дані в одне з його джерел даних, довіра до результатів, отриманих від цього API, може зробити додаток вразливим або скомпрометованим.
Висновок
Багато з 10 найбільших ризиків безпеки, пов’язаних з API, можуть здатися простими, адже здебільшого це різні способи надання зловмисникам доступу до даних.
Проблема з API полягає в тому, що вони діють як обхідні шляхи для доступу до внутрішніх компонентів додатка. Якщо ці обхідні шляхи не будуть ретельно сплановані на ранніх стадіях проєктування та розробки програми, вони можуть обійти засоби контролю доступу, які можуть бути присутніми в додатку.
Часто можна помилково розглядати будь-який OWASP Top 10 як контрольний список вразливостей, але мета API Security Top 10 чітко сформульована у вступі: «навчати тих, хто займається розробкою та підтримкою API, наприклад, розробників, дизайнерів, архітекторів, менеджерів або організацій». Саме тому фахівці з безпеки не включені в список – бо безпека API починається задовго до того, як вони починають займатися тестуванням і захистом. Основний висновок з Топ 10 безпеки API OWASP полягає в тому, що безпечні API завжди повинні починатися з безпечного дизайну додатків. Однак в реальності API рідко бувають ідеально спроєктовані, реалізовані або відстежувані, тому інструменти для виявлення API та тестування безпеки API є важливою частиною будь-якого набору інструментів для забезпечення безпеки додатків.
