Ba'zi tizimlar internetdan to'g'ridan-to'g'ri kirib bo'lmaydigan ichki API'larni o'z ichiga oladi. Server-side parameter pollution veb-sayt foydalanuvchi kiritmasini (input) ichki API'ga yuboriladigan server tomonidagi so'rovga yetarli kodlashsiz (encoding) joylashtirganda yuzaga keladi. Bu hujumchi parametrlarni manipulyatsiya qilishi yoki kiritishi (inject) mumkinligini bildiradi — bu esa, masalan, unga quyidagilarga imkon berishi mumkin:
Har qanday foydalanuvchi kiritmasini har qanday turdagi parameter pollution uchun sinashingiz mumkin. Masalan, query parametrlari, forma maydonlari, sarlavhalar (headers) va URL yo'l parametrlari — bularning barchasi zaif bo'lishi mumkin.
Bu zaiflik ba'zan HTTP parameter pollution deb ataladi. Biroq bu atama veb-ilova xavfsizlik devori (WAF) ni chetlab o'tish usuliga nisbatan ham qo'llaniladi. Chalkashlikning oldini olish uchun ushbu mavzuda biz faqat server-side parameter pollution deb ataymiz.
Bundan tashqari, nomi o'xshash bo'lsa-da, bu zaiflik sinfi server-side prototype pollution bilan juda kam umumiylikka ega.
Query string'da server-side parameter pollution'ni sinash uchun kiritmangizga #, & va = kabi query sintaksis belgilarini joylang va ilova qanday javob berishini kuzating.
Foydalanuvchilarni username'i bo'yicha qidirish imkonini beruvchi zaif ilovani ko'rib chiqamiz. Foydalanuvchini qidirganingizda brauzeringiz quyidagi so'rovni yuboradi:
GET /userSearch?name=peter&back=/homeFoydalanuvchi ma'lumotini olish uchun server ichki API'ga quyidagi so'rov bilan murojaat qiladi:
GET /users/search?name=peter&publicProfile=trueServer tomonidagi so'rovni qisqartirishga urinish uchun URL-kodlangan # belgisidan foydalanishingiz mumkin. Javobni izohlashga yordam berish uchun # belgisidan keyin biror satr ham qo'shishingiz mumkin.
Masalan, query string'ni quyidagicha o'zgartirishingiz mumkin:
GET /userSearch?name=peter%23foo&back=/homeFront-end quyidagi URL'ga kirishga urinadi:
GET /users/search?name=peter#foo&publicProfile=true# belgisini URL-kodlash juda muhim. Aks holda front-end ilova uni fragment identifikatori sifatida talqin qiladi va u ichki API'ga uzatilmaydi.
Query qisqartirilgan-qisqartirilmaganligi haqidagi ipuchlari uchun javobni ko'rib chiqing. Masalan, agar javob peter foydalanuvchisini qaytarsa, server tomonidagi query qisqartirilgan bo'lishi mumkin. Agar Invalid name xato xabari qaytsa, ilova foo ni username qismi sifatida qabul qilgan bo'lishi mumkin. Bu server tomonidagi so'rov qisqartirilmagan bo'lishi mumkinligini ko'rsatadi.
Agar server tomonidagi so'rovni qisqartira olsangiz, bu publicProfile maydonining true ga o'rnatilishi shartini olib tashlaydi. Buni ommaga ochiq bo'lmagan foydalanuvchi profillarini qaytarish uchun ekspluatatsiya qilishingiz mumkin.
Server tomonidagi so'rovga ikkinchi parametr qo'shishga urinish uchun URL-kodlangan & belgisidan foydalanishingiz mumkin.
Masalan, query string'ni quyidagicha o'zgartirishingiz mumkin:
GET /userSearch?name=peter%26foo=xyz&back=/homeBu ichki API'ga quyidagi server tomonidagi so'rovni keltirib chiqaradi:
GET /users/search?name=peter&foo=xyz&publicProfile=trueQo'shimcha parametr qanday tahlil qilingani haqidagi ipuchlari uchun javobni ko'rib chiqing. Masalan, agar javob o'zgarmagan bo'lsa, bu parametr muvaffaqiyatli kiritilgan, lekin ilova tomonidan e'tiborsiz qoldirilgan bo'lishi mumkinligini bildiradi.
Yanada to'liqroq manzarani shakllantirish uchun qo'shimcha sinovlar o'tkazishingiz kerak bo'ladi.
Agar query string'ni o'zgartira olsangiz, server tomonidagi so'rovga ikkinchi yaroqli parametr qo'shishga urinishingiz mumkin.
Query string'ga kirita oladigan parametrlarni qanday aniqlashni bilish uchun Yashirin parametrlarni topish bo'limiga qarang.
Masalan, email parametrini aniqlagan bo'lsangiz, uni query string'ga quyidagicha qo'shishingiz mumkin:
GET /userSearch?name=peter%26email=foo&back=/homeBu ichki API'ga quyidagi server tomonidagi so'rovni keltirib chiqaradi:
GET /users/search?name=peter&email=foo&publicProfile=trueQo'shimcha parametr qanday tahlil qilingani haqidagi ipuchlari uchun javobni ko'rib chiqing.
Ilova server-side parameter pollution'ga zaifligini tasdiqlash uchun asl parametrni bekor qilishga (override) urinib ko'rishingiz mumkin. Buni bir xil nomdagi ikkinchi parametrni kiritish orqali amalga oshiring.
Masalan, query string'ni quyidagicha o'zgartirishingiz mumkin:
GET /userSearch?name=peter%26name=carlos&back=/homeBu ichki API'ga quyidagi server tomonidagi so'rovni keltirib chiqaradi:
GET /users/search?name=peter&name=carlos&publicProfile=trueIchki API ikkita name parametrini talqin qiladi. Buning ta'siri ilova ikkinchi parametrni qanday qayta ishlashiga bog'liq. Bu turli veb-texnologiyalarda farq qiladi. Masalan:
carlos bo'yicha foydalanuvchi qidiruviga olib keladi.peter,carlos bo'yicha foydalanuvchi qidiruviga olib keladi, natijada Invalid username xato xabari paydo bo'lishi mumkin.peter bo'yicha foydalanuvchi qidiruviga olib keladi va natija o'zgarmaydi.Agar asl parametrni bekor qila olsangiz, ekspluatatsiya o'tkazishingiz mumkin. Masalan, so'rovga name=administrator qo'shishingiz mumkin. Bu sizga administrator foydalanuvchi sifatida tizimga kirish imkonini berishi mumkin.
RESTful API parametr nomlari va qiymatlarini query string o'rniga URL yo'liga (path) joylashtirishi mumkin. Masalan, quyidagi yo'lni ko'rib chiqamiz:
/api/users/123URL yo'li quyidagicha bo'linishi mumkin:
/api — asosiy (root) API endpoint./users — resursni ifodalaydi, bu holatda users./123 — parametrni ifodalaydi, bu yerda muayyan foydalanuvchi identifikatori.Foydalanuvchi profillarini ularning username'i bo'yicha tahrirlash imkonini beruvchi ilovani ko'rib chiqamiz. So'rovlar quyidagi endpointga yuboriladi:
GET /edit_profile.php?name=peterBu quyidagi server tomonidagi so'rovni keltirib chiqaradi:
GET /api/private/users/peterHujumchi API'dan foydalanish uchun server tomonidagi URL yo'l parametrlarini manipulyatsiya qilishi mumkin. Bu zaiflikni sinash uchun parametrlarni o'zgartirish maqsadida path traversal ketma-ketliklarini qo'shing va ilova qanday javob berishini kuzating.
Siz name parametri qiymati sifatida URL-kodlangan peter/../admin ni yuborishingiz mumkin:
GET /edit_profile.php?name=peter%2f..%2fadminBu quyidagi server tomonidagi so'rovga olib kelishi mumkin:
GET /api/private/users/peter/../adminAgar server tomonidagi mijoz yoki back-end API bu yo'lni normallashtirsa (normalize), u /api/private/users/admin ga yechilishi mumkin.
Hujumchi serverning boshqa tuzilgan (structured) ma'lumot formatlarini — masalan JSON yoki XML — qayta ishlashidagi zaifliklardan foydalanish uchun parametrlarni manipulyatsiya qilishi mumkin. Buni sinash uchun foydalanuvchi kiritmalariga kutilmagan tuzilgan ma'lumotni kiriting va server qanday javob berishini ko'ring.
Foydalanuvchilarga o'z profilini tahrirlash imkonini beruvchi va o'zgarishlarni server tomonidagi API'ga so'rov bilan qo'llaydigan ilovani ko'rib chiqamiz. Ismingizni tahrirlaganingizda brauzeringiz quyidagi so'rovni yuboradi:
POST /myaccount
name=peterBu quyidagi server tomonidagi so'rovni keltirib chiqaradi:
PATCH /users/7312/update
{"name":"peter"}So'rovga access_level parametrini quyidagicha qo'shishga urinishingiz mumkin:
POST /myaccount
name=peter","access_level":"administratorAgar foydalanuvchi kiritmasi yetarli validatsiya yoki sanitatsiyasiz server tomonidagi JSON ma'lumotga qo'shilsa, bu quyidagi server tomonidagi so'rovni keltirib chiqaradi:
PATCH /users/7312/update
{"name":"peter","access_level":"administrator"}Bu peter foydalanuvchisiga administrator kirish huquqi berilishiga olib kelishi mumkin.
Query string'ga kirita oladigan parametrlarni qanday aniqlashni bilish uchun Yashirin parametrlarni topish bo'limiga qarang.
Xuddi shunday, lekin mijoz tomonidagi foydalanuvchi kiritmasi JSON ma'lumotda bo'lgan misolni ko'rib chiqamiz. Ismingizni tahrirlaganingizda brauzeringiz quyidagi so'rovni yuboradi:
POST /myaccount
{"name": "peter"}Bu quyidagi server tomonidagi so'rovni keltirib chiqaradi:
PATCH /users/7312/update
{"name":"peter"}So'rovga access_level parametrini quyidagicha qo'shishga urinishingiz mumkin:
POST /myaccount
{"name": "peter\",\"access_level\":\"administrator"}Agar foydalanuvchi kiritmasi dekodlansa, so'ng yetarli kodlashsiz server tomonidagi JSON ma'lumotga qo'shilsa, bu quyidagi server tomonidagi so'rovni keltirib chiqaradi:
PATCH /users/7312/update
{"name":"peter","access_level":"administrator"}Yana, bu peter foydalanuvchisiga administrator kirish huquqi berilishiga olib kelishi mumkin.
Tuzilgan format injection javoblarda ham yuzaga kelishi mumkin. Masalan, bu foydalanuvchi kiritmasi ma'lumotlar bazasida xavfsiz saqlanib, so'ng back-end API'dan kelgan JSON javobga yetarli kodlashsiz joylashtirilganda sodir bo'lishi mumkin. Odatda javoblardagi tuzilgan format injection'ni so'rovlardagi kabi aniqlash va ekspluatatsiya qilishingiz mumkin.
Quyidagi misol JSON'da, lekin server-side parameter pollution har qanday tuzilgan ma'lumot formatida yuzaga kelishi mumkin. XML uchun misolni XML external entity (XXE) injection mavzusidagi XInclude hujumlari bo'limida ko'ring.
Burp server-side parameter pollution zaifliklarini aniqlashga yordam beradigan avtomatlashtirilgan vositalarni o'z ichiga oladi.
Burp Scanner audit o'tkazayotganda shubhali kiritma transformatsiyalarini (suspicious input transformations) avtomatik aniqlaydi. Bular ilova foydalanuvchi kiritmasini qabul qilib, uni biror tarzda o'zgartirib, so'ng natijani yanada qayta ishlaganda yuzaga keladi. Bu xatti-harakat majburiy ravishda zaiflik hisoblanmaydi, shu sabab yuqorida keltirilgan qo'lda usullar yordamida qo'shimcha sinov o'tkazishingiz kerak bo'ladi. Batafsil ma'lumot uchun Suspicious input transformation muammosi ta'rifiga qarang.
Shuningdek, server tomonidagi injection zaifliklarini aniqlash uchun Backslash Powered Scanner BApp'dan foydalanishingiz mumkin. Skaner kiritmalarni zerikarli (boring), qiziqarli (interesting) yoki zaif (vulnerable) deb tasniflaydi. Qiziqarli kiritmalarni yuqorida keltirilgan qo'lda usullar yordamida tekshirishingiz kerak bo'ladi. Batafsil ma'lumot uchun Backslash Powered Scanning: hunting unknown vulnerability classes oq qog'ozini (whitepaper) ko'ring.
Server-side parameter pollution'ning oldini olish uchun kodlanishi shart bo'lmagan belgilarni aniqlash maqsadida allowlist'dan foydalaning va boshqa barcha foydalanuvchi kiritmasi server tomonidagi so'rovga qo'shilishidan oldin kodlanganiga ishonch hosil qiling. Shuningdek, barcha kiritma kutilgan format va tuzilishga mos kelishini ta'minlashingiz kerak.