Що таке SSRF і як захистити застосунок
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: SSRF (Server-Side Request Forgery) — це вразливість, яка дає змогу зловмиснику змусити сервер застосунку надіслати запит на непередбачену адресу. Так сервер може звернутися до ресурсів, недоступних безпосередньо з інтернету, наприклад до служб у внутрішній мережі. На відміну від CSRF, де використовується браузер користувача, у випадку SSRF запит надсилає сам сервер.
Як працює SSRF — простий приклад
Уявіть застосунок, у якому можна додати фотографію товару, вставивши адресу зображення. Користувач указує URL, тобто адресу ресурсу, а сервер завантажує файл і зберігає його в каталозі магазину. Це зручна функція, але застосунок має перевіряти, куди він насправді підключається.
Якщо застосунок приймає будь-яку адресу, зловмисник може замість фотографії вказати службу, доступну лише з мережі сервера. Тоді застосунок стає посередником: надсилає запит туди, куди сам зловмисник не міг би дістатися. Якщо застосунок ще й повертає отриманий вміст користувачеві, він може розкрити внутрішні дані.
Це можна порівняти з працівником рецепції, який на прохання будь-кого приносить документи із закритих приміщень. Проблема не в самому перенесенні документів, а в тому, що ніхто не перевіряє, звідки їх дозволено брати й кому можна передавати.
Саме завантаження даних з адреси, указаної користувачем, ще не означає наявності вразливості. SSRF виникає тоді, коли користувач може спрямувати запит за межі дозволених ресурсів, а застосунок не забезпечує дотримання відповідних обмежень.
Де виникає SSRF і які наслідки може мати
SSRF може стосуватися будь-якої функції, яка звертається до іншого ресурсу на основі даних, контрольованих користувачем. Типові приклади — створення попереднього перегляду посилань, імпорт документів, завантаження зображень і створення файлів PDF із вебсторінок. Подібний ризик виникає і з вебхуками — автоматичними сповіщеннями, які надсилаються на вказану адресу.
Наслідки залежать від того, до яких ресурсів має доступ сервер і як застосунок обробляє відповідь. Серед можливих наслідків:
- читання інформації з внутрішніх служб;
- визначення того, які служби доступні в мережі сервера;
- доступ до метаданих хмарного середовища, які іноді містять облікові дані для автентифікації;
- виконання операцій у службі, яка безпідставно довіряє трафіку з внутрішньої мережі.
SSRF не означає автоматичного захоплення всього сервера. Проте небезпека зростає, коли застосунок має широкий доступ до мережі, а внутрішні служби не вимагають автентифікації.
Існує також blind SSRF — варіант, за якого зловмисник не бачить безпосередньо відповіді ресурсу, до якого звернувся сервер. Відсутність відображеного вмісту не усуває вразливості: саме надсилання запиту може спричинити небажану операцію або розкрити інформацію через поведінку застосунку.
SSRF і CSRF — подібні назви, різні механізми
CSRF (Cross-Site Request Forgery) полягає в тому, що браузер користувача змушують надіслати небажаний запит до застосунку. При цьому браузер може автоматично додати дані сеансу, наприклад файл cookie користувача, який увійшов у систему. Зазвичай мета — виконати операцію з правами цього користувача.
У випадку SSRF запит надсилає сервер, а атака використовує його мережевий доступ і можливі права. Наявність жертви, яка увійшла в систему, не є обов’язковою умовою такої атаки, хоча сама вразлива функція може бути доступна лише після входу.
| Ознака | SSRF | CSRF |
|---|---|---|
| Хто надсилає запит? | Сервер застосунку | Браузер користувача |
| Що використовується? | Доступ і права сервера | Сеанс користувача |
| Основний напрям захисту | Контроль адрес призначення з’єднань і доступу до мережі | Перевірка запитів, що змінюють стан, зокрема за допомогою токенів CSRF |
Ці засоби захисту не взаємозамінні. Токен CSRF не розв’язує проблеми сервера, який завантажує дані з недозволених адрес. А фільтрація вихідних з’єднань не замінює захисту сеансу користувача.
Як знизити ризик SSRF
Спершу з’ясуйте, чи справді застосунок має завантажувати дані з будь-якої адреси. Якщо інтеграція стосується однієї служби, безпечніше зберігати її адресу в конфігурації, а від користувача приймати лише ідентифікатор ресурсу.
Якщо користувачеві необхідно вказувати адреси, застосуйте кілька рівнів захисту:
- Обмежте дозволені адреси призначення. Якщо функція це дозволяє, використовуйте закритий список довірених хостів, портів і протоколів. Не обмежуйте перевірку адрес пошуком фрагмента тексту.
- Перевіряйте цільові IP-адреси. Враховуйте IPv4 та IPv6 і блокуйте недозволені діапазони, зокрема приватні мережі, локальні адреси та спеціальні точки доступу до метаданих хмарного середовища.
- Контролюйте перенаправлення та DNS. Адреса, яка здається безпечною, може перенаправити до забороненого ресурсу. Перевірка має охоплювати фактичну адресу призначення з’єднання, а не лише початковий URL.
- Обмежте вихідний трафік. Мережеві правила мають унеможливлювати доступ застосунку до непотрібних йому служб. Також установіть обмеження часу очікування та розміру відповіді.
Не передавайте автоматично файли cookie, токени та інші облікові дані для автентифікації на адреси, указані користувачем. У хмарному середовищі також ознайомтеся з офіційною документацією постачальника щодо захисту служби метаданих.
Із чого почати перевірку застосунку
Складіть список функцій, у яких сервер завантажує дані на основі адреси або іншого значення, указаного користувачем. Для кожної визначте дозволені адреси призначення з’єднань, спосіб обробки перенаправлень і те, які дані повертаються користувачеві.
Виконуйте тести лише у власному середовищі або за згодою власника. Для початку виберіть одну функцію, наприклад імпорт зображення, і перевірте, чи діють її обмеження також після перенаправлення, а не лише для адреси, введеної у формі.
Дивіться також: Що означає www?
Читайте також
