ประเภทการโจมตี API และการลดผลกระทบจากการถูกโจมตี

บทความนี้จะไม่ได้ให้ความสมบูรณ์แบบ แต่เราจะเน้นที่ช่องโหว่ API สามอันดับแรก (ตาม OWASP) มาตรฐานสากลของ OWASP เป็นสิ่งสำคัญในการอ่าน เพราะไม่เพียงแต่ได้รับการพัฒนาโดยผู้เชี่ยวชาญทั่วโลกเท่านั้น แต่ยังอ่านโดยผู้คุกคามที่จะใช้ประโยชน์จากจุดอ่อนเหล่านั้นด้วย

OWASP กำหนดความเสี่ยงของ API โดยพิจารณาจากระดับของการใช้ประโยชน์จากช่องโหว่ของ API ความชุกของจุดอ่อน การตรวจหาจุดอ่อน และผลกระทบทางเทคนิค ดังนั้น 10 อันดับแรกของ API จึงอยู่ในลำดับวิธีการเสี่ยงของ OWASP วิธีการเสี่ยงของพวกเขาไม่ได้พิจารณาถึงโอกาสที่จะเกิดขึ้นจริงหรือผลกระทบนั้นขึ้นอยู่กับแต่ละธุรกิจ แต่ทั้งสามนี้เป็นจุดเริ่มต้นที่ดี เพราะพวกเขาส่งผลกระทบต่อบริษัทขนาดใหญ่ เช่น Peloton ในปี 2564

1. API1: 2019 การอนุญาตระดับออบเจ็กต์ที่ใช้งานไม่ได้ (BOLA)

ในช่องโหว่นี้ หรือที่เรียกว่า BOLA API จะเปิดเผยปลายทางที่จัดการตัวระบุอ็อบเจ็กต์ ซึ่งจะทำให้ผู้เยี่ยมชมสามารถเข้าถึงทรัพยากรจำนวนมากได้ การโจมตีนี้เหมือนกับ Insecure Direct Object Reference (IDOR) ที่แอปพลิเคชันใช้ข้อมูลประจำตัวที่ผู้ใช้ระบุเพื่อเข้าถึงวัตถุ ในด้าน API นั้น BOLA มีความแม่นยำมากกว่า IDOR – ปัญหาคือการให้สิทธิ์ใช้งานไม่ได้ในลำดับของการเรียก API ทุกการเรียกไปยังแหล่งข้อมูลที่ใช้อินพุตที่ผู้ใช้ให้มาควรมีการตรวจสอบสิทธิ์ระดับออบเจ็กต์

นี่เป็นตัวอย่างง่ายๆ เกี่ยวกับวิธีการทำงาน

การเรียก API มีเส้นทางต่อไปนี้: /customers/user/bob/profile. ผู้โจมตีจะพยายามใช้ชื่อต่างๆ แทน “บ๊อบ” เพื่อดูว่าสามารถเข้าถึงอะไรได้บ้าง เช่น:

/customers/user/alice/profile

/customers/user/john/profile

แม้ว่าชื่อจะถูกแทนที่ด้วยอักขระผสมแบบยาว หากลำดับอักขระเหล่านั้นเป็นแบบต่อเนื่องหรือคาดเดาได้ ปัญหายังคงอยู่และมีความเสี่ยง

การลดผลกระทบ

– ใช้กลไกการอนุญาตที่ขึ้นอยู่กับนโยบายผู้ใช้และลำดับชั้น

– ใช้กลไกการอนุญาตเพื่อตรวจสอบว่าผู้ใช้ที่เข้าสู่ระบบมีสิทธิ์ดำเนินการตามที่ร้องขอในบันทึกในทุกฟังก์ชันที่ใช้อินพุตจากไคลเอนต์เพื่อเข้าถึงบันทึกในฐานข้อมูลหรือไม่

– ใช้ค่าแบบสุ่มและคาดเดาไม่ได้สำหรับรหัสบันทึก

– ประเมินการตรวจสอบการอนุญาต

2. API2: 2019 การตรวจสอบสิทธิ์ผู้ใช้ที่ใช้งานไม่ได้

เมื่อมีการนำกลไกการตรวจสอบความถูกต้องไปใช้อย่างไม่เหมาะสม ผู้โจมตีสามารถประนีประนอมโทเค็นการพิสูจน์ตัวตนหรือใช้ประโยชน์จากข้อบกพร่องในการใช้งานโดยสันนิษฐานว่าเป็นตัวตนของผู้ใช้รายอื่น

ตัวอย่างที่ชัดเจนของช่องโหว่นี้คือการละเมิด Parler ในปี 2021 ปัจจัยอื่น ๆ เข้ามามีบทบาทในการละเมิดทั้งหมด แต่อย่างน้อยหนึ่งจุดปลายทางไม่ต้องการการตรวจสอบสิทธิ์ ทำให้ใครก็ตามที่พบ (และบางคนทำ) เข้าถึงภาพได้โดยไม่ จำกัด

การลดผลกระทบ

– ใช้การรับรองความถูกต้องตามมาตรฐานอุตสาหกรรมและกลไกการสร้างโทเค็น (และอ่านเอกสารประกอบ)

– ระวังโฟลว์การตรวจสอบสิทธิ์ API ที่เป็นไปได้ทั้งหมดในผลิตภัณฑ์หรือบริการ (มือถือ/ เว็บ/ลิงก์ในรายละเอียดที่ใช้การรับรองความถูกต้องด้วยคลิกเดียว/อื่นๆ)

– ถือว่าปลายทาง “ลืมรหัสผ่าน” เป็นจุดสิ้นสุดการเข้าสู่ระบบในแง่ของกำลังเดรัจฉาน การจำกัดอัตรา และการป้องกันการล็อก

– ใช้แผ่นโกงการตรวจสอบสิทธิ์ OWASP

– ใช้การรับรองความถูกต้องด้วยหลายปัจจัยทุกที่และทุกเวลาที่เป็นไปได้

– ตรวจสอบรหัสผ่านที่ไม่รัดกุม

– ควรใช้คีย์ API สำหรับการตรวจสอบสิทธิ์แอปไคลเอ็นต์ แต่ไม่ใช่การตรวจสอบสิทธิ์ผู้ใช้

3. API3: 2019 การเปิดเผยข้อมูลมากเกินไป

นักพัฒนา นักออกแบบ และ/หรือวิศวกรอาจไม่คำนึงถึงความละเอียดอ่อนของข้อมูล พวกเขาอาจชอบใช้การกรองฝั่งไคลเอ็นต์ ซึ่งหมายความว่าข้อมูลจะไม่ถูกกรองก่อนเข้าถึงผู้ใช้

เมื่อทำการทดสอบ ให้ถามว่า “ผู้ใช้ควรรู้อะไร” และแสดงจำนวนข้อมูลขั้นต่ำที่จำเป็น

การลดผลกระทบ

– ทดสอบหรือดักจับการเรียก API (โดยใช้ เช่น Postman หรือ OWASP ZAP) และมองหา “โทเค็น” หรือ “คีย์” เพื่อดูว่าจะเปิดเผยอะไร

– ภัยคุกคามจำลองข้อมูลเพื่อตรวจสอบโฟลว์และการกรองข้อมูล

– ไม่ต้องพึ่งพาการกรองข้อมูลที่สำคัญในฝั่งไคลเอ็นต์

– ตรวจสอบการตอบสนองของ API พวกเขามีข้อมูลที่ถูกต้องหรือไม่?

– กำหนดประเภทข้อมูลที่ข้ามเส้นลวด มีความละเอียดอ่อน เป็นความลับ PII ฯลฯ หรือไม่? หากใช่ แสดงว่าอาจเป็นภัยคุกคามด้านความปลอดภัยและความเป็นส่วนตัว

แง่มุมที่สำคัญของการรักษาความปลอดภัยและการจัดการความเสี่ยงคือการยอมรับว่าไม่มีสิ่งใดที่ปลอดภัย 100% หรือปราศจากความเสี่ยง มีความเสี่ยงอยู่เสมอ แนวคิดหนึ่งในการป้องกันตัวเองดูเหมือนยาก คนที่เดินสูงและมั่นใจ ไม่มีเครื่องประดับหรือกระเป๋าเงินที่มองเห็นได้ และไม่ฟุ้งซ่านถือเป็นเป้าหมายที่ยากกว่าการถูกไล่ล่ามากกว่าคนที่ทรุดโทรม เกียจคร้าน มีสร้อยคอและสร้อยข้อมือที่มองเห็นได้ และกำลังคุยโทรศัพท์อยู่ (ฟุ้งซ่าน) อดีตไม่ได้ขจัดความเสี่ยง แต่นำเสนอความเสี่ยงที่ลดลงอย่างมาก

การรักษาความปลอดภัย API จำเป็นต้องย้ายไปสู่ท่าทางที่มั่นใจและรูปแบบความเสี่ยงที่ลดลง ผู้โจมตีกำลังมองหา OWASP API 10 อันดับแรกและรายการกลไกการโจมตีทั่วไปอื่นๆ จากนั้นจึงนำไปใช้กับเป้าหมาย API ที่พลาดสิ่งเหล่านี้มีความเสี่ยงมากกว่าองค์กรที่จัดการเรื่องนี้ แม้ว่าจะมีปัญหาด้านความปลอดภัยอื่นๆ อยู่บ้าง (และมีปัญหาด้านความปลอดภัยอยู่เสมอ) แต่ถ้าผู้โจมตีมีช่วงเวลาที่ยากลำบากในการโจมตีเป้าหมาย ก็มีแนวโน้มที่พวกเขาจะเดินหน้าต่อไป ความท้าทายที่สำคัญสำหรับองค์กรคือไม่มีใครรู้ว่าผู้โจมตีกำลังทำอะไรเมื่อไรหรือกำลังทำอะไร ดังนั้นการรักษาความมั่นคงปลอดภัยจึงเป็นความท้าทายอีกประการหนึ่ง (คิดว่าเป็นการรักษาความปลอดภัยในงาน) วิธีหนึ่งในการทำความคุ้นเคยกับความปลอดภัยของ API ให้ดีขึ้นคือการตรวจสอบปัจจัยพื้นฐาน

การมุ่งความสนใจไปที่บางรายการที่มีความเสี่ยงสูงไม่สามารถแก้ไขช่องโหว่ทั้งหมดได้ แต่การมุ่งเน้นดังกล่าวจะให้คำแนะนำในทันทีสำหรับทีมวิศวกรรม นักพัฒนา ความปลอดภัย และความเป็นส่วนตัว ในทางกลับกัน นี่เป็นแผนงานสำหรับโครงการและงาน และป้องกันไม่ให้เกิดความประมาทเลินเล่อ การตอบสนองเชิงรุกและมีส่วนร่วมเหล่านี้ต่อช่องโหว่ที่ทราบช่วยเพิ่มความปลอดภัยของบริการและความไว้วางใจของลูกค้า

https://www.cybersecurity-insiders.com/api-attack-types-and-mitigations/