ช่องโหว่ OATH API ยอดนิยม
ช่องโหว่ OATH API ยอดนิยม: บทนำ
เมื่อพูดถึงการหาประโยชน์ API เป็นจุดเริ่มต้นที่ดีที่สุด API การเข้าถึงมักประกอบด้วยสามส่วน ไคลเอนต์จะออกโทเค็นโดย Authorization Server ซึ่งทำงานควบคู่กับ API API ได้รับโทเค็นการเข้าถึงจากลูกค้าและใช้กฎการให้สิทธิ์เฉพาะโดเมนตามนั้น
แอพพลิเคชั่นซอฟต์แวร์สมัยใหม่มีความเสี่ยงต่ออันตรายต่างๆ ติดตามช่องโหว่ล่าสุดและข้อบกพร่องด้านความปลอดภัย การมีเกณฑ์มาตรฐานสำหรับช่องโหว่เหล่านี้เป็นสิ่งสำคัญในการรับประกันความปลอดภัยของแอปพลิเคชันก่อนที่จะเกิดการโจมตี แอปพลิเคชันของบุคคลที่สามใช้โปรโตคอล OAuth มากขึ้นเรื่อยๆ ผู้ใช้จะได้รับประสบการณ์การใช้งานโดยรวมที่ดีขึ้น เช่นเดียวกับการเข้าสู่ระบบและการอนุญาตที่เร็วขึ้น ด้วยเทคโนโลยีนี้ อาจมีความปลอดภัยมากกว่าการให้สิทธิ์แบบเดิม เนื่องจากผู้ใช้ไม่จำเป็นต้องเปิดเผยข้อมูลประจำตัวของตนกับแอปพลิเคชันของบุคคลที่สามเพื่อเข้าถึงทรัพยากรที่กำหนด แม้ว่าโปรโตคอลจะปลอดภัย แต่วิธีการนำไปใช้อาจทำให้คุณถูกโจมตีได้
เมื่อออกแบบและโฮสต์ API บทความนี้จะมุ่งเน้นไปที่ช่องโหว่ OAuth ทั่วไป รวมถึงการบรรเทาความปลอดภัยต่างๆ
การอนุญาตระดับวัตถุที่ใช้งานไม่ได้
มีพื้นผิวการโจมตีมากมายหากการอนุญาตถูกละเมิด เนื่องจาก API ให้การเข้าถึงอ็อบเจ็กต์ เนื่องจากต้องตรวจสอบความถูกต้องของรายการที่เข้าถึง API ได้ จึงมีความจำเป็น ใช้การตรวจสอบการให้สิทธิ์ระดับวัตถุโดยใช้เกตเวย์ API เฉพาะผู้ที่มีข้อมูลการอนุญาตที่เหมาะสมเท่านั้นที่ควรได้รับอนุญาตให้เข้าถึง
การตรวจสอบผู้ใช้ที่ใช้งานไม่ได้
โทเค็นที่ไม่ได้รับอนุญาตเป็นอีกวิธีที่ผู้โจมตีเข้าถึง API ได้บ่อยครั้ง ระบบการตรวจสอบสิทธิ์อาจถูกแฮ็กหรือคีย์ API อาจถูกเปิดเผยโดยไม่ได้ตั้งใจ โทเค็นการรับรองความถูกต้องอาจเป็น ใช้โดยแฮกเกอร์ เพื่อรับการเข้าถึง ตรวจสอบบุคคลเฉพาะเมื่อเชื่อถือได้ และใช้รหัสผ่านที่รัดกุม ด้วย OAuth คุณจะทำได้มากกว่าแค่คีย์ API และเข้าถึงข้อมูลของคุณได้ คุณควรคิดเสมอว่าคุณจะเข้าและออกจากสถานที่ได้อย่างไร โทเค็นที่มีข้อจำกัดของผู้ส่ง OAuth MTLS อาจใช้ร่วมกับ Mutual TLS เพื่อรับประกันว่าไคลเอนต์จะไม่ทำงานผิดปกติและส่งต่อโทเค็นไปยังบุคคลที่ไม่ถูกต้องในขณะที่เข้าถึงเครื่องอื่น
การส่งเสริม API:
การเปิดเผยข้อมูลมากเกินไป
ไม่มีข้อจำกัดเกี่ยวกับจำนวนปลายทางที่สามารถเผยแพร่ได้ ส่วนใหญ่แล้ว ฟีเจอร์บางอย่างอาจไม่พร้อมใช้งานสำหรับผู้ใช้ทุกคน การเปิดเผยข้อมูลมากเกินความจำเป็น คุณทำให้ตัวคุณเองและผู้อื่นตกอยู่ในอันตราย หลีกเลี่ยงการเปิดเผยที่ละเอียดอ่อน ข้อมูล จนกว่าจะมีความจำเป็นอย่างยิ่ง นักพัฒนาสามารถระบุได้ว่าใครสามารถเข้าถึงอะไรได้โดยใช้ขอบเขตและการอ้างสิทธิ์ OAuth การอ้างสิทธิ์อาจระบุว่าส่วนใดของข้อมูลที่ผู้ใช้สามารถเข้าถึงได้ การควบคุมการเข้าถึงอาจทำได้ง่ายขึ้นและจัดการได้ง่ายขึ้นโดยใช้โครงสร้างมาตรฐานใน API ทั้งหมด
การขาดทรัพยากรและการจำกัดอัตรา
กลุ่ม Black Hat มักจะใช้การโจมตีแบบปฏิเสธการให้บริการ (DoS) เป็นวิธีที่ใช้ความรุนแรงในการครอบงำเซิร์ฟเวอร์ และลดเวลาในการทำงานลงเหลือศูนย์ เนื่องจากไม่มีข้อจำกัดเกี่ยวกับทรัพยากรที่อาจถูกเรียกใช้ API จึงเสี่ยงต่อการถูกโจมตีที่บั่นทอน 'การใช้เกตเวย์ API หรือเครื่องมือการจัดการ คุณอาจกำหนดข้อจำกัดด้านอัตราสำหรับ API ได้ ควรรวมการกรองและการแบ่งหน้า เช่นเดียวกับคำตอบที่ถูกจำกัด
การกำหนดค่าผิดพลาดของระบบรักษาความปลอดภัย
แนวทางการกำหนดค่าความปลอดภัยที่แตกต่างกันนั้นค่อนข้างครอบคลุม เนื่องจากมีความเป็นไปได้สูงที่การกำหนดค่าความปลอดภัยจะผิดพลาด สิ่งเล็กน้อยหลายอย่างอาจเป็นอันตรายต่อความปลอดภัยของแพลตฟอร์มของคุณ เป็นไปได้ว่ากลุ่มหมวกดำที่มีจุดประสงค์แอบแฝงอาจค้นพบข้อมูลที่ละเอียดอ่อนที่ส่งไปเพื่อตอบสนองต่อข้อความค้นหาที่ผิดรูปแบบ ดังตัวอย่าง
งานมวลชน
เพียงเพราะไม่ได้กำหนดจุดสิ้นสุดแบบสาธารณะไม่ได้หมายความว่าไม่สามารถเข้าถึงได้โดยนักพัฒนา API ลับอาจถูกดักจับและทำวิศวกรรมย้อนกลับโดยแฮ็กเกอร์ได้อย่างง่ายดาย ลองดูตัวอย่างพื้นฐานนี้ ซึ่งใช้ Bearer Token แบบเปิดใน API “ส่วนตัว” ในทางกลับกัน อาจมีเอกสารสาธารณะสำหรับบางสิ่งที่มีไว้สำหรับใช้ส่วนตัวโดยเฉพาะ ข้อมูลที่เปิดเผยอาจถูกใช้โดยหมวกดำเพื่อไม่เพียงแค่อ่านเท่านั้น แต่ยังปรับเปลี่ยนลักษณะของวัตถุอีกด้วย คิดว่าตัวเองเป็นแฮ็กเกอร์ในขณะที่คุณค้นหาจุดอ่อนที่อาจเกิดขึ้นในการป้องกันของคุณ อนุญาตให้เฉพาะผู้ที่มีสิทธิ์เข้าถึงสิ่งที่ส่งคืนเท่านั้น เพื่อลดช่องโหว่ ให้จำกัดแพ็คเกจการตอบสนอง API ผู้ตอบไม่ควรเพิ่มลิงก์ใดๆ ที่ไม่จำเป็นอย่างยิ่ง
API ที่ส่งเสริม:
การจัดการสินทรัพย์ที่ไม่เหมาะสม
นอกเหนือจากการเพิ่มประสิทธิภาพการทำงานของนักพัฒนาแล้ว เวอร์ชันปัจจุบันและเอกสารประกอบยังมีความสำคัญต่อความปลอดภัยของคุณเอง เตรียมการเปิดตัวเวอร์ชันใหม่และการเลิกใช้งาน API เก่าล่วงหน้า ใช้ API ที่ใหม่กว่าแทนที่จะปล่อยให้เก่ายังคงใช้งานอยู่ ข้อมูลจำเพาะ API สามารถใช้เป็นแหล่งความจริงหลักสำหรับเอกสารประกอบ
การฉีด
API มีความเสี่ยงที่จะถูกฉีด แต่ก็เป็นแอปของนักพัฒนาบุคคลที่สามเช่นกัน รหัสที่เป็นอันตรายอาจใช้เพื่อลบข้อมูลหรือขโมยข้อมูลที่เป็นความลับ เช่น รหัสผ่านและหมายเลขบัตรเครดิต บทเรียนที่สำคัญที่สุดที่จะนำมาจากสิ่งนี้คือการไม่ขึ้นอยู่กับการตั้งค่าเริ่มต้น การจัดการหรือผู้จัดหาเกตเวย์ของคุณควรสามารถรองรับความต้องการแอปพลิเคชันเฉพาะของคุณได้ ข้อความแสดงข้อผิดพลาดไม่ควรมีข้อมูลที่ละเอียดอ่อน เพื่อป้องกันไม่ให้ข้อมูลระบุตัวตนรั่วไหลออกนอกระบบ ควรใช้นามแฝง Pairwise ในโทเค็น สิ่งนี้ทำให้แน่ใจว่าไม่มีไคลเอนต์ใดที่ทำงานร่วมกันเพื่อระบุตัวผู้ใช้
การบันทึกและการตรวจสอบไม่เพียงพอ
เมื่อการโจมตีเกิดขึ้น ทีมต่างๆ จำเป็นต้องมีกลยุทธ์การโต้ตอบที่คิดมาอย่างดี นักพัฒนาจะยังคงใช้ประโยชน์จากช่องโหว่ต่อไปโดยไม่ถูกจับได้หากไม่มีระบบบันทึกและตรวจสอบที่เชื่อถือได้ ซึ่งจะเพิ่มความสูญเสียและสร้างความเสียหายต่อการรับรู้ของสาธารณชนที่มีต่อบริษัท ใช้กลยุทธ์การตรวจสอบ API ที่เข้มงวดและการทดสอบปลายทางการผลิต ผู้ทดสอบหมวกขาวที่พบช่องโหว่ตั้งแต่เนิ่นๆ ควรได้รับรางวัลเป็นเงินรางวัล เส้นทางบันทึกอาจได้รับการปรับปรุงโดยรวมข้อมูลประจำตัวของผู้ใช้ลงในธุรกรรม API ตรวจสอบให้แน่ใจว่าสถาปัตยกรรม API ของคุณทุกชั้นได้รับการตรวจสอบโดยใช้ข้อมูลโทเค็นการเข้าถึง
สรุป
สถาปนิกแพลตฟอร์มอาจติดตั้งระบบของตนเพื่อให้ล้ำหน้าผู้โจมตีไปหนึ่งก้าวโดยปฏิบัติตามเกณฑ์ช่องโหว่ที่กำหนดไว้ เนื่องจาก API อาจให้การเข้าถึงข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) การรักษาความปลอดภัยของบริการดังกล่าวจึงมีความสำคัญอย่างยิ่งต่อความมั่นคงของบริษัทและการปฏิบัติตามกฎหมาย เช่น GDPR ห้ามส่งโทเค็น OAuth โดยตรงผ่าน API โดยไม่ใช้ API Gateway และ Phantom Token Approach
API ที่ส่งเสริม:
