วิธีเฝ้าดูการเปลี่ยนแปลงในหน้าชำระเงิน: ดูอะไรและเมื่อไร

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

ทำไมต้องเฝ้าดูหน้าชำระเงิน ไม่ใช่แค่ทั้งเว็บไซต์

หน้าชำระเงินเป็นหน้าเดียวที่การโจมตีกลายเป็นเงินได้ทันที โค้ดที่คัดลอกข้อมูลบัตรหรือสลับ QR ของ Pix (ระบบชำระเงินทันทีของ Banco Central do Brasil หรือธนาคารกลางบราซิล) แค่ต้องทำงานที่นั่น จึงมักปิดตัวเองไว้ในส่วนอื่นของเว็บไซต์ ในเดือนกันยายน 2026 ร้านค้าในบราซิลที่โดนโค้ดประเภทนี้เห็นอาการทางการค้าก่อนการแจ้งเตือนทางเทคนิคใด ๆ นั่นคือการยกเลิกคำสั่งซื้อที่เลือก Pix เพิ่มขึ้น

การเฝ้าดูหน้าชำระเงินยังเป็นข้อบังคับด้วย ตั้งแต่วันที่ 31 มีนาคม 2025 ข้อกำหนด 11.6.1 ของ PCI DSS กำหนดให้มีกลไกตรวจจับการเปลี่ยนแปลงที่ไม่ได้รับอนุญาตในเนื้อหาของหน้าเว็บและในส่วนหัวด้านความปลอดภัย โดยตรวจอย่างน้อยสัปดาห์ละครั้ง หรือตามความถี่ที่กำหนดจากการวิเคราะห์ความเสี่ยงของบริษัทเอง

สิ่งที่ต้องเฝ้าดู: สี่ชั้น

1. ไฟล์บนเซิร์ฟเวอร์

ไฟล์ของแพลตฟอร์ม ธีม และปลั๊กอิน การเปลี่ยนแปลงนอกการเผยแพร่ตามแผนคือสัญญาณคลาสสิกที่สุดของการถูกเจาะระบบ

สิ่งที่ชั้นนี้มองไม่เห็น: โค้ดที่มาจากที่อยู่ภายนอกและมีอยู่เฉพาะในเบราว์เซอร์

2. สคริปต์ที่หน้าเว็บโหลด

รายการทุกอย่างที่หน้าชำระเงินดึงเข้ามา ได้แก่ ไฟล์ของร้านเอง เครื่องมือวิเคราะห์ แชต พิกเซลโฆษณา และสคริปต์ของผู้ให้บริการชำระเงิน นี่คือบัญชีรายการที่ข้อกำหนด 6.4.3 ของ PCI DSS ต้องการ โดยแต่ละรายการต้องมีผู้รับผิดชอบ เหตุผล และการรับรองความสมบูรณ์

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

3. ส่วนหัวด้านความปลอดภัย

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

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

4. สิ่งที่หน้าจอของลูกค้าแสดง

QR ของ Pix ข้อความ Pix Copia e Cola (รหัสชำระเงินแบบข้อความที่ลูกค้าคัดลอกไปวางในแอปธนาคาร) linha digitável (ชุดตัวเลขสำหรับชำระเงิน) ของ boleto (ใบแจ้งชำระเงินผ่านธนาคารของบราซิล) ที่อยู่กระเป๋าเงิน แบบฟอร์มที่รับบัตรเครดิตและบัตรเดบิต และปลายทางที่แบบฟอร์มนั้นส่งข้อมูลไป ตรงนี้คือที่ที่กลโกงเกิดขึ้น และเป็นที่ที่มันปรากฏออกมาทั้งหมด

สิ่งที่ชั้นนี้ต้องการ: การเทียบสิ่งที่อยู่บนหน้าจอกับสิ่งที่ร้านออกให้ ไม่ใช่แค่บันทึกว่ามีบางอย่างเปลี่ยนไป

ตรวจบ่อยแค่ไหน

ไม่มีความถี่เดียวที่ใช้ได้กับทุกอย่าง หลักปฏิบัติคือกำหนดความถี่แยกตามชั้น:

• ไฟล์บนเซิร์ฟเวอร์: ทุกครั้งที่เผยแพร่และทุกวัน พร้อมแจ้งเตือนทันทีเมื่อมีการเปลี่ยนแปลงนอกรอบการเผยแพร่
• สคริปต์และส่วนหัว: ตรวจต่อเนื่อง โดยมีคนทบทวนอย่างน้อยสัปดาห์ละครั้ง ซึ่งเป็นขั้นต่ำของข้อ 11.6.1
• หน้าจอของลูกค้า: ทุกครั้งที่หน้าชำระเงินโหลด QR ที่ถูกสลับเมื่อวันอังคารเวลา 10:00 น. ได้รับเงินไปแล้วตั้งแต่ 10:01 น.

วิธีต่าง ๆ และสิ่งที่แต่ละวิธีมองเห็น

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

สามวิธีแรกบอกได้ว่า "มีบางอย่างเปลี่ยนไป" มีเพียงวิธีสุดท้ายที่บอกได้ว่า "ลูกค้ากำลังจะจ่ายเงินให้คนผิด"

วิธีตั้งการแจ้งเตือนที่มีคนตอบสนองจริง

1. กำหนดว่าอะไรได้รับอนุญาต ถ้าไม่มีรายการสคริปต์และปลายทางที่คาดไว้ ทุกการแจ้งเตือนก็เป็นแค่เสียงรบกวน
2. แยกเรื่องด่วนออกจากเรื่องประจำ สคริปต์ใหม่บนหน้าชำระเงินและ QR ที่ไม่ตรงกันเป็นเรื่องด่วน การเปลี่ยนเวอร์ชันของเครื่องมือวิเคราะห์เป็นเรื่องประจำที่ทบทวนได้ภายในสัปดาห์
3. ส่งเรื่องด่วนไปยังคนที่ลงมือได้ ใช้ช่องทางที่มีคนเข้าเวร ไม่ใช่กล่องอีเมล
4. รวมสัญญาณทางเทคนิคกับสัญญาณทางการค้า อัตรา Pix ที่ค้าง การทิ้งหน้าชำระเงิน และคำร้องเรียนว่าจ่ายแล้วแต่ไม่มีคำสั่งซื้อ มีน้ำหนักเท่ากับการแจ้งเตือนเรื่องไฟล์
5. เก็บหลักฐาน วันที่ หน้าเว็บ สิ่งที่เปลี่ยน และผู้อนุมัติ นี่คือสิ่งที่ผู้ตรวจประเมิน PCI DSS ขอ และช่วยได้เมื่อต้องอธิบายเหตุการณ์ให้ลูกค้าฟัง

เช็กลิสต์ฉบับย่อ

• รายการสคริปต์ของหน้าชำระเงิน พร้อมผู้รับผิดชอบและเหตุผล
• การแจ้งเตือนเมื่อไฟล์ถูกแก้ไขนอกรอบการเผยแพร่
• นโยบายความปลอดภัยของเนื้อหาที่เปิดการรายงานไว้
• การเฝ้าดูในเบราว์เซอร์ของลูกค้าจริง ไม่ใช่แค่ผ่านบอต
• การเทียบ QR, Copia e Cola, linha digitável และแบบฟอร์มบัตรกับสิ่งที่ร้านออกให้
• แดชบอร์ดรายวันแสดงอัตรา Pix ที่ค้าง
• บันทึกทุกการเปลี่ยนแปลงที่อนุมัติและทุกการแจ้งเตือนที่จัดการแล้ว

สำหรับบริบทของการโจมตีที่การเฝ้าดูนี้ช่วยป้องกัน อ่าน Magecart คืออะไร และวิธีปกป้องร้านค้าออนไลน์ สำหรับข้อกำหนด ดูการปฏิบัติตาม PCI DSS

Proteside ช่วยได้ตรงไหน

Proteside ดูแลชั้นที่สองและชั้นที่สี่ในเบราว์เซอร์ของผู้ซื้อ คือเก็บบัญชีรายการสคริปต์ของหน้าชำระเงิน และตรวจในทุกคำสั่งซื้อว่า QR, Copia e Cola, linha digitável และแบบฟอร์มบัตรตรงกับที่ร้านออกให้หรือไม่ ถ้าไม่ตรง ระบบจะบล็อกการสลับก่อนการยืนยัน แจ้งร้าน และบันทึกกรณีนั้นเป็นหลักฐานสำหรับ PCI DSS ดูวิธีการทำงาน