ຜົນກະທົບ
ຜູ້ໂຈມຕີສາມາດນຳໃຊ້ສ່ວນທີ່ບໍ່ມີສ່ວນຫົວຄວາມປອດໄພເພື່ອປະຕິບັດ Cross-Site Scripting (XSS), clickjacking, ແລະການໂຈມຕີດ້ວຍເຄື່ອງຈັກໃນກາງ [S1][S3]. ໂດຍບໍ່ມີການປົກປ້ອງເຫຼົ່ານີ້, ຂໍ້ມູນຜູ້ໃຊ້ທີ່ລະອຽດອ່ອນສາມາດຖືກຂັບໄລ່, ແລະຄວາມສົມບູນຂອງແອັບພລິເຄຊັນສາມາດຖືກທໍາລາຍໂດຍສະຄິບທີ່ເປັນອັນຕະລາຍທີ່ຖືກໃສ່ເຂົ້າໄປໃນສະພາບແວດລ້ອມຂອງຕົວທ່ອງເວັບ [S3].
ສາເຫດ
ເຄື່ອງມືພັດທະນາທີ່ຂັບເຄື່ອນໂດຍ AI ມັກຈະຈັດລໍາດັບຄວາມສໍາຄັນຂອງລະຫັດທີ່ເປັນປະໂຫຍດຫຼາຍກວ່າການຕັ້ງຄ່າຄວາມປອດໄພ. ດັ່ງນັ້ນ, ຫຼາຍໆແມ່ແບບ AI ທີ່ສ້າງຂື້ນຈະຍົກເລີກສ່ວນຫົວການຕອບສະຫນອງ HTTP ທີ່ສໍາຄັນທີ່ຕົວທ່ອງເວັບທີ່ທັນສະໄຫມອີງໃສ່ການປ້ອງກັນໃນຄວາມເລິກ [S1]. ຍິ່ງໄປກວ່ານັ້ນ, ການຂາດການປະສົມປະສານຂອງການທົດສອບຄວາມປອດໄພຂອງຄໍາຮ້ອງສະຫມັກແບບເຄື່ອນໄຫວ (DAST) ໃນໄລຍະການພັດທະນາຫມາຍຄວາມວ່າຊ່ອງຫວ່າງການຕັ້ງຄ່າເຫຼົ່ານີ້ບໍ່ຄ່ອຍຈະຖືກກໍານົດກ່ອນທີ່ຈະນໍາໃຊ້ [S2].
ແກ້ໄຂຄອນກີດ
- ນຳໃຊ້ສ່ວນຫົວຄວາມປອດໄພ: ກຳນົດຄ່າເວັບເຊີບເວີ ຫຼືກອບແອັບພລິເຄຊັນໃຫ້ລວມເອົາ
Content-Security-Policy,Strict-Transport-Security,X-Frame-Options, ແລະX-Content-Type-OptionsZXFIXVIBETOKEN4CV. - ການໃຫ້ຄະແນນອັດຕະໂນມັດ: ໃຊ້ເຄື່ອງມືທີ່ໃຫ້ຄະແນນຄວາມປອດໄພໂດຍອີງໃສ່ການມີຫົວ ແລະຄວາມເຂັ້ມແຂງເພື່ອຮັກສາທ່າທາງຄວາມປອດໄພສູງ [S1].
- ການສະແກນແບບຕໍ່ເນື່ອງ: ຮວມຕົວສະແກນຊ່ອງໂຫວ່ແບບອັດຕະໂນມັດເຂົ້າໃນທໍ່ CI/CD ເພື່ອສະໜອງການເບິ່ງເຫັນຢ່າງຕໍ່ເນື່ອງເຂົ້າໄປໃນພື້ນຜິວການໂຈມຕີຂອງແອັບພລິເຄຊັນ [S2].
ວິທີການ FixVibe ທົດສອບສໍາລັບມັນ
FixVibe ກວມເອົາມັນແລ້ວຜ່ານໂມດູນເຄື່ອງສະແກນ headers.security-headers passive. ໃນລະຫວ່າງການສະແກນແບບ passive ປົກກະຕິ, FixVibe ດຶງເອົາເປົ້າໝາຍຄືບຣາວເຊີ ແລະກວດສອບການຕອບສະໜອງ HTML ທີ່ມີຄວາມໝາຍ ແລະການເຊື່ອມຕໍ່ສຳລັບ CSP, HSTS, X-Frame-Options, X-Content-Type-Options, RefererPolicy, Pery-Policy. ໂມດູນຍັງທຸງ CSP ແຫຼ່ງສະຄຣິບທີ່ອ່ອນແອ ແລະຫຼີກເວັ້ນຂໍ້ດີທີ່ບໍ່ຖືກຕ້ອງກ່ຽວກັບ JSON, 204, ການປ່ຽນເສັ້ນທາງ, ແລະການຕອບໂຕ້ຄວາມຜິດພາດທີ່ສ່ວນຫົວຂອງເອກະສານເທົ່ານັ້ນບໍ່ໄດ້ນຳໃຊ້.
