Server Side Request Forgery
Особливості цієї вразливості
Експлуатація вимагає від зловмисника знайти кінцеву точку API, яка отримує доступ до URI, наданого клієнтом. Загалом базовий SSRF (коли відповідь повертається зловмиснику) легше використовувати, ніж сліпий SSRF, у якому зловмисник не має зворотного зв’язку про те, чи була атака успішною чи ні.
Поширеність
Сучасні концепції розробки додатків заохочують розробників отримувати доступ до URI, наданих клієнтом. Відсутність або неналежна перевірка таких URI є типовими проблемами. Щоб виявити проблему, знадобляться регулярні запити API та аналіз відповідей. Якщо відповідь не повертається (сліпий SSRF), виявлення вразливості вимагає більше зусиль і творчості.
Впливи
Успішне використання може призвести до перерахування внутрішніх служб (наприклад, сканування портів), розкриття інформації, обхід брандмауерів або інших механізмів безпеки. У деяких випадках це може призвести до DoS або використання сервера як проксі для приховування шкідливих дій.
Як зрозуміти що API вразлива?
Помилки підробки запитів на стороні сервера (SSRF) виникають, коли API отримує віддалений ресурс без перевірки URL-адреси, наданої користувачем. Це дозволяє зловмиснику змусити програму надіслати створений запит до несподіваного пункту призначення, навіть якщо він захищений брандмауером або VPN.
Сучасні концепції розробки додатків роблять SSRF більш поширеним і небезпечнішим.
Більш поширені – такі концепції заохочують розробників отримувати доступ до зовнішнього ресурсу на основі введення користувача: веб-перехоплення, отримання файлів із URL-адрес, настроюваний SSO та попередній перегляд URL-адрес.
Ще небезпечніше – сучасні технології, такі як хмарні провайдери, Kubernetes і Docker, відкривають канали керування та контролю через HTTP, добре відомих шляхах. Ці канали є легкою мішенню для атаки SSRF.
Ризик SSRF не завжди можна повністю усунути. Обираючи механізм захисту, важливо враховувати ризики та потреби бізнесу.
Приклади сценаріїв атак
Сценарій №1
Соціальна мережа дозволяє користувачам завантажувати фотографії профілю. Користувач може вибрати або завантажити файл зображення зі своєї машини, або надати URL-адресу зображення. Буде запущено такий виклик API:
POST /api/profile/upload_picture { "picture_url": "http://example.com/profile_pic.jpg" }
Зловмисник може надіслати шкідливу URL-адресу та розпочати сканування портів у внутрішній мережі за допомогою кінцевої точки API.
{ "picture_url": "localhost:8080" }
За часом відповіді зловмисник може визначити, відкритий порт чи ні.
Сценарій №2
Продукт безпеки генерує логи, коли виявляє аномалії в мережі. Деякі команди вважають за краще переглядати події в ширшій, більш загальній системі моніторингу, такій як SIEM (Інформація про безпеку та керування подіями). Для цього продукт забезпечує інтеграцію з іншими системами за допомогою веб-хуків.
У рамках створення нового вебхука мутація GraphQL надсилається разом із URL-адресою API SIEM.
POST /graphql [ { "variables": {}, "query": "mutation { createNotificationChannel(input: { channelName: \"ch_piney\", notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \"http://www.siem-system.com/create_new_event\", send_test_req: true } ] } }){ channelId } }" } ]
Під час процесу створення API надсилає запит на надану URL-адресу веб-хуку та надає користувачеві відповідь.
Зловмисник може використати цей потік і зробити запит API до конфіденційного ресурсу, наприклад внутрішньої хмарної служби метаданих, яка розкриває облікові дані:
POST /graphql [ { "variables": {}, "query": "mutation { createNotificationChannel(input: { channelName: \"ch_piney\", notificationChannelConfig: { customWebhookChannelConfigs: [ { url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", send_test_req: true } ] } }) { channelId } } } ]
Оскільки програма показує відповідь на запит, зловмисник може переглянути облікові дані хмарного середовища.
Як запобігти
Ізолюйте механізм отримання ресурсів у вашій мережі: зазвичай ці функції спрямовані на отримання віддалених ресурсів, а не внутрішніх.
За можливості використовуйте дозволені списки.
Використовуйте добре перевірений аналізатор URL-адрес, який підтримується, щоб уникнути проблем, спричинених невідповідностями аналізу URL-адрес.
Перевірте та дезінфікуйте всі вхідні дані, надані клієнтом.
Не надсилайте необроблені відповіді клієнтам.