ຜົນກະທົບ
ຜູ້ໂຈມຕີສາມາດລັກເອົາຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ຜ່ານການພິສູດຢືນຢັນຈາກຜູ້ໃຊ້ແອັບພລິເຄຊັນທີ່ມີຄວາມສ່ຽງ [S2]. ຖ້າຜູ້ໃຊ້ເຂົ້າເບິ່ງເວັບໄຊທ໌ທີ່ເປັນອັນຕະລາຍໃນຂະນະທີ່ເຂົ້າສູ່ລະບົບແອັບຯທີ່ມີຄວາມສ່ຽງ, ເວັບໄຊທ໌ທີ່ເປັນອັນຕະລາຍສາມາດເຮັດໃຫ້ຄໍາຮ້ອງຂໍຂ້າມຕົ້ນສະບັບໄປຫາ API ຂອງແອັບຯແລະອ່ານຄໍາຕອບ [S1][S2]. ນີ້ສາມາດນໍາໄປສູ່ການລັກຂໍ້ມູນສ່ວນຕົວ, ລວມທັງໂປຣໄຟລ໌ຜູ້ໃຊ້, CSRF tokens, ຫຼືຂໍ້ຄວາມສ່ວນຕົວ [S2].
ສາເຫດ
CORS ແມ່ນກົນໄກທີ່ອີງໃສ່ HTTP-header ທີ່ອະນຸຍາດໃຫ້ເຊີບເວີກໍານົດວ່າຕົ້ນກໍາເນີດ (ໂດເມນ, ໂຄງການ, ຫຼືພອດ) ໄດ້ຖືກອະນຸຍາດໃຫ້ໂຫລດຊັບພະຍາກອນ [S1]. ໂດຍປົກກະຕິແລ້ວ ຊ່ອງໂຫວ່ເກີດຂື້ນເມື່ອນະໂຍບາຍ CORS ຂອງເຊີບເວີມີຄວາມຍືດຫຍຸ່ນເກີນໄປ ຫຼືປະຕິບັດບໍ່ດີ [S2]:
- ສ່ວນຫົວຕົ້ນກຳເນີດທີ່ສະທ້ອນຄືນ: ບາງເຊີບເວີອ່ານສ່ວນຫົວ
Originຈາກການຮ້ອງຂໍຂອງລູກຄ້າ ແລະສະທ້ອນມັນກັບຄືນໃນສ່ວນຫົວຄຳຕອບAccess-Control-Allow-Origin(ACAO) [S2]. ນີ້ປະສິດທິຜົນອະນຸຍາດໃຫ້ເວັບໄຊທ໌ໃດຫນຶ່ງເຂົ້າເຖິງຊັບພະຍາກອນ [S2]. - Wildcards ຕັ້ງຄ່າຜິດ: ໃນຂະນະທີ່ຕົວແທນ
*ອະນຸຍາດໃຫ້ແຫຼ່ງທີ່ມາໃດໆໃນການເຂົ້າເຖິງຊັບພະຍາກອນ, ມັນບໍ່ສາມາດຖືກນໍາໃຊ້ສໍາລັບການຮ້ອງຂໍທີ່ຕ້ອງການຂໍ້ມູນປະຈໍາຕົວ (ເຊັ່ນ cookies ຫຼືຫົວຂໍ້ການອະນຸຍາດ) [S3]. ນັກພັດທະນາມັກຈະພະຍາຍາມຂ້າມສິ່ງນີ້ໂດຍການສ້າງສ່ວນຫົວ ACAO ແບບເຄື່ອນໄຫວໂດຍອີງໃສ່ຄໍາຮ້ອງຂໍ [S2]. - ບັນຊີຂາວ 'null': ບາງແອັບພລິເຄຊັນໃນລາຍຊື່
nullທີ່ເປັນບັນຊີຂາວ, ເຊິ່ງສາມາດຖືກກະຕຸ້ນໂດຍການຮ້ອງຂໍການປ່ຽນເສັ້ນທາງ ຫຼືໄຟລ໌ທ້ອງຖິ່ນ, ອະນຸຍາດໃຫ້ເວັບໄຊທ໌ທີ່ເປັນອັນຕະລາຍສາມາດປອມຕົວເປັນຕົ້ນກໍາເນີດnullເພື່ອເຂົ້າເຖິງ ZXCVFIXVIBETOKEN2ZFIXVIXZ. - ຄວາມຜິດພາດການແຍກວິເຄາະ: ຄວາມຜິດພາດໃນ regex ຫຼືການຈັບຄູ່ສະຕຣິງໃນເວລາທີ່ການກວດສອບສ່ວນຫົວ
Originສາມາດອະນຸຍາດໃຫ້ຜູ້ໂຈມຕີໃຊ້ໂດເມນເຊັ່ນtrusted-domain.com.attacker.com[S2].
ມັນເປັນສິ່ງສໍາຄັນທີ່ຄວນສັງເກດວ່າ CORS ບໍ່ແມ່ນການປົກປ້ອງຕໍ່ Cross-Site Request Forgery (CSRF) [S2].
ແກ້ໄຂຄອນກີດ
- ໃຊ້ບັນຊີຂາວແບບຄົງທີ່: ຫຼີກເວັ້ນການສ້າງສ່ວນຫົວ
Access-Control-Allow-Originແບບເຄື່ອນໄຫວຈາກສ່ວນຫົວOriginຂອງການຮ້ອງຂໍ [S2]. ແທນທີ່ຈະ, ປຽບທຽບຕົ້ນກໍາເນີດຂອງຄໍາຮ້ອງຂໍກັບບັນຊີລາຍຊື່ hardcoded ຂອງໂດເມນທີ່ເຊື່ອຖືໄດ້ [S3]. - ຫຼີກເວັ້ນຕົ້ນກໍາເນີດ 'null': ຢ່າລວມເອົາ
nullໃນບັນຊີຂາວຂອງແຫຼ່ງກໍາເນີດທີ່ອະນຸຍາດ [S2] ຂອງທ່ານ. - ຈໍາກັດຂໍ້ມູນປະຈໍາຕົວ: ພຽງແຕ່ຕັ້ງ
Access-Control-Allow-Credentials: trueຖ້າມີຄວາມຈໍາເປັນຢ່າງແທ້ຈິງສໍາລັບການໂຕ້ຕອບຂ້າມຕົ້ນສະບັບສະເພາະ [S3]. - ໃຊ້ການກວດສອບທີ່ຖືກຕ້ອງ: ຖ້າທ່ານຕ້ອງສະຫນັບສະຫນູນຫຼາຍຕົ້ນກໍາເນີດ, ໃຫ້ແນ່ໃຈວ່າການກວດສອບຄວາມຖືກຕ້ອງສໍາລັບສ່ວນຫົວ
Originແມ່ນແຂງແຮງແລະບໍ່ສາມາດຂ້າມຜ່ານໂດເມນຍ່ອຍຫຼືໂດເມນທີ່ມີລັກສະນະຄ້າຍຄືກັນ [S2].
ວິທີການ FixVibe ທົດສອບສໍາລັບມັນ
FixVibe ຕອນນີ້ລວມເອົາອັນນີ້ເປັນການກວດສອບທີ່ມີການເຄື່ອນໄຫວ. ຫຼັງຈາກການກວດສອບໂດເມນ, active.cors ສົ່ງຄໍາຮ້ອງຂໍ API ທີ່ມີຕົ້ນກໍາເນີດດຽວກັນກັບຕົ້ນກໍາເນີດຂອງການໂຈມຕີແບບສັງເຄາະແລະທົບທວນຄືນຫົວຂໍ້ການຕອບສະຫນອງ CORS. ລາຍງານມັນສະທ້ອນເຖິງຕົ້ນກຳເນີດທີ່ຕົນເອງມັກ, ຕົວແທນ CORS ທີ່ເປັນຕົວຕົນຂອງນາມບັດ, ແລະ CORS ທີ່ເປີດກ້ວາງຢູ່ໃນຈຸດສິ້ນສຸດ API ທີ່ບໍ່ແມ່ນສາທາລະນະໃນຂະນະທີ່ຫຼີກເວັ້ນສຽງລົບກວນຊັບສິນສາທາລະນະ.