วิธี Audit HTTPS และ TLS ของร้านค้าออนไลน์และ E-commerce พร้อม Evidence ที่ควรเก็บ

ร้านค้าคุณมี HTTPS ครบ จริงหรือแค่ มี

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

การ Audit ที่แท้จริงต้องแยกสองคำถามออกจากกัน คือ \"ร้านนี้มี HTTPS หรือไม่\" กับ \"ร้านนี้มี HTTPS ถูกต้องครบทุกจุดที่มีความเสี่ยงหรือไม่\" บทความนี้เป็นแนวทางตรวจแบบหลังสำหรับร้านค้าออนไลน์ที่ต้องการรู้สถานะจริงก่อนที่ลูกค้าหรือผู้ตรวจสอบภายนอกจะเป็นคนพบปัญหาก่อน

ตรวจใบรับรองและ Certificate Chain ด้วยเครื่องมือในเบราว์เซอร์

ดูรายละเอียดใบรับรองผ่านไอคอนล็อกบนแถบที่อยู่

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

ตรวจ Certificate Chain ให้ครบ ไม่ใช่แค่ใบรับรองปลายทาง

ใบรับรอง TLS ที่ติดตั้งไม่ครบ Chain อาจแสดงผลปกติในเบราว์เซอร์บางตัวแต่มีปัญหาในเบราว์เซอร์หรืออุปกรณ์บางประเภท ปัญหานี้ตรวจพบยากด้วยตาเปล่าเพียงอย่างเดียว ควรใช้เครื่องมือตรวจสอบใบรับรองออนไลน์ที่เชื่อถือได้ตรวจซ้ำอย่างน้อยเมื่อมีการติดตั้งหรือเปลี่ยนใบรับรองใหม่ทุกครั้ง

ปัญหา Certificate Chain ไม่ครบพบได้บ่อยหลังย้ายเซิร์ฟเวอร์หรือเปลี่ยนผู้ให้บริการโฮสติ้ง เพราะไฟล์ใบรับรองกลางที่เชื่อมโยงไปยังผู้ออกใบรับรองต้นทาง อาจไม่ได้ถูกคัดลอกไปยังเซิร์ฟเวอร์ใหม่ครบถ้วน ควรตรวจซ้ำทุกครั้งหลังย้ายระบบ ไม่ใช่แค่ตอนติดตั้งใบรับรองใหม่เท่านั้น

ตรวจโดเมนย่อยที่อาจถูกลืม เช่น API หรือระบบสมาชิก

ร้านค้าที่มีระบบสมาชิกหรือ API แยกโดเมน เช่น account. หรือ api. มักถูกลืมตรวจเพราะไม่ใช่หน้าที่ลูกค้าทั่วไปเข้าถึงโดยตรง แต่หากระบบเหล่านี้เชื่อมต่อกับข้อมูลลูกค้าหรือคำสั่งซื้อ ก็ควรตรวจใบรับรองเช่นเดียวกับโดเมนหลัก

ตรวจ Mixed Content เฉพาะหน้าตะกร้าและหน้าชำระเงินอย่างเป็นระบบ

เปิดเครื่องมือนักพัฒนาบนเบราว์เซอร์เพื่อดูคำเตือนที่แท็บคอนโซล

เปิดหน้าตะกร้าสินค้าและหน้าชำระเงินด้วยเครื่องมือนักพัฒนาของเบราว์เซอร์ แล้วดูแท็บคอนโซลว่ามีคำเตือน Mixed Content หรือไม่ คำเตือนเหล่านี้มักระบุ URL ของไฟล์ที่มีปัญหาให้ทราบตรง ๆ ทำให้ตามแก้ได้ตรงจุดโดยไม่ต้องเดา

ตรวจแท็บเครือข่ายเพื่อดูคำขอที่ยังส่งผ่าน http://

ดูแท็บเครือข่ายในเครื่องมือนักพัฒนาเพื่อกรองรายการคำขอที่ยังส่งผ่าน http:// ระหว่างโหลดหน้าตะกร้าและหน้าชำระเงิน แม้บางคำขอจะไม่ใช่ Active Mixed Content ที่เบราว์เซอร์บล็อกโดยอัตโนมัติ แต่ก็ควรแก้ให้เป็น https:// ทั้งหมดเพื่อความสอดคล้อง

ทดสอบซ้ำหลังทีมการตลาดเพิ่มสคริปต์หรือวิดเจ็ตใหม่

กำหนดให้การตรวจ Mixed Content เป็นขั้นตอนบังคับทุกครั้งที่มีการเพิ่มสคริปต์หรือวิดเจ็ตใหม่จากทีมการตลาด ไม่ใช่ตรวจเฉพาะตอน Audit ประจำปี เพราะสคริปต์เหล่านี้มักถูกเพิ่มนอกรอบการพัฒนาปกติและเป็นสาเหตุหลักที่ทำให้ร้านที่เคยผ่านการตรวจแล้วกลับมีปัญหาใหม่

เก็บ Evidence: สิ่งที่ควรบันทึกไว้เป็นหลักฐานการตรวจ

ภาพหน้าจอของสถานะใบรับรองพร้อมวันที่ตรวจ

บันทึกภาพหน้าจอรายละเอียดใบรับรองของแต่ละโดเมน พร้อมวันที่ทำการตรวจ เพื่อใช้เป็นหลักฐานว่าเคยตรวจสอบเมื่อใด และเปรียบเทียบกับผลการตรวจครั้งถัดไปได้ว่ามีอะไรเปลี่ยนแปลงไปบ้าง

รายการหน้าที่ตรวจ Mixed Content แล้วพร้อมผลลัพธ์

ทำตารางรายชื่อหน้าที่ตรวจ Mixed Content แล้ว พร้อมระบุว่าพบปัญหาหรือไม่ และหากพบ ระบุ URL ของไฟล์ที่มีปัญหาและวันที่แก้ไขเสร็จ ตารางนี้ใช้ตอบคำถามทีมภายในหรือคู่ค้าได้ทันทีโดยไม่ต้องตรวจซ้ำทุกครั้งที่ถูกถาม

บันทึกผลทดสอบเส้นทางเชื่อมต่อ Payment Gateway

บันทึกผลการทดสอบว่าหน้าชำระเงินและเส้นทางเชื่อมต่อไปยัง Payment Gateway ยังคง HTTPS ตลอดเส้นทางหรือไม่ พร้อมวันที่ทดสอบ เพราะเส้นทางนี้อาจเปลี่ยนแปลงเมื่อผู้ให้บริการชำระเงินอัปเดตระบบของตนเอง แม้ร้านค้าจะไม่ได้แก้ไขอะไรฝั่งตัวเอง

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

ตรวจแผนที่ Redirect จาก URL เก่าว่าไม่มีจุดตกหล่น

สำหรับร้านที่เคยย้ายจาก HTTP เป็น HTTPS มาก่อน ให้สุ่มตรวจ URL เก่าของหน้าสินค้าและหน้าบทความว่ายัง Redirect ไปยัง HTTPS ถูกต้องอยู่หรือไม่ การเปลี่ยนแปลงระบบภายใน เช่นการย้ายแพลตฟอร์มหรือปรับโครงสร้าง URL ใหม่ อาจทำให้กฎ Redirect เดิมหลุดไปโดยไม่มีใครสังเกต

ตรวจว่าไฟล์ Sitemap ปัจจุบันมีเฉพาะ URL แบบ https:// และไม่มี URL เก่าที่เป็น http:// หลงเหลืออยู่ หากพบ URL แบบ http:// ในไฟล์ Sitemap ให้ถือเป็นสัญญาณว่าระบบสร้าง Sitemap อัตโนมัติอาจยังอ้างอิงการตั้งค่าเดิมที่ไม่ได้อัปเดต

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

ตรวจเวอร์ชัน TLS และ Cipher Suite ที่เซิร์ฟเวอร์รองรับ

นอกเหนือจากตรวจใบรับรองและ Mixed Content การ Audit ที่ครบถ้วนควรตรวจลึกลงไปถึงเวอร์ชัน TLS และ Cipher Suite ที่เซิร์ฟเวอร์ยอมรับด้วย เพราะร้านค้าที่มีใบรับรองถูกต้องและไม่มี Mixed Content เลย อาจยังเปิดให้เชื่อมต่อด้วยเวอร์ชัน TLS เก่าที่มีช่องโหว่รู้จักอยู่เบื้องหลังโดยไม่มีใครสังเกต เพราะเบราว์เซอร์ส่วนใหญ่จะเชื่อมต่อด้วยเวอร์ชันใหม่ที่สุดที่ทั้งสองฝั่งรองรับร่วมกันโดยอัตโนมัติ ทำให้ผู้ตรวจทั่วไปไม่เห็นปัญหานี้จากการเปิดเว็บด้วยเบราว์เซอร์ปกติ

ใช้เครื่องมือตรวจสอบออนไลน์เพื่อดูเวอร์ชันที่เซิร์ฟเวอร์ยอมรับ

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

ตรวจข้อกำหนดเวอร์ชัน TLS ขั้นต่ำจาก Payment Gateway

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

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

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

ควร Audit HTTPS และ TLS บ่อยแค่ไหน ควร Audit เต็มรูปแบบอย่างน้อยปีละครั้ง และตรวจซ้ำเฉพาะจุดทุกครั้งที่มีการเพิ่มสคริปต์การตลาดใหม่ เปลี่ยนผู้ให้บริการชำระเงิน หรือย้ายแพลตฟอร์มร้านค้า เพราะเหตุการณ์เหล่านี้เป็นจุดที่มักทำให้การตั้งค่าเดิมหลุดไปโดยไม่มีใครสังเกต

ต้องเก็บ Evidence การตรวจไว้นานแค่ไหน ควรเก็บอย่างน้อยจนถึงรอบการ Audit ครั้งถัดไป เพื่อใช้เปรียบเทียบว่ามีอะไรเปลี่ยนแปลงไปบ้างระหว่างสองรอบการตรวจ ร้านที่มีคู่ค้าหรือ Payment Gateway ที่ขอดูประวัติการตรวจสอบ อาจจำเป็นต้องเก็บไว้นานกว่านั้นตามที่คู่ค้ากำหนด

เครื่องมือนักพัฒนาในเบราว์เซอร์เพียงพอสำหรับตรวจ Mixed Content ทั้งร้านหรือไม่ เพียงพอสำหรับตรวจทีละหน้า แต่หากต้องการตรวจทั้งร้านที่มีสินค้าจำนวนมาก ควรใช้ร่วมกับการสุ่มตรวจเป็นชุดตามหมวดหมู่สินค้า เพราะการเปิดตรวจทุกหน้าสินค้าด้วยมือทีละหน้าไม่คุ้มเวลาสำหรับร้านขนาดใหญ่

เช็กลิสต์ปฏิบัติ

• ตรวจรายละเอียดใบรับรองของทุกโดเมนและซับโดเมนที่ร้านใช้งาน ไม่ใช่แค่โดเมนหลัก
• ตรวจ Certificate Chain ให้ครบด้วยเครื่องมือตรวจสอบใบรับรองออนไลน์ที่เชื่อถือได้
• ตรวจโดเมนย่อยที่มักถูกลืม เช่น API หรือระบบสมาชิก
• เปิดเครื่องมือนักพัฒนาตรวจแท็บคอนโซลของหน้าตะกร้าและหน้าชำระเงินหา Mixed Content
• ตรวจแท็บเครือข่ายกรองคำขอที่ยังส่งผ่าน http:// ระหว่างโหลดหน้าสำคัญ
• บันทึกภาพหน้าจอสถานะใบรับรองพร้อมวันที่ตรวจไว้เป็นหลักฐาน
• ทำตารางรายชื่อหน้าที่ตรวจ Mixed Content แล้วพร้อมผลลัพธ์และวันที่แก้ไข
• สุ่มตรวจ URL เก่าว่ายัง Redirect ไป HTTPS ถูกต้อง และตรวจไฟล์ Sitemap ไม่มี URL แบบ http:// หลงเหลือ

ข้อผิดพลาดที่พบบ่อย

• เห็นสัญลักษณ์ล็อกบนแถบที่อยู่แล้วสรุปว่าทั้งร้านปลอดภัยโดยไม่ตรวจหน้าอื่นเพิ่ม
• ตรวจใบรับรองเฉพาะโดเมนหลัก ไม่ได้ตรวจโดเมนย่อยของ API หรือระบบสมาชิก
• ตรวจ Mixed Content ครั้งเดียวตอน Audit ประจำปี ไม่ตรวจซ้ำหลังทีมการตลาดเพิ่มสคริปต์ใหม่
• ไม่บันทึกหลักฐานการตรวจไว้ ทำให้ตอบคำถามทีมภายในหรือคู่ค้าไม่ได้ทันทีเมื่อถูกถามย้อนหลัง
• ไม่ตรวจไฟล์ Sitemap หลังย้ายแพลตฟอร์มหรือปรับโครงสร้าง URL ใหม่ ปล่อยให้มี URL เก่าหลงเหลือ

สรุป

การ Audit HTTPS และ TLS ของร้านค้าออนไลน์ที่แท้จริง ต้องมองข้ามสัญลักษณ์ล็อกไปดูรายละเอียดใบรับรองทุกโดเมน ตรวจ Mixed Content เฉพาะจุดเสี่ยงสูงอย่างหน้าตะกร้าและชำระเงินด้วยเครื่องมือนักพัฒนา และเก็บหลักฐานการตรวจไว้เป็นระบบเพื่อเปรียบเทียบในรอบถัดไป การ Audit ที่ทำครั้งเดียวแล้วไม่ตรวจซ้ำหลังมีการเปลี่ยนแปลงมักเป็นจุดที่ทำให้ปัญหากลับมาโดยไม่มีใครรู้ตัว

แหล่งข้อมูลอ้างอิง

• OWASP HTTP Security Response Headers Cheat Sheet
• ศูนย์ความรู้ด้านความปลอดภัยเว็บไซต์ของ trusty
• เช็กลิสต์ HTTPS และ TLS สำหรับร้านค้าออนไลน์
• วิธีวางระบบ HTTPS และ TLS สำหรับร้านค้าออนไลน์แบบเป็นขั้นตอน