ຜົນກະທົບ
APIs ທີ່ຖືກເຄາະຮ້າຍເຮັດໃຫ້ຜູ້ໂຈມຕີສາມາດຂ້າມສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ ແລະໂຕ້ຕອບໂດຍກົງກັບຖານຂໍ້ມູນ ແລະການບໍລິການດ້ານຫຼັງ [S1]. ນີ້ສາມາດນໍາໄປສູ່ການຂູດຂໍ້ມູນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ, ການຄອບຄອງບັນຊີຜ່ານ brute-force, ຫຼືການບໍລິການທີ່ບໍ່ສາມາດໃຊ້ໄດ້ເນື່ອງຈາກຊັບພະຍາກອນ [S3][S5].
ສາເຫດ
ສາເຫດຕົ້ນຕໍແມ່ນການເປີດເຜີຍຂອງເຫດຜົນພາຍໃນຜ່ານຈຸດສິ້ນສຸດທີ່ຂາດການກວດສອບແລະການປົກປ້ອງທີ່ພຽງພໍ [S1]. ຜູ້ພັດທະນາມັກຈະສົມມຸດວ່າຖ້າຄຸນສົມບັດບໍ່ປາກົດຢູ່ໃນ UI, ມັນປອດໄພ, ນໍາໄປສູ່ການຄວບຄຸມການເຂົ້າເຖິງທີ່ແຕກຫັກ [S2] ແລະນະໂຍບາຍ CORS ທີ່ໄດ້ຮັບອະນຸຍາດທີ່ໄວ້ວາງໃຈ [S4] ຫຼາຍເກີນໄປ.
ລາຍການກວດສອບຄວາມປອດໄພ API ທີ່ສໍາຄັນ
- ບັງຄັບໃຊ້ການຄວບຄຸມການເຂົ້າເຖິງຢ່າງເຂັ້ມງວດ: ທຸກໆຈຸດສິ້ນສຸດຕ້ອງກວດສອບວ່າຜູ້ຮ້ອງຂໍມີການອະນຸຍາດທີ່ເຫມາະສົມສໍາລັບຊັບພະຍາກອນສະເພາະທີ່ຖືກເຂົ້າເຖິງ [S2].
- ການຈຳກັດອັດຕາການປະຕິບັດ: ປ້ອງກັນການລ່ວງລະເມີດອັດຕະໂນມັດ ແລະການໂຈມຕີ DoS ໂດຍການຈຳກັດຈຳນວນການຮ້ອງຂໍທີ່ລູກຄ້າສາມາດເຮັດໄດ້ພາຍໃນໄລຍະເວລາສະເພາະ [S3].
- ກຳນົດຄ່າ CORS ຢ່າງຖືກຕ້ອງ: ຫຼີກເວັ້ນການໃຊ້ແຫຼ່ງກຳເນີດຂອງນາມບັດ (
*) ສຳລັບຈຸດສິ້ນສຸດທີ່ຮັບຮອງຄວາມຖືກຕ້ອງ. ກຳນົດແຫຼ່ງທີ່ມາທີ່ອະນຸຍາດຢ່າງຈະແຈ້ງເພື່ອປ້ອງກັນການຮົ່ວໄຫຼຂອງຂໍ້ມູນຂ້າມເວັບໄຊ [S4]. - ການເບິ່ງເຫັນຈຸດສິ້ນສຸດຂອງການກວດສອບ: ສະແກນຫາຈຸດສິ້ນສຸດທີ່ "ເຊື່ອງໄວ້" ຫຼືບໍ່ມີເອກະສານເປັນປະຈຳ ທີ່ອາດຈະເປີດເຜີຍຟັງຊັນທີ່ລະອຽດອ່ອນ [S1].
ວິທີການ FixVibe ທົດສອບສໍາລັບມັນ
FixVibe ຕອນນີ້ກວມເອົາລາຍການກວດສອບນີ້ຜ່ານການກວດສອບສົດຫຼາຍຄັ້ງ. Active-gated probes test auth endpoint rate limiting, CORS, CSRF, SQL injection, auth-flow ຈຸດອ່ອນ, ແລະບັນຫາ API ອື່ນໆທີ່ປະເຊີນກັບການຢັ້ງຢືນເທົ່ານັ້ນ. ການກວດສອບແບບ Passive ກວດເບິ່ງສ່ວນຫົວຄວາມປອດໄພ, ເອກະສານ API ສາທາລະນະແລະການເປີດເຜີຍ OpenAPI, ແລະຄວາມລັບໃນຊຸດລູກຄ້າ. ການສະແກນ Repo ເພີ່ມການທົບທວນຄວາມສ່ຽງລະດັບລະຫັດສໍາລັບ CORS ທີ່ບໍ່ປອດໄພ, ການແຊກແຊງ SQL ດິບ, ຄວາມລັບ JWT ທີ່ອ່ອນແອ, ການໃຊ້ການຖອດລະຫັດສະເພາະ JWT, ຊ່ອງຫວ່າງລາຍເຊັນຂອງ webhook, ແລະບັນຫາການເພິ່ງພາອາໄສ.