Вебийн аюулгүй байдал цуврал 1/n - Misconfigured CORS & CSRF attack

CORS буюу Cross-Origin Resource Sharing-ыг буруу тохируулсанаар ямар асуудал үүсдэг вэ гэдгийг тайлбарлахын өмнө CORS болон SOP гэж юу вэ гэдгийг ойлгоцгооё.

Бидний одоогийн ашиглаж байгаа ихэнх веб хөтчүүд default-аар SOP /Same-Origin Policy/-ыг мөрдүүлдэг. SOP нь энгийнээр: та веб хөтчөөсөө https://hello.mn гэсэн вебрүү хандан өөрийн эрхээрээ нэвтрэн үйлчилгээ авч байхад өөр нэг tab дээр орсон байгаа http://goodbye.mn сайт дэх javascript код hello.mn-рүү хандалт хийх, ирсэн өгөгдөлрүү хандах боломжгүй байхаар зохицуулдаг дүрэм гэсэн үг юм. Тэгэхээр веб хөтөч нь SOP-ын дүрмийн дагуу протокол /https or http/, домайн, порт гэсэн 3 зүйл бүгд ижил байгаа эсэхийг шалгаад ижил бол resource /image, video, script, data/-руу хандахыг зөвшөөрдөг, үгүй бол блоклодог байхнээ.

Гэтэл орчин үеийн вебүүдийн шаардлага нэмэгдэж https://hello.mn сайтад зочилсны дараа өөрийн эрхээрээ нэвтрэхэд https://auth.hello.mn-рүү хандалт хийн хэрэглэгчээ танидаг, https://api.hello.mn-рүү хандалт хийн өгөгдлөө авах, боловсруулах шаардлагууд үүссэн бөгөөд SOP-ын ижил домайнтай байх гэдэг default дүрмийг зөрчих шаардлага үүсэхэд CORS-ыг ашиглах болсон.

CORS нь хэрхэн ажилладаг вэ гэвэл https://hello.mn дэх скриптээс https://auth.hello.mn-рүү хандалт хийхэд

1. Веб хөтөч HTTP хүсэлтийн header хэсэгт Origin: https://hello.mn утгыг нэмээд явуулна. Энэ нь auth.hello.mn-руу hello.mn-ээс хандаж байгаа шүү гэдэг утгыг илтгэнэ.
2. Харин сервер талд Origin толгойн утгыг шалгаад манай resource-руу хандах ёстой домайн мөн үү үгүй юу гэдгийг шалган баталгаажууулаад зөвшөөрсөн тохиолдолд HTTP response-ын header хэсэгт Access-Control-Allow-Origin: https://hello.mn гэж явуулна. Энэ нь api.hello.mn-рүү хандалт хийгээд ирсэн response-ыг нь hello.mn дэх скриптээс унших эрхийг нь олгож байгаа гэж ойлгож болно.

Дээрх жишээний `Access-Control-Allow-Credentials: true` нь hello.mn буюу Access-Control-Allow-Origin-аар дамжуулан зөвшөөрөл өгсөн домайнд веб хөтөч дээр хадгалагдаж байгаа auth.hello.mn домайнд харгалзах Cookie-г ашиглах зөвшөөрлийг олгож байгаа гэсэн үг юм.

За тэгэхээр CORS-ыг буруу тохируулснаар ямар асуудлууд үүсэж болохыг NodeJS-ын жишээн дээр авч үзье. Зарим хөгжүүлэгчид CORS-ын ач холбогдлыг нарийн ойлгоогүйгээсээ болоод browser талд алдаа гарч HTTP request илгээгдэхгүй үед CORS-ын Origin-ыг '*' буюу wildcard-аар нь тохируулчихдаг.

Дээрх 3 жишээтэй төстэй байдлаар код бичигсэн бол https://hello.mn дэх javascript-ээс https://auth.hello.mn-руу HTTP хүсэлт илгээхэд HTTP Response header-ын утга бүгд дараах байдалтай байна.

Ингэснээр таны вебийн resource-руу дурын домайнаас хандалт хийх боломжтой болгож байгаа бөгөөд энэ сул талыг ашиглан CSRF /Cross Site Request Forgery/ халдлага хийн нууц мэдээлэл хулгайлах боломжтой. CSRF халдлага нь халдагч этгээд хэрэглэгчийг хууран өөрийн бэлдсэн хортой скрипт бүхий вебрүү хандуулж хэрэглэгчийн browser дээрх зэргэлдээ вебээс өгөгдөл хулгайлах, имэйл солих, нууц үг өөрчлөх гэх мэт үйлдэл хийлгэж болдог халдлага юм.

Илүү ойлгомжтой болгох үүднээс өөрсдийн жишээн дээрээ авч үзье.

api.hello.mn/user/chatHistory endpoint нь хэрэглэгчийн бичсэн чатын түүхийг харуулдаг бөгөөд вебийн backend хөгжүүлэгч өмнөх жишээ кодон дээр харуулсан шиг эмзэг байдал үүсгэхээр код бичсэн бол

1. Хэрэглэгч hello.mn сайтад өөрийн эрхээрээ нэвтрэн орох үед browser дээр түүний Cookie хадгалагдана. Тухайн cookie-г api.hello.mn, hello.mn домайнд ашиглах боломжтой гэж үзье.
2. Халдагч этгээд hello.mn сайт нь CORS-оо буруу тохируулсан гэдгийг илрүүлсэн учраас онилсон хэрэглэгчийнхээ чатын түүхийг хулгайлахын тулд доорх скриптыг бэлдээд https://attacker.mn/cors.html URL дээр байршуулжээ. XMLHttpRequest сан нь Javascript-ээс HTTP хүсэлт илгээх боломжийг олгодог ба "https://api.hello.mn/user/chatHistory" endpoint-руу GET хүсэлт илгээж байна. Харин 6-р мөрний withCredentials=true нь api.hell.mn-руу хандалт хийхдээ browser дээр хадгалагдаж байгаа api.hello.mn-ны cookie-г хүсэлттэй хамт илгээнэ. Уул нь browser-ын default дүрэм болох Same-Origin Policy-ны дагуу attacker.mn дээрх скрипт api.hello.mn-ны cookie-рүү хандалт хийхийг хориглосон байсан ч хөгжүүлэгч маань insecure код бичсэний улмаас дурын домайнаас *.hello.mn-рүү хандах мөн cookie-г нь ашиглаж боломжийг нь олгочихсоныг санаж байгаа байх.
3. Халдагч этгээд хэрэглэгчийг ямар нэг заль хэрэглэн hello.mn-рүү логин хийсний дараа https://attacker.mn/cors.html URL-руу хандуулна
4. Хэрэглэгчийн browser дээр https://attacker.mn/cors.html хуудас ачаалагдахад хэрэглэгч өөрөө юу ч мэдээгүй байхад нь түүний чатын түүхийг аваад https://attacker.mn/gotChat endpoint-руу POST хүсэлтээр илгээчихэж байгаа юм.

Нэгэнт CORS-ыг буруу тохируулсанаар ямар нөлөөтэй гэдгийг нь ойлгосон учраас нэмэлтээр Express дээрх 2 insecure coding practice-ын талаар авч үзье

1. Origin: true Хэрвээ шууд origin: true утгыг оноовол клэйн талаас ирсэн HTTP header-ын Origin дэх утгыг автоматаар HTTP response дэх Access-Control-Allow-Origin-ны утга болгоод явуулна. Өөрөөр хэлбэл HTTP request-д Origin: https://attacker.mn гэсэн хүсэлт сервер дээр ирсэн бол сервер Access-Control-Allow-Origin: https://attacker.mn болно гэсэн үг. Энэ нь wildcard-аар тохируулсанаас бараг л ялгаагүй.
2. Insufficient regex cors сан нь origin-ыг шалгахдаа regex ашиглах боломжтой ба хэрвээ шалгаж байгаа regex-ээ алдаатай биччихвэл халдагад өртөх боломжтой. Жишээлбэл 6-р мөрний regex-ын цэг /./ нь дурын тэмдэгт гэсэн утгыг илэрхийлдэг учраас халдагч abchello.mn домайныг худалдан авч CSRF халдлага үйлдэх боломжтой юм.

CORS-ыг хэрхэн зөв тохируулах вэ?

1. Хэрвээ танай веб өөрөөсөө гадна зөвхөн нэг домайнтай харьцах шаардлагатай бол тухайн домайныг шууд хатуугаар кодондоо зааж өгч болно.
2. Хэрвээ нэгээс дээш домайнтай харьцдаг бол домайнуудыг array-д whitelist байдлаар хийгээд Origin-ны утгыг тэдгээр whitelist-д байгаа эсэхийг шалгаж болно.
3. Regex бичихдээ зөв, алдаагүй бичих

Нүүр зургийг: https://portswigger.net/cms/images/75/7a/8a2462c12947-article-how-to-be-web-security-researcher.png

Хүсэлт гаргах

Танд тохиромжтой шийдлийг бид санал болгоно.