ສະຫຼຸບ OWASP API Top 10 ແລະ 6 API Security Best Practices ຈາກ F5
ແອັບພິເຄຊັ່ນໃນປັດຈຸບັນຖືກພັດທະນາໃຫ້ມີຄວາມຊັບຊ້ອນ ແລະ ທັນສະໄໝຫຼາຍຍິ່ງຂຶ້ນ ທັງຍັງສາມາດເຊື່ອມຕໍ່ກັບລະບົບຕ່າງໆ ເພື່ອປະສານການເຮັດວຽກໄດ້ຢ່າງສະດວກ ແລະ ວ່ອງໄວ ສົ່ງຜົນໃຫ້ API ຖືກໃຊ້ງານເປັນຈຳນວນຫຼາຍ ບົດຄວາມນີ້ F5 ໄດ້ອອກມາເປີດເຜີຍເຖິງຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງ API ຕາມ OWAP API Top 10 ແລະ ແນວທາງປະຕິບັດທີ່ດີທີ່ສຸດໃນການປ້ອງກັນ API ຈາກໄພຄຸກຄາມໄຊເບີ.
API ເຕີບໂຕຢ່າງກ້າວກະໂດດ ສ່ຽງຖືກແຮັກເກີໂຈມຕີຫຼາຍຂຶ້ນ
ປະຕິເສດບໍ່ໄດ້ວ່າເກືອບທຸກອົງກອນໃນປັດຈຸບັນຕ່າງພາກັນເຮັດ Digital Transformation, ແອັບພິເຄຊັ່ນຖືກພັດທະນາໃຫ້ມີຄວາມທັນສະໄໝດ້ວຍສະຖາປັດຕະຍາກຳແບບ Microservices ຊຶ່ງແບ່ງ Function ການເຮັດວຽກອອກເປັນຫຼາຍໆສ່ວນ ໃນຂະນະທີ່ Developer ກໍ່ແບ່ງອອກເປັນຫຼາຍທີມຫຼາຍຂຶ້ນ ເພື່ອໃຫ້ອອກຄຸນສົມບັດ ແລະ Function ການໃຊ້ງານໃໝ່ໆ ສູ່ຕະຫຼາດໄດ້ຢ່າງວ່ອງໄວ ລວມເຖິງການປັບໄປໃຊ້ Hybrid ແລະ Multi-cloud ຂອງອົງກອນເຫຼົ່ານີ້ ລ້ວນແຕ່ເຊື່ອມຕໍ່ ແລະ ປະສານການເຮັດວຽກຜ່ານທາງ API ສົ່ງຜົນໃຫ້ລະບົບ API ເຕີບໂຕຢ່າງກ້າວກະໂດດ.
ຈາກການສຳຫຼວດພົບວ່າຫຼາຍກວ່າ 90% ຂອງການຈະລາຈອນເທິງອິນເຕີເນັດ ຖືກຈຳແນກເປັນການຮັບສົ່ງຂໍ້ມູນ API (JSON/SML) ຈຶ່ງເປັນສາເຫດທີ່ເຮັດໃຫ້ອາຊະຍາກອນໄຊເບີເລີ່ມຫາຊ່ອງໂຫວ່ ແລະ ໂຈມຕີລະບົບ API ຫຼາຍຂຶ້ນ ການຂາດຄວາມຮັບຮູ້ ແລະ ການປ້ອງກັນ API ອາດກໍ່ໃຫ້ເກີດເຫດ Data Breach ຫຼື ຂໍ້ມູນຮົ່ວໄຫຼສູ່ສາທາລະນະໄດ້ ຊຶ່ງສາເຫດອັນດັບໜຶ່ງຂອງການເຈາະລະບົບ API ຄື No Authentication ຕາມມາດ້ວຍ Bad Authentication ແລະ Bad Authorization.
ສະຫຼຸບຄວາມສ່ຽງຂອງ API ຈາກ OWASP API Top 10
ໃນປີ 2019 OWASP ໄດ້ເຮັດວິໄຈ ແລະ ສຳຫຼວດຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງ API ຈຳແນກອອກເປັນ 10 ອັນດັບ ດັ່ງນີ້:
API1: Broken Object Level Authorization (BOLA)
ການເປີດໃຫ້ເຂົ້າເຖິງຂໍ້ມູນໂດຍໃຊ້ Object ID ຊຶ່ງສ່ຽງຖືກແຮັກເກີເຂົ້າເຖິງຂໍ້ມູນອື່ນໆ ຜ່ານທາງ Object ID ທີ່ບໍ່ແມ່ນຂອງຕົນເອງໄດ້ ດັ່ງພາບຕົວຢ່າງດ້ານລຸ່ມທີ່ James Lee ສັງເກດພົບວ່າມີການໃຊ້ User ID ເພື່ອເຂົ້າເຖິງຂໍ້ມູນສ່ວນບຸກຄົນ ແທນທີ່ຈະໃຊ້ໝາຍເລກ 23 ເພື່ອເຂົ້າເຖິງຂໍ້ມູນຂອງຕົນເອງ ແຕ່ກັບໃຊ້ໝາຍເລກ 24 ເພື່ອເຂົ້າເຖິງຂໍ້ມູນຂອງບຸກຄົນອື່ນແທນ (ໃນທີ່ນີ້ຄືຂໍ້ມູນຂອງ Claire Lee) ແນະນຳວ່າຄວນມີການເຮັດ Authorization Policy ໃນລະດັບ Object ທັງເທິງໂຄ້ດ (Code) ແລະ ເທິງ API Gateway ລວມເຖິງການກວດຈັບພຶດຕິກຳເພື່ອຮັບມືກັບຄວາມສ່ຽງດັ່ງກ່າວ.
API2: Broken User Authentication
ການໂຈມຕີເພື່ອ bypass ການພິສູດຕົວຕົນ ຊຶ່ງອາດຈະເກີດຈາກການທີ່ບໍ່ມີລະບົບການພິສູດຕົວຕົນ, ລະບົບບໍ່ດີພໍ (Weak JWT) ຫຼື ການໂຈມຕີອື່ນໆ ເຊັ່ນ: Credential Stuffing, ການລັກ API Key ໄປໃຊ້ສວມຮອຍສິດທິ ເປັນຕົ້ນ. ຄວາມສ່ຽງນີ້ປ້ອງກັນໄດ້ໂດຍການໃຊ້ລະບົບພິສູດຕົວຕົນທີ່ດີພຽງພໍ ເຊັ່ນ: OAuth/OIDC.
API3: Excessive Data Exposure
ການເປີດເຜີຍຂໍ້ມູນຫຼາຍເກີນໄປເມື່ອຖືກຮ້ອງຂໍຜ່ານ API ຊຶ່ງສ່ຽງຕໍ່ກັບຂໍ້ມູນຄວາມລັບບາງຢ່າງ ເຊັ່ນ: ໝາຍເລກບັດເຄຣດິດ ອາດຮົ່ວໄຫຼອອກໄປໄດ້ ສາມາດຫຼຸດຄວາມສ່ຽງນີ້ໄດ້ດ້ວຍການອອກແບບໃຫ້ລະບົບ API ຕອບກັບສະເພາະຂໍ້ມູນທີ່ຈຳເປັນ ຫຼື ຫາ solution ທີ່ມາກວດຈັບ ແລະ Mask ຂໍ້ມູນສຳຄັນທີ່ຖືກສົ່ງອອກໄປ.
API4: Lack of Resource & Rate Limiting
ການໂຈມຕີເກີດຂຶ້ນໄດ້ເມື່ອບໍ່ມີການຈຳກັດຈຳນວນເນື້ອຫາ ແລະ ປະເພດຂອງຄຳຮ້ອງຂໍ API ຈາກຜູ້ໃຊ້ ຊຶ່ງຖ້າມີຄຳຮ້ອງຂໍຫຼາຍເກີນໄປ, Payload ໃຫຍ່ເກີນໄປ ຫຼື ມີການດາວໂຫຼດ/ອັບໂຫຼດຟາຍຂະໜາດໃຫຍ່ ອາດສ່ຽງເກີດເງື່ອນໄຂ DoS ໄດ້ ແນະນຳໃຫ້ເຮັດ Rate Limits ເທິງ API Gateway ເພື່ອໃຫ້ໝັ້ນໃຈວ່າລະບົບ API ຈະພ້ອມໃຊ້ງານຕະຫຼອດເວລາ.
API5: Broken Function Level Authorization
ຄວາມສ່ຽງຄ້າຍຄືກັບ API1 ແຕ່ເກີດຈາກການເປີດໃຫ້ແຮັກເກີສາມາດໃຊ້ຟັງຊັ່ນຕ່າງໆໄດ້ໂດຍບໍ່ມີສິດ ດັ່ງພາບຕົວຢ່າງດ້ານລຸ່ມ ກຸ່ມ Admin ມີສິດໃຊ້ຟັງຊັ່ນ (function) GET, POST, DELETE ໃນຂະນະທີ່ກຸ່ມ Users ສາມາດໃຊ້ໄດ້ແຕ່ຟັງຊັ່ນ GET ເພື່ອເບິ່ງຂໍ້ມູນໄດ້ຢ່າງດຽວ ແຕ່ກັບໃຊ້ function ອື່ນໆ ເພື່ອອັບເດດ ຫຼື ລຶບຂໍ້ມູນໄດ້ ເປັນຕົ້ນ ວິທີການປ້ອງກັນກໍ່ຄ້າຍຄືກັບ API1 ຄື ເຮັດ Access Control Policy ທັງເທິງໂຄ້ດ ແລະ ເທິງ API Gateway.
API6: Mass Assignment
ໂດຍທົ່ວໄປແລ້ວ ຈະມີການຈຳກັດພາຣາມິເຕີ (Parameter) ທີ່ໃຊ້ສົ່ງຄຳຮ້ອງຂໍ API ວ່າຕ້ອງເປັນຊຸດພາຣາມິເຕີນີ້ເທົ່ານັ້ນ ແຕ່ຖ້າເປີດໃຊ້ຟັງຊັ່ນ Allow Bypass of Mapping Restriction ຈະເຮັດໃຫ້ສາມາດເພີ່ມພາຣາມິເຕີອື່ນເຂົ້າໄປໃນການສົ່ງຄຳຮ້ອງຂໍໄດ້ ເຖິງວ່າການເຮັດແບບນີ້ຈະຊ່ວຍເພີ່ມຄວາມສະດວກສະບາຍໃຫ້ແກ່ Developer ແຕ່ກໍ່ສ້າງຊ່ອງໂຫວ່ໃຫ້ແຮັກເກີສາມາດສົ່ງພາຣາມິເຕີເຂົ້າມາແກ້ໄຂ ຫຼື ປ່ຽນແປງຂໍ້ມູນພາຍໃນໄດ້ເຊັ່ນກັນ ແນະນຳໃຫ້ສ້າງ OpenAPI Specification (OAS) ຕາມ Business Logic ເທິງ API Endpoints ແລ້ວ import ເຂົ້າ WAAP ຫຼື API Gateway ເພື່ອກວດສອບຄຳຮ້ອງຂໍ API ທີ່ສົ່ງເຂົ້າມາວ່າເປັນໄປຕາມທີ່ກຳນົດໄວ້ ຫຼື ບໍ່.
API7: Security Misconfiguration
ການຕັ້ງຄ່າການຮັກສາຄວາມປອດໄພທີ່ຜິດພາດ ຫຼື ໃຊ້ຄ່າເລີ່ມຕົ້ນຈາກໂຮງງານ ເຊັ່ນ: ລືມປິດພອດ (Port) ເລີ່ມຕົ້ນຈາກໂຮງງານ ໃຊ້ລະຫັດຜ່ານທີ່ຄາດເດົາໄດ້ງ່າຍ ຫຼື ເປີດໃຫ້ໃຊ້ Method ທີ່ບໍ່ເໝາະສົມ ເປັນຕົ້ນ. ການໝັ່ນກວດສອບ API Inventory ແລະ ໃຊ້ເຄື່ອງມືກວດສອບການຕັ້ງຄ່າຕ່າງໆ ເປັນແນວທາງປະຕິບັດທີ່ດີໃນການຫຼຸດຄວາມສ່ຽງນີ້.
API8: Injection
ຄວາມສ່ຽງນີ້ຄ້າຍຄືກັບການໂຈມຕີ Web Apps ທີ່ແຮັກເກີສາມາດສົ່ງ script ບາງຢ່າງເຂົ້າມາປະມວນຜົນໃນລະບົບຫຼັງບ້ານໄດ້ ເຊັ່ນ: GET /api/account?id=”321′ OR 1=1″ ເພື່ອເຮັດ SQL Injection ລັກຂໍ້ມູນຈາກ Database Server ເປັນຕົ້ນ ແນະນຳໃຫ້ເຮັດ SAST & DAST Analysis ເພື່ອຄົ້ນຫາ ແລະ ຈັດການກັບຊ່ອງໂຫວ່ເຫຼົ່ານີ້ເທິງໂຄ້ດ ຫຼື ໃຊ້ລະບົບກວດຈັບ Malicious Payload ຂະນະ Runtime.
API9: Improper Assets Management
ການລືມຍົກເລີກການໃຊ້ API ເວີຊັ່ນທົດສອບ ຫຼື ເວີຊັ່ນເກົ່າທີ່ບໍ່ໄດ້ໃຊ້ງານແລ້ວ (ເອີ້ນວ່າ Shadow API) ເຮັດໃຫ້ແຮັກເກີສາມາດເຂົ້າເຖິງ API ເຫຼົ່ານີ້ທີ່ມີການຮັກສາຄວາມປອດໄພຕ່ຳກວ່າ ແລະ ເຈາະຊ່ອງໂຫວ່ເຂົ້າມາເຮັດອັນຕະລາຍແອັບພິເຄຊັ່ນພາຍໃນໄດ້ ຄວາມສ່ຽງນີ້ຈັດການໄດ້ໂດຍການເຮັດ API Discovery ແລະ ຕິດຕາມການໃຊ້ API ຢ່າງຕໍ່ເນື່ອງ ເພື່ອເບິ່ງວ່າມີ API ຫຍັງແດ່ທີ່ເປີດໃຊ້ງານຢູ່ ທັງພາຍໃນ ແລະ ພາຍນອກ.
API10: Insufficient Logging and Monitoring
ການຂາດການບັນທຶກຂໍ້ມູນເຝົ້າລະວັງ ແລະ ລາຍງານເຫດການດ້ານຄວາມປອດໄພທີ່ເໝາະສົມ ຫຼື ບໍ່ພຽງພໍ ເຮັດໃຫ້ບໍ່ສາມາດກວດຈັບເຫດການຜິດປົກກະຕິ ລວມເຖິງບໍ່ສາມາດຕິດຕາມເຫດໂຈມຕີທີ່ເກິດຂື້ນໄດ້ວ່າ ເກີດບ່ອນໃດ, ແບບໃດ ແລະ ເມື່ອໃດ ແນະນຳໃຫ້ຈັດເກັບ Log ໃນລະດັບແອັບພິເຄຊັ່ນ ແລະ ຂໍ້ມູນໃນຮູບແບທີ່ຊ່ວຍໃຫ້ສາມາດວິເຄາະດ້ານຄວາມປອດໄພໄດ້ຢ່າງຄອບຄຸມ.
6 ແນວທາງປະຕິບັດທີ່ດີທີ່ສຸດໃນການຮັກສາຄວາມປອດໄພໃຫ້ API
F5 ໄດ້ໃຫ້ຄຳແນະນຳໃນການພັດທະນາກົນລະຍຸດການຮັກສາຄວາມປອດໄພໃຫ້ API 6 ຂໍ້ ດັ່ງນີ້:
1. Proactive Security
ສ້າງແນວທາງການຮັກສາຄວາມປອດໄພ API ໃຫ້ເປັນມາດຕະຖານ ເຊັ່ນ: ການໃຊ້ API Documentation (OAS) ເພື່ອລະບຸວ່າໃຜເຂົ້າເຖິງບໍລິການຫຍັງຜ່ານ API ໄດ້ແດ່, ວິທີທີ່ໃຊ້ງານຄືຫຍັງ, ພາຣາມິເຕີທີ່ໃຊ້ປະກອບດ້ວຍຫຍັງແດ່ ເປັນຕົ້ນ.
2. Access Control
ນອກຈາກການພິສູດຕົວຕົນແລ້ວ ອົງກອນຄວນກຳນົດສິດທິ ແລະ ຄວບຄຸມການເຂົ້າເຖິງ API ຂອງແຕ່ລະຜູ້ໃຊ້ງານໄດ້ ເພື່ອປ້ອງກັນ Unauthorized Access.
3. API Discovery
ຫົວໃຈສຳຄັນໃນການຄົ້ນຫາ Shadow API ທີ່ເກີດຂື້ນໃນລະບົບ ຈາກທັງພາຍໃນ ແລະ ພາຍນອກ ລວມເຖິງ API ທີ່ໃຊ້ງານຢູ່ມີຄວາມປອດໄພພຽງພໍ ຫຼື ບໍ່.
4. Data Protection
ຄວນຫາເຄື່ອງມືໃນການປ້ອງກັນ Malicious Payload ເພື່ອບໍ່ໃຫ້ເກີດ Injection ແລະ ປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນສຳຄັນຫຼຸດໄປສູ່ພາຍນອກ.
5. Continuous Security
ປັບປຸງການພັດທະນາຊ໋ອບແວໂດຍການນຳຂະບວນການດ້ານຄວາມປອດໄພໃສ່ເຂົ້າໄປໃນທຸກເຟສຂອງ API Lifecycle (CI/CD Pipeline) ແທນທີ່ຈະດຳເນີນການຫຼັງຈາກທີ່ພັດທະນາຊ໋ອບແວສຳເລັດຮຽບຮ້ອຍແລ້ວ.
6. Resource Protection
ໃຊ້ Rate Limits ເພື່ອປ້ອງກັນການໂຈມຕີແບບ DoS/DDoS ແລະ ເຮັດໃຫ້ໝັ້ນໃຈວ່າ API ຈະພ້ອມໃຊ້ງານຕະຫຼອດເວລາ.
ຕາຕະລາງດ້ານລຸ່ມສະແດງໃຫ້ເຫັນເຕັກໂນໂລຊີທີ່ໃຊ້ໃນການສ້າງ API Security ໂດຍແບ່ງອອກເປັນ 3 ສ່ວນ ຄື: Access Control, Network Security ແລະ Runtime Protection.
ແນ່ນອນວ່າ Defense-in-Depth ຍັງເປັນແນວທາງປະຕິບັດທີ່ສຳຄັນໃນການປົກປ້ອງ API.
ເອກະສານອ້າງອີງ: https://www.techtalkthai.com/owasp-api-top-10-and-6-api-security-best-practices-by-f5/
Meesaisak 25 April 2023 1065 reads
Print
ແອັບພິເຄຊັ່ນໃນປັດຈຸບັນຖືກພັດທະນາໃຫ້ມີຄວາມຊັບຊ້ອນ ແລະ ທັນສະໄໝຫຼາຍຍິ່ງຂຶ້ນ ທັງຍັງສາມາດເຊື່ອມຕໍ່ກັບລະບົບຕ່າງໆ ເພື່ອປະສານການເຮັດວຽກໄດ້ຢ່າງສະດວກ ແລະ ວ່ອງໄວ ສົ່ງຜົນໃຫ້ API ຖືກໃຊ້ງານເປັນຈຳນວນຫຼາຍ ບົດຄວາມນີ້ F5 ໄດ້ອອກມາເປີດເຜີຍເຖິງຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງ API ຕາມ OWAP API Top 10 ແລະ ແນວທາງປະຕິບັດທີ່ດີທີ່ສຸດໃນການປ້ອງກັນ API ຈາກໄພຄຸກຄາມໄຊເບີ.
API ເຕີບໂຕຢ່າງກ້າວກະໂດດ ສ່ຽງຖືກແຮັກເກີໂຈມຕີຫຼາຍຂຶ້ນ
ປະຕິເສດບໍ່ໄດ້ວ່າເກືອບທຸກອົງກອນໃນປັດຈຸບັນຕ່າງພາກັນເຮັດ Digital Transformation, ແອັບພິເຄຊັ່ນຖືກພັດທະນາໃຫ້ມີຄວາມທັນສະໄໝດ້ວຍສະຖາປັດຕະຍາກຳແບບ Microservices ຊຶ່ງແບ່ງ Function ການເຮັດວຽກອອກເປັນຫຼາຍໆສ່ວນ ໃນຂະນະທີ່ Developer ກໍ່ແບ່ງອອກເປັນຫຼາຍທີມຫຼາຍຂຶ້ນ ເພື່ອໃຫ້ອອກຄຸນສົມບັດ ແລະ Function ການໃຊ້ງານໃໝ່ໆ ສູ່ຕະຫຼາດໄດ້ຢ່າງວ່ອງໄວ ລວມເຖິງການປັບໄປໃຊ້ Hybrid ແລະ Multi-cloud ຂອງອົງກອນເຫຼົ່ານີ້ ລ້ວນແຕ່ເຊື່ອມຕໍ່ ແລະ ປະສານການເຮັດວຽກຜ່ານທາງ API ສົ່ງຜົນໃຫ້ລະບົບ API ເຕີບໂຕຢ່າງກ້າວກະໂດດ.
ຈາກການສຳຫຼວດພົບວ່າຫຼາຍກວ່າ 90% ຂອງການຈະລາຈອນເທິງອິນເຕີເນັດ ຖືກຈຳແນກເປັນການຮັບສົ່ງຂໍ້ມູນ API (JSON/SML) ຈຶ່ງເປັນສາເຫດທີ່ເຮັດໃຫ້ອາຊະຍາກອນໄຊເບີເລີ່ມຫາຊ່ອງໂຫວ່ ແລະ ໂຈມຕີລະບົບ API ຫຼາຍຂຶ້ນ ການຂາດຄວາມຮັບຮູ້ ແລະ ການປ້ອງກັນ API ອາດກໍ່ໃຫ້ເກີດເຫດ Data Breach ຫຼື ຂໍ້ມູນຮົ່ວໄຫຼສູ່ສາທາລະນະໄດ້ ຊຶ່ງສາເຫດອັນດັບໜຶ່ງຂອງການເຈາະລະບົບ API ຄື No Authentication ຕາມມາດ້ວຍ Bad Authentication ແລະ Bad Authorization.
ສະຫຼຸບຄວາມສ່ຽງຂອງ API ຈາກ OWASP API Top 10
ໃນປີ 2019 OWASP ໄດ້ເຮັດວິໄຈ ແລະ ສຳຫຼວດຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງ API ຈຳແນກອອກເປັນ 10 ອັນດັບ ດັ່ງນີ້:
API1: Broken Object Level Authorization (BOLA)
ການເປີດໃຫ້ເຂົ້າເຖິງຂໍ້ມູນໂດຍໃຊ້ Object ID ຊຶ່ງສ່ຽງຖືກແຮັກເກີເຂົ້າເຖິງຂໍ້ມູນອື່ນໆ ຜ່ານທາງ Object ID ທີ່ບໍ່ແມ່ນຂອງຕົນເອງໄດ້ ດັ່ງພາບຕົວຢ່າງດ້ານລຸ່ມທີ່ James Lee ສັງເກດພົບວ່າມີການໃຊ້ User ID ເພື່ອເຂົ້າເຖິງຂໍ້ມູນສ່ວນບຸກຄົນ ແທນທີ່ຈະໃຊ້ໝາຍເລກ 23 ເພື່ອເຂົ້າເຖິງຂໍ້ມູນຂອງຕົນເອງ ແຕ່ກັບໃຊ້ໝາຍເລກ 24 ເພື່ອເຂົ້າເຖິງຂໍ້ມູນຂອງບຸກຄົນອື່ນແທນ (ໃນທີ່ນີ້ຄືຂໍ້ມູນຂອງ Claire Lee) ແນະນຳວ່າຄວນມີການເຮັດ Authorization Policy ໃນລະດັບ Object ທັງເທິງໂຄ້ດ (Code) ແລະ ເທິງ API Gateway ລວມເຖິງການກວດຈັບພຶດຕິກຳເພື່ອຮັບມືກັບຄວາມສ່ຽງດັ່ງກ່າວ.
API2: Broken User Authentication
ການໂຈມຕີເພື່ອ bypass ການພິສູດຕົວຕົນ ຊຶ່ງອາດຈະເກີດຈາກການທີ່ບໍ່ມີລະບົບການພິສູດຕົວຕົນ, ລະບົບບໍ່ດີພໍ (Weak JWT) ຫຼື ການໂຈມຕີອື່ນໆ ເຊັ່ນ: Credential Stuffing, ການລັກ API Key ໄປໃຊ້ສວມຮອຍສິດທິ ເປັນຕົ້ນ. ຄວາມສ່ຽງນີ້ປ້ອງກັນໄດ້ໂດຍການໃຊ້ລະບົບພິສູດຕົວຕົນທີ່ດີພຽງພໍ ເຊັ່ນ: OAuth/OIDC.
API3: Excessive Data Exposure
ການເປີດເຜີຍຂໍ້ມູນຫຼາຍເກີນໄປເມື່ອຖືກຮ້ອງຂໍຜ່ານ API ຊຶ່ງສ່ຽງຕໍ່ກັບຂໍ້ມູນຄວາມລັບບາງຢ່າງ ເຊັ່ນ: ໝາຍເລກບັດເຄຣດິດ ອາດຮົ່ວໄຫຼອອກໄປໄດ້ ສາມາດຫຼຸດຄວາມສ່ຽງນີ້ໄດ້ດ້ວຍການອອກແບບໃຫ້ລະບົບ API ຕອບກັບສະເພາະຂໍ້ມູນທີ່ຈຳເປັນ ຫຼື ຫາ solution ທີ່ມາກວດຈັບ ແລະ Mask ຂໍ້ມູນສຳຄັນທີ່ຖືກສົ່ງອອກໄປ.
API4: Lack of Resource & Rate Limiting
ການໂຈມຕີເກີດຂຶ້ນໄດ້ເມື່ອບໍ່ມີການຈຳກັດຈຳນວນເນື້ອຫາ ແລະ ປະເພດຂອງຄຳຮ້ອງຂໍ API ຈາກຜູ້ໃຊ້ ຊຶ່ງຖ້າມີຄຳຮ້ອງຂໍຫຼາຍເກີນໄປ, Payload ໃຫຍ່ເກີນໄປ ຫຼື ມີການດາວໂຫຼດ/ອັບໂຫຼດຟາຍຂະໜາດໃຫຍ່ ອາດສ່ຽງເກີດເງື່ອນໄຂ DoS ໄດ້ ແນະນຳໃຫ້ເຮັດ Rate Limits ເທິງ API Gateway ເພື່ອໃຫ້ໝັ້ນໃຈວ່າລະບົບ API ຈະພ້ອມໃຊ້ງານຕະຫຼອດເວລາ.
API5: Broken Function Level Authorization
ຄວາມສ່ຽງຄ້າຍຄືກັບ API1 ແຕ່ເກີດຈາກການເປີດໃຫ້ແຮັກເກີສາມາດໃຊ້ຟັງຊັ່ນຕ່າງໆໄດ້ໂດຍບໍ່ມີສິດ ດັ່ງພາບຕົວຢ່າງດ້ານລຸ່ມ ກຸ່ມ Admin ມີສິດໃຊ້ຟັງຊັ່ນ (function) GET, POST, DELETE ໃນຂະນະທີ່ກຸ່ມ Users ສາມາດໃຊ້ໄດ້ແຕ່ຟັງຊັ່ນ GET ເພື່ອເບິ່ງຂໍ້ມູນໄດ້ຢ່າງດຽວ ແຕ່ກັບໃຊ້ function ອື່ນໆ ເພື່ອອັບເດດ ຫຼື ລຶບຂໍ້ມູນໄດ້ ເປັນຕົ້ນ ວິທີການປ້ອງກັນກໍ່ຄ້າຍຄືກັບ API1 ຄື ເຮັດ Access Control Policy ທັງເທິງໂຄ້ດ ແລະ ເທິງ API Gateway.
API6: Mass Assignment
ໂດຍທົ່ວໄປແລ້ວ ຈະມີການຈຳກັດພາຣາມິເຕີ (Parameter) ທີ່ໃຊ້ສົ່ງຄຳຮ້ອງຂໍ API ວ່າຕ້ອງເປັນຊຸດພາຣາມິເຕີນີ້ເທົ່ານັ້ນ ແຕ່ຖ້າເປີດໃຊ້ຟັງຊັ່ນ Allow Bypass of Mapping Restriction ຈະເຮັດໃຫ້ສາມາດເພີ່ມພາຣາມິເຕີອື່ນເຂົ້າໄປໃນການສົ່ງຄຳຮ້ອງຂໍໄດ້ ເຖິງວ່າການເຮັດແບບນີ້ຈະຊ່ວຍເພີ່ມຄວາມສະດວກສະບາຍໃຫ້ແກ່ Developer ແຕ່ກໍ່ສ້າງຊ່ອງໂຫວ່ໃຫ້ແຮັກເກີສາມາດສົ່ງພາຣາມິເຕີເຂົ້າມາແກ້ໄຂ ຫຼື ປ່ຽນແປງຂໍ້ມູນພາຍໃນໄດ້ເຊັ່ນກັນ ແນະນຳໃຫ້ສ້າງ OpenAPI Specification (OAS) ຕາມ Business Logic ເທິງ API Endpoints ແລ້ວ import ເຂົ້າ WAAP ຫຼື API Gateway ເພື່ອກວດສອບຄຳຮ້ອງຂໍ API ທີ່ສົ່ງເຂົ້າມາວ່າເປັນໄປຕາມທີ່ກຳນົດໄວ້ ຫຼື ບໍ່.
API7: Security Misconfiguration
ການຕັ້ງຄ່າການຮັກສາຄວາມປອດໄພທີ່ຜິດພາດ ຫຼື ໃຊ້ຄ່າເລີ່ມຕົ້ນຈາກໂຮງງານ ເຊັ່ນ: ລືມປິດພອດ (Port) ເລີ່ມຕົ້ນຈາກໂຮງງານ ໃຊ້ລະຫັດຜ່ານທີ່ຄາດເດົາໄດ້ງ່າຍ ຫຼື ເປີດໃຫ້ໃຊ້ Method ທີ່ບໍ່ເໝາະສົມ ເປັນຕົ້ນ. ການໝັ່ນກວດສອບ API Inventory ແລະ ໃຊ້ເຄື່ອງມືກວດສອບການຕັ້ງຄ່າຕ່າງໆ ເປັນແນວທາງປະຕິບັດທີ່ດີໃນການຫຼຸດຄວາມສ່ຽງນີ້.
API8: Injection
ຄວາມສ່ຽງນີ້ຄ້າຍຄືກັບການໂຈມຕີ Web Apps ທີ່ແຮັກເກີສາມາດສົ່ງ script ບາງຢ່າງເຂົ້າມາປະມວນຜົນໃນລະບົບຫຼັງບ້ານໄດ້ ເຊັ່ນ: GET /api/account?id=”321′ OR 1=1″ ເພື່ອເຮັດ SQL Injection ລັກຂໍ້ມູນຈາກ Database Server ເປັນຕົ້ນ ແນະນຳໃຫ້ເຮັດ SAST & DAST Analysis ເພື່ອຄົ້ນຫາ ແລະ ຈັດການກັບຊ່ອງໂຫວ່ເຫຼົ່ານີ້ເທິງໂຄ້ດ ຫຼື ໃຊ້ລະບົບກວດຈັບ Malicious Payload ຂະນະ Runtime.
API9: Improper Assets Management
ການລືມຍົກເລີກການໃຊ້ API ເວີຊັ່ນທົດສອບ ຫຼື ເວີຊັ່ນເກົ່າທີ່ບໍ່ໄດ້ໃຊ້ງານແລ້ວ (ເອີ້ນວ່າ Shadow API) ເຮັດໃຫ້ແຮັກເກີສາມາດເຂົ້າເຖິງ API ເຫຼົ່ານີ້ທີ່ມີການຮັກສາຄວາມປອດໄພຕ່ຳກວ່າ ແລະ ເຈາະຊ່ອງໂຫວ່ເຂົ້າມາເຮັດອັນຕະລາຍແອັບພິເຄຊັ່ນພາຍໃນໄດ້ ຄວາມສ່ຽງນີ້ຈັດການໄດ້ໂດຍການເຮັດ API Discovery ແລະ ຕິດຕາມການໃຊ້ API ຢ່າງຕໍ່ເນື່ອງ ເພື່ອເບິ່ງວ່າມີ API ຫຍັງແດ່ທີ່ເປີດໃຊ້ງານຢູ່ ທັງພາຍໃນ ແລະ ພາຍນອກ.
API10: Insufficient Logging and Monitoring
ການຂາດການບັນທຶກຂໍ້ມູນເຝົ້າລະວັງ ແລະ ລາຍງານເຫດການດ້ານຄວາມປອດໄພທີ່ເໝາະສົມ ຫຼື ບໍ່ພຽງພໍ ເຮັດໃຫ້ບໍ່ສາມາດກວດຈັບເຫດການຜິດປົກກະຕິ ລວມເຖິງບໍ່ສາມາດຕິດຕາມເຫດໂຈມຕີທີ່ເກິດຂື້ນໄດ້ວ່າ ເກີດບ່ອນໃດ, ແບບໃດ ແລະ ເມື່ອໃດ ແນະນຳໃຫ້ຈັດເກັບ Log ໃນລະດັບແອັບພິເຄຊັ່ນ ແລະ ຂໍ້ມູນໃນຮູບແບທີ່ຊ່ວຍໃຫ້ສາມາດວິເຄາະດ້ານຄວາມປອດໄພໄດ້ຢ່າງຄອບຄຸມ.
6 ແນວທາງປະຕິບັດທີ່ດີທີ່ສຸດໃນການຮັກສາຄວາມປອດໄພໃຫ້ API
F5 ໄດ້ໃຫ້ຄຳແນະນຳໃນການພັດທະນາກົນລະຍຸດການຮັກສາຄວາມປອດໄພໃຫ້ API 6 ຂໍ້ ດັ່ງນີ້:
1. Proactive Security
ສ້າງແນວທາງການຮັກສາຄວາມປອດໄພ API ໃຫ້ເປັນມາດຕະຖານ ເຊັ່ນ: ການໃຊ້ API Documentation (OAS) ເພື່ອລະບຸວ່າໃຜເຂົ້າເຖິງບໍລິການຫຍັງຜ່ານ API ໄດ້ແດ່, ວິທີທີ່ໃຊ້ງານຄືຫຍັງ, ພາຣາມິເຕີທີ່ໃຊ້ປະກອບດ້ວຍຫຍັງແດ່ ເປັນຕົ້ນ.
2. Access Control
ນອກຈາກການພິສູດຕົວຕົນແລ້ວ ອົງກອນຄວນກຳນົດສິດທິ ແລະ ຄວບຄຸມການເຂົ້າເຖິງ API ຂອງແຕ່ລະຜູ້ໃຊ້ງານໄດ້ ເພື່ອປ້ອງກັນ Unauthorized Access.
3. API Discovery
ຫົວໃຈສຳຄັນໃນການຄົ້ນຫາ Shadow API ທີ່ເກີດຂື້ນໃນລະບົບ ຈາກທັງພາຍໃນ ແລະ ພາຍນອກ ລວມເຖິງ API ທີ່ໃຊ້ງານຢູ່ມີຄວາມປອດໄພພຽງພໍ ຫຼື ບໍ່.
4. Data Protection
ຄວນຫາເຄື່ອງມືໃນການປ້ອງກັນ Malicious Payload ເພື່ອບໍ່ໃຫ້ເກີດ Injection ແລະ ປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນສຳຄັນຫຼຸດໄປສູ່ພາຍນອກ.
5. Continuous Security
ປັບປຸງການພັດທະນາຊ໋ອບແວໂດຍການນຳຂະບວນການດ້ານຄວາມປອດໄພໃສ່ເຂົ້າໄປໃນທຸກເຟສຂອງ API Lifecycle (CI/CD Pipeline) ແທນທີ່ຈະດຳເນີນການຫຼັງຈາກທີ່ພັດທະນາຊ໋ອບແວສຳເລັດຮຽບຮ້ອຍແລ້ວ.
6. Resource Protection
ໃຊ້ Rate Limits ເພື່ອປ້ອງກັນການໂຈມຕີແບບ DoS/DDoS ແລະ ເຮັດໃຫ້ໝັ້ນໃຈວ່າ API ຈະພ້ອມໃຊ້ງານຕະຫຼອດເວລາ.
ຕາຕະລາງດ້ານລຸ່ມສະແດງໃຫ້ເຫັນເຕັກໂນໂລຊີທີ່ໃຊ້ໃນການສ້າງ API Security ໂດຍແບ່ງອອກເປັນ 3 ສ່ວນ ຄື: Access Control, Network Security ແລະ Runtime Protection.
ແນ່ນອນວ່າ Defense-in-Depth ຍັງເປັນແນວທາງປະຕິບັດທີ່ສຳຄັນໃນການປົກປ້ອງ API.
ເອກະສານອ້າງອີງ: https://www.techtalkthai.com/owasp-api-top-10-and-6-api-security-best-practices-by-f5/
