Неправильні конфігурації – основний шлях атак на вебдодатки. Незалежно від безпеки коду, некоректно налаштоване середовище виконання може зробити застосунок вразливим. У цей місяць обізнаності з кібербезпеки Invicti підготував добірку з п’яти категорій неправильних налаштувань додатків.
Загалом, неправильні конфігурації застосунку – це будь-який недолік безпеки, напряму спричинений налаштуваннями додатка або його середовища, а не вразливістю в ньому. Наприклад, якщо застосунок не є вразливим у середовищі розробки, але стає таким після впровадження в продакшн, ймовірно, проблема полягає в неправильних конфігураціях безпеки.
1. Вразливі компоненти технологічного стека
Будь-який вебдодаток – це лише зовнішній шар технологічного стека, що сягає операційної системи. В залежності від його сучасності й архітектури, до вебтехнологічного стека можуть входити вебсервер, сервер додатків, сервер баз даних, вебфреймворк, динамічні залежності й інші компоненти. Якщо вони не обслуговуються належним чином, відсутність патча або оновлення безпеки може дати зловмисникам можливість експлуатувати вразливу версію продукту і, потенційно, скомпрометувати систему, не чіпаючи сам додаток (наприклад, через виконання віддаленого коду сервером застосунку).
2. Відсутній або недостатній контроль доступу
Багато витоків даних відбуваються не через проникнення зловмисника в систему, а тому, що він виявив щось у відкритому доступі, наприклад бакети хмарного сховища, чутливі файли та забуті API. Забезпечення належного контролю доступу на багатьох рівнях важливе для безпечної розробки додатків. Але він також має бути впроваджений у розгортання й операції, особливо, коли компоненти застосунку стають все більш розподіленими. Наприклад, неправильно налаштований вебсервер може дозволити зловмисникам завантажити вихідний код додатка, викриваючи інтелектуальну власність і спрощуючи пошук вразливостей шляхом прямого аналізу коду.
3. Налаштування за замовчуванням або для розробки
Середовища розробки та продакшну мають дуже різні вимоги. Для першого критично важливо отримувати якнайбільше інформації про помилки, і заходи безпеки часто вимикають (або їх просто ще не існує) для налагодження програми. Тобто багато компонентів за замовчуванням мають менш безпечні, але ґрунтовніші налаштування для спрощення розробки, тому їх блокування повинно бути частиною процесу розгортання. Якщо компоненти належним чином не захищені задля зменшення поверхні атаки й убезпечення даних, вони можуть надавати зловмисникам надлишкову інформацію або викривати ресурси чи акаунти користувачів, які взагалі не мають бути доступні.
4. Відсутні або неправильні HTTP заголовки безпеки
Впровадження HTTP заголовків безпеки є одним із найпростіших способів запобігти цілим класам вебатак, не торкаючись жодного рядка коду додатка. Серед них обов’язковими є заголовки Політики Безпеки Вмісту (CSP) для зменшення вразливості до cross-site scripting і заголовок Суворої Безпеки Передачі HTTP (HSTS) для забезпечення зашифрованого зв’язку і запобігання man-in-the-middle атакам. Їх впровадження це важлива фундаментальна практика, але неправильна конфігурація цих заголовків може стати ризиком: від хибного почуття безпеки, коли правила CSP не виконують свою задачу, до того, що домен стає недоступним через некоректний заголовок HSTS.
5. Надлишкові привілеї процесів
Підвищення привілеїв зазвичай є першою ціллю будь-якого зловмисника, якому вдалося зробити перший крок для компрометації сервера. Аби цьому запобігти, посилення захисту додатка має включати розділення всіх процесів у стеку (якщо це можливо та доречно) для зменшення ризику розширення атаки та надання їм лише мінімальних необхідних для функціонування привілеїв. Наприклад, об’єднаний запуск усіх серверів із повним доступом до файлів є зручним для розробки на локальному комп’ютері, але якщо це робиться в середовищі продакшну, то це створює ризик компрометації всієї системи шляхом однієї успішної ін’єкції команди.
Підвищення обізнаності з основ безпеки додатків
Правильні конфігурації додатка – це фундаментальна частина його безпеки. Застосунок повинен залишати розробку без відомих вразливостей, і потім має бути поміщений у захищене та перевірене середовище виконання. Лише чогось одного недостатньо – потрібно забезпечити та протестувати все.
