ช่องโหว่ OAuth และรูปแบบการโจมตี

เซิร์ฟเวอร์การอนุญาต OAuth ต้องตรวจสอบพารามิเตอร์ redirect_uri อย่างเคร่งครัด หากเซิร์ฟเวอร์ยอมรับการจับคู่คำนำหน้าหรือการจับคู่แบบไวลด์การ์ด (เช่น ยอมรับ URL ใด ๆ ที่ขึ้นต้นด้วย "https://app.example.com") ผู้โจมตีอาจสร้างคำขอการอนุญาตที่เปลี่ยนเส้นทางไปยัง "https://app.example.com.attacker.com/steal" หรือไปยังการเปลี่ยนเส้นทางแบบเปิดบนโดเมนที่ถูกต้อง เพื่อขโมยรหัสการอนุญาต

หากไม่มีการป้องกัน CSRF ผู้โจมตีสามารถเริ่มกระบวนการ OAuth และหลอกเบราว์เซอร์ของเหยื่อให้ดำเนินการอนุญาตจนเสร็จสิ้น เหยื่อจะอนุญาตไคลเอ็นต์ของผู้โจมตีโดยไม่ตั้งใจ พารามิเตอร์ "state" (RFC 6749) ป้องกันเหตุการณ์นี้ได้ โดยไคลเอ็นต์สร้าง state แบบสุ่ม ใส่ไว้ในคำขอ และตรวจสอบว่าในข้อมูลเรียกกลับมีค่าตรงกัน หากไม่ตรงกัน ให้ยกเลิกกระบวนการ

บนแพลตฟอร์มอุปกรณ์เคลื่อนที่ แอปที่เป็นอันตรายสามารถลงทะเบียนโครงร่าง URI แบบกำหนดเองเดียวกับไคลเอ็นต์ OAuth ที่ถูกต้อง และดักจับรหัสการอนุญาตที่เปลี่ยนเส้นทางหลังจากผู้ใช้ตรวจสอบสิทธิ์แล้ว PKCE (RFC 7636) เป็นการป้องกันที่สมบูรณ์ รหัสที่ถูกดักจับจะไม่มีประโยชน์หากไม่มีตัวตรวจสอบรหัสที่มีเพียงแอปที่ถูกต้องเท่านั้นที่สร้างไว้ตั้งแต่เริ่มกระบวนการ

เมื่อโทเค็น ID หรือโทเค็นการเข้าถึงอยู่ในแฟรกเมนต์ของ URL หรือพารามิเตอร์คำค้น การนำทางต่อจากหน้านั้นจะส่ง URL ในส่วนหัว Referer ซึ่งอาจทำให้โทเค็นรั่วไหลไปยังสคริปต์วิเคราะห์ข้อมูลของบุคคลที่สามหรือผู้ให้บริการ CDN ควรใช้กระบวนการรหัสการอนุญาตที่ส่งโทเค็นผ่านช่องทางเบื้องหลังเสมอ เพื่อไม่ให้โทเค็นปรากฏใน URL

เมื่อไคลเอ็นต์รองรับผู้ให้บริการ OAuth หลายราย การโจมตีแบบสับเปลี่ยนจะหลอกให้ไคลเอ็นต์ส่งรหัสการอนุญาตที่ได้รับจากผู้ให้บริการ A ไปยังจุดปลายทางโทเค็นของผู้ให้บริการ B ไคลเอ็นต์ต้องตรวจสอบข้ออ้างสิทธิ์ "iss" ในโทเค็น ID และผูกข้อมูลเรียกกลับเข้ากับผู้ให้บริการเฉพาะรายที่เริ่มกระบวนการ โดยใช้พารามิเตอร์ state หรือ JARM (โหมดการตอบกลับการอนุญาตที่รักษาความปลอดภัยด้วย JWT)

การโจมตีแบบปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF) มุ่งเป้าไปที่การนำ OAuth ไปใช้ซึ่งส่งคำขอ HTTP ฝั่งเซิร์ฟเวอร์ไปยัง redirect_uri หากเซิร์ฟเวอร์การอนุญาตดึงข้อมูลจาก redirect_uri เพื่อยืนยัน ผู้โจมตีอาจระบุที่อยู่ IP ภายใน (เช่น http://169.254.169.254/latest/meta-data/) เพื่อเข้าถึงข้อมูลเมทาดาทาของอินสแตนซ์คลาวด์หรือบริการภายใน การตรวจสอบ redirect_uri อย่างเคร่งครัดโดยอาศัยรายการอนุญาตจะป้องกันการโจมตีนี้

แอปพลิเคชันจำนวนมากใช้ข้ออ้างสิทธิ์อีเมลจากโทเค็น ID ของ OIDC เพื่อเชื่อมโยงบัญชีข้ามผู้ให้บริการ หากผู้โจมตีควบคุมที่อยู่อีเมลที่ตรงกับบัญชีของเหยื่อในผู้ให้บริการรายอื่น ผู้โจมตีสามารถลงทะเบียนกับผู้ให้บริการอื่นโดยใช้อีเมลดังกล่าวและเข้าถึงบัญชีของเหยื่อได้ การป้องกันคือเชื่อมโยงบัญชีด้วยคู่ (iss, sub) เท่านั้น ห้ามใช้เพียงอีเมล

การโจมตีแบบสร้างความสับสนของอัลกอริทึม JWT อาศัยการนำไปใช้ที่เชื่อถือส่วนหัว "alg" เพื่อเลือกอัลกอริทึมตรวจสอบ การโจมตีทำโดยเปลี่ยน "alg" จาก "RS256" เป็น "HS256" แล้วลงลายเซ็นโทเค็นด้วยคีย์สาธารณะของเซิร์ฟเวอร์ในฐานะข้อมูลลับของ HMAC (เนื่องจากคีย์สาธารณะเปิดเผยอยู่แล้ว) การป้องกันคือระบุอัลกอริทึมที่คาดหมายไว้อย่างชัดเจนในโค้ดตรวจสอบเสมอ และอย่าเชื่อถือข้ออ้างสิทธิ์ alg ในส่วนหัวโทเค็น

ผู้โจมตีลงทะเบียนไคลเอ็นต์ OAuth ที่เป็นอันตรายโดยใช้ชื่อและโลโก้ที่ดูน่าเชื่อถือ แล้วส่งลิงก์ฟิชชิงไปยังเป้าหมาย เหยื่อจะเห็นหน้าจอคำยินยอม OAuth ของจริง (โฮสต์โดย Google, Microsoft และอื่น ๆ) สำหรับแอปพลิเคชันที่เป็นอันตราย แล้วอนุญาตให้เข้าถึง การป้องกันคือตรวจสอบว่า client_id สอดคล้องกับแอปพลิเคชันที่คาดหมาย Google และ Microsoft มีโครงการตรวจสอบไคลเอ็นต์สำหรับแอปพลิเคชันที่ถูกต้อง

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

ป้องกันการนำ OAuth ไปใช้ด้วยวิธีต่อไปนี้ ตรวจสอบ redirect_uri ให้ตรงกันทุกประการ กำหนดให้ไคลเอ็นต์สาธารณะทุกประเภทใช้ PKCE ตรวจสอบพารามิเตอร์ state เพื่อป้องกัน CSRF ผูกโทเค็น ID ด้วย (iss, sub) ไม่ใช่อีเมล ระบุอัลกอริทึม JWT ที่คาดหมายไว้อย่างชัดเจน ขอขอบเขตเท่าที่จำเป็น ใช้โทเค็นการเข้าถึงที่มีอายุสั้นพร้อมการหมุนเวียนโทเค็นการต่ออายุ และตรวจสอบลักษณะของหน้าจอคำยินยอมเพื่อประเมินความเสี่ยงจากการปลอมแปลงแบรนด์

เซิร์ฟเวอร์การอนุญาต OAuth ยอมรับ redirect_uri ใด ๆ ที่ขึ้นต้นด้วย "https://app.example.com" การดำเนินการนี้เปิดให้เกิดการโจมตีใด

การโจมตี OAuth ที่สำคัญ ได้แก่ การเปลี่ยนเส้นทางแบบเปิดจากการตรวจสอบ redirect_uri ที่หละหลวม (ใช้การจับคู่ที่ตรงกันทุกประการ) CSRF จากการไม่มีพารามิเตอร์ state การดักจับรหัสบนอุปกรณ์เคลื่อนที่ (บรรเทาได้ด้วย PKCE) โทเค็นรั่วไหลใน URL การโจมตีแบบสับเปลี่ยนในระบบที่มีผู้ให้บริการหลายราย (ตรวจสอบ iss) SSRF จาก redirect_uri ที่เซิร์ฟเวอร์ดึงข้อมูล การชนกันของข้ออ้างสิทธิ์อีเมล (ใช้ iss+sub) ความสับสนของอัลกอริทึม JWT (กำหนด alg ที่คาดหมาย) และฟิชชิงผ่านหน้าจอคำยินยอมปลอม