วิธีป้องกัน Webhook Replay Attack ใน Node.js ด้วย PostgreSQL
เจาะลึกวิธีบล็อกการโจมตีเว็บฮุกซ้ำซ้อนและการส่งคำขอเบิ้ลด้วยระบบฐานข้อมูล PostgreSQL และ Node.js พร้อมโค้ด SQL และมิดเดิลแวร์ Express
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การตรวจสอบลายเซ็น (Signature) อย่างเดียวไม่เพียงพอต่อการป้องกัน Replay Attack
- การใช้ฐานข้อมูล PostgreSQL ร่วมกับ Unique Constraint ช่วยป้องกันคำขอซ้ำได้ระดับฮาร์ดแวร์
- การสร้างตาราง processed_webhooks และ Index ช่วยให้ค้นหาเหตุการณ์ที่เคยประมวลผลแล้วได้อย่างรวดเร็ว
- ระบบมิดเดิลแวร์ใน Express ช่วยคัดกรองข้อมูลก่อนส่งต่อไปยังส่วนประมวลผลหลัก
การจัดการเว็บฮุกสำหรับระบบชำระเงินอาจดูเป็นเรื่องง่าย จนกระทั่งเซิร์ฟเวอร์ของคุณต้องเจอกับปัญหานโยบายส่งข้อมูลซ้ำจากเครือข่ายถึง 3 ครั้งติด หรือถูกผู้ไม่หวังดีดักจับข้อมูลที่ถูกต้องแล้วนำกลับมาส่งซ้ำเพื่อพยายามเพิ่มยอดเงินในบัญชีของตนเองสองครั้ง การตรวจสอบลายเซ็นถือเป็นขั้นตอนแรกที่สำคัญ แต่ก็ยังไม่สามารถป้องกันการโจมตีแบบ Replay Attack ที่นำข้อมูลที่ถูกต้องแต่เคยส่งไปแล้วกลับมารisend ใหม่ได้ บทความนี้จะมาแนะนำวิธีการสร้างระบบป้องกันหลายชั้นด้วย Node.js และ PostgreSQL เพื่อให้มั่นใจว่าทุก ๆ เพย์โหลดของเว็บฮุกจะถูกประมวลผลเพียงครั้งเดียวเท่านั้น
แม้ว่านักพัฒนาหลายคนอาจเลือกใช้ Redis ในการจัดเก็บรหัสเหตุการณ์ที่ประมวลผลแล้ว แต่หากระบบแคชเกิดการล้างข้อมูล (Flush) หรือคอนเทนเนอร์รีสตาร์ทในช่วงที่มีปริมาณการใช้งานหนาแน่น คุณก็อาจสูญเสียสถานะข้อมูลเหล่านั้นไปได้ การหันมาใช้ PostgreSQL พร้อมกับฟีเจอร์ Unique Constraint จึงเข้ามาช่วยรับประกันความปลอดภัยในระดับฐานข้อมูลได้อย่างแท้จริง หากมีคำขอที่เหมือนกันเป๊ะสองรายการวิ่งเข้ามาที่แบ็กเอนด์ในเสี้ยววินาทีเดียวกัน ระบบล็อกของ Postgres จะจัดการระงับและตัดรายการที่ซ้ำออกไปทันที
การเลือกใช้ฐานข้อมูลเชิงสัมพันธ์อย่าง PostgreSQL แทนแคชความเร็วสูงอย่าง Redis ในกรณีนี้ มีจุดเด่นสำคัญคือความคงทนของข้อมูล (Durability) ที่เหนือกว่า แม้เซิร์ฟเวอร์จะล่มกะทันหัน ข้อมูลประวัติการรับเว็บฮุกจะไม่หายไป ช่วยป้องกันความเสี่ยงเรื่องการจ่ายเงินซ้ำซ้อนซึ่งเป็นหัวใจสำคัญของระบบฟินเทค
สำหรับการสร้างโครงสร้างฐานข้อมูล นักพัฒนาสามารถนำชุดคำสั่ง SQL ด้านล่างนี้ไปปรับใช้เพื่อติดตามเหตุการณ์เว็บฮุกที่เข้ามาในระบบได้ทันที:
- สร้างตาราง processed_webhooks พร้อมคอลัมน์ id, event_id, signature และ created_at
- กำหนดค่า UNIQUE บนคอลัมน์ event_id เพื่อป้องกันการบันทึกข้อมูลซ้ำ
- สร้าง Index บนคอลัมน์ event_id เพื่อเร่งความเร็วในการค้นหาข้อมูลขาเข้า
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในส่วนของการพัฒนาฝั่ง Express Middleware ระบบตรวจสอบความปลอดภัยจะทำหน้าที่คัดกรองสิ่งสำคัญสามประการก่อนที่จะอนุญาตให้มีการรันจุดสัมผัสข้อมูล (Touch Point Execution) การออกแบบความปลอดภัยของเว็บฮุกในลักษณะนี้จะช่วยปกป้องระบบของคุณได้เป็นอย่างดี แม้ว่าผู้ให้บริการระบบชำระเงินจะทำการส่งข้อมูลซ้ำถี่แค่ไหน หรือผู้ประสงค์ร้ายจะพยายามส่งข้อมูลเก่ากลับมาก็ตาม
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น