DeviceCheck และ App Attest: เกราะป้องกันแอป iOS จากกลโกง
เจาะลึกวิธีใช้ DeviceCheck และ App Attest สองเฟรมเวิร์กจาก Apple เพื่อปิดช่องโหว่บอต ฟาร์มซิมูเลเตอร์ และการโกงโปรโมชันในแอป iOS
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- HTTPS เข้ารหัสการเชื่อมต่อแต่ไม่ยืนยันตัวตนไคลเอนต์
- DeviceCheck (iOS 11+) ให้สตอเรจ 2 บิตต่ออุปกรณ์ที่รอดพ้นจากการลบแอป
- App Attest (iOS 14+) ใช้ Secure Enclave สร้างกุญแจยืนยันความถูกต้องของคำขอ
- เซิร์ฟเวอร์ต้องตรวจสอบความถูกต้องด้วยตนเองเพื่อป้องกันการปลอมแปลง
คำขอที่ส่งเข้ามายังจุดสิ้นสุด API ของคุณไม่ว่าจะเป็น POST /api/redeem จะมีหน้าตาเหมือนกันทั้งหมด ไม่ว่าจะส่งมาจากแอปพลิเคชันบน iPhone ของแท้ จากแอปที่ถูกดัดแปลงบนเครื่องที่เจลเบรกแล้ว หรือจากสคริปต์ Python ที่เขียนขึ้นหลังจากมีคนดักจับข้อมูลการรับส่งด้วย Charles Proxy โปรโตคอล HTTPS ยืนยันเพียงแค่ว่าการเชื่อมต่อถูกเข้ารหัส แต่ไม่ได้การันตีตัวตนของไคลเอนต์ที่อยู่ปลายทางเลยแม้แต่น้อย
บริษัท Apple ได้จัดเตรียมเฟรมเวิร์กสองตัวเพื่อเข้ามาอุดรอยรั่วนี้ บทความนี้จะพาไปทำความเข้าใจถึงสิ่งที่แต่ละเฟรมเวิร์กการันตี สิ่งที่ทำไม่ได้ และแนวทางการใช้งานอย่างถูกต้องโดยไม่ตกหลุมพรางที่มักพบบ่อยในคู่มือทั่วไป
เฟรมเวิร์กแรกคือ DeviceCheck (รองรับตั้งแต่ iOS 11 ขึ้นไป) ซึ่งทำหน้าที่หลักสองประการ ได้แก่ ยืนยันว่าโทเค็นมาจากอุปกรณ์ Apple ของแท้ที่ติดตั้งแอปของคุณซึ่งผูกกับบัญชีนักพัฒนา และมอบพื้นที่จัดเก็บข้อมูลจำนวน 2 บิตต่ออุปกรณ์ต่อหนึ่งนักพัฒนาบนเซิร์ฟเวอร์ของ Apple พื้นที่ 2 บิตนี้ซึ่งเท่ากับ 4 สถานะ สามารถคงอยู่ได้แม้ว่าผู้ใช้จะลบและติดตั้งแอปใหม่ ซึ่งนั่นคือหัวใจสำคัญของมัน
ข้อจำกัดที่ควรทราบคือ DeviceCheck ไม่ได้ตรวจจับการเจลเบรก ไม่ได้บอกว่าไบนารีของแอปถูกแก้ไขหรือไม่ และไม่ใช่การยืนยันตัวตนผู้ใช้ สตอเรจขนาด 2 บิตนี้ช่วยตอบคำถามที่แฟล็กในเครื่องทำไม่ได้ เช่น ผู้ใช้ที่ลบแอป ติดตั้งใหม่ และสร้างบัญชีใหม่ ก็ยังคงเข้าถึงข้อมูล 2 บิตชุดเดิมได้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การใช้โทเค็นจากฟังก์ชัน generateToken ของ DeviceCheck มีข้อควรระวังสำคัญคือต้องถือว่าเป็นโทเค็นแบบใช้ครั้งเดียว แม้ว่าจะยังคงใช้งานได้นานพอสำหรับการลองส่งคำขอซ้ำในกรณีที่เจอปัญหาเฉพาะกิจ แต่ไม่ควรนำโทเค็นเดิมกลับมาใช้ซ้ำหลายครั้ง นักพัฒนาควรสร้างโทเค็นใหม่สำหรับทุก ๆ คำขอที่ส่งเข้ามา เพื่อความปลอดภัยสูงสุดและป้องกันการถูกดักข้อมูลนำไปเล่นซ้ำ
เฟรมเวิร์กตัวที่สองคือ App Attest (รองรับตั้งแต่ iOS 14 ขึ้นไป) ซึ่งเข้ามาตอบโจทย์ที่ยากกว่าเดิม นั่นคือการตรวจสอบว่าคำขอนี้มาจากสำเนาแอปที่ไม่มีการดัดแปลงแก้ไขใช่หรือไม่ โดยระบบจะทำงานด้วยการสร้างคู่กุญแจ (Key Pair) ขึ้นภายในฮาร์ดแวร์ Secure Enclave ของอุปกรณ์ กุญแจส่วนตัว (Private Key) จะไม่มีวันหลุดออกจากฮาร์ดแวร์และไม่สามารถคัดลอกออกไปได้ จากนั้น Apple จะออกใบรับรอง (Certificate Chain) เพื่อรับรองว่ากุญแจนี้เป็นของแอปเวอร์ชันแท้ที่มี Team ID และ Bundle ID ของคุณกำกับอยู่
"App Attest turns 'rate limit the abuse' into 'the abuse's cannot reach the endpoint.'"
Dev.to
กระบวนการทำงานจะแบ่งออกเป็นสองเฟสสำคัญ ได้แก่ การออกใบรับรอง (Attestation) ซึ่งเกิดขึ้นหนึ่งครั้งต่อการติดตั้งกุญแจและเกี่ยวข้องกับเซิร์ฟเวอร์ของ Apple ซึ่งมีต้นทุนสูง และการยืนยันตัวตน (Assertion) ที่เกิดขึ้นกับทุกคำขอในเวลาต่อมาซึ่งมีต้นทุนต่ำและไม่ต้องผ่านเซิร์ฟเวอร์ของ Apple อีก เซิร์ฟเวอร์ของคุณจะทำหน้าที่ตรวจสอบความถูกต้องด้วยกุญแจสาธารณะที่จัดเก็บไว้
ความร่วมมือของทั้งสองเครื่องมือนี้ช่วยแก้ปัญหาในหลายมิติ เช่น การบล็อกทราฟฟิกบอตและการโจมตีด้วยการสวมรอยข้อมูล (Credential Stuffing) การป้องกันการใช้ซิมูเลเตอร์ฟาร์มบัญชีฟรี การจัดการการใช้โปรโมชันซ้ำ และการตรวจจับแอปที่ถูกแก้ไขแพตช์ไฟล์ IPA เพื่อข้ามการตรวจสอบใบรับรอง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น