บทเรียนจาก 4 บั๊กที่ชุดทดสอบมองไม่ข้าม แต่พังในระบบจริง
นักพัฒนาแอปส่งข้อความเข้ารหัสเผยเบื้องหลังการพบบั๊ก 4 จุดที่ทำให้ข้อความหายและข้อมูลรั่วไหล แม้ชุดทดสอบทั้งหมดจะผ่านแบบ 100%
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ชุดทดสอบ 216 ข้อผ่านฉลุย แต่ฟีเจอร์ส่งข้อความออฟไลน์พังยับในระบบจริง
- ปัญหาระหว่างรอยต่อของส่วนประกอบคือจุดบอดที่การทดสอบแบบแยกส่วนตรวจไม่พบ
- การยืนยันการรับข้อความก่อนถอดรหัสทำให้เซิร์ฟเวอร์ลบข้อมูลทิ้งอย่างถาวร
- บทเรียนสำคัญคือการทดสอบบนสภาพแวดล้อมจริงช่วยหาบั๊กสำคัญเจอใน 10 นาที
การเขียนชุดทดสอบให้ผ่านครบทุกข้อไม่ได้หมายความว่าระบบจะทำงานได้อย่างไร้ที่ติ นักพัฒนาซอฟต์แวร์รายหนึ่งได้ออกมาแบ่งปันประสบการณ์ผ่านแพลตฟอร์ม Dev.to หลังจากที่เขาพัฒนาฟีเจอร์รับส่งข้อความแบบออฟไลน์สำหรับแอปพลิเคชันส่งข้อความเข้ารหัสแบบปลายทางต่อปลายทาง (End-to-End Encryption) โดยชุดทดสอบทั้ง 216 ข้อ ไม่ว่าจะเป็นยูนิตเทสต์สำหรับเลเยอร์จัดเก็บข้อมูล อินทิเกรตชันเทสต์กับฐานข้อมูล Postgres จริง หรือเอ็นด์ทูเอ็นด์เทสต์ผ่าน WebSocket ต่างก็ผ่านทั้งหมด แต่เมื่อนำไปทดสอบบนระบบจริงกลับพบข้อผิดพลาดร้ายแรงถึง 4 จุด
บั๊กตัวแรกเกิดขึ้นจากช่องว่างระหว่างเวลาที่ซ็อกเก็ตเปิดเชื่อมต่อกับการโหลดกุญแจถอดรหัสจากที่เก็บข้อมูลในเบราว์เซอร์ ซึ่งในสภาพแวดล้อมการทดสอบการโหลดกุญแจเกิดขึ้นในทันที แต่บนเครื่องจริงกระบวนการนี้เป็นแบบอะซิงโครนัส ส่งผลให้ข้อความที่เซิร์ฟเวอร์ส่งมาทันทีที่เชื่อมต่อถูกทิ้งไปเพราะยังไม่มีกุญแจสำหรับถอดรหัส
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ช่องว่างระหว่างการเชื่อมต่อเครือข่ายและการเตรียมพร้อมของแอปพลิเคชัน (Initialization Gap) เป็นจุดบอดคลาสสิกที่มักเกิดขึ้นในแอปพลิเคชันแบบเรียลไทม์ การจำลองสภาพแวดล้อมในเครื่องทดสอบมักจะตัดเรื่องดีเลย์ของการทำ I/O หรือการรอหน่วยความจำออกไป ทำให้นักพัฒนาประเมินจังหวะเวลา (Timing) พลาดไปเมื่อโค้ดต้องไปรันบนฮาร์ดแวร์และเครือข่ายจริง
ปัญหาที่สองมีความรุนแรงยิ่งกว่าเนื่องจากทำให้ข้อมูลสูญหาย เซิร์ฟเวอร์ถูกตั้งค่าให้ลบข้อความที่พักไว้ทันทีเมื่อไคลเอนต์ส่งสัญญาณยืนยัน แต่ไคลเอนต์กลับส่งสัญญาณยืนยันตั้งแต่วินาทีที่ข้อความเดินทางมาถึงซ็อกเก็ต ก่อนที่แอปพลิเคชันจะทันได้ถอดรหัส จัดเก็บ หรือแสดงผลให้ผู้ใช้เห็น ส่งผลให้ข้อความหายไปจากทั้งสองฝั่งอย่างถาวรโดยไม่มีการบันทึกไว้
บั๊กตัวที่สามเกี่ยวข้องกับตรรกะการจัดเก็บข้อมูลที่ไม่สมบูรณ์ ระบบถูกออกแบบให้บันทึกข้อความทุกฉลุยและลบออกเมื่อผู้รับยืนยันการรับ แต่สำหรับข้อความที่ส่งถึงผู้รับที่ออนไลน์อยู่ตลอดเวลา ข้อความจะถูกส่งตรงไปหาอีกฝ่ายทันทีโดยไม่ผ่านการจัดเก็บ ทำให้ไม่มีการยืนยันการรับและไม่มีการลบ ส่งผลให้เซิร์ฟเวอร์สะสมสำเนาบทสนทนาไว้เงียบ ๆ จนกว่าจะมีการล้างข้อมูลทุกสัปดาห์ ส่วนบั๊กตัวสุดท้ายคือการลบห้องแชตที่ทิ้งกุญแจเข้ารหัสไว้เบื้องหลัง ทำให้แอปพยายามกู้คืนบทสนทนาที่อีกฝั่งลบไปแล้วและไม่สามารถถอดรหัสได้อีกต่อไป
"สิ่งที่บั๊กเหล่านี้มีเหมือนกันคือ ทุกตัวอาศัยอยู่ตรงรอยต่อระหว่างส่วนประกอบ แต่ละส่วนประกอบทำงานได้อย่างถูกต้องเมื่อแยกจากกัน แต่ตัวระบบกลับทำงานไม่ได้"
นักพัฒนาผู้เขียนบทความบน Dev.toจากเหตุการณ์ดังกล่าวทำให้นักพัฒนาปรับเปลี่ยนแนวทางการทำงานใหม่ โดยกำหนดกฎเหล็กว่าโค้ดส่วนใดก็ตามที่ต้องสัมผัสกับที่เก็บข้อมูลจริง ระบบเครือข่ายจริง หรืออุปกรณ์เครื่องอื่น จะต้องถูกนำไปทดสอบบนบิวด์จริงที่เตรียมเผยแพร่เสมอ ไม่ใช่แค่บนเซิร์ฟเวอร์จำลองสำหรับการพัฒนา ซึ่งการทดสอบบนสภาพแวดล้อมจริงเพียงสิบนาทีก็เพียงพอที่จะค้นพบบั๊กที่ทำข้อมูลสูญหายได้ทันที โดยโปรเจกต์นี้เป็นส่วนหนึ่งของแอปพลิเคชันส่งข้อความที่เน้นความเป็นส่วนตัวซึ่งสร้างขึ้นบน Midnight โดยใช้ศูนย์ความรู้ (Zero-Knowledge Proofs) ในการยืนยันตัวตนบนบล็อกเชน
ที่มา:
Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น