Cross Site Request Forgery yoki CSRF - bu zararli sayt, xat, xabar, ilova yoki boshqa biror narsa foydalanuvchi brauzerini o‘sha foydalanuvchi allaqachon autentifikatsiya qilingan boshqa saytda biror amalni bajarishga majbur qilganda sodir bo‘ladigan hujumdir. Bu ko'pincha foydalanuvchi bilmasdan sodir bo'ladi.
CSRF hujumidan zarar ko'rgan saytga bog'liq. Mana bir misol:
- Bob onlayn-banking mijozidagi shaxsiy hisobiga kiradi, ba'zi operatsiyalarni bajaradi, lekin tizimdan chiqmaydi.
- Bob pochtasini tekshiradi va notanish saytga havolani bosadi.
- Noma'lum sayt Bobning bankining onlayn mijoziga Bobning oldingi sessiyasidan saqlangan ma'lumotni Bobning cookie-fayliga o'tkazib, pul o'tkazish uchun so'rov yuboradi.
- Bank sayti Bob CSRF tokenidan foydalanmasdan noma'lum (zararli) saytdan so'rovni qabul qiladi va tarjimani amalga oshiradi.
Bundan ham qiziqroq bo'lib, bu zararli odamga havola bo'lganda
sayt haqiqiy HTML-da bo'lishi mumkin, buning natijasida Bo-
havolani bosishingiz shart emas: ... Agar Bob qurilmasi (masalan, brauzer) render qilsa
Agar ushbu rasm biriktirilgan bo'lsa, u malicious_site.com saytiga so'rov yuboradi va CSRF hujumini amalga oshirishi mumkin.
Endi, CSRF hujumlarining xavfini bilgan holda, siz ularni turli usullar bilan himoya qilishingiz mumkin, ulardan eng mashhuri, ehtimol, ma'lumotlarni o'zgartirishi mumkin bo'lgan har qanday so'rov bilan yuborilishi kerak bo'lgan CSRF tokenidan foydalanishdir (masalan, POST so'rovlari bilan). Veb-ilova (masalan, Bobning onlayn banki) ikki qismdan iborat token yaratishi kerak, ulardan biri Bob oladi, ikkinchisi esa ilovada saqlanadi.
Bob pul o‘tkazish so‘rovini amalga oshirmoqchi bo‘lganida, u token yuborishi kerak bo‘ladi, u bank tomonidan ilovada saqlangan token yordamida haqiqiyligi tekshiriladi.
Endi biz CSRF va CSRF tokenlari haqida bilganimizdan so'ng, Cross Origin Resource Sharing (CORS) aniqroq bo'ladi, garchi men buni yangi maqsadlarni o'rganayotganimda payqagan bo'lsam ham. Umuman olganda, CORS ma'lumotlarga kirishi mumkin bo'lgan resurslar ro'yxatini cheklaydi. Boshqacha qilib aytganda, CORS saytni himoya qilish uchun foydalanilganda, maqsadli dasturga qo'ng'iroq qilish uchun Javascript yozishingiz, javobni o'qishingiz va agar maqsadli sayt sizga ruxsat bersa, boshqa qo'ng'iroq qilishingiz mumkin.
Agar bu chalkash tuyulsa, HackerOne.com/activity.json saytiga qo‘ng‘iroq qilish uchun Javascriptdan foydalanib ko‘ring, javobni o‘qing va ikkinchi qo‘ng‘iroqni amalga oshiring. Quyidagi №3 misolda buning ahamiyati va mumkin bo'lgan vaqtinchalik echimlarni ko'rasiz.
Va nihoyat, shuni ta'kidlash kerakki (buni ta'kidlagan Jobert Abmaga rahmat) CSRF tokeni bo'lmagan har bir so'rov bekor emas. Ba'zi saytlar qo'shimcha tekshiruvlarni amalga oshirishi mumkin, masalan, chiquvchi yon sarlavhani solishtirish (garchi bu xavfsizlik kafolati emas va ma'lum vaqtinchalik echimlar mavjud). Bu so'ralgan manbaga bog'langan sahifaning manzilini aniqlaydigan maydon. Boshqacha qilib aytganda, agar chiquvchi tomon (yo'naltiruvchi)
HTTP so'rovini olgan saytdan boshqa saytdan POST qo'ng'irog'ini qilsa, sayt qo'ng'iroqqa CSRF tokeni yordamida erishilgan effektga erishishga ruxsat bermasligi mumkin. Bundan tashqari, har bir sayt token yaratish yoki belgilashda csrf atamasidan foydalanmaydi. Masalan, Badoo-da bu quyida tavsiflanganidek rt parametridir.
CSRF testi uchun OWASP testini o'qing
ga misollar
1. O'rnatilgan Shopify foydalanuvchilarini eksport qiling
Qiyinchilik: past
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users
Tavsif:
Shopify API yuqorida ko'rsatilgan URL orqali o'rnatilgan foydalanuvchilar ro'yxatini eksport qilish uchun oxirgi nuqtani taqdim etadi. Zaiflik shundaki, sayt ushbu so'nggi nuqtaga so'rov yuborishi va javoban ma'lumot olishi mumkin edi, chunki
Shopify bu so‘rovni tasdiqlash uchun CSRF tokenidan foydalanmadi. Natijada, shubhasiz jabrlanuvchi nomidan ariza yuborish uchun quyidagi HTML koddan foydalanish mumkin.
1 2
9
Ushbu misolda, sahifaga oddiy tashrif buyurganingizda, Javascript jabrlanuvchining brauzerida o'rnatilgan Shopify cookie-fayllaridan foydalangan holda Shopify API-ga GET so'rovini o'z ichiga olgan shaklni yuboradi.
xulosalar
Hujumlaringizni kengaytiring va xatolarni nafaqat veb-saytda, balki APIda ham qidiring. API so'nggi nuqtalari zaifliklar uchun potentsial maydonchadir, shuning uchun buni yodda tutish kerak, ayniqsa API veb-interfeys yaratilgandan keyin ishlab chiqilgan yoki foydalanishga topshirilgan bo'lishi mumkinligini bilsangiz.
2. Shopify-ni Twitter-dan uzish
Qiyinchilik: past
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Shopify Twitter integratsiyasini ta'minlaydi, bu do'kon egalariga o'z mahsulotlari haqida tvit qilish imkonini beradi. Xuddi shunday, xizmat Twitter hisobini bog'langan do'kondan o'chirishga ruxsat beradi va o'chiradi.
Twitter hisobingizni do'kondan uzish uchun URL yuqorida keltirilgan. Soʻrov yuborayotganda Shopify CSRF tokenini tasdiqlamadi, bu tajovuzkorga soxta havola yaratishga imkon berdi, bu havolani bosish shubhasiz doʻkon egasini oʻz doʻkonini Twitterdan uzib qoʻyishiga olib keladi.
Zaiflikni tavsiflab, WeSecureApp zaif so‘rovning quyidagi misolini taqdim etdi, img tegidan foydalanish zaif URL manziliga qo‘ng‘iroq qilishini unutmang:
1 GET / auth / twitter / HTTP ni o'chirish / 1.1 2 Xost: twitter-commerce.shopifyapps.com 3 Foydalanuvchi agenti: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv: 43.0) Gecko / 201001 Firefox / 201001. 5 Qabul qilish: matn / html, ilova / xhtml + xml, ilova / x 6 ml 7 Qabul qilish tili: en-US, en; q = 0,5 8 Qabul qilish-kodlash: gzip, deflate 9 Referer: https: // twitter-commerce .shopifyapps.com / accou 10 nt 11 Cookie: _twitter-commerce_session = REDACTED 12> Ulanish: saqlab qolish
Brauzer uzatilgan URL manzilidan rasm olish uchun GET so‘rovini yuborganligi va CSRF tokeni tasdiqlanmaganligi sababli, maxsus do‘kon endi o‘chirib qo‘yilgan:
1 2
36
xulosalar
Bunday vaziyatda tavsiflangan zaiflikni Burp yoki Firefox Tamper Data kabi proksi-serverdan foydalanishda topish mumkin edi, Shopify-ga yuborilgan so'rovni ko'rib chiqish va bu so'rov GET so'rovi yordamida amalga oshirilganligini ko'rish kifoya edi. Bu halokatli bo'lgani uchun va GET so'rovlari serverga ma'lumotlarni o'zgartirmasligi kerak, buni tekshirishga arziydi.
3. Badoo hisobini to'liq egallab oling
Qiyinchilik: o'rtacha
Url: https://badoo.com
Hisobot havolasi: https://hackerone.com/reports/12770312
Hisobot sanasi: 2016 yil 1 aprel
To'langan mukofot: 852 dollar
Tavsif:
Agar siz Badoo-ga nazar tashlasangiz, URL-ga rt parametrini kiritish orqali ular CSRF dan himoyalanganligini ko'rishingiz mumkin, bu atigi 5 ta belgidan iborat (hech bo'lmaganda yozish vaqtida). Badoo HackerOne’da kampaniya boshlaganida buni payqagan bo‘lsam-da, undan foydalanishning yo‘lini topa olmadim. Biroq, Mahmud Jamol (zombiehelp54) uni topdi.
Rt parametrining ma'nosini anglab etgach, u parametr deyarli barcha json javoblarida qaytarilganligini ham payqadi. Afsuski, bu juda yaxshi natija bermadi, chunki CORS ushbu javoblarni o'qish orqali Badoo-ni hujumlardan himoya qiladi. Mahmud qidiruvda davom etdi.
Ma'lum bo'lishicha, https://eu1.badoo.com/worker-scope/chrome-ser faylida rt qiymati bor. Yaxshisi, bu fayl
tajovuzkor tomonidan o'zboshimchalik bilan o'qilishi mumkin edi va talab qilmadi
jabrlanuvchilar zararli veb-sahifaga tashrif buyurishdan boshqa hech qanday chora ko'rmaydilar. Mana u taqdim etgan kod:
1 2
3Asosan, jabrlanuvchi sahifani yuklaganida, ular Badoo skriptiga so'rov yubordilar, o'sha foydalanuvchi uchun rt parametrini oldilar va keyin jabrlanuvchi nomidan so'rov yubordilar. Bu holatda u Mahmudning akkauntini jabrlanuvchining akkaunti bilan bog‘lagan, bu esa hisobni to‘liq egallab olish imkonini bergan.
xulosalar
Tutun bor joyda olov bor.Mahmud bu yerda rt parametri turli joylarda, aniq json javoblarida qaytarilganini payqadi. Shunday qilib, u bu holatda JS faylida foydalanish mumkin bo'lgan joyda ko'rsatilishi mumkin deb to'g'ri taxmin qildi.
Natijalar
CSRF hujumlari hujumlar uchun yana bir xavfli vektor bo'lib, jabrlanuvchining faol harakatisiz yoki hatto uni ogohlantirmasdan amalga oshirilishi mumkin. CSRF zaif tomonlarini topish biroz zukkolik va yana hamma narsani sinab ko'rishga tayyorlikni talab qiladi.
Odatda, agar sayt POST so'rovini yuborsa, formalar Rails kabi sukut bo'yicha ramkalar bilan himoyalangan, ammo APIlar
alohida hikoya bo'lsin. Masalan, Shopify birinchi navbatda Ruby on Rails asosiga asoslangan bo'lib, sukut bo'yicha barcha shakllar uchun CSRF himoyasini ta'minlaydi (garchi u o'chirib qo'yilishi mumkin). Biroq, bu ramka bilan qurilgan APIlar uchun bu shart emasligi aniq. Nihoyat, serverdagi ma'lumotlarni o'zgartiradigan (masalan, o'chirish harakati) va GET so'rovi bilan amalga oshiriladigan qo'ng'iroqlarga e'tibor bering.
ASP.NET MVC eng shov-shuvli emas, balki veb-ishlab chiquvchilar orasida mashhur stek hisoblanadi. (Anti) xakerlik nuqtai nazaridan, uning standart funksionalligi sizga ba'zi bir asosiy xavfsizlikni ta'minlaydi, ammo xakerlik hiylalarining katta qismidan himoyalanish uchun qo'shimcha himoya zarur. Ushbu maqolada biz ASP.NET dasturchisi (Core, MVC, MVC Razor yoki Web Forms) xavfsizlik haqida bilishi kerak bo'lgan asoslarni ko'rib chiqamiz.
Keling, barcha ma'lum turdagi hujumlardan boshlaylik.
SQL in'ektsiyasi
G'alati, lekin 2017 yilda in'ektsiya va xususan, SQL in'ektsiyasi "OWASP xavfsizlik xavfining eng yaxshi 10 taligi" (Ochiq veb-ilovalar xavfsizligi loyihasi) orasida birinchi o'rinda turadi. Ushbu turdagi hujum foydalanuvchi tomonidan kiritilgan ma'lumotlar server tomonida so'rov parametrlari sifatida ishlatilishini anglatadi.
Klassik SQL in'ektsiyasi misoli Web Forms ilovalari uchun ko'proq xosdir. Parametrlarni so'rov qiymatlari sifatida ishlatish hujumlardan himoya qilishga yordam beradi:
String commandText = "Foydalanuvchilar SET holatini yangilash = 1 WHERE CustomerID = @ID;"; SqlCommand buyrug'i = yangi SqlCommand (commandText, connectionString); buyruq.Parameters ["@ ID"]. Qiymat = mijoz identifikatori;
Agar siz MVC ilovasini ishlab chiqayotgan bo'lsangiz, Entity Framework ba'zi zaifliklarni qamrab oladi. MVC/EF ilovasida ishlaydigan SQL in'ektsiyasini olish qiyin bo'lishi kerak. Biroq, agar siz ExecuteQuery yordamida SQL-ni bajarsangiz yoki yomon yozilgan saqlangan protseduralarni chaqirsangiz, bu mumkin.
ORM SQL in'ektsiyasidan qochsa ham (yuqoridagi misollar bundan mustasno), atributlarni model maydonlari va shuning uchun shakllar olishi mumkin bo'lgan qiymatlar bilan cheklash tavsiya etiladi. Misol uchun, agar maydonga faqat matn kiritish mumkin deb hisoblansa, u holda ^ + $ oralig'ini belgilash uchun Regex-dan foydalaning. Va agar maydonga raqamlar kiritilishi kerak bo'lsa, buni talab sifatida ko'rsating:
Ommaviy string Zip (olish; sozlash;)
Veb-shakllarda siz validatorlar yordamida qiymatlarni cheklashingiz mumkin. Misol:
Chunki .NET 4.5 veb-shakllari Ko'zga tashlanmaydigan tekshirishdan foydalanadi. Bu shakl qiymatini tekshirish uchun qo'shimcha kod yozishingiz shart emasligini anglatadi.
Ma'lumotlarni tekshirish, xususan, saytlararo skript (XSS) deb ataladigan boshqa taniqli zaiflikdan himoya qilishga yordam beradi.
XSS
XSS ning odatiy misoli - sharh yoki mehmonlar kitobi yozuviga skript qo'shish. Bu shunday ko'rinishi mumkin:
Tasavvur qilganingizdek, ushbu misolda saytingizdan cookie-fayllar ba'zi xaker manbalariga parametr sifatida uzatiladi.
Veb-shakllarda siz quyidagi kod bilan xato qilishingiz mumkin:
kechirasiz<%= username %>lekin parol noto'g'ri
Foydalanuvchi nomi o'rniga skript bo'lishi mumkinligi aniq. Skriptning bajarilishini oldini olish uchun siz hech bo'lmaganda uning mazmunini kodlaydigan boshqa ASP.NET ifodasidan foydalanishingiz mumkin.
Agar biz Razor-dan foydalansak, satrlar avtomatik ravishda kodlanadi, bu XSS-ni amalga oshirish imkoniyatini minimallashtiradi - xaker uni faqat qo'pol xatoga yo'l qo'ygan taqdirdagina tortib olishi mumkin, masalan, @ Html.Raw (Model.username) yoki modelingizdagi string o'rniga MvcHtmlString dan foydalaning.
XSS dan qo'shimcha himoya qilish uchun ma'lumotlar C# kodida ham kodlangan. NET Core'da siz System.Text.Encodings.Web nom maydonidagi quyidagi kodlovchilardan foydalanishingiz mumkin: HtmlEncoder, JavaScriptEncoder va UrlEncoder.
Quyidagi misol qatorni qaytaradi
