CSRF: คุกกี้และโทเค็น SameSite
ทำความเข้าใจว่าการปลอมแปลงคำขอข้ามไซต์ใช้ประโยชน์จากคุกกี้อย่างไร ใช้ SameSite=Strict/Lax เพื่อป้องกัน และเพิ่มโทเค็นซิงโครไนเซอร์เพื่อการปกป้องเพิ่มเติม
CSRF: คุกกี้และโทเค็น SameSite เป็นบทเรียน Frontend Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Frontend Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Frontend Academy มีบทเรียนทั้งหมด 4 บทเรียน
CSRF คืออะไร
การปลอมแปลงคำขอข้ามไซต์: ผู้โจมตีหลอกเบราว์เซอร์ของผู้ใช้ที่ผ่านการยืนยันตัวตนแล้วให้ส่งคำขอไปยังไซต์ของคุณ เบราว์เซอร์จะแนบคุกกี้ของผู้ใช้ไปด้วย เซิร์ฟเวอร์จึงคิดว่าเป็นคำขอที่ถูกต้องจากผู้ใช้
การโจมตี CSRF แบบคลาสสิก
ผู้ใช้เข้าสู่ระบบ bank.com อยู่ จากนั้นเข้าไปที่ evil.com evil.com ส่งแบบฟอร์มที่ซ่อนไปยัง bank.com/transfer พร้อมหมายเลขบัญชีของผู้โจมตี เบราว์เซอร์ส่งคุกกี้เซสชันของ bank.com ไปโดยอัตโนมัติ เซิร์ฟเวอร์จึงโอนเงิน
ปัญหาเรื่องความไว้วางใจ
CSRF ทำงานได้เพราะเบราว์เซอร์แนบคุกกี้ไปกับคำขอข้ามต้นทางโดยอัตโนมัติ เซิร์ฟเวอร์ไม่สามารถรู้ได้ว่าคำขอมาจากไซต์อันตราย หากไม่มีการป้องกันเพิ่มเติม
คุกกี้ SameSite — วิธีแก้ไขสมัยใหม่
แอตทริบิวต์คุกกี้ SameSite ควบคุมว่าจะส่งคุกกี้เมื่อใดในคำขอข้ามต้นทาง Strict: จะไม่ส่งข้ามต้นทางเลย Lax (ค่าเริ่มต้นใน Chrome): ส่งเฉพาะเมื่อไปยังหน้าเว็บระดับบนสุดด้วยการนำทางแบบ GET None: ส่งเสมอ (ต้องมี Secure ด้วย)
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Laxค่าเริ่มต้น SameSite=Lax
Chrome กำหนดให้คุกกี้ทั้งหมดเป็น Lax หากไม่ได้ระบุ SameSite วิธีนี้บล็อก CSRF ส่วนใหญ่ได้ แต่ควรระบุค่าอย่างชัดเจนอยู่ดี
ใช้ SameSite=Strict เพื่อความปลอดภัยสูงสุด
ใช้ Strict กับคุกกี้ที่มีความอ่อนไหวสูงที่สุด (เซสชันผู้ดูแลระบบ การทำธุรกรรมธนาคาร) ข้อเสียคือ ผู้ใช้จะดูเหมือนออกจากระบบเมื่อเข้ามาผ่านลิงก์จากไซต์อื่น
โทเค็น CSRF (รูปแบบซิงโครไนซ์)
หากต้องรองรับเบราว์เซอร์รุ่นเก่าหรือต้องการความปลอดภัยเพิ่มเติม ให้ใช้โทเค็น CSRF เซิร์ฟเวอร์จะสร้างโทเค็นแบบสุ่ม ฝังโทเค็นไว้ในหน้าเว็บ และกำหนดให้ต้องส่งโทเค็นนี้มากับคำขอทุกครั้งที่เปลี่ยนแปลงสถานะ
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionคุกกี้แบบส่งซ้ำสองครั้ง
เซิร์ฟเวอร์ตั้งค่าคุกกี้ CSRF (ไม่ใช้ HttpOnly เพื่อให้ JS อ่านได้) ไคลเอ็นต์อ่านค่าแล้วส่งค่านั้นมาในส่วนหัว เซิร์ฟเวอร์ตรวจสอบว่าคุกกี้ตรงกับส่วนหัว ผู้โจมตีไม่สามารถอ่านคุกกี้ข้ามต้นทางได้ จึงไม่สามารถสร้างส่วนหัวให้เหมือนกันได้
เหตุผลที่วิธีนี้ใช้ได้
evil.com ของผู้โจมตีไม่สามารถอ่านคุกกี้จาก bank.com ได้ (นโยบายต้นทางเดียวกัน) ดังนั้นจึงไม่สามารถตั้งค่าส่วนหัว X-CSRF-Token ได้ คำขอจึงไม่ผ่านการตรวจสอบโทเค็นบนเซิร์ฟเวอร์
CSRF ในแอปหน้าเดียวที่ใช้โทเค็น Bearer
หากยืนยันตัวตนด้วย Authorization: Bearer <jwt> ที่จัดเก็บไว้ในหน่วยความจำ (ไม่ใช่คุกกี้) จะไม่เกิดปัญหา CSRF เพราะเบราว์เซอร์ไม่ส่งส่วนหัวโดยอัตโนมัติ ข้อแลกเปลี่ยนคือ มีความเสี่ยงต่อ XSS มากขึ้น (เนื่องจากโทเค็นที่ JS เข้าถึงได้อาจถูกขโมย)
เคล็ดลับใช้ส่วนหัวแบบกำหนดเอง
สำหรับ API ที่รับเฉพาะ JSON พร้อมส่วนหัวแบบกำหนดเอง (เช่น X-Requested-With) เบราว์เซอร์จะส่งคำขอ OPTIONS ก่อนตรวจสอบ และจะไม่รวมคุกกี้ไว้ในคำขอก่อนตรวจสอบ จึงบล็อก CSRF แบบใช้แบบฟอร์มอย่างง่ายได้ในทางปฏิบัติ
จุดปลายทางแบบทำซ้ำได้เทียบกับแบบเปลี่ยนแปลงสถานะ
CSRF มีผลหลักกับคำขอที่เปลี่ยนแปลงสถานะ (POST, PUT, DELETE) จุดปลายทางแบบ GET ควรทำงานซ้ำได้โดยไม่เกิดผลข้างเคียง เพื่อให้ GET ที่ถูกปลอมแปลงไม่ก่อให้เกิดความเสียหาย
ตรวจสอบอย่างรวดเร็ว
ค่าคุกกี้ SameSite ใดที่ป้องกันไม่ให้ส่งคุกกี้ในคำขอข้ามไซต์ส่วนใหญ่โดยค่าเริ่มต้นในเบราว์เซอร์สมัยใหม่
สรุป: การป้องกัน CSRF
กำหนด SameSite=Lax (หรือ Strict) ให้คุกกี้เซสชัน เพื่อบล็อก CSRF ส่วนใหญ่ เพิ่ม HttpOnly + Secure ใช้โทเค็น CSRF (แบบซิงโครไนซ์หรือคุกกี้แบบส่งซ้ำสองครั้ง) เพื่อการป้องกันเพิ่มเติม โทเค็น Bearer ในส่วนหัวช่วยหลีกเลี่ยง CSRF แต่เพิ่มความเสี่ยงจาก XSS เคล็ดลับใช้ส่วนหัวแบบกำหนดเองจะบังคับให้มีคำขอก่อนตรวจสอบ ทำให้คำขอ GET ทำงานซ้ำได้โดยไม่เกิดผลข้างเคียง
เรียนรู้ HTML ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 41
- บทเรียน
- 163
คำถามที่พบบ่อย
บทเรียน “CSRF: คุกกี้และโทเค็น SameSite” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “CSRF: คุกกี้และโทเค็น SameSite” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Frontend Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Frontend Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “CSRF: คุกกี้และโทเค็น SameSite”
ทำความเข้าใจว่าการปลอมแปลงคำขอข้ามไซต์ใช้ประโยชน์จากคุกกี้อย่างไร ใช้ SameSite=Strict/Lax เพื่อป้องกัน และเพิ่มโทเค็นซิงโครไนเซอร์เพื่อการปกป้องเพิ่มเติม คุณปฏิบัติ Frontend Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Frontend Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Frontend Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “CSRF: คุกกี้และโทเค็น SameSite” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Frontend Academy นี้ได้ไหม
ได้ บทเรียน Frontend Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การป้องกัน XSS: การเข้ารหัสเอาต์พุตและ CSP
- CSRF: คุกกี้และโทเค็น SameSite
- Content Security Policy: nonce และแฮช
- โฟลว์ OAuth จากฟรอนต์เอนด์