TechTalkThai ศูนย์รวมข่าว Enterprise IT ออนไลน์แห่งแรกในประเทศไทย
แอปพลิเคชันในปัจจุบันถูกพัฒนาให้มีความซับซ้อนและทันสมัยมากยิ่งขึ้น ทั้งยังสามารถเชื่อมต่อกับระบบต่างๆ เพื่อผสานการทำงานได้อย่างสะดวกและรวดเร็ว ส่งผลให้ API ถูกใช้งานเป็นจำนวนมาก บทความนี้ F5 ได้ออกมาเปิดเผยถึงความเสี่ยงด้านความมั่นคงปลอดภัยของ API ตาม OWAP API Top 10 และแนวทางปฏิบัติที่ดีที่สุดในการป้องกัน API จากภัยคุกคามไซเบอร์
API เติบโตอย่างก้าวกระโดด เสี่ยงถูกแฮ็กเกอร์โจมตีมากขึ้น
ปฏิเสธไม่ได้ว่าเกือบทุกองค์กรในปัจจุบันต่างมุ่งหน้าทำ Digital Transformation กันทั้งสิ้น แอปพลิเคชันถูกพัฒนาให้มีความทันสมัยด้วยสถาปัตยกรรมแบบ Microservices ซึ่งแบ่งฟังก์ชันการทำงานออกเป็นหลายๆ ส่วน ในขณะที่ Developer ก็แบ่งออกเป็นหลายทีมมากขึ้น เพื่อให้ออกฟีเจอร์และฟังก์ชันการใช้งานใหม่ๆ สู่ตลาดได้อย่างรวดเร็ว รวมถึงการปรับไปใช้ 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 ทั้งบนโค้ดและบน API Gateway รวมถึงการตรวจจับพฤติกรรมเพื่อรับมือกับความเสี่ยงดังกล่าว
API2: Broken User Authentication
การโจมตีเพื่อบายพาสการพิสูจน์ตัวตน ซึ่งอาจเกิดจากการที่ไม่มีระบบการพิสูจน์ตัวตน ระบบไม่แข็งแกร่งเพียงพอ (Weak JWT) หรือการโจมตีอื่นๆ เช่น Credential Stuffing, การขโมย API Key ไปใช้สวมสิทธิ์ เป็นต้น ความเสี่ยงนี้ป้องกันได้โดยการใช้ระบบพิสูจน์ตัวตนที่แข็งแกร่ง เช่น OAuth/OIDC
API3: Excessive Data Exposure
การเผลอเปิดเผยข้อมูลมากเกินไปเมื่อถูกร้องขอผ่าน API ซึ่งเสี่ยงต่อการที่ข้อมูลความลับบางอย่าง เช่น หมายเลขบัตรเครดิต อาจรั่วไหลออกไปด้วยได้ สามารถลดความเสี่ยงนี้ได้ด้วยการออกแบบให้ระบบ API ตอบกลับเฉพาะข้อมูลที่จำเป็น หรือหาโซลูชันมาตรวจจับและทำการ Mask ข้อมูลสำคัญที่ถูกส่งออกไป
API4: Lack of Resource & Rate Limiting
การโจมตีเกิดขึ้นได้เมื่อไม่มีการจำกัดจำนวน เนื้อหา และประเภทของคำร้องขอ API จากผู้ใช้ ซึ่งถ้ามีคำร้องขอมากเกินไป Payload ใหญ่เกินไป หรือมีการดาวน์โหลด/อัปโหลดไฟล์ขนาดใหญ่ อาจเสี่ยงเกิดเงื่อนไข DoS ได้ แนะนำให้ทำ Rate Limits บน API Gateway เพื่อให้มั่นใจว่าระบบ API จะพร้อมใช้งานตลอดเวลา
API5: Broken Function Level Authorization
ความเสี่ยงคล้าย API1 แต่เกิดจากการเผลอเปิดให้แฮ็กเกอร์สามารถใช้ฟังก์ชันต่างๆ ได้โดยไม่มีสิทธิ์ ดังภาพตัวอย่างด้านล่าง กลุ่ม Admin มีสิทธิ์ใช้ฟังก์ชัน GET, POST, DELETE ในขณะที่กลุ่ม Users สามารถใช้ได้แค่ฟังก์ชัน GET เพื่อดูข้อมูลได้อย่างเดียว แต่กลับใช้ฟังก์ชันอื่นๆ เพื่ออัปเดตหรือลบข้อมูลได้ด้วย เป็นต้น วิธีการป้องกันก็คล้าย API1 คือ จัดทำ Access Control Policy ทั้งบนโค้ดและบน API Gateway
API6: Mass Assignment
โดยทั่วไปแล้ว จะมีการจำกัดพารามิเตอร์ที่ใช้ส่งคำร้องขอ API ว่าต้องเป็นชุดพารามิเตอร์นี้เท่านั้น แต่ถ้าเปิดใช้ฟังก์ชัน Allow Bypass of Mapping Restriction จะทำให้สามารถเพิ่มพารามิเตอร์อื่นเข้าไปในการส่งคำร้องขอได้ แม้ว่าการทำเช่นนี้จะช่วยเพิ่มความสะดวกสบายให้แก่ Developer แต่ก็สร้างช่องโหว่ให้แฮ็กเกอร์สามารถส่งพารามิเตอร์เข้ามาแก้ไขหรือเปลี่ยนแปลงข้อมูลภายในได้เช่นกัน แนะนำให้สร้าง OpenAPI Specification (OAS) ตาม Business Logic บน API Endpoints แล้วอิมพอร์ตเข้า WAAP หรือ API Gateway เพื่อตรวจสอบคำร้องขอ API ที่ส่งเข้ามาว่าเป็นไปตามที่กำหนดไว้หรือไม่
API7: Security Misconfiguration
การตั้งค่าการรักษาความมั่นคงปลอดภัยที่ผิดพลาด หรือเผลอใช้ค่าเริ่มต้นจากโรงงาน เช่น ลืมปิดพอร์ตเริ่มต้นจากโรงงาน ใช้รหัสผ่านที่ไม่แข็งแกร่งพอ หรือเปิดให้ใช้ Method ที่ไม่เหมาะสม เป็นต้น การหมั่นตรวจสอบ API Inventory และใช้เครื่องมือตรวจสอบการตั้งค่าต่างๆ เป็นแนวทางปฏิบัติที่ดีในการลดความเสี่ยงนี้
API8: Injection
ความเสี่ยงนี้คล้ายกับการโจมตี Web Apps ที่แฮ็กเกอร์สามารถส่งสคริปต์บางอย่างเข้ามาประมวลผลในระบบหลังบ้านได้ เช่น 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
F5 ผู้นำด้าน Application Delivery และ Security
F5 เป็นผู้ให้บริการเทคโนโลยีด้าน Application Delivery และ Security ที่ครอบคลุมทั้งแอปพลิเคชันแบบดั้งเดิม และแอปพลิเคชันยุคใหม่ที่ใช้สถาปัตยกรรมแบบ Microservices และ API บน Hybrid Cloud และ Multi-cloud โดยโซลูชัน API Security ของ F5 ประกอบด้วย
- การป้องกัน N-S Inbound Traffic ได้แก่ ADC, WAF, DDoS, Authentication, SSL Offload, DNS ฯลฯ
- Service Discovery สำหรับค้นหา Shadow API และตรวจสอบว่า API ที่ใช้งานอยู่มีการตั้งค่าความมั่นคงปลอดภัยแข็งแกร่งเพียงพอหรือไม่
- Microgateway สำหรับติดตาม E-W Traffic รวมถึงกำหนดนโยบายการพิสูจน์ตัวตนและกำหนดสิทธิ์การเข้าถึงในการคุยกันผ่าน API ระหว่าง Containers ได้
ผู้ที่สนใจเกี่ยวกับ OWASP API Top 10 และแนวทางปฏิบัติที่ดีที่สุดสำหรับ API Security สามารถรับชมการบรรยาย F5 Webinar เรื่อง “Don’t Get Stung by the OWASP API Top 10” โดยคุณชยาวัทน์ อุสะทโก Solutions Engineer จาก F5 ได้ที่นี่
