Himoyaga kirish

Saytlararo so'rovni soxtalashtirish (CSRF)

Spring saytlararo so'rovni soxtalashtirishdan (CSRF) himoya qilish uchun kompleks vositalarni taqdim etadi. Keyingi bo'limlarda quyidagilarni ko'rib chiqamiz:

• >CSRF hujumi nima?

• CSRF hujumidan himoya qilish

• CSRF bo'yicha tavsiyalar

CSRF hujumi nima?

CSRF hujumi nimani anglatishini tushunish uchun eng yaxshi usul - aniq misolni ko'rib chiqishdir.

Misol qilish uchun, bankingiz saytida foydalanuvchi hisobdan boshqa bank hisob raqamiga pul o'tkazish imkonini beruvchi forma bor deb tasavvur qilaylik. O'tkazma formasi quyidagicha ko'rinishi mumkin:

<form method="post"
	action="/transfer">
<input type="text"
	name="amount"/>
<input type="text"
	name="routingNumber"/>
<input type="text"
	name="account"/>
<input type="submit"
	value="Transfer"/>
</form>

Bunga mos keluvchi HTTP-so'rov quyidagicha ko'rinishi mumkin:

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876

Endi tasavvur qiling, siz bankingiz saytida tizimga kirgansiz va chiqmasdan qaroqchilarning saytiga tashrif buyurdingiz. Qaroqchilarning veb-saytida quyidagi forma mavjud:

<form method="post"
	action="https://bank.example.com/transfer">
<input type="hidden"
	name="amount"
	value="100.00"/>
<input type="hidden"
	name="routingNumber"
	value="evilsRoutingNumber"/>
<input type="hidden"
	name="account"
	value="evilsAccountNumber"/>
<input type="submit"
	value="Win Money!"/>
</form>

Pul yutib olishingiz ehtimoli yoqadi, shuning uchun "yutib olish" tugmasini bosasiz. Natijada siz bilmagan holda 100 dollarni qaroqchilarga yuborasiz. Bu jarayon avtomatlashtirilishi mumkin edi, shunda siz hatto tugmani bosishingizga ham hojat qolmaydi. Yana ko'proq xavf, bu osonlik bilan XSS hujumiga duchor bo'lgan do'stona saytlarga tashrif buyurish orqali sodir bo'lishi mumkin. Bunday hujumlardan foydalanuvchilarni qanday himoya qilishimiz mumkin?

CSRF hujumidan himoya qilish

CSRF hujumlarini amalga oshirishni imkoniyatini keltirib chiqaruvchi sabab shundaki, jabrlanuvchi saytidan kelgan HTTP-so'rov va qaroqchi saytidan kelgan so'rov bir xil. Bu degani, qaroqchi saytlaridan kelgan so'rovlarni rad etib, bank saytlaridan kelgan so'rovlarni qabul qilish imkoni yo'q. CSRF hujumidan himoya qilish uchun, biz so'rovda qaroqchi saytidan uzatilishi mumkin bo'lmagan nimadir borligiga ishonch hosil qilishimiz kerak, shunda biz ikki so'rovni farqlay olamiz.

Spring CSRF hujumidan himoya qilish uchun ikki mexanizmni taqdim etadi:

• Sinxronizator token shabloni

• Cookie faylida SameSite atributini kiritish

Xavfsiz metodlar idempotent bo'lishi kerak

CSRF himoya qilishining har qanday varianti ishlashi uchun, ilova "xavfsiz" HTTP-metodlari idempotent ekanligiga ishonch hosil qilishi kerak. Bu degani, GET, HEAD, OPTIONS va TRACE HTTP-metodlari ilovaning holatini o'zgartirmasligi kerak.

Sinxronizator token shabloni

CSRF hujumidan himoya qilishning eng keng tarqalgan va eng to'liq usuli bu sinxronizator token shablonidan foydalanishdir. Bu yechim shundaki, har bir HTTP-so'rov davomida, bizning seans cookie faylimizdan tashqari, HTTP-so'rovda CSRF token deb nomlangan xavfsiz tasodifiy ishlab chiqarilgan qiymat mavjud bo'lishi talab qilinadi.

HTTP-so'rov uzatilgandan keyin, server kutilgan CSRF tokenni qidirishi va hrakatdagi HTTP-so'rovdagi CSRF token bilan solishtirishi kerak. Agar qiymatlar mos kelmasa, HTTP-so'rov rad etilishi kerak.

Bu jarayonda asosiy nuqta shundaki, haqiqiy CSRF token HTTP-so'rovning brauzer tomonidan avtomatik ravishda qo'shilmaydigan qismida bo'lishi kerak. Masalan, haqiqiy CSRF tokenni HTTP-parametr yoki HTTP-sarlavha ichida kiritish CSRF hujumidan himoya qiladi. Haqiqiy CSRF token cookie fayli ichida talab qilish ishlamaydi, chunki cookie fayllar brauzer tomonidan avtomatik ravishda HTTP-so'rovga qo'shiladi.

Biz kutilgan voqealarni kamroq qat'iy qilib qo'yishimiz va ilova holatini yangilaydigan har bir HTTP-so'rov uchun faqat haqiqiy CSRF token talab qilishimiz mumkin. Buning ishlashi uchun, bizning ilovamiz xavfsiz HTTP-metodlar idempotent ekanligiga ishonch hosil qilishi kerak. Bu foydalanish qolini oshiradi, chunki biz tashqi saytlardan bizning saytimizga havolalar yuborishga ruxsat berishimiz kerak. Shuningdek, biz GET HTTP-metodiga tasodifiy token qo'shishimiz shart emas, chunki bu tokenlarning oshkor etilishiga olib kelishi mumkin.

Keling, sinxronizator token shablonidan foydalanilganda misolimiz qanday o'zgarishini ko'rib chiqaylik. Haqiqiy CSRF token _csrf nomli HTTP-parametrda bo'lishi shart deb tasavvur qilaylik. Bizning ilovamizdagi o'tkazma formasi quyidagicha ko'rinadi:

<form method="post"
	action="/transfer">
<input type="hidden"
	name="_csrf"
	value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>
<input type="text"
	name="amount"/>
<input type="text"
	name="routingNumber"/>
<input type="hidden"
	name="account"/>
<input type="submit"
	value="Transfer"/>
</form>

Endi forma CSRF token qiymati bilan yashirin kirish ma'lumotlariga ega. Tashqi saytlar CSRF tokenni o'qiy olmaydi, chunki bir xil manba siyosati qaroqchilar saytini javobni o'qishiga imkon bermaydi.

Pulni o'tkazishning mos keluvchi HTTP-so'rovi quyidagicha ko'rinadi:

POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

Endi HTTP-so'rovda xavfsiz tasodifiy qiymat bilan _csrf parametri mavjudligini ko'rishingiz mumkin. Qaroqchilar sayti _csrf parametri uchun to'g'ri qiymatni uzata olmaydi (u qaroqchilar saytida aniq tarzda uzatilishi kerak), va o'tkazma server kutilgan CSRF token bilan haqiqiy CSRF tokenni solishtirganda muvaffaqiyatsiz bo'ladi.

SameSite Atributi

CSRF hujumidan himoya qilishning rivojlanayotgan usuli - cookie fayllari uchun SameSite atributini belgilash. Server cookie sozlashda SameSite atributini ko'rsatishi mumkin, shunda cookie tashqi saytlardan kelganda yuborilmasin.

SameSite atributi bilan HTTP-javob sarlavhasi quyidagicha ko'rinishi mumkin:

Set-Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly; SameSite=Lax

SameSite atributining mumkin bo'lgan qiymatlari:

• Strict – bu variant belgilanganida, bir xil saytdan kelgan har qanday so'rov cookie ni o'z ichiga oladi. Aks holda, cookie HTTP-so'rovga kiritilmaydi.

• Lax – agar berilgan cookie bir xil saytdan keltirilsa yoki so'rov yuqori darajadagi navigatsiyadan kelgan bo'lsa, va metod idempotent bo'lsa, cookie yuboriladi. Aks holda, cookie HTTP-so'rovga qo'shilmaydi.

Bizning misolimizni SameSite atributidan foydalangan holda qanday himoya qilishni ko'rib chiqaylik. Bank ilovasi himoya qilish uchun sessiya cookie fayliga SameSite atributini o'rnatishi mumkin.

Bizning sessiya cookie fayliga SameSite atributini o'rnatishda, brauzer bankingiz saytida o'tkaziladigan so'rovlar bilan cookie faylini yuborishni davom ettiradi. Ammo, brauzer qaroqchining veb-saytidan keladigan so'rov bilan cookie faylini yubormaydi. Qaroqchilar saytida o'tkazilgan so'rovning sessiyasi ilova tomonidan aniqlanmaydi, va ilova CSRF hujumidan himoya qilinadi.

CSRF hujumidan himoya qilishda SameSite atributidan foydalanayotganingizda bilishingiz kerak bo'lgan ba'zi muhim ijtirolar mavjud.

SameSite atributini Strict qiymatiga o'rnatish yaxshiroq himoya qiladi, lekin foydalanuvchilarni chalkashtirib yuborishi mumkin. Misol uchun, foydalanuvchi, ijtimoiy tarmoq saytidan bir elektron pochta email.example.orgga kiradi. Foydalanuvchi ijtimoiy tarmoq saytiga kirishni kutadi. Lekin SameSite atributi Strict qiymatiga ega bo'lsa, cookie fayl yuborilmaydi va foydalanuvchi autentifikatsiya qilinmaydi.

Yana bir ko'rinadigan masala shuki, SameSite attributi foydalanuvchilarni himoya qilish uchun, brauzer SameSite atributini qo'llab-quvvatlashi kerak. Hozirgi zamonaviy brauzerlar SameSite atributini qo'llab-quvvatlaydi. Ammo, hali ham ishlayotgan eski brauzerlar, bunday qo'llab-quvvatlashni ta'minlamasligi mumkin.

Shuning uchun odatda SameSite atributidan foydalanish chuqurashyol sifatida tavsiya etiladi, va uni CSRF hujumidan himoya qilish uchun yagona mexanizm sifatida foydalanish tavsiya etilmaydi.

CSRF himoyasi foydalanish holatlari

CSRF himoyasidan qachon foydalanish kerak? Biz CSRF himoyasidan faqat huddi foydalanuvchilar foydalanadigan brauzerlar uchun ishlov bera oladigan har qanday so'rov uchun foydalanishni tavsiya etamiz. Agar siz faqat brauzer bo'lmagan mijozlar uchun xizmat yaratayotgan bo'lsangiz, ehtimol siz CSRF himoyasini o'chirishingiz kerak bo'ladi.

CSRF himoyasi va JSON formati

Ko'p so'raladigan savol: "JSON so'rovlar, javascript orqali amalga oshirilgan bo'lsa, himoya qilish kerakmi?". Qisqa javob: "Bu holatga bog'liq". Ammo, json so'rovlariga ta'sir qiluvchi CSRF eksploytlari mavjud bo'lishi mumkinligi haqida xabarlar mavjud. Misol uchun, qaroqchi quyidagi formadan foydalanib CSRF hujumini amalga oshirishi mumkin:

<form action="https://bank.example.com/transfer" method="post" enctype="text/plain">
	<input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
	<input type="submit"
		value="Win Money!"/>
</form>

Natijada quyidagicha JSON tuzilishi hosil bo'ladi:

{ "amount": 100,
"routingNumber": "evilsRoutingNumber",
"account": "evilsAccountNumber",
"ignore_me": "=test"
}

Agar ilova Content-Type ni tekshirmasa, u bu eksploytga duch kelishi mumkin edi. Spring MVC dasturlarida Content-Type ni tekshirish konfiguratsiyaga bog'liq holda, url manzilining oxirgi qismi .json bilan o'zgartirilsa ham, eksployt ta'sirida qolishi mumkin:

<form action="https://bank.example.com/transfer.json" method="post" enctype="text/plain">
	<input name='{"amount":100,"routingNumber":"evilsRoutingNumber","account":"evilsAccountNumber", "ignore_me":"' value='test"}' type='hidden'>
	<input type="submit"
		value="Win Money!"/>
</form>

Stateless brauzer ilovalari uchun CSRF

Ilovam stateless bo'lsa nima qilishim kerak? Bu faktning o'zi sizning himoyangiz to'liq ekanligini anglatmaydi. Agar foydalanuvchiga veb-brauzerda ko'rish kerak bo'lmasa, bu so'rov hali ham CSRF hujumlariga moyil bo'lishi mumkin.

Misol uchun, JSESSIONID o'rniga autentifikatsiya qilish uchun maxsus cookie ishlatiladigan ilovani ko'rib chiqing. CSRF hujumi amalga oshirilganda, maxsus cookie fayl JSESSIONID cookie fayli kabi avtomatik ravishda so'rov bilan uzatiladi. Bu ilova CSRF hujumlariga moyildir.

Basic autentifikatsiyadan foydalanadigan ilovalar ham CSRF hujumlariga moyil. Bu ilova zaif, chunki brauzer har qanday so'rovni avtomatik ravishda foydalanuvchi nomi va parol bilan birga yuboradi, xuddi oldingi misolimizda JSESSIONID cookie fayli kabi.

CSRF bo'yicha tavsiyalar

CSRF hujumlaridan himoya qilishni amalga oshirishda bir necha o'ziga xos jihatlar mavjud.

Tizimga kirish

Systemga kirish so'rovini soxtalashtirishdan himoya qilish uchun, tizimga kirish HTTP-so'rovi CSRF hujumidan himoyalangan bo'lishi kerak. Tizimga kirish so'rovini soxtalashtirishdan himoya qilish zarur, shunda qaroqchi jabrlanuvchining maxfiy ma'lumotlarini o'qiy olmaydi. Bu hujum quyidagicha amalga oshiriladi:

• Qaroqchi foydalanuvchi CSRF orqali tizimga kiradi va qaroqchi foydalanuvchining hisob ma'lumotlaridan foydalanib muvaffaqiyatli tizimga kiradi. Bu orqali jabrlanuvchi qaroqchi foydalanuvchi sifatida autentifikatsiya qilinadi.

• Qaroqchi foydalanuvchi jabrlanuvchini hiylaga solib, veb-saytiga tashrif buyurishga va maxfiy ma'lumotlarni kiritishga majbur qiladi.

• Ma'lumot qaroqchi foydalanuvchi hisobiga bog'lanadi, so'ngra u tizimga o'z ma'lumotlari bilan kirib, jabrlanuvchining maxfiy ma'lumotlarini ko'rishi mumkin.

Tizimga kirish so'rovlarini CSRF hujumidan himoya qilishda murakkablik qo'shishi mumkin, bu sessiya vaqti tugashida foydalanuvchini ajablantirishi mumkin, natijada so'rov rad etiladi. Foydalanuvchilar to'satdan sessiya kerakligini kutishmaydi, tizimga kirishda vaqtni kutish hamda foydalanuvchilarga noqulaylik tug'dirishi mumkin.

Tizimdan chiqish

Tizimdan chiqish so'rovlari soxtalashtirilishiga yo'l qo'ymaslik uchun, tizimdan chiqish HTTP-so'rovi CSRF hujumidan himoyalangan bo'lishi kerak. Tizimdan chiqish so'rovlarini soxtalashtirishdan himoya qilish, qaroqchiga jabrlanuvchining maxfiy ma'lumotlarini o'qish imkoniyatini beruvchi hujumni oldini olish uchun zarurdir. Ushbu hujum haqida ko'proq ma'lumotni ushbu blogda topishingiz mumkin.

Tizimdan chiqish so'rovlarini CSRF hujumidan himoya qilishda murakkablik qo'shishi mumkin, bu sessiya vaqti tugashiga qaramasdan foydalanuvchilarga xavfsizlikni ta'minlash uchun zarurdir. Sessiya vaqti va foydalanuvchilar uchun tushunarsizlik keltirib chiqarishi mumkin, chunki ular tizimdan chiqishda sessiya kerakligini kutishmaydi.

CSRF va sessiya vaqt tugashi

Eng ko'p kutilgan CSRF token sessiyada saqlanadi. Bu degani, sessiya tugashi bilanoq, server kutilgan CSRF tokenni topolmaydi va HTTP-so'rovni rad etadi. Vaqt tugash bilan bog'liq muammoni hal qilishning bir necha variantlari mavjud, har biri o'z kamchiliklariga ega.

• Vaqt tugashining ta'sirini kamaytirishning eng yaxshi usuli - formani yuborish paytida CSRF tokenni so'rash uchun JavaScript kodidan foydalanish. Keyin forma CSRF token bilan yangilanadi va yuboriladi.

• Boshqa variant - JavaScriptdan foydalanish, bu foydalanuvchiga sessiyasi tugashidan oldin xabar beradi. Foydalanuvchi sessiyani davom ettirish va yangilash uchun tugmani bosishi mumkin.

• Nihoyat, kutilgan CSRF token cookie faylida saqlanishi mumkin. Bu kutilgan CSRF tokenni sessiya tugashidan keyin saqlab qolishni ta'minlaydi.

  Nega kutilgan CSRF token cookie faylida saqlanmasligi kerak degan savol tug'ilishi mumkin. Bu boshqa domen tomonidan sarlavha (masalan, cookie ni belgilash uchun) o'rnatilishi mumkin bo'lgan eksploytlar bilan bog'liqdir. Ruby on Rails ham X-Requested-With sarlavha mavjud bo'lganda CSRF tekshiruvlarini o'tkazmaydi. Ko'proq ma'lumotni webappsec.orgda topishingiz mumkin. Boshqa kamchiligi shundaki, agar token buzilgan bo'lsa, uni haqiqiy deb e'lon qilish imkoniyatini yo'qotasiz.

Multipart (fayllarni yuklash)

Multipart so'rovlarini (fayllarni yuklash) CSRF hujumidan himoya qilish bilan bog'liq muammo tovuq va tuxum masalasidir. CSRF hujumidan himoya qilish uchun biz haqiqiy CSRF tokenni olish uchun HTTP-so'rovning jismini o'qishimiz kerak. Ammo jismini o'qish, demak fayl yuklanadi, bu esa tashqi sayt har qanday faylni yuklash imkoniga ega bo'lishini anglatadi.

Multipart/form-data bilan CSRF himoya qilishning ikki variantlari mavjud. Har bir variant o'z kompromislari bor.

• CSRF tokenni jismining ichiga joylashtirish

• CSRF tokenni URL manziliga joylashtirish

CSRF tokenni jismining ichiga joylashtirish

Birinchi variant - haqiqiy CSRF tokenni so'rov jismining ichiga qo'shish. Agar CSRF token jismining ichiga joylashtirilsa, jismini o'qiladi, lekin autentifikatsiya qilinmasdan oldin. Bu narsani serverda vaqtincha saqlash mumkin qiladi. Ammo, faqat autentifikatsiya qilingan foydalanuvchilar faylni yuklashni amalga oshirishi va ilova tomonidan qayta ishlanishi mumkin. Umuman, bu tavsiya etiladigan usul, chunki vaqtincha fayllarni yuklash aksariyat serverlarga kam ta'sir qiladi.

CSRF tokenni URL manziliga qo'shish

Agar vaqtincha fayllarni yuklash imkonsiz bo'lsa, boshqa alternativ variant - kutilgan CSRF tokenni so'rov parametri sifatida formaning amali o'zgaruvchisiga qo'shish. Bu usulning kamchiligi so'rov parametrlari sizib chiqishi mumkin. Umuman, maxfiy ma'lumotlarni jismining yoki sarlavhalari ichiga joylashtirish maqsadga muvofiqdir, bu esa ularning sizib chiqishini oldini olishga yordam beradi. Qo'shimcha ma'lumotni "RFC 2616: URI da maxfiy ma'lumotlarni kodlash"ning 15.1.3 bo'limida topishingiz mumkin.

HiddenHttpMethodFilter

Ba'zi ilovalarda forma parametri HTTP-metodini o'zgartirish uchun ishlatilishi mumkin. Masalan, quyidagi forma HTTP-metodini delete sifatida, post o'rniga ishlatish uchun ishlatilishi mumkin.

<form action="/process"
	method="post">
	<!-- ... -->
	<input type="hidden"
		name="_method"
		value="delete"/>
</form>

HTTP-metodining o'zgarishi filter orqali amalga oshiriladi. Bu filter Spring Securityni qo'llab-quvvatlash vositalaridan oldin o'rnatilishi kerak. E'tibor bering, o'zgartirish faqat postda sodir bo'ladi, shuning uchun bu odatda haqiqiy muammo tug'dirmaydi. Shu bilan birga, eng yaxshi yondashuv uni Spring Security filtrlari oldidan qo'yishdir.

Xavfsiz HTTP-javob sarlavhalari

Veb-ilovalarning xavfsizligini oshirish uchun foydalanish mumkin bo'lgan ko'plab HTTP-javob sarlavhalari mavjud. Ushbu bo'limda Spring Security tomonidan aniq qo'llab-quvvatlanadigan turli xil HTTP-javob sarlavhalariga bag'ishlangan. Zarur bo'lsa, Spring Security shuningdek, xususiy sarlavhalar bilan foydalanish uchun ham moslashtirilishi mumkin.

Xavfsizlik sarlavhalari bo'yicha standartlar

Spring Security xavfsizlik sarlavhalari uchun HTTP-javoblarning standart to'plamini, xavfsiz parametrlarni ta'minlash uchun, taqdim etadi.

Spring Security quyidagi sarlavhalarni standart tarzda taqdim etadi:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Agar standart parametrlar sizning ehtiyojlaringizni qondirmasa, siz standartlar bo'yicha sarlavhalarni osonlik bilan o'chirishingiz, o'zgartirishingiz yoki qo'shishingiz mumkin. Har bir sarlavha haqida qo'shimcha ma'lumot olish uchun quyidagi bo'limlarga murojaat qiling:

• Cache Control

• Mazmun turi parametrlari

• HTTP Strict Transport Security

• X-Frame-Options Sarlavhasi

• X-XSS-Protection Sarlavhasi

Cache Control

Spring Security xavfsiz kontentni himoya qilish uchun keshlashni avtomatik ravishda o'chiradi.

Agar foydalanuvchi maxfiy ma'lumotlarni ko'rish uchun avtorizatsiya qilinsa va tizimdan chiqqan bo'lsa, biz xakerlarning "Orqaga" tugmasini bosib, maxfiy ma'lumotlarni ko'rishini oldini olishimiz kerak. Avtomatik ravishda quyidagi keshni boshqarish sarlavhalari yuboriladi:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

Himoya qilish uchun avtomatik ravishda qo'shimcha ravishda, Spring Security ushbu sarlavhalarni standard sifatida qo'shadi. Biroq, agar sizning ilovangiz o'z keshni boshqarish sarlavhalarini ta'minlasa, Spring Security o'z sarlavhalarini qo'llamaydi. Bu CSS va JavaScript kabi statik resurslarni keshlash imkonini beradi.

Mazmun turi parametrlari

Tarixan, Internet Explorerning ayrim versiyalari kontentni aniqlash orqali so'rovning mazmun turini taxmin qilishga urinishgan. Bu brauzerlarga foydalanuvchi tajribasini yaxshilash uchun mazmun turini taxmin qilish orqali yordam berdi. Masalan, agar brauzer JavaScript faylini qabul qilsa va mazmuni turini aniqlamasa, u o'zi mazmun turini aniqlab va ishga tushirishi mumkin.

Kontentni aniqlash bilan bog'liq masala shundaki, bu xakerlarga poliglotlardan (masalan, bir necha turdagi kontent sifatida ishlatilishi mumkin bo'lgan fayl) foydalanib, XSS hujumlarini o'tkazishga imkon berdi. Masalan, ba'zi saytlar foydalanuvchilarga saytga qabul qilingan postscript hujjatini yuklab olish va ko'rishga ruxsat berishi mumkin. Xaker postscript hujjatini yaratishi mumkin, bu esa JavaScript fayli sifatida ham qabul qilinishi mumkin bo'lgan hujjatdir va uni XSS hujumini o'tkazishda ishlatishi mumkin.

Spring Security standart bo'yicha kontentni aniqlashni o'chirib qo'yadi va HTTP-javoblar uchun quyidagi sarlavha qo'shadi:

X-Content-Type-Options: nosniff

HTTP Strict Transport Security (HSTS)

Bankingiz veb-saytiga kirganingizda, mybank.example.com yoki mybank.example.com yozasizmi? Agar protokol httpsni o'tkazib yuborsangiz, bu potentsial "ortadagi odam" (man-in-the-middle) hujumlariga moyil qilishi mumkin. Hatto sayt mybank.example.com ga yo'naltirilsa, xaker dastlabki HTTP-so'rovni tutishi va javobni manipulyatsiya qilishi mumkin (masalan, uni mibank.example.com ga yo'naltirib, kirish ma'lumotlarini o'g'irlashi mumkin).

Ko'plab foydalanuvchilar protokol httpsni o'tkazib yuborishadi, shuning uchun HTTP Strict Transport Security (HSTS) protokoli yaratilgan. Mybank.example.com HSTS xost sifatida qo'shilganda, brauzer avtomatik ravishda mybank.example.com ga kirish har qanday so'rovni mybank.example.com sifatida ko'rishi mumkin. Bu "ortadagi odam" hujumini sezilarli darajada kamaytiradi.

Saytni HSTS xost sifatida belgilashning bir usuli esa, brauzerda xostni oldindan yuklashdir. Yana bir usuli - Strict-Transport-Security sarlavhasini javobga qo'shish. Masalan, Spring Security quyidagi sarlavhani avtomatik ravishda qo'shadi, bu brauzerga domenni bir yil (bir yilda taxminan 31536000 soniya) davomida HSTS xost deb ko'rishni ko'rsatadi:

Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload

includeSubDomains majburiy bo'lmagan direktivasi brauzerga subdomenlarni (masalan, secure.mybank.example.com) HSTS domen sifatida ko'rishni ko'rsatadi.

preload majburiy bo'lmagan direktivasi brauzerga domenni oldindan yuklashni ko'rsatadi. HSTSni oldindan yuklash haqida batafsil ma'lumotni hstspreload.org saytida topishingiz mumkin.

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) veb-klientga, ma'lum bir veb-server bilan bog'liq ochiq kalitni, soxtalangan sertifikatlar bilan o'z ichiga olgan "ortadagi odam" (MITM) hujumlaridan himoya qilish uchun ishlatishni belgilaydi. HPKPni to'g'ri ishlatish MITM hujumlaridan qo'shimcha himoya qilish qatlamlarini qo'shishi mumkin. Ammo HPKPni murakkabligi sababli, ko'plab mutaxassislar endi uni ishlatishni tavsiya qilmaydi va Chrome uni qo'llab-quvvatlashni to'xtatdi.

HPKPni ishlatish endi tavsiya etilmasligi haqida qo'shimcha ma'lumotni "Is HTTP Public Key Pinning Dead?" va "I’m giving up on HPKP" maqolalarida o'qishingiz mumkin.

X-Frame-Options Sarlavhasi

Sizning saytingizni freymlanganda qo'shish imkoniyatini berish xavfsizlik nuqtai nazaridan muammo bo'lishi mumkin. Masalan, murakkab CSS-stilizatsiya yordamida foydalanuvchini ular bosishni xohlamagan joyda bosishga aldash mumkin. Masalan, foydalanuvchi o'z internet-bankiga kirganida, boshqa foydalanuvchilarga kirish imkoniyati beradigan tugmani bosishi mumkin. Bu hujum turi clickjacking deb ataladi.

Clickjacking hujumiga qarshi tura olishning bir necha usuli mavjud. Masalan, eski brauzerlarni clickjacking hujumidan himoya qilish uchun frame breaker kodini ishlatish mumkin. U mukammal emas, lekin eski brauzerlar uchun frame breaker kodi - bu eng yaxshi narsadir.

Clickjacking muammosini hal qilishning zamonaviy yondashuvi X-Frame-Options sarlavhasidan foydalanishdan iborat. Spring Security sivellarida, xostni freymlashda ko'rsatish qachonki manba ko'rinishda namoyish etilmasligi uchun quyidagi sarlavha qo'shiladi:

X-Frame-Options: DENY

X-XSS-Protection Sarlavhasi

Ba'zi brauzerlar aks ettirilgan XSS hujumlariga qarshi filtratsiyani qo'llab-quvvatlaydi. Bu ishonchli himoya sifatida qaralmaydi, lekin XSS hujumlariga qarshi yordam beradi.

Filtrlash odatda foydalanishga kiritiladi, shuning uchun qo'shilgan sarlavha odatda faqat uning faolligini ta'minlaydi va brauzerga XSS hujumi aniqlanganda nima qilish kerakligini ko'rsatadi. Masalan, filtrning o'zi muammosiz ishlashini ta'minlash uchun ba'zida mazmunni eng kam agressiv tarzda o'zgartirish mumkin. Ba'zan bu o'zgartirish o'z-o'zidan XSS zaifligi bo'lishi mumkin. Buning o'rniga, mazmunni bloklash, lekin uni tuzatishga urinishdan yaxshiroqdir. Spring Security avtomatik ravishda mazmunni bloklash orqali quyidagi sarlavhani qo'shadi:

X-XSS-Protection: 1; mode=block

Content Security Policy (CSP) Spetsifikatsiyasi

Content Security Policy (CSP) - veb-ilovalari kontent kiritish zaifliklari kabi kontentli zaifliklari, jumladan saytlari o'rtasidagi skriptni ishga tushirishni (XSS) xavfini kamaytirish uchun foydalanishi mumkin bo'lgan mexanizmdir. CSP deklarativ siyosat bo'lib, veb-ilovalar mualliflariga resurslarni yuklash kutilgan manbalarni biladigan va oxir-oqibat foydalanuvchi (foydalanuvchi agenti) bilan almashishni ta'minlaydi.

Veb-ilova CSPni qo'llashni boshlash uchun javobga quyidagi HTTP sarlavhalarini qo'shishi mumkin:

• Content-Security-Policy

• Content-Security-Policy-Report-Only

Bu sarlavhalarning har biri mijoz tomonidan amalga oshirilgan xavfsizlik siyosatini amalga oshirish mexanizmi sifatida foydalaniladi. Xavfsizlik siyosati to'plami, qandaydir resurs ko'rinishini cheklashga javobgar bo'lgan siyosat e'lonlarini o'z ichiga oladi.

Masalan, veb-ilova skriptlarni yuklashni faqat maxsus ishonilgan manbalaridan kutayotganini quyidagi sarlavha javobini qo'shib e'lon qilishi mumkin:

Content-Security-Policy: script-src https://trustedscripts.example.com

Ko'rsatilgan script-src direktivasida e'lon qilingan manbadan boshqa manbadan skript yuklashga urinish foydalanuvchi agenti tomonidan bloklanadi. Shuningdek, agar xavfsizlik siyosatida report-uri direktivasi e'lon qilingan bo'lsa, buzilish haqida foydalanuvchi agenti e'lon qilingan URL manzili orqali xabar beradi.

Masalan, agar veb-ilova e'lon qilingan xavfsizlik siyosatini buzadigan bo'lsa, foydalanuvchi agenti haqida report-uri direktivasida belgilangan URL manziliga yuboriladi:

Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/

Buzilish xabarlari standart JSON tuzilmalari bo'lib, ularni veb-ilova o'z API yoki ochiq ommaviy xavfsizlik xabarlarini olish uchun foydalanishi mumkin, masalan report-uri.com/.

Content-Security-Policy-Report-Only sarlavhasi veb-ilovalar mualliflariga va administratorlariga xavfsizlik siyosatini kuzatish imkonini beradi, lekin uning amalga oshirilishini ta'minli. Bu sarlavhani tajriba va sayt uchun xavfsizlik siyosatini ishlab chiqishda ishlatadi. Agar siyosat samarali deb hisoblansa, u Content-Security-Policy sarlavha maydonining o'rniga qo'llaniladi.

Quyidagi javob sarlavhasi bilan, siyosat veb-saytda ikki manba manzilidan skriptlarni yuklashga ruxsat beradi:

Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/

Agar sayt ushbu siyosatni buzadigan bo'lsa va evil.com saytidan skript yuklashga urinib ko'rsa, foydalanuvchi agenti xabarni report-uri direktivasida belgilangan URL manziliga yuboradi, lekin buzadigan resurs yuklanishiga ruxsat beriladi.

Content Security Policy spetsifikatsiyasini veb-ilovaga qo'llash ko'pincha shunchalik oson emas. Ma'lumotni xavfsizlik siyosatini ishlab chiqishda qo'shimcha foyda berishi mumkin bo'lgan resurslar quyida keltirilgan.

Content Security Policyga kirish

CSP bo'yicha qo'llanma - Mozilla Developer Network

W3C Tavsiyanoma

Referrer Policy Spetsifikatsiyasi

Referrer Policy - bu veb-ilovalarga foydalanuvchining oldingi sahifasi qayerdaligini aniqlash imkoniyatini beruvchi mexanizmdir.

Spring Security Referrer Policy sarlavhasini ishlatadi va uning turli siyosatlarini qo'llab-quvvatlaydi:

Referrer-Policy: same-origin

Referrer-Policy javob sarlavhasi brauzerga oldingi foydalanuvchi joylashgan manbani xabar qilishni ko'rsatadi.

Feature Policy Spetsifikatsiyasi

Feature Policy - bu veb-razrabotchilarga brauzerda maxsus APIlar va veb-funktsiyalarning ishlashini faollashtirish, deactivatsiya qilish va o'zgartirish imkonini beruvchi mexanizmdir.

Feature-Policy: geolocation 'self'

Feature Policyni ishlatib, razrabotchilar brauzerda saytlar uchun foydalaniladigan maxsus funksiyalarga qo'llaniladigan "siyosatlarni" tanlashlari mumkin. Ushbu siyosatlar saytdagi APIga kirishni cheklaydi yoki maxsus funksiyalar uchun brauzerning ishlash qoidalarini o'zgartiradi.

Permissions Policy Spetsifikatsiyasi

Permissions Policy - bu veb-razrabotchilarga brauzerda maxsus APIlar va veb-funktsiyalarning ishlashini faollashtirish, deactivatsiya qilish va o'zgartirish imkonini beruvchi mexanizmdir.

Permissions-Policy: geolocation=(self)

Permissions Policyni ishlatib, razrabotchilar brauzerda saytlar uchun foydalaniladigan maxsus funksiyalarga qo'llaniladigan "siyosatlarni" tanlashlari mumkin. Ushbu siyosatlar saytdagi APIga kirishni cheklaydi yoki maxsus funksiyalar uchun brauzerning ishl