เมื่อระบบชำระเงินถูกเจาะ: ได้ของฟรีโดยไม่จ่ายเงินได้อย่างไรด้วยช่องโหว่ IDOR

เมื่อระบบชำระเงินถูกเจาะ: ได้ของฟรีโดยไม่จ่ายเงินได้อย่างไรด้วยช่องโหว่ IDOR

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

เข้าใจ IDOR คืออะไร?

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

จินตนาการว่าคุณมีรหัสสินค้า product_id=123 ใน URL ถ้าคุณเปลี่ยนเป็น product_id=124 แล้วเห็นสินค้าอีกชิ้นที่คุณไม่ได้เป็นเจ้าของ นั่นแหละคือ IDOR

ช่องโหว่ IDOR ในระบบชำระเงินเกิดขึ้นได้อย่างไร?

เรื่องราวเริ่มต้นเมื่อมีคนต้องการซื้อสินค้าหรือบริการ เช่น ประกันภัย ระบบจะสร้าง policyid ที่ไม่ซ้ำกันขึ้นมาก่อนที่จะมีการชำระเงินจริง โดยสมมติว่า policyid นี้คือ 456

จากนั้นผู้ซื้อก็จะเข้าสู่ขั้นตอนการชำระเงิน ระบบจะส่ง policy_id นี้ไปยัง payment gateway เพื่อดำเนินการ Payment gateway ทำหน้าที่จัดการการชำระเงินและเมื่อสำเร็จก็จะส่งข้อมูล callback กลับมายังเซิร์ฟเวอร์ของร้านค้าเพื่อยืนยันว่าการชำระเงินเสร็จสมบูรณ์แล้ว

ปัญหาใหญ่เกิดจากการที่เซิร์ฟเวอร์ของร้านค้า เชื่อใจ ข้อมูลที่ส่งมาใน callback URL มากเกินไป โดยเฉพาะอย่างยิ่งกับค่า policy_id ที่ส่งมาพร้อมกัน เช่น /payment_callback?policy_id=456&status=success

ผู้โจมตีสามารถฉวยโอกาสตรงนี้ได้ด้วยการ:

1. เริ่มกระบวนการชำระเงินสำหรับ policy_id ของตนเอง (สมมติว่าเป็น 123) แต่ยังไม่ต้องจ่ายจริง
2. เมื่อระบบเรียก payment gateway และได้ callback URL กลับมา ผู้โจมตีจะดักจับ callback URL นี้ไว้
3. ผู้โจมตีแก้ไข policyid ใน callback URL จาก 123 ให้เป็น policyid ของนโยบายที่ยังไม่จ่ายเงิน เช่น 456 แล้วส่ง callback ที่แก้ไขแล้วนี้กลับไปยังเซิร์ฟเวอร์ของร้านค้าด้วยตนเอง
4. เนื่องจากเซิร์ฟเวอร์เชื่อข้อมูลใน URL มันจึงคิดว่า policy_id 456 ได้รับการชำระเงินแล้ว และทำการออกกรมธรรม์หรือเปิดใช้งานบริการให้ทันที โดยที่ไม่มีเงินเข้าจริง

ผลกระทบที่ร้ายแรงและน่าตกใจ

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

ป้องกันอย่างไรไม่ให้ตกเป็นเหยื่อ?

หัวใจสำคัญของการป้องกันคือ ห้ามเชื่อข้อมูลที่มาจากฝั่งผู้ใช้งานหรือภายนอกระบบแบบสุ่มสี่สุ่มห้าเด็ดขาด ควรมีการ ตรวจสอบฝั่งเซิร์ฟเวอร์ อย่างเข้มงวดทุกครั้ง:

• สร้างและตรวจสอบ Transaction ID ที่ไม่ซ้ำกัน: เมื่อส่งข้อมูลไปยัง payment gateway ควรสร้าง transaction ID ที่ไม่ซ้ำกันขึ้นมา และเก็บไว้ในฐานข้อมูลฝั่งเซิร์ฟเวอร์ เมื่อได้รับ callback กลับมา ให้ใช้ transaction ID ที่ได้จาก callback ไปตรวจสอบกับ payment gateway อีกครั้งว่าการชำระเงินนั้นถูกต้องและตรงกับ transaction ID ที่เราสร้างไว้หรือไม่
• ผูกข้อมูลอย่างรัดกุม: อย่าผูก policy_id โดยตรงกับ callback URL ควรใช้ transaction ID ที่สร้างขึ้นภายในเท่านั้นในการอ้างอิงและยืนยันสถานะการชำระเงิน
• ใช้ลายเซ็นดิจิทัล (Cryptographic Signatures): Payment gateway มักจะมีฟังก์ชันสำหรับตรวจสอบ ลายเซ็นดิจิทัล หรือ Hash ของข้อมูลใน callback ซึ่งช่วยยืนยันความถูกต้องและความสมบูรณ์ของข้อมูลว่าไม่ถูกแก้ไขระหว่างทาง
• จัดการสถานะอย่างรัดกุม: นโยบายหรือคำสั่งซื้อควรเปลี่ยนสถานะเป็น “ชำระเงินแล้ว” ก็ต่อเมื่อได้รับ การยืนยันจาก payment gateway และผ่านการ ตรวจสอบความถูกต้อง ฝั่งเซิร์ฟเวอร์อย่างสมบูรณ์แล้วเท่านั้น

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