SSRF: serverni o'z ichki tarmog'iga so'rov yuborishga majburlash

Oldingi darslarda hujum foydalanuvchining brauzeriga tegdi. Endi nishonni o'zgartiramiz: serverning o'zi. Ko'p serverlarda tashqi dunyodan ko'rinmaydigan ichki xizmatlar bor — admin panel localhost da, ma'lumotlar bazasi ichki tarmoqda, bulutda esa maxsus metadata manzili kalitlar bilan. Bularga tashqaridan yetib bo'lmaydi.

SSRF shu devorni aylanib o'tadi: agar sayt biror URL'ga o'zi so'rov yuborsa (rasm yuklash, havolani tekshirish, hisobot generatsiya qilish), siz o'sha URL'ni ichki manzilga o'zgartirasiz — va server siz uchun o'sha manzilga boradi. Devor tashqaridan mustahkam, lekin server allaqachon ichkarida.

Bu darsdan keyin siz SSRF'ni topa olasiz, uch xil filtr chetlashini tushunasiz va Django'da tashqi so'rovlarni to'g'ri cheklay olasiz.

Buzilgan taxmin#

SSRF'ning ildizi bitta ishonchli ko'ringan taxminda:

"Server faqat men bergan, ishonchli manzillarga so'rov yuboradi."

Dasturchi funksiyani yozadi — masalan "shu URL'dagi rasmni yukla" — va URL'ni foydalanuvchi berishini o'ylamaydi, yoki o'ylasa ham "kim ham ichki manzil yozardi" deydi. Aslida:

• Server uchun localhost — o'zi, ya'ni tashqaridan yashirin xizmatlar.

• Server ichki tarmoqda (192.168.x.x, 10.x.x.x) — o'sha tarmoqning ichida turibdi.

• Bulutda 169.254.169.254 — metadata xizmati, ko'pincha kalitlar bilan.

Foydalanuvchi bergan URL — matn emas, serverga beriladigan buyruq: qayerga borishni foydalanuvchi hal qiladi, server esa o'z ichki imtiyozlari bilan boradi.

Atamalar#

Nazariya: server ishonchli mijoz#

Zaif qolip odatda "URL'ni oldim, so'rov yubordim" ko'rinishida:

# Zaif: foydalanuvchi bergan URL'ga server to'g'ridan-to'g'ri boradi
import requests


def check_stock(request):
    url = request.POST["stockApi"]  # <-- foydalanuvchidan
    response = requests.get(url)  # <-- server o'zi boradi
    return HttpResponse(response.text)

Foydalanuvchi stockApi ga http://localhost/admin yozsa, server o'z admin paneliga boradi — chunki server uchun localhost o'zi. Tashqi foydalanuvchi hech qachon yeta olmaydigan sahifa endi ochiq.

Tashqi hujumchi ──✗──► localhost/admin   (devor bloklaydi)
Tashqi hujumchi ─────► SAYT ─────► localhost/admin   (server ichkarida ✓)
                       "URL'ni men berdim"

Amaliyot#

Bu eng toza SSRF: filtr yo'q. Server siz bergan URL'ga o'z nomidan boradi, ya'ni o'z admin paneliga. Tashqaridan localhost/admin ga yeta olmaysiz, lekin server allaqachon o'sha mashinada — siz shunchaki uni so'rov yuborishga ko'ndirdingiz.

Server nafaqat o'ziga, balki butun ichki tarmoqqa yeta oladi. Siz uni tarmoqni skanerlash quroliga aylantirasiz — har bir IP'ni sinab, admin panel qayerda ekanini topasiz. Bu — SSRF'ning haqiqiy kuchi: server sizga ichki tarmoqqa "deraza" ochib beradi.

Denylist — sanashga urinish, va sanash doim to'liq emas. localhost ni 127.1, 127.0.0.1 ni 0, 2130706433 (o'nlik shakl), [::1] (IPv6) — bir manzilning o'nlab yozuvi bor. Filtr admin so'zini bloklasa, uni kodlab yuborasiz. Nimani taqiqlashni sanaganingizda, doim bittasini unutasiz.

Allowlist kuchliroq, lekin u ham URL'ni qanday o'qishga bog'liq. URL sintaksisi murakkab: @ belgisi, # fragment, kodlangan belgilar — server URL'ni bir xil, filtr boshqacha o'qishi mumkin. Bu farq — teshik. Yechim URL'ni "tekshirish" emas, uni parse qilib, komponentlarini solishtirishda.

Bu labning saboqi ikki qismli. Birinchi: zaifliklar birlashadi — o'zicha zararsiz open redirect SSRF filtrini teshib o'tadi. Ikkinchi: server yo'naltirishga ergashsa, filtr faqat birinchi manzilni tekshiradi, oxirgisini emas. Ishonchli domenga yuborilgan so'rov ishonchsiz joyga tushib qoladi.

Nima ishlamaydi va nega#

"localhost va 127.0.0.1 ni bloklasam yetadi." 3-lab: bitta manzilning o'nlab yozuvi bor — 127.1, 0, 2130706433, [::1]. Qora ro'yxat hech qachon to'liq emas.

"Faqat o'z domenimni ruxsat etaman." 4-lab: URL'ni tekshirish qiyin — @, #, kodlash server bilan filtrni turlicha o'qitadi. 5-lab: o'z domeningizdagi redirect sizni ichkariga olib kiradi.

"Javob qaytmasa, SSRF xavfsiz." Javob ko'rinmasa ham (blind SSRF), server borgani out-of-band kanal bilan tasdiqlanadi va ichki ta'sir (o'chirish, ishga tushirish) baribir bo'ladi.

Endi yopamiz#

SSRF'ni "URL'ni tekshirish" bilan to'liq yopib bo'lmaydi — 4 va 5-lab buni ko'rsatdi. To'g'ri yechim bir necha qatlam:

1. Allowlist, domen emas — to'liq URL parse qilib. Foydalanuvchi faqat tanlaydi, URL'ni o'zi yozmaydi:

# Zaif: URL foydalanuvchidan, tekshiruv matn darajasida
url = request.POST["stockApi"]
if "localhost" not in url:  # <-- yengil aldanadi
    requests.get(url)

# To'g'riroq: foydalanuvchi ID tanlaydi, URL'ni server yasaydi
supplier = get_object_or_404(Supplier, pk=request.POST["supplier_id"])
requests.get(supplier.stock_url)  # <-- URL ishonchli manbadan

2. Server so'rovlarini tarmoq darajasida cheklang. Ilova ichki manzillarga (127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 169.254.0.0/16) umuman bora olmasin — buni firewall yoki chiquvchi proksida qo'ying, ilova kodiga tayanmang.

3. Yo'naltirishlarga ergashmang yoki har qadamni qayta tekshiring:

# Yo'naltirishni o'chirish: server oxirgi manzilga jimgina o'tib ketmasin
requests.get(url, allow_redirects=False, timeout=5)

Aniq misol: bu sayt tashqariga so'rov yuboradigan ikki joyi bor — GitHub repo sonini olish (github.py) va Telegram'ga e'lon (announce.py). Ikkalasida ham manzil qat'iy — GitHub API va Telegram API'ning o'zgarmas https hosti, foydalanuvchi URL bermaydi (kodda # noqa: S310 (fixed https host) izohi shuni belgilaydi). Ya'ni SSRF uchun asosiy shart — foydalanuvchi boshqaradigan URL — bu yerda umuman yo'q. Eng yaxshi himoya aynan shu: URL'ni foydalanuvchidan olmaslik.

Nazorat savollari#

1. SSRF nima uchun ishlaydi? Server uchun localhost nimani anglatadi?
2. Nega tashqi hujumchi localhost/admin ga yeta olmaydi, server esa yeta oladi?
3. 2-labda serverni nimaga aylantirdingiz? "Ichki tarmoqqa deraza" nima degani?
4. Bitta IP-manzilni necha xil yozish mumkin? Bu denylist'ni nega yiqitadi (3-lab)?
5. Allowlist denylist'dan kuchliroq. Uni nega baribir aldash mumkin (4-lab)?
6. Open redirect o'zicha zararsiz. U SSRF bilan qanday birlashadi (5-lab)?
7. cloud metadata manzili (169.254.169.254) nega SSRF uchun eng xavfli nishon?
8. Nega SSRF'ni faqat ilova kodida tuzatish yetarli emas? Tarmoq darajasi nima beradi?
9. allow_redirects=False nimadan himoya qiladi?
10. Eng ishonchli yechim nima — nega "URL'ni tozalash" emas?

Report uchun talablar#

1. Skrinshot: kamida bitta labda admin panel yoki "solved" ko'ringan holat.
2. Skanerlash: 2-labda ichki manzilni qanday topdingiz? Burp Intruder sozlamangizni tushuntiring.
3. Filtr sindi: 3, 4 yoki 5-labda filtrni qanday aldadingiz? Kamida bittasini o'z so'zingiz bilan yozing.
4. Tuzatuvchi kod: tasavvuriy (yoki o'z loyihangizdan) tashqi URL qabul qiladigan view oling. Uni yuqoridagi uch qatlamdan kamida ikkitasi bilan yoping. Oldingi va keyingi holatni keltiring.

Keyingi dars: SQL injection — foydalanuvchi kiritgan matn bazaga buyruq bo'lib tushganda, va nega parametrlangan so'rov yagona to'g'ri yechim.