Підробка запитів на стороні сервера (SSRF) – це атака, яка дозволяє зловмисникам надсилати шкідливі запити до інших систем через вразливий вебсервер. Ця вразливість входить до списку OWASP Top 10 як один із головних ризиків безпеки додатків, що може призвести до розкриття інформації та відкрити шлях до небезпечніших атак (тепер у категорії «Порушений контроль доступу»). Нижче розглянуто механізм роботи SSRF, а також методи виявлення та запобігання таким загрозам у вебдодатках.
Вступ до SSRF
Вебдодатки можуть ініціювати запити між серверами HTTP. Зазвичай вони використовуються для отримання віддалених ресурсів, таких як оновлення програмного забезпечення, або для імпорту метаданих з URL чи іншого додатка. Такі міжсерверні запити загалом не є небезпечними, але за умови неправильної реалізації можуть призвести до появи SSRF.
Вразливість підробки запитів на стороні сервера (SSRF) виникає, коли для формування цільового URL використовуються дані, які може контролювати користувач. Для здійснення атаки зловмисник змінює значення параметра у вразливому вебдодатку, щоб створювати запити або керувати ними з боку сервера.
Зовнішні ресурси, до яких звертається вебдодаток, можуть включати внутрішні сервіси (наприклад, RSS-стрічку з іншого сайту). Для отримання віддаленої стрічки розробники можуть використовувати такий URL:
https://example.com/feed.php?url=externalsite.com/feed/to
Якщо зловмисник зможе змінити параметр url на localhost (loopback-інтерфейс), це дозволить йому переглядати локальні ресурси, розміщені на сервері, що робить їх вразливими для SSRF.
Можливість контролювати пункт призначення запитів на стороні сервера відкриває простір для багатьох шкідливих дій, зокрема:
Зловживання довірчими відносинами між вразливим сервером та іншими системами.
- Обхід білих списків IP.
- Обхід служб автентифікації на основі хостів.
- Читання вебресурсів та інших корисних активів, недоступних для публіки (наприклад, API метаданих у середовищах AWS або trace.axd в ASP.NET).
- Сканування портів у внутрішній мережі, до якої під’єднано сервер.
- Читання файлів із вебсервера.
- Перегляд сторінок стану та взаємодія з API від імені вебсервера.
- Отримання конфіденційної інформації (наприклад, IP-адреси сервера, що працює за зворотним проксі).
SSRF в OWASP Top 10
SSRF є добре відомою вразливістю і регулярно входить до списку десяти головних ризиків безпеки вебдодатків від Open Web Application Security Project. У OWASP Top 10 за 2021 рік вона вперше отримала власну категорію – A10:2021 – підробка запитів на стороні сервера (SSRF), на основі результатів опитування спільноти. Наразі в OWASP Top 10 2025 ця категорія включена в «Порушений контроль доступу».
Оскільки сучасні вебдодатки стають складнішими та більш взаємопов’язаними, отримання URL стало фундаментальною операцією для доставки контенту та функціональності. Зі зростанням кількості запитів на стороні сервера такі вразливості також почастішали. Водночас їхній масштаб та вплив розширюються через поширення хмарних сервісів і складних архітектур додатків, що дозволяє зловмисникам отримувати доступ до вебінфраструктур і джерел даних через скомпрометований сервер.
Типова експлуатація вразливості
У типовому сценарії зловмисник, якому потрібен доступ до внутрішнього сервера, не може використовувати прямі запити, оскільки їх заблокує фаєрвол. Натомість він може використати SSRF, щоб провести атаку через такий алгоритм:
- Нападник надсилає підроблений запит до вразливого вебсервера, який знаходиться в одній внутрішній мережі з цільовим сервером.
- Вразливий вебсервер надсилає контрольований зловмисником запит до цілі в обхід фаєрвола.
- Цільовий сервер відповідає запитуваними даними.
- Залежно від специфіки вразливості, інформація надсилається назад суб’єкту загрози. Найчастіше ці дані доводиться витягувати або виводити іншими способами (out-of-band).
Чому SSRF небезпечна?
Тоді як багато вебвразливостей впливають безпосередньо на цільову систему, SSRF дає змогу використовувати її як посередника для надсилання запитів до третьої системи. Хоча сама атака може не завдавати прямої шкоди, вона надає доступ до внутрішніх систем, які не повинні бути доступними з Інтернету. Є декілька причин чому це небезпечно.
SSRF зловживає довірою між внутрішніми системами
Відповідно до найкращих практик безпеки, поверхня атаки повинна залишатися мінімальною на всіх рівнях. У внутрішніх мережах це зазвичай означає, що доступ до певних портів або дій дозволено лише окремим довіреним машинам. Для підтримання безпеки з можливістю обміну даними та виконання адміністративних завдань сервери часто мають довірчі відносини з обраними пристроями.
На рівні мережі така довіра може означати, що фаєрвол дозволяє доступ до певних портів, лише якщо пристрій знаходиться в тій самій локальній мережі або якщо його IP-адреса є в білому списку. На рівні програмного забезпечення може існувати неявна довіра до локальних машин – для деяких адміністративних завдань не потрібна автентифікація, якщо IP-адреса є 127.0.0.1 або належить до внутрішньої мережі. Це додає певний рівень фізичної безпеки: навіть отримавши дійсні облікові дані, зловмисник не зможе увійти без доступу до локальної мережі.
Завдяки SSRF зловмисник може обійти такі обмеження й звертатися до інших серверів, які довіряють скомпрометованій машині. Це відкриває можливість доступу до внутрішніх даних або взаємодії з портами, недоступними із зовнішньої мережі. Підробляючи серверні запити, зовнішній зловмисник може виконувати шкідливі дії на цільовому сервері, які інакше були б неможливими ззовні.
SSRF дає змогу зловмисникам сканувати локальні або зовнішні мережі
Вразливість дозволяє сканувати локальні або зовнішні мережі, до яких підключений сервер. Хоча пряме вилучення даних зазвичай неможливе, злодії використовують час завантаження сторінки, повідомлення про помилки або банери досліджуваної служби, щоб опосередковано визначити, чи відповідає цільова служба та, чи відкритий перевірений порт.
Приклад: сканування мережі через SSRF вразливість
Припустимо, існує вебсайт із сервісом для завантаження JPEG-зображень із віддаленого джерела з метою визначення їхніх розмірів. Як контроль безпеки сервіс перевіряє наявність у відповіді HTTP-заголовка Content-Type зі значенням image/jpeg. Якщо заголовок відсутній або містить інше значення, сервіс повертає помилку «Будь ласка, надавайте зображення лише у форматі JPEG».
У разі проблеми з підключенням повертається повідомлення «Зображення не знайдено!».
- Аналіз реакції сервісу на різні вхідні дані: Запит https://victim.com/image.php?url=https://example.com/picture.jpg повертає висоту та ширину. Це дійсне зображення з правильним Content-Type.
- Запит HTML-файлу: https://victim.com/image.php?url=https://example.com/index.html Сервіс повертає «Будь ласка, надавайте зображення лише у форматі JPEG», оскільки сторінка має неправильний заголовок (text/html замість image/jpeg).
- Запит із недійсним URL: https://victim.com/image.php?url=https://example.invalid/ Повертається . У разі проблеми з підключенням повертається повідомлення «Зображення не знайдено!», що означає помилку отримання ресурсу.
Знаючи поведінку застосунку, зловмисник може використати її у своїх намірах. Оскільки дійсний URL із відсутнім або неправильним заголовком Content-Type повертає певну помилку, можна надіслати запит із внутрішнім URL:
https://victim.com/image.php?url=127.0.0.1:3306
Отримання помилки . У разі проблеми з підключенням повертається повідомлення «Зображення не знайдено!» означатиме відсутність відповіді від хоста 127.0.0.1 на порту 3306. Проте повідомлення «Будь ласка, надавайте зображення лише у форматі JPEG» свідчитиме про те, що внутрішній сервер відповів, а отже, на цьому порту запущено службу. Таким чином, вразливий вебдодаток можна використовувати для перевірки різних внутрішніх IP і портів, щоб виконати повне сканування. Фактично така SSRF-вразливість дозволяє зловмисникам проводити сканування портів без використання справжнього сканера портів.
SSRF може розкривати файли та внутрішні ресурси на сервері
Коли вміст віддаленого ресурсу безпосередньо рендериться на сторінці, виникає ймовірність того, що зловмисники зможуть прочитати вміст локальних файлів. Наприклад, вебсервіс, який видаляє всі зображення з наданого URL і форматує текст. Для цього він бере тіло відповіді для заданої URL та застосовує до нього текстове форматування.
Якщо такий сервіс дозволяє передавати URL file:// замість звичайних http:// або https://, це можна використати для доступу до локальної файлової системи. Наприклад, URL file:///etc/passwd в UNIX-системі відобразить вміст файлу passwd. Ця ж техніка підходить для перегляду вихідного коду самого вебдодатка.
Потенційні наслідки атак
Як видно з наведених вище прикладів, прямим наслідком експлуатації SSRF майже завжди є розкриття інформації, оскільки зловмисники отримують багато корисних даних про системи та ресурси, які мають бути для них недоступними. Однак непрямі наслідки можуть бути значно серйознішими та дозволяють злодіям:
- Використовувати вразливий сервер як сканер портів та IP-адрес для внутрішніх та зовнішніх систем.
- Взаємодіяти з протоколами на кшталт Gopher (якщо увімкнено) для додаткової розвідки.
- Виявляти IP-адреси серверів за допомогою зворотнього проксі.
- Отримувати віддалене виконання коду.
Оскільки SSRF насамперед є каналом доступу для подальшої розвідки та атак, можливі й багато інших сценаріїв. Вони залежать від того, як вразливий вебдодаток використовує відповіді, отримані від віддаленого ресурсу. У поєднанні з іншими вразливостями та за відповідних умов SSRF може мати серйозні наслідки.
Запобігання SSRF
Для запобігання подібним загрозам настійно рекомендується використовувати білі списки дозволених доменів і протоколів для віддалених ресурсів, що отримуються вебсервером. Загалом варто уникати прямого використання введених користувачем даних в будь-яких функціях, які можуть робити запити від імені сервера. Хоча очищення та фільтрація вводу є гарною практикою, на них не варто покладатися як на єдиний метод захисту – охопити всі можливі сценарії обходу практично неможливо.
Для обходу фільтрації URL можуть використовуватися різноманітні методи:
- Застосування закодованих IP-адрес, які транслюються в локальні (наприклад, 1 або 123.123.123 еквівалентні localhost).
- Використання імен хостів, які перетворюються у внутрішні IP.
- Обхід чорних списків хостів шляхом додавання крапок у кінці імені.
Це лише невелика частина інструментів для обходу, тому головною рекомендацією залишається уникнення вводу неперевірених даних у функціях, що генерують серверні запити.
Виявлення SSRF вразливостей у вебдодатках
Сучасні рішення для динамічного тестування безпеки застосунків (DAST), такі як Invicti (на базі Acunetix та Netsparker), можуть виявляти багато вразливостей підробки запитів на стороні сервера (SSRF) під час роботи застосунку, включаючи такі як out-of-band.
Для більш раннього виявлення в процесі розробки дуже корисними є інструменти статичного тестування безпеки застосунків (SAST), наприклад, від Mend.io.
Invicti та Mend.io мають бездоганну інтеграцію для централізованого управління вразливостями. Якщо ви бажаєте протестувати будь-яке з цих рішень безкоштовно, будь ласка, залиште свої контактні дані у формі нижче.
