ทำไมยอด Lead พุ่งกลางดึกทั้งที่ไม่ได้ยิงแอดช่วงนั้นเลย

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

หลังไล่ตรวจ Log พบว่า Request พวกนั้นไม่มี User ID ที่สอดคล้องกับผู้ใช้ LINE จริง บาง Payload มีรูปแบบข้อมูลที่ไม่ตรงกับที่ LINE ส่งมาตามปกติเลย เมื่อสืบต่อไปอีกจึงพบว่าเซิร์ฟเวอร์รับ Webhook ของธุรกิจนี้ไม่เคยตรวจลายเซ็นเลยสักครั้งตั้งแต่เริ่มใช้งาน ใครก็ตามที่รู้ URL ปลายทางสามารถยิง Request ปลอมเข้ามาปะปนกับข้อมูลจริงได้ตลอดเวลา

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

Signature Verification คืออะไร ทำงานร่วมกับ Webhook ยังไง

ทุกครั้งที่ LINE ส่ง Event มาทาง Webhook ไม่ว่าจะเป็น Follow, Message หรือ Postback LINE จะแนบค่าลายเซ็นมาในหัว Request ชื่อ X-Line-Signature ด้วยเสมอ ค่านี้คำนวณมาจากเนื้อหา Request ทั้งหมดผสมกับ Channel Secret ของแต่ละบัญชี โดยใช้อัลกอริทึม HMAC-SHA256 แล้วเข้ารหัสเป็น Base64

หน้าที่ของเซิร์ฟเวอร์ปลายทางคือคำนวณค่าเดียวกันนี้ขึ้นมาเองจาก Request ที่ได้รับ โดยใช้ Channel Secret ตัวเดียวกัน แล้วเทียบว่าค่าที่คำนวณได้ตรงกับค่าที่ส่งมาในหัว X-Line-Signature หรือไม่ ถ้าตรงกัน แปลว่า Request นี้มาจาก LINE จริงและเนื้อหาไม่ถูกแก้ไขระหว่างทาง ถ้าไม่ตรง ควรปฏิเสธ Request นั้นทันทีโดยไม่ประมวลผลต่อ

หลักการนี้คล้ายกับการเซ็นชื่อกำกับเอกสารสำคัญ คนอื่นอาจปลอมแปลงเนื้อหาเอกสารได้ แต่ถ้าไม่รู้กุญแจลับที่ใช้เซ็น ก็ไม่สามารถสร้างลายเซ็นที่ตรงกันได้ Channel Secret จึงเปรียบเสมือนกุญแจลับที่ธุรกิจต้องเก็บไว้เป็นความลับ ไม่เปิดเผยในโค้ดฝั่ง Client หรือที่ใดที่เข้าถึงได้จากภายนอก

ทำไมการข้ามขั้นตอนตรวจลายเซ็นถึงเป็นความเสี่ยงจริง

เหตุผลที่ทีมพัฒนาบางทีมข้ามขั้นตอนนี้ไป มักเป็นเพราะตอนพัฒนาเบื้องต้นเน้นให้ระบบรับ Event ได้ก่อน แล้วค่อยกลับมาเพิ่มการตรวจสอบทีหลัง แต่หลายครั้ง ‘ทีหลัง’ นั้นไม่เคยมาถึง เพราะระบบดูเหมือนทำงานได้ปกติ ไม่มีใครรู้ว่ากำลังเปิดช่องให้ Request ปลอมเข้ามาได้ตลอดเวลา

ความเสี่ยงไม่ได้จำกัดแค่เรื่องข้อมูลเพี้ยน แต่รวมถึงการที่ใครก็ตามที่รู้ URL ปลายทางของ Webhook สามารถยิง Request จำนวนมากเข้ามาเพื่อทดสอบ สร้างภาระให้เซิร์ฟเวอร์ประมวลผลข้อมูลที่ไม่มีความหมาย หรือแม้แต่พยายามสร้าง Lead ปลอมเข้าไปในระบบเพื่อรบกวนการทำงานของทีมขาย ซึ่งต่างจากปัญหาทั่วไปที่พูดถึงใน เรื่องพื้นฐานของ LINE webhook tracking ตรงที่ปัญหานี้เป็นเรื่องความน่าเชื่อถือของข้อมูล ไม่ใช่แค่ความครบถ้วน

ธุรกิจที่เชื่อมข้อมูลจาก Webhook เข้ากับการส่ง Conversion กลับแพลตฟอร์มโฆษณา ยิ่งต้องระวังเรื่องนี้มากขึ้น เพราะถ้ามี Event ปลอมปนเข้ามาแล้วถูกส่งต่อเป็น Conversion โดยไม่มีการกรอง จะทำให้ข้อมูลที่ส่งกลับไปเทรนอัลกอริทึมโฆษณาผิดเพี้ยนไปด้วย ยิ่งใช้เวลานานเท่าไรกว่าจะรู้ตัว ข้อมูลสะสมที่ผิดก็ยิ่งเยอะขึ้นเท่านั้น

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

ขั้นตอนตรวจลายเซ็นที่เซิร์ฟเวอร์ปลายทางควรทำ

การตรวจลายเซ็นมีลำดับขั้นตอนที่ค่อนข้างตายตัว ไล่ตามนี้:

1. รับ Request Body แบบดิบ (Raw Body) ไว้ก่อนที่ Framework จะแปลงเป็น JSON Object เพราะการคำนวณลายเซ็นต้องใช้ข้อความต้นฉบับเป๊ะ ๆ ไม่ใช่ข้อมูลที่ถูกแปลงรูปแบบไปแล้ว
2. ดึงค่า Channel Secret ของ Channel ที่เกี่ยวข้องมาจากที่เก็บค่าลับที่ปลอดภัย ไม่ Hardcode ไว้ในโค้ดที่อาจหลุดออกไปได้
3. คำนวณ HMAC-SHA256 จาก Raw Body โดยใช้ Channel Secret เป็นคีย์ แล้วเข้ารหัสผลลัพธ์เป็น Base64
4. เทียบค่าที่คำนวณได้กับค่าในหัว X-Line-Signature ของ Request นั้น โดยใช้วิธีเปรียบเทียบที่ป้องกัน Timing Attack ไม่ใช่การเทียบสตริงแบบธรรมดา
5. ถ้าค่าไม่ตรงกัน ให้ตอบกลับด้วยสถานะปฏิเสธทันทีและไม่ประมวลผล Event ใด ๆ ในนั้นต่อ พร้อมบันทึก Log ไว้เพื่อตรวจสอบภายหลังว่ามี Request แปลกปลอมเข้ามาบ่อยแค่ไหน

เทียบผลลัพธ์ระหว่างเซิร์ฟเวอร์ที่ตรวจลายเซ็นกับที่ไม่ตรวจ

เพื่อให้เห็นภาพความต่างชัดขึ้น ตารางนี้เทียบสิ่งที่เกิดขึ้นจริงระหว่างสองแนวทาง:

ข้อผิดพลาดที่พบบ่อยตอนเขียนโค้ดตรวจลายเซ็น

ข้อผิดพลาดที่พบบ่อยที่สุดคือการดึงข้อมูลจาก Request หลังจาก Framework แปลงเป็น JSON แล้วนำไปคำนวณลายเซ็น ซึ่งจะได้ค่าที่ไม่ตรงกับต้นฉบับเสมอ เพราะการแปลง JSON กลับเป็นสตริงอาจเรียงลำดับ Key หรือจัดรูปแบบช่องว่างต่างจากต้นฉบับที่ LINE ส่งมา ทำให้ลายเซ็นไม่ตรงกันทั้งที่ Request นั้นมาจาก LINE จริง

ข้อผิดพลาดที่สองคือธุรกิจที่มีหลาย Channel เช่นแยกตามแบรนด์หรือสาขา แล้วใช้ Channel Secret ตัวเดียวกันตรวจสอบทุก Request โดยไม่แยกตาม Channel ที่ Event นั้นส่งมา ทำให้ Event จาก Channel หนึ่งตรวจผ่านด้วย Secret ของอีก Channel ทั้งที่ควรแยกกันอย่างเคร่งครัด

ข้อผิดพลาดที่สามคือลืมจัดการกรณีที่ Channel Secret ถูกหมุนเวียนหรือเปลี่ยนใหม่ เพราะเหตุผลด้านความปลอดภัย ถ้าโค้ดฝั่งเซิร์ฟเวอร์ยังอ้างอิงค่าเก่าที่ถูกเปลี่ยนไปแล้ว จะทำให้ Request จริงจาก LINE ถูกปฏิเสธทั้งหมด กลายเป็นปัญหาตรงข้ามคือ Event จริงเข้าไม่ได้เลยแทนที่จะกันของปลอมออก

จะรู้ได้ยังไงว่าระบบตรวจลายเซ็นทำงานถูกต้องแล้ว

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

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

หลังจากมั่นใจว่าระบบตรวจสอบทำงานถูกต้อง ควรตั้ง Monitoring ไว้ดู Log การปฏิเสธ Request เป็นระยะ ถ้าจู่ ๆ มี Request ที่ถูกปฏิเสธจำนวนมากผิดปกติ อาจเป็นสัญญาณว่ามีคนพยายามยิง Request ปลอมเข้ามาซ้ำ ๆ ซึ่งควรแจ้งทีมเทคนิคให้ตรวจสอบเพิ่มเติม ไม่ใช่ปล่อยผ่านเพราะระบบ ‘ป้องกันได้อยู่แล้ว’

ทีมที่เพิ่งเปลี่ยนแพลตฟอร์มโฮสติ้งหรือย้ายเซิร์ฟเวอร์ ควรทดสอบขั้นตอนนี้ซ้ำอีกครั้งเสมอ เพราะบางครั้งการย้ายระบบอาจทำให้วิธีอ่าน Raw Body เปลี่ยนไปโดยไม่ตั้งใจ เช่น Framework เวอร์ชันใหม่แปลง Body ให้อัตโนมัติก่อนถึงโค้ดตรวจลายเซ็น ทำให้จู่ ๆ การตรวจสอบที่เคยทำงานถูกต้องกลับพังไปเฉย ๆ โดยไม่มีใครแก้โค้ดส่วนนั้นเลย

ผลกระทบต่อคุณภาพข้อมูลถ้าไม่เคยตรวจลายเซ็นเลย

ธุรกิจที่ใช้ข้อมูลจาก Webhook ไปตัดสินใจเรื่องงบโฆษณาหรือประเมินผลงานแอดมิน ควรตระหนักว่าถ้าไม่เคยตรวจลายเซ็นมาก่อน ข้อมูลสะสมในอดีตอาจมี Event ที่ไม่ได้มาจาก LINE จริงปนอยู่โดยไม่รู้ตัว การไปเปรียบเทียบตัวเลขข้ามช่วงเวลา เช่นเทียบยอด Lead เดือนนี้กับเดือนก่อนหน้าที่ยังไม่มีการตรวจลายเซ็น อาจให้ข้อสรุปที่คลาดเคลื่อนได้

สิ่งที่ควรทำเมื่อเพิ่งเริ่มตรวจลายเซ็นคือทำเครื่องหมายไว้ในระบบว่าข้อมูลก่อนวันที่เริ่มใช้การตรวจสอบมีความน่าเชื่อถือต่ำกว่าข้อมูลหลังจากนั้น เพื่อให้ทีมที่ดูรายงานเข้าใจว่าเส้นแบ่งอยู่ตรงไหน ไม่ใช่เอาข้อมูลสองช่วงมาเทียบกันตรง ๆ เหมือนคุณภาพเท่ากัน

ในระยะยาว การมี Signature Verification ที่แข็งแรงเป็นพื้นฐานสำคัญก่อนจะไปพูดเรื่องซับซ้อนกว่า เช่นการผูก Event เข้ากับที่มาของทราฟฟิกตามที่กล่าวถึงใน ช่องว่างระหว่างคลิกกับการเข้า LINE เพราะถ้าฐานข้อมูล Event ยังไม่น่าเชื่อถือตั้งแต่ต้น การวิเคราะห์ขั้นถัดไปก็จะสร้างบนฐานที่ไม่มั่นคงไปด้วย

สรุป

Lead ที่เข้ามากลางดึกทั้งที่ไม่มีแอดวิ่งอาจไม่ใช่เรื่องบังเอิญ แต่เป็นสัญญาณของช่องโหว่ที่มาจากการไม่ตรวจ LINE webhook signature verification ซึ่งเปิดทางให้ Request ปลอมปนเข้ามากับข้อมูลจริงได้ตลอดเวลาโดยไม่มีใครรู้ตัว

ถ้าธุรกิจของคุณยังไม่เคยตรวจสอบเรื่องนี้ ลองเริ่มจากตรวจโค้ดฝั่งรับ Webhook ว่ามีขั้นตอนตรวจลายเซ็นอยู่หรือไม่ แล้วทดสอบด้วยการยิง Request ปลอมเข้าไปดูว่าเซิร์ฟเวอร์ปฏิเสธได้จริงหรือเปล่า ก่อนจะไปสนใจเรื่องซับซ้อนกว่าอย่างการวิเคราะห์ที่มาของทราฟฟิก

• Signature Verification คือการตรวจลายเซ็นดิจิทัลด้วย Channel Secret เพื่อยืนยันว่า Request มาจาก LINE จริง
• ข้อผิดพลาดที่พบบ่อยคือคำนวณลายเซ็นจากข้อมูลที่ถูกแปลงไปแล้ว ไม่ใช่ Raw Body ต้นฉบับ
• ควรทดสอบทั้งกรณี Request จริงผ่านและ Request ปลอมถูกปฏิเสธ ไม่ใช่ทดสอบแค่ปุ่ม Verify อย่างเดียว

คำถามที่พบบ่อย