Основні вразливості OATH API
Основні вразливості OATH API: вступ
Коли справа доходить до експлойтів, API є найкращим місцем для початку. API Доступ зазвичай складається з трьох частин. Клієнтам токени видає сервер авторизації, який працює разом із API. API отримує маркери доступу від клієнта та на їх основі застосовує правила авторизації для конкретного домену.
Сучасні програмні додатки вразливі до різноманітних небезпек. Будьте в курсі найновіших експлойтів і недоліків безпеки; Наявність контрольних показників для цих вразливостей є важливою для забезпечення безпеки програми до того, як станеться атака. Програми сторонніх розробників все більше покладаються на протокол OAuth. Завдяки цій технології користувачі матимуть кращий загальний досвід, а також швидший вхід і авторизацію. Це може бути більш безпечним, ніж звичайна авторизація, оскільки користувачам не потрібно розкривати свої облікові дані сторонній програмі, щоб отримати доступ до певного ресурсу. Хоча сам протокол безпечний і захищений, спосіб його реалізації може зробити вас відкритим для атак.
Під час розробки та розміщення API ця стаття зосереджена на типових уразливостях OAuth, а також на різних засобах захисту.
Порушена авторизація на рівні об’єкта
У разі порушення авторизації існує велика площа атаки, оскільки API надають доступ до об’єктів. Оскільки елементи, доступні через API, повинні бути автентифіковані, це необхідно. Реалізуйте перевірки авторизації на рівні об’єкта за допомогою шлюзу API. Лише ті, хто має відповідні облікові дані дозволу, повинні мати доступ.
Порушена автентифікація користувача
Неавторизовані токени є ще одним поширеним способом для зловмисників отримати доступ до API. Системи автентифікації можуть бути зламані або ключ API може бути помилково відкритий. Можуть бути маркери автентифікації використовується хакерами отримати доступ. Автентифікуйте людей, лише якщо їм можна довіряти, і використовуйте надійні паролі. За допомогою OAuth ви можете вийти за межі простих ключів API та отримати доступ до своїх даних. Завжди потрібно думати про те, як ви будете в’їжджати та виходити з місця. Обмежені маркери відправника OAuth MTLS можна використовувати разом із Mutual TLS, щоб гарантувати, що клієнти не поведуть себе неправильно та не передадуть маркери неправильній стороні під час доступу до інших машин.
Просування API:
Надмірний доступ до даних
Немає обмежень щодо кількості кінцевих точок, які можна опублікувати. У більшості випадків не всі функції доступні для всіх користувачів. Розкриваючи більше даних, ніж це абсолютно необхідно, ви наражаєте себе та інших на небезпеку. Уникайте розкриття чутливих інформація поки це абсолютно необхідно. Розробники можуть визначати, хто до чого має доступ, використовуючи області OAuth і претензії. Твердження можуть вказувати, до яких розділів даних має доступ користувач. Контроль доступу можна зробити простішим і легшим у управлінні, використовуючи стандартну структуру для всіх API.
Відсутність ресурсів і обмеження швидкості
Чорні капелюхи часто використовують напади на відмову в обслуговуванні (DoS) як метод грубої сили, щоб перевантажити сервер і таким чином скоротити час його безвідмовної роботи до нуля. Без обмежень щодо ресурсів, які можна викликати, API є вразливим до виснажливих нападів. «Використовуючи шлюз API або інструмент керування, ви можете встановити обмеження швидкості для API. Має бути включено фільтрування та розбиття на сторінки, а також обмеження відповідей.
Неправильна конфігурація системи безпеки
Різні вказівки щодо конфігурації безпеки є досить вичерпними через значну ймовірність неправильної конфігурації безпеки. Деякі дрібниці можуть поставити під загрозу безпеку вашої платформи. Цілком можливо, що чорні капелюхи з прихованими цілями можуть виявити конфіденційну інформацію, надіслану у відповідь на неправильно сформовані запити, наприклад.
Масове призначення
Те, що кінцева точка не визначена публічно, не означає, що до неї не можуть отримати доступ розробники. Секретний API може бути легко перехоплений і оброблений хакерами. Подивіться на цей базовий приклад, у якому використовується відкритий маркер носія в «приватному» API. З іншого боку, публічна документація може існувати для чогось, що призначено виключно для особистого використання. Розкрита інформація може бути використана чорними капелюхами не тільки для читання, але й для маніпулювання характеристиками об’єктів. Вважайте себе хакером, шукаючи потенційні слабкі місця у своєму захисті. Дозволити лише тим, хто має належні права, доступ до того, що було повернуто. Щоб мінімізувати вразливість, обмежте пакет відповідей API. Респонденти не повинні додавати будь-які посилання, які не є абсолютно необхідними.
Розширений API:
Неналежне управління активами
Окрім підвищення продуктивності розробника, поточні версії та документація важливі для вашої власної безпеки. Готуйтеся до впровадження нових версій і припинення підтримки старих API заздалегідь. Використовуйте новіші API замість того, щоб дозволяти використовувати старі. Специфікацію API можна використовувати як основне джерело істини для документації.
Вприск
Інтерфейси програмного інтерфейсу вразливі до ін’єкцій, як і програми сторонніх розробників. Шкідливий код може бути використаний для видалення даних або викрадення конфіденційної інформації, наприклад паролів і номерів кредитних карток. Найважливіший урок, який слід винести з цього — не залежати від налаштувань за замовчуванням. Ваше керівництво або постачальник шлюзу повинні бути в змозі задовольнити ваші унікальні потреби програми. Повідомлення про помилки не повинні містити конфіденційну інформацію. Щоб запобігти витоку ідентифікаційних даних за межі системи, у маркерах слід використовувати парні псевдоніми. Це гарантує, що жоден клієнт не зможе разом ідентифікувати користувача.
Недостатня реєстрація та моніторинг
Коли атака все ж має місце, командам потрібна добре продумана стратегія реакції. Розробники продовжуватимуть використовувати вразливості, не будучи спійманими, якщо не буде надійної системи реєстрації та моніторингу, що збільшить збитки та погіршить сприйняття компанії громадськістю. Прийміть суворий моніторинг API і стратегію тестування кінцевих точок виробництва. Тестери білого капелюха, які знаходять уразливості на ранній стадії, повинні бути винагороджені схемою винагороди. Шлях журналу можна покращити, включивши дані користувача в транзакції API. Переконайтеся, що всі рівні вашої архітектури API перевіряються за допомогою даних Access Token.
Висновок
Архітектори платформ можуть оснастити свої системи так, щоб вони були на крок попереду зловмисників, дотримуючись встановлених критеріїв уразливості. Оскільки API можуть забезпечувати доступ до інформації, що дозволяє ідентифікувати особу (PII), підтримка безпеки таких служб має вирішальне значення як для стабільності компанії, так і для дотримання законодавства, наприклад GDPR. Ніколи не надсилайте маркери OAuth безпосередньо через API без використання шлюзу API та підходу Phantom Token.
Розширений API:
