SSRF (підробка запитів на боці сервера) — вразливість, яка дає змогу змусити сервер надсилати запити на адреси зловмисника, зокрема у внутрішні системи, закриті від інтернету.
Як працює SSRF
Багато застосунків завантажують ресурси за URL: будують прев’ю посилань, імпортують зображення, викликають вебхуки чи конвертують сторінки в PDF. Якщо сервер не обмежує, куди може підключатися, зловмисник передає адресу на кшталт http://localhost/admin, внутрішню IP-адресу чи хмарний сервіс метаданих 169.254.169.254. Запит надходить від довіреного сервера, тому міжмережеві екрани його пропускають, а внутрішні сервіси вважають легітимним. Слабкість описано як CWE-918.
Чому це важливо
- Крадіжка хмарних ключів — сервіси метаданих AWS, Azure і Google Cloud можуть повернути тимчасові ключі доступу. Під час зламу Capital One 2019 року SSRF дала змогу отримати такі ключі й викрасти дані понад 100 мільйонів клієнтів.
- Доступ до внутрішніх сервісів — адмінпанелей, баз даних, API Kubernetes та інших систем за периметром.
- Розвиток атаки — у поєднанні з іншими помилками SSRF веде до віддаленого виконання коду; ланцюжок ProxyLogon проти Microsoft Exchange починався саме з SSRF.
2021 року SSRF виокремили в окрему категорію OWASP Top 10. По суті, вразливий сервер стає проксі для зловмисника й різко розширює доступну йому поверхню атаки. На відміну від атаки «людина посередині», SSRF не потребує позиції в мережі — досить вразливої функції.
Як запобігти
- Дозволяти вихідні запити лише до білого списку доменів і протоколів, не покладаючись лише на чорні списки.
- Визначати й перевіряти IP-адресу призначення, блокувати приватні, loopback- і link-local-діапазони, зокрема після перенаправлень.
- Використовувати IMDSv2 в AWS та аналогічні механізми в інших хмарах.
- Виносити компоненти, що завантажують URL, в окремий сегмент зі суворими правилами вихідного трафіку.
Як і інші вразливості вебзастосунків, SSRF допомагає виявити регулярне тестування безпеки.
