Cyber Security Academy · บทเรียน

Cross-Site Request Forgery (CSRF)

เรียนรู้ว่าการโจมตี CSRF ปลอมแปลงคำขอที่ผ่านการยืนยันตัวตนได้อย่างไร และโทเค็น CSRF กับคุกกี้ SameSite ช่วยป้องกันได้อย่างไร

Cross-Site Request Forgery (CSRF) เป็นบทเรียน Cyber Security Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cyber Security Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

CSRF คืออะไร

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

วิธีการทำงานของ CSRF

สถานการณ์:

เหยื่อเข้าสู่ระบบ bank.com อยู่ (มีคุกกี้เซสชันในเบราว์เซอร์)
เหยื่อเปิดหน้าเว็บของผู้โจมตีที่มี: <img src="https://bank.com/transfer?to=attacker&amount=1000">
เบราว์เซอร์ส่งคำขอ GET พร้อมแนบคุกกี้ของ bank.com
ธนาคารดำเนินการโอนเงิน

CSRF ผ่านคำขอ POST

CSRF ผ่าน POST ต้องใช้แบบฟอร์ม:

<form action="https://bank.com/transfer" method="POST" id="f">
  <input name="to" value="attacker">
  <input name="amount" value="1000">
</form>
<script>document.getElementById("f").submit()</script>

โทเค็น CSRF

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

แอตทริบิวต์คุกกี้ SameSite

SameSite=Strict: จะไม่ส่งคุกกี้ไปพร้อมกับคำขอข้ามไซต์เลย SameSite=Lax: จะส่งคุกกี้ไปพร้อมกับการนำทางระดับบนสุดที่ปลอดภัย (ลิงก์) แต่จะไม่ส่งไปพร้อมกับ POST จากเว็บไซต์อื่น เบราว์เซอร์สมัยใหม่ตั้งค่าเริ่มต้นเป็น Lax ซึ่งช่วยลดความเสี่ยงจาก CSRF ได้อย่างมาก

รูปแบบส่งคุกกี้ซ้ำสองครั้ง

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

ส่วนหัวคำขอแบบกำหนดเอง

สำหรับคำขอ AJAX การกำหนดให้มีส่วนหัวแบบกำหนดเอง (เช่น X-Requested-With: XMLHttpRequest) จะช่วยป้องกัน CSRF ได้ เนื่องจากเบราว์เซอร์ปิดกั้นไม่ให้สคริปต์ข้ามต้นทางตั้งค่าส่วนหัวโดยอำเภอใจ (CORS เป็นผู้บังคับใช้กฎนี้)

เมื่อโทเค็น CSRF ยังไม่เพียงพอ

โทเค็น CSRF จะใช้ไม่ได้ผลหาก:

มี XSS อยู่ — ผู้โจมตีสามารถอ่านโทเค็นผ่าน JavaScript ได้
โทเค็นรั่วไหลในที่อยู่เว็บ (ส่วนหัว Referer)
โทเค็นคาดเดาได้หรือนำกลับมาใช้ซ้ำ
กำหนดค่า CORS ไม่ถูกต้องจนอนุญาตต้นทางของผู้โจมตี

การทดสอบ CSRF

ขั้นตอนการทดสอบ:

ระบุคำขอที่เปลี่ยนแปลงสถานะ (POST, PUT, DELETE)
ลบหรือแก้ไขโทเค็น CSRF แล้วส่งคำขอซ้ำ
สร้างการส่งแบบฟอร์มข้ามต้นทางและตรวจสอบว่าดำเนินการสำเร็จหรือไม่
ตรวจสอบแอตทริบิวต์ SameSite ของคุกกี้เซสชัน

CSRF ใน API

API แบบโอนสถานะตามทรัพยากรที่ใช้ข้อมูลรูปแบบเจสันมักไม่เสี่ยงต่อ CSRF หากมีคุณสมบัติดังนี้:

กำหนดให้ใช้ Content-Type: application/json (แบบฟอร์ม HTML ไม่สามารถตั้งค่านี้ได้)
ใช้การยืนยันตัวตนด้วยโทเค็น (ส่วนหัวการอนุญาต ไม่ใช่คุกกี้)

แต่ API ที่ยอมรับคุกกี้ยังคงต้องมีการป้องกัน CSRF

ภาพรวม CSRF ในปัจจุบัน

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

ตรวจสอบอย่างรวดเร็ว: CSRF

การป้องกันหลักจากการโจมตี CSRF ในแอปพลิเคชันเว็บคืออะไร

สรุปบทเรียน

CSRF อาศัยการที่เบราว์เซอร์แนบคุกกี้ไปกับคำขอโดยอัตโนมัติ เพื่อปลอมแปลงคำขอที่ผ่านการยืนยันตัวตนจากเว็บไซต์ที่เป็นอันตราย การป้องกันหลักคือโทเค็น CSRF ที่ตรวจสอบฝั่งเซิร์ฟเวอร์ การป้องกันเสริมคือแอตทริบิวต์คุกกี้ SameSite=Strict/Lax API ที่ใช้การยืนยันตัวตนด้วยโทเค็นในส่วนหัว (ไม่ใช่คุกกี้) จะต้านทาน CSRF ได้ตามธรรมชาติ ควรใช้การป้องกันหลายชั้นร่วมกัน เพราะ XSS สามารถหลีกเลี่ยงโทเค็น CSRF ได้หากมีอยู่

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

บทเรียน “Cross-Site Request Forgery (CSRF)” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “Cross-Site Request Forgery (CSRF)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cyber Security Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cyber Security Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “Cross-Site Request Forgery (CSRF)”

เรียนรู้ว่าการโจมตี CSRF ปลอมแปลงคำขอที่ผ่านการยืนยันตัวตนได้อย่างไร และโทเค็น CSRF กับคุกกี้ SameSite ช่วยป้องกันได้อย่างไร คุณปฏิบัติ Cyber Security Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cyber Security Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cyber Security Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “Cross-Site Request Forgery (CSRF)” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cyber Security Academy นี้ได้ไหม

ได้ บทเรียน Cyber Security Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Cyber Security Academy