SQL injection: kiritilgan matn bazaga buyruq bo'lib tushganda

Bu kursda ko'p marta bitta naqshni ko'rdik: ishonchsiz ma'lumot bajariladigan joyga tozalanmasdan tushadi. XSS'da u brauzerda kodga aylandi. Endi o'sha naqshni ma'lumotlar bazasida ko'ramiz — foydalanuvchi kiritgan matn SQL so'rovining bir qismi bo'lib qo'shilsa, u so'rovni o'zgartira oladi.

SQL injection eng qadimiy zaifliklardan biri, lekin hali ham ishlab turibdi. Uning mag'zini bu saytda allaqachon bir marta ko'rgansiz — SQL injection'ni o'z ko'zingiz bilan ko'ring va yoping maqolasida zaif ilova yozib, uni buzgan edik. Bu dars o'sha bilimni PortSwigger labllarida mustahkamlaydi va uch xil hujum shaklini ko'rsatadi.

Bu darsdan keyin siz SQLi'ni topa olasiz, uni loginni chetlab o'tish, ma'lumot chiqarish va "ko'r" (blind) shakllarida ishga tushira olasiz va nega parametrlangan so'rov yagona to'g'ri yechim ekanini tushunasiz.

Buzilgan taxmin#

SQL injection bitta odatiy qulaylikdan tug'iladi:

"So'rovni satrlarni qo'shib yasayman — kiritilgan qiymatni shunchaki orasiga qo'yaman."

Dasturchi so'rovni shunday yozadi:

query = "SELECT * FROM products WHERE category = '" + category + "'"

Uning tasavvurida category — bitta so'z, masalan Gifts. Lekin category ichida ' belgisi bo'lsa, u satrni yopadi va qolgani SQL kodiga aylanadi. Ma'lumot bilan kod bir satrga aralashib ketgan — va brauzer XSS'da HTMLni ajratolmagani kabi, baza ham bu yerda ma'lumotni koddan ajratolmaydi.

Kiritilgan qiymat — matn emas, so'rovning bir qismi: ma'lumot bo'lib qoladimi yoki buyruqqa aylanadimi, uni yozish usuli hal qiladi.

Atamalar#

Nazariya: ma'lumot va kod bir satrda#

Zaif qolip — satr qo'shish orqali so'rov yasash:

# Zaif: category satrga qo'shiladi, ' belgisi so'rovni ochib yuboradi
def products(request):
    category = request.GET.get("category", "")
    query = f"SELECT * FROM products WHERE category = '{category}' AND released = 1"
    rows = run_sql(query)
    return render(request, "products.html", {"rows": rows})

category ga Gifts' OR 1=1-- yozilsa, so'rov shunga aylanadi:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

OR 1=1 hamma qatorni chiqaradi, -- esa AND released = 1 ni izohga aylantirib "o'chiradi". Yashirin mahsulotlar ham ko'rinadi — chunki sizning matningiz endi so'rovning mantiqini boshqaradi.

Amaliyot#

Bu SQLi'ning eng toza ko'rinishi: sizning matningiz so'rovning mantiqini o'zgartiradi. OR 1=1 shartni doim rost qiladi, -- qolgan filtrni izohga aylantiradi. Server yashirin mahsulotni sizdan yashirdi, lekin so'rovni sizga ochiq qoldirdi.

Bu SQLi'ning eng xavfli oqibatlaridan biri: -- parol tekshiruvini izohga aylantiradi, ya'ni parol umuman tekshirilmaydi. Autentifikatsiyaning o'zi chetlab o'tildi. Bir belgi — ' — butun login mantiqini yiqitdi.

Bu — UNION hujumining tayyorgarligi. UNION bilan boshqa jadvaldan ma'lumot olishdan oldin, ustunlar soni mos kelishi kerak. NULL lar bilan sinab, xato yo'qolgan sonni topasiz. Bu mexanik qadam, lekin usiz keyingisi ishlamaydi.

Mana SQLi nega shunchalik xavfli: so'rov bitta jadval uchun yozilgan, lekin UNION orqali siz butunlay boshqa jadvalni — parollar saqlanadigan jadvalni — o'sha sahifada chiqarasiz. Mahsulot ro'yxati endi foydalanuvchi parollari ro'yxati.

Bu eng nozik shakl: natija umuman ko'rinmaydi. Lekin sahifaning bor yoki yo'q bo'lishi ham axborot — har so'rov bitta "ha/yo'q" savol. "Parolning birinchi harfi 'a' dan kattami?" degan minglab savol bilan, ko'rinmaydigan ma'lumotni harflab tiklaysiz. Ko'rinmaslik himoya emas — bilvosita signal ham signal.

Nima ishlamaydi va nega#

"' belgisini bloklasam yetadi." Denylist doim teshik: kodlangan tirnoq, UNION o'rniga boshqa texnika, raqamli kontekstda tirnoq umuman kerak emas. Belgilarni sanashga urinsangiz, bittasini o'tkazib yuborasiz.

"Xato xabarlarini yashirsam, blind SQLi ishlamaydi." 5-lab: natija ko'rinmasa ham, sahifaning javob berishi yoki bermasligi — bilvosita signal. Yashirish sekinlashtiradi, to'xtatmaydi.

"Kirishni tozalab, xavfli so'zlarni olib tashlayman." SELECT so'zini SELSELECTECT qilib yozsangiz, bittasini olib tashlagach SELECT qoladi. Denylist SQLi'ni hech qachon to'liq yopmaydi.

Endi yopamiz#

SQLi'ning yechimi bitta va u mutlaq: parametrlangan so'rov. Qiymatni so'rov satriga qo'shmang — bazaga alohida bering, u qiymatni hech qachon kod deb o'qimaydi.

# XAVFLI: qiymat satrga qo'shiladi — SQLi shu yerda
query = f"SELECT * FROM products WHERE category = '{category}'"
run_sql(query)

# TO'G'RI: qiymat alohida beriladi, baza uni doim ma'lumot deb oladi
run_sql("SELECT * FROM products WHERE category = %s", [category])

Farq ko'rinmas, lekin tubdan: parametrlangan so'rovda category ichida nima bo'lishidan qat'i nazar — ' OR 1=1-- bo'lsa ham — u bitta matn qiymat bo'lib qoladi, hech qachon SQL kodiga aylanmaydi.

Django ORM buni avtomatik qiladi:

# Django ORM har doim parametrlaydi — SQLi bu yerda deyarli imkonsiz
Product.objects.filter(category=category, released=True)

Nega kirishni tozalash emas. Kirishni tozalash (masalan ' ni olib tashlash) — noto'g'ri qatlam: bir xil qiymat bir kontekstda xavfli, boshqasida to'g'ri (O'Brien familiyasi). Parametrlash muammoni ildizidan yechadi — ma'lumot va kodni ajratadi — tozalash esa har doim yamoq bo'lib qoladi.

Aniq misol: bu saytda grep -rn "\.raw(\|\.extra(\|cursor.execute" apps/ bitta natija beradi — healthz da cursor.execute("SELECT 1"). U qat'iy matn, foydalanuvchi qiymati umuman yo'q. Ya'ni butun ilovada foydalanuvchi ma'lumoti bilan xom SQL yozilgan birorta joy yo'q — hamma so'rov ORM orqali, ORM esa har doim parametrlaydi. SQLi bu yerda dizayn bo'yicha imkonsiz.

Nazorat savollari#

1. SQL injection nega ishlaydi? "Ma'lumot va kod bir satrda" nimani anglatadi?
2. ' OR 1=1-- da har uch qism nima qiladi (', OR 1=1, --)?
3. 2-labda administrator'-- parolni nega tekshirtirmaydi?
4. UNION hujumida nega avval ustunlar sonini topish kerak (3-lab)?
5. Blind SQLi'da natija ko'rinmasa, ma'lumotni qanday chiqarasiz (5-lab)?
6. Parametrlangan so'rov nega SQLi'ni to'xtatadi? Qiymat qayerda "kod bo'lishdan" to'xtaydi?
7. Django ORM SQLi'dan qanday himoya qiladi? Qaysi metodlar bundan mustasno?
8. raw() ni parametrsiz ishlatsangiz nima bo'ladi?
9. Nega "' belgisini bloklash" SQLi'ni yopmaydi?
10. Nega kirishni tozalash emas, parametrlash to'g'ri yechim? Ildiz va yamoq farqini ayting.

Report uchun talablar#

1. Skrinshot: kamida ikkita labda "solved" yoki chiqarilgan ma'lumot (parollar/mahsulotlar) ko'ringan holat.
2. UNION: 3 va 4-labda ustunlar sonini qanday topdingiz va users jadvalini qanday chiqardingiz?
3. Blind: 5-labda ko'rinmaydigan ma'lumotni qaysi "ha/yo'q" savollar bilan tikladingiz? Jarayonni tushuntiring.
4. Tuzatuvchi kod: o'z loyihangizdan (yoki tasavvuriy) satr qo'shib yasalgan so'rov toping. Uni parametrlangan so'rovga yoki ORM'ga o'tkazing. Oldingi va keyingi holatni keltiring.

Keyingi dars: Autentifikatsiya zaifliklari — login sahifasi eng ko'p hujum qilinadigan eshik, va nega "parol to'g'ri bo'lsa kiritamiz" degan mantiq yetarli emas.