การตรวจสอบระดับสูงสำหรับนักพัฒนา รวมถึงคำแนะนำในการพัฒนา API อย่างปลอดภัย รายการตรวจสอบนี้มุ่งเน้นไปที่กลยุทธ์และวิธีแก้ปัญหาเพื่อทำความเข้าใจและบรรเทาช่องโหว่เฉพาะและความเสี่ยงด้านความปลอดภัยของ Application Programming Interfaces (API) ซึ่งครอบคลุมปัญหาด้านความปลอดภัย API 10 อันดับแรกของ OWASP ทั้งหมด รายการตรวจสอบนี้ใช้ได้กับแอปพลิเคชันทุกประเภทที่ใช้ API สำหรับการสื่อสาร
ก่อนที่จะเข้าใจแนวทางปฏิบัติที่ดีที่สุด เราควรเข้าใจก่อนว่าเหตุใดจึงสำคัญสำหรับนักพัฒนาที่จะต้องรักษาความปลอดภัยของ API
- ตั้งแต่ธนาคาร การค้าปลีก และการขนส่ง API เป็นส่วนสำคัญของเว็บแอปพลิเคชัน และสามารถพบได้ในแอปพลิเคชันที่ติดต่อกับลูกค้า คู่ค้า และภายใน
- โดยธรรมชาติแล้ว API จะเปิดเผยลอจิกของแอปพลิเคชันและข้อมูลที่ละเอียดอ่อน เช่น ข้อมูลที่สามารถระบุตัวตนได้ และด้วยเหตุนี้จึงกลายเป็นเป้าหมายของผู้โจมตี
- หากไม่มี API ที่ปลอดภัย ก็จะเกิดปัญหาและทำให้ระบบนั้นใช้งานไม่ได้หรือไม่มีอีกต่อไป
Broken object-level authorization
- ใช้การตรวจสอบการให้สิทธิ์กับนโยบายผู้ใช้และลำดับชั้น
- อย่าพึ่งพา ID ที่ไคลเอนต์ส่งมา ใช้ ID ที่จัดเก็บไว้ในวัตถุเซสชันแทน
- ตรวจสอบการอนุญาตสำหรับคำขอของลูกค้าแต่ละรายในการเข้าถึงฐานข้อมูล
- ใช้รหัสสุ่มที่ไม่สามารถเดาได้ (UUID)
Broken authentication
- ตรวจสอบวิธีที่เป็นไปได้ทั้งหมดในการรับรองความถูกต้องกับ API ทั้งหมด
- API สำหรับการรีเซ็ตรหัสผ่านและลิงค์แบบใช้ครั้งเดียวยังช่วยให้ผู้ใช้ตรวจสอบสิทธิ์ได้ และควรได้รับการปกป้องอย่างเข้มงวดเช่นเดียวกัน
- ใช้การรับรองความถูกต้องมาตรฐาน การสร้างโทเค็น การจัดเก็บรหัสผ่าน และการยืนยันตัวตนแบบหลายปัจจัย (MFA)
- ใช้โทเค็นการเข้าถึงที่มีอายุสั้น
- ตรวจสอบแอปของคุณ (เพื่อให้คุณรู้ว่าใครกำลังคุยกับคุณ)
- ใช้การจำกัดอัตราที่เข้มงวดยิ่งขึ้นสำหรับการรับรองความถูกต้อง และใช้นโยบายการล็อกและการตรวจสอบรหัสผ่านที่ไม่รัดกุม
Excessive data exposure
- อย่าพึ่งพาผู้ใช้ในการกรองข้อมูล
- ตรวจสอบการตอบสนองของ API ทั้งหมดและปรับเปลี่ยนให้ตรงกับสิ่งที่ผู้ใช้ API ต้องการจริงๆ
- กำหนดโครงสร้างข้อมูลสำหรับการตอบกลับ API ทั้งหมดอย่างระมัดระวัง
- อย่าลืมเกี่ยวกับการตอบสนองข้อผิดพลาด กำหนดโครงสร้างข้อมูลที่เหมาะสมด้วย
- ให้ระบุข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) และปรับการใช้งานให้เหมาะสม
- บังคับใช้การตรวจสอบการตอบสนองเพื่อป้องกันการรั่วไหลของข้อมูลหรือข้อยกเว้นโดยไม่ตั้งใจ
Lack of resources and rate limiting
- กำหนดการจำกัดอัตราที่เหมาะสม
- จำกัดขนาด
- ปรับแต่งการจำกัดอัตราให้ตรงกับ API ไคลเอนต์ ที่ควรได้รับอนุญาต
- เพิ่มการตรวจสอบอัตราส่วนการใช้งาน
- กำหนดขีดจำกัดสำหรับทรัพยากรคอนเทนเนอร์
Broken function level authorization
- อย่าพึ่งพาไคลเอนต์เพื่อบังคับใช้การเข้าถึงของผู้ดูแลระบบ
- ปฏิเสธการเข้าถึงทั้งหมดตามค่าเริ่มต้น
- อนุญาตให้ดำเนินการกับผู้ใช้ที่อยู่ในกลุ่มหรือบทบาทที่เหมาะสมเท่านั้น
- อนุญาตการออกแบบและทดสอบอย่างถูกต้อง
Mass assignment
- อย่าผูกข้อมูลขาเข้าและวัตถุภายในโดยอัตโนมัติ
- กำหนดพารามิเตอร์ที่ต้องการอย่างชัดเจน
- ใช้คุณสมบัติ readOnly ที่ตั้งค่าเป็น true ใน object schema สำหรับคุณสมบัติทั้งหมดที่สามารถดึงข้อมูลผ่าน API แต่ไม่ควรแก้ไข
- กำหนดโครงสร้างข้อมูล ประเภท และรูปแบบที่คุณจะยอมรับในคำขอในเวลาออกแบบอย่างแม่นยำ และบังคับใช้ในขณะรันไทม์
Security misconfiguration
- ค้นหาข้อบกพร่องในการกำหนดค่าโดยอัตโนมัติ
- ปิดการใช้งานคุณสมบัติที่ไม่จำเป็น
- จำกัดการเข้าถึงระดับผู้ดูแลระบบ
- กำหนดและบังคับใช้เอาต์พุตทั้งหมด รวมถึงข้อผิดพลาด
Injection
- อย่าไว้ใจผู้ใช้ API ของคุณ แม้ว่าจะเป็นข้อมูลภายในก็ตาม
- กำหนดข้อมูลอินพุตทั้งหมดอย่างเคร่งครัด และบังคับใช้เมื่อรันไทม์
- ตรวจสอบ กรอง ข้อมูลขาเข้าทั้งหมด
- กำหนด จำกัด และบังคับใช้เอาต์พุต API เพื่อป้องกันการรั่วไหลของข้อมูล
Improper assets management
- ใช้ API ที่เป็นปัจจุบันทั้งหมด
- จำกัดการเข้าถึงสิ่งที่ไม่ควรเปิดเผยต่อสาธารณะ
- จำกัดการเข้าถึงข้อมูลที่ใช้งานจริง และแยกการเข้าถึงข้อมูลที่ใช้งานจริงและข้อมูลที่ไม่ได้ใช้งานจริง
- ใช้การควบคุมภายนอกเพิ่มเติม เช่น ไฟร์วอลล์ API
- เลิกใช้ API เวอร์ชันเก่าหรือการแก้ไขความปลอดภัยของ backport อย่างเหมาะสม
- ใช้การรับรองความถูกต้องที่เข้มงวด การเปลี่ยนเส้นทาง CORS และอื่นๆ
Insufficient logging and monitoring
- บันทึกความพยายามที่ล้มเหลว การเข้าถึงที่ถูกปฏิเสธ การตรวจสอบอินพุตล้มเหลว หรือความล้มเหลวในการตรวจสอบนโยบายความปลอดภัย
- ตรวจสอบให้แน่ใจว่าบันทึกได้รับการจัดรูปแบบเพื่อให้เครื่องมืออื่นๆ ใช้งานได้เช่นกัน
- ป้องกันบันทึก เช่น ข้อมูลที่มีความละเอียดอ่อนสูง
- บันทึกรายละเอียดที่เพียงพอเพื่อระบุตัวผู้โจมตี
- หลีกเลี่ยงการมีข้อมูลที่ละเอียดอ่อนในบันทึก หากคุณต้องการข้อมูลเพื่อจุดประสงค์ในการแก้ไขจุดบกพร่อง ให้แก้ไขบางส่วน
คุณสามารถดูเพิ่มเติมได้สำหรับความรู้ที่แบ่งปันโดยชุมชน OWASP
