July 28, 2026
Session Hijacking
สรุปเคสช่องโหว่ลักไก่: แกะรอย Session Replay เจาะทะลุ 2FA จากคุกกี้ไร้เงา HttpOnly
By Pornthep Kongkiattisak
วันก่อนได้ลอง Session Hijacking กับ Web ที่สมัครเป็นสมาชิกอยู่ แล้วเจอเคสที่น่าสนใจ ระบบเว็บบริการแห่งนั้น มีการตั้งค่าคุกกี้แบบ "Missing Cross-Site Restriction" หรือการตั้งค่าคุกกี้แบบ "SameSite=None" โดยไม่มีการควบคุมความปลอดภัยข้ามไซต์ แถมแฟล็กสำคัญอย่าง HttpOnly และ Secure ถูกปล่อยทิ้งเป็น False
ความน่ากลัวคือ ค่าพาสเวิร์ดที่คิดว่าปลอดภัยเพราะเป็นสายอักขระยาวๆ กลับถูกขโมยไป "ส่งต่อซ้ำ" (Replay) จนสวมรอยได้สำเร็จโดยไม่ต้องแก้รหัสผ่านจริง
[Q.] ใครเป็น คน กำหนด ว่า SameSite=None , Server หรือ Client
[A.] Server เป็นคนกำหนด โดยส่งผ่าน HTTP Response Header ชื่อ Set-Cookie ส่วน Client (Browser) มีหน้าที่บันทึกและปฏิบัติตามคำสั่งนั้น (ในเคสของ Web ที่ทดสอบนี้ น่าจะ Set ความปลอดภัยยังไม่ดี )
[ข้อมูลเสริม]
Server เป็นผู้กำหนดค่า SameSite ผ่าน HTTP Response Header (Set-Cookie) โดยส่งคำสั่งมายังเบราว์เซอร์ของผู้ใช้งาน
การตั้งค่าคุกกี้ที่ไม่ปลอดภัย:
-
SameSite=None: อนุญาตให้ส่งคุกกี้ข้ามเว็บไซต์ได้
-
HttpOnly=False: ยอมให้สคริปต์ (เช่น JavaScript) เข้าถึงค่าคุกกี้ได้
-
Secure=False: ยอมให้ส่งคุกกี้ผ่านช่องทาง HTTP ที่ไม่เข้ารหัสได้
ความเสี่ยงและแนวทางป้องกัน:
-
ความเสี่ยง: เสี่ยงต่อการถูกขโมยคุกกี้ผ่านช่องทาง Cross-Site Scripting (XSS) หรือการทำ Session Hijacking
-
แนวทางแก้ไข: ควรปรับค่าเป็น SameSite=Lax หรือ Strict, เปิดใช้งาน HttpOnly=True และกำหนด Secure=True เสมอ
[ reference: https://securelist.com/cookies-and-session-hijacking/117390/ ]
[ for education only ]