สรุปสั้น
Google ประกาศว่าฟีเจอร์ด้านความปลอดภัย Device Bound Session Credentials (DBSC) ของ Chrome พร้อมใช้งานทั่วไปและเริ่มทยอยปล่อยให้ผู้ใช้ทุกคนแล้ว เพื่อป้องกันการยึดบัญชี (account takeover) ฟีเจอร์นี้ทำงานโดยผูก session cookie เข้ากับฮาร์ดแวร์ของเครื่องผู้ใช้ด้วยวิธีเข้ารหัส ทำให้ cookie ที่ถูกขโมยไปใช้งานบนเครื่องอื่นไม่ได้ จุดประสงค์หลักคือสกัดมัลแวร์ประเภท infostealer ที่ขโมย session cookie แล้วนำไปข้ามการยืนยันตัวตนแบบหลายปัจจัย (MFA) เพื่อสวมรอยเข้าบัญชีเหยื่อ DBSC เปิดให้ทดสอบแบบเบต้ามาตั้งแต่เดือนเมษายน และถูกประกาศครั้งแรกตั้งแต่ปี 2024 ปัจจุบันเริ่มใช้งานจริงใน Chrome 146 บน Windows ก่อน ส่วนผู้ใช้ macOS จะได้รับในเวอร์ชันถัดไปที่ยังไม่ประกาศกำหนดการ
รายละเอียดข่าว
เว็บไซต์ BleepingComputer รายงานเมื่อวันที่ 30 พฤษภาคม 2569 ว่า Google ได้เปิดใช้งานฟีเจอร์ Device Bound Session Credentials (DBSC) ให้ผู้ใช้ Chrome ทุกคนอย่างเป็นทางการแล้ว หลังจากผ่านช่วงทดสอบเบต้ามาตั้งแต่เดือนเมษายน 2569 ฟีเจอร์นี้ถูกออกแบบมาเพื่อแก้ปัญหาการขโมย session cookie ซึ่งเป็นหนึ่งในเทคนิคยอดนิยมของแฮ็กเกอร์ในการยึดบัญชีผู้ใช้
แนวคิดของ DBSC คือการเชื่อมโยง session ของผู้ใช้เข้ากับฮาร์ดแวร์โดยตรง โดยอาศัยชิปความปลอดภัยของเครื่อง เช่น Trusted Platform Module (TPM) บน Windows หรือ Secure Enclave บน macOS คู่กุญแจสาธารณะและกุญแจส่วนตัว (public/private key) ที่ใช้เข้ารหัสจะถูกสร้างขึ้นภายในชิปความปลอดภัย จึงไม่สามารถถูกขโมยออกไปได้ ส่งผลให้แม้แฮ็กเกอร์จะขโมย session cookie ไปได้ ก็ไม่สามารถนำไปใช้บนเครื่องอื่นได้
ที่ผ่านมา มัลแวร์ infostealer จำนวนมากมุ่งขโมย cookie ที่เก็บไว้ในเบราว์เซอร์ แล้วนำไปสวมรอย session ของเหยื่อเพื่อข้าม MFA โดยตรง ซึ่ง DBSC จะตัดเส้นทางนี้ออกไป เพราะ cookie ที่ถูกขโมยจะใช้งานไม่ได้หากไม่ได้อยู่บนเครื่องต้นทางที่ผูกกุญแจไว้
Google ระบุว่าโปรโตคอล DBSC ถูกออกแบบโดยคำนึงถึงความเป็นส่วนตัวตั้งแต่ต้น แต่ละ session จะมีกุญแจเฉพาะของตัวเอง ป้องกันไม่ให้เว็บไซต์นำมาเชื่อมโยงพฤติกรรมผู้ใช้ข้าม session หรือข้ามเว็บไซต์บนเครื่องเดียวกันได้ อีกทั้งโปรโตคอลยังแลกเปลี่ยนข้อมูลเท่าที่จำเป็น โดยส่งเฉพาะกุญแจสาธารณะของแต่ละ session เพื่อยืนยันการครอบครองเท่านั้น และไม่เปิดเผยตัวระบุของอุปกรณ์ (device identifier)
ปัจจุบัน DBSC เริ่มใช้งานจริงใน Chrome 146 สำหรับ Windows ส่วนผู้ใช้ macOS จะได้รับฟีเจอร์นี้ในเวอร์ชันถัดไปที่ยังไม่มีการประกาศกำหนดการที่แน่นอน
วิธีการทำงานของการป้องกัน
หัวใจของ DBSC อยู่ที่การพิสูจน์ว่า session ที่ส่ง cookie มานั้นอยู่บนเครื่องเดิมจริง โดยเซิร์ฟเวอร์จะออกความท้าทาย (challenge) ให้เบราว์เซอร์ลงนามด้วยกุญแจส่วนตัวที่ฝังอยู่ในชิปความปลอดภัย หากกุญแจส่วนตัวไม่ได้อยู่บนเครื่องนั้น การลงนามก็จะล้มเหลว ทำให้ cookie ที่ถูกขโมยออกไปกลายเป็นของไร้ค่าทันทีเมื่ออยู่นอกเครื่องต้นทาง เนื่องจากกุญแจถูกสร้างและเก็บภายใน TPM หรือ Secure Enclave มัลแวร์ที่รันในระดับผู้ใช้ทั่วไปจึงไม่สามารถดึงกุญแจส่วนตัวออกมาได้
ผลกระทบต่อไทย
ผู้ใช้งานและองค์กรในไทยที่ใช้ Google Chrome เป็นเบราว์เซอร์หลักจะได้รับประโยชน์โดยตรงจากการป้องกันชั้นนี้ โดยเฉพาะในยุคที่มัลแวร์ infostealer เช่น ตระกูล Lumma, RedLine และ StealC ระบาดหนักและมักโจมตีผู้ใช้คนไทยผ่านไฟล์ติดตั้งซอฟต์แวร์เถื่อนและเว็บไซต์ปลอม การขโมย session cookie เพื่อข้าม MFA เป็นภัยที่กระทบทั้งบัญชีอีเมล ระบบธนาคารออนไลน์ และระบบภายในองค์กร DBSC จะช่วยลดความเสี่ยงนี้อย่างมีนัยสำคัญ อย่างไรก็ตาม ผู้ใช้ในไทยส่วนใหญ่ยังใช้ Windows เป็นหลัก จึงควรอัปเดต Chrome ให้เป็นเวอร์ชัน 146 ขึ้นไปเพื่อเปิดใช้งานฟีเจอร์นี้ และต้องเข้าใจว่า DBSC ไม่ได้แทนที่การป้องกันมัลแวร์ที่ต้นทาง
คำแนะนำ
ผู้ดูแลระบบและผู้ใช้ทั่วไปควรอัปเดต Google Chrome ให้เป็นเวอร์ชัน 146 ขึ้นไปบน Windows เพื่อให้ได้รับการป้องกัน DBSC โดยเร็ว ตรวจสอบว่าเครื่องเปิดใช้งาน TPM อยู่ เพราะฟีเจอร์ต้องอาศัยชิปความปลอดภัยในการสร้างกุญแจ องค์กรควรสนับสนุนให้เว็บแอปพลิเคชันและระบบยืนยันตัวตนของตนรองรับโปรโตคอล DBSC เพื่อให้การป้องกันมีผลครบวงจร นอกจากนี้ควรคงมาตรการป้องกัน infostealer ที่ต้นทางไว้เสมอ ทั้งการติดตั้ง EDR หลีกเลี่ยงซอฟต์แวร์เถื่อน และให้ความรู้ผู้ใช้เรื่องการหลอกลวงดาวน์โหลด เพราะ DBSC ช่วยลดผลกระทบของ cookie ที่ถูกขโมย แต่ไม่ได้หยุดการติดมัลแวร์ในเครื่อง