หลอกลวงได้แม้มีโทเค็น: เจาะเกราะป้องกัน CSRF ด้วยการเปลี่ยนวิธีส่งข้อมูล
โลกออนไลน์เต็มไปด้วยภัยคุกคามที่เราอาจมองข้าม หนึ่งในนั้นคือการโจมตีแบบ Cross-Site Request Forgery (CSRF) ซึ่งเปรียบเสมือนการปลอมแปลงคำสั่ง โดยแฮกเกอร์จะหลอกให้เบราว์เซอร์ของผู้ใช้งานส่งคำขอที่ไม่พึงประสงค์ไปยังเว็บไซต์ที่ผู้ใช้ล็อกอินอยู่โดยไม่รู้ตัว
ลองจินตนาการว่าคุณกำลังเข้าสู่ระบบธนาคารออนไลน์อยู่ แล้วไปเปิดหน้าเว็บไซต์อันตรายอีกหน้าหนึ่ง แฮกเกอร์สามารถใช้ช่องโหว่ CSRF เพื่อให้เบราว์เซอร์ของคุณสั่งโอนเงินไปบัญชีของพวกเขาได้ทันที โดยที่คุณไม่ทันสังเกต
สองบรรทัด
โทเค็นป้องกัน CSRF: เกราะกำบังที่บางครั้งก็ร้าวได้
เพื่อป้องกันการโจมตีลักษณะนี้ เว็บไซต์ส่วนใหญ่จึงใช้กลไกที่เรียกว่า CSRF Token (โทเค็นป้องกัน CSRF)
หลักการทำงานคือ เมื่อคุณเข้าสู่หน้าเว็บที่ต้องมีการส่งข้อมูลสำคัญ เช่น แบบฟอร์มเปลี่ยนรหัสผ่าน ระบบจะสร้างโทเค็นพิเศษขึ้นมา โทเค็นนี้เป็นรหัสสุ่มที่ไม่ซ้ำใคร และจะถูกส่งไปพร้อมกับข้อมูลในแบบฟอร์มนั้น
เมื่อคุณส่งข้อมูลกลับไปที่เซิร์ฟเวอร์ เซิร์ฟเวอร์จะตรวจสอบว่าโทเค็นที่ได้รับมานั้นตรงกับที่เคยส่งให้คุณไปหรือไม่ หากไม่ตรงกัน คำขอนั้นก็จะถูกปฏิเสธ ทำให้แฮกเกอร์ที่พยายามปลอมแปลงคำขอไม่สามารถทำสำเร็จได้ เพราะพวกเขาไม่มีโทเค็นที่ถูกต้อง
สองบรรทัด
เมื่อการเปลี่ยนวิธีส่งข้อมูลคือช่องทางให้แฮกเกอร์
แม้จะมีกลไกป้องกันที่ดีอย่าง CSRF Token แต่ก็ไม่ใช่ทุกครั้งที่มันจะทำงานได้สมบูรณ์แบบ แฮกเกอร์บางคนสามารถหาทาง ข้ามผ่านโทเค็น เหล่านี้ได้ด้วยวิธีที่คาดไม่ถึง นั่นคือการ เปลี่ยนวิธีการส่งคำขอ (HTTP Method) จาก POST เป็น GET
ปกติแล้ว การส่งข้อมูลที่เปลี่ยนแปลงสถานะหรือข้อมูลสำคัญ มักจะใช้ HTTP Method แบบ POST เช่น การเปลี่ยนรหัสผ่าน การเพิ่มสินค้าลงตะกร้า หรือการทำธุรกรรมทางการเงิน
ในขณะที่ Method แบบ GET มักใช้สำหรับการเรียกดูข้อมูลเท่านั้น เช่น การเปิดหน้าเว็บ การค้นหาสินค้า
สองบรรทัด
กลไกการเจาะระบบ: ทำไมถึงทำงานได้?
ช่องโหว่นี้เกิดขึ้นเมื่อระบบหลังบ้านของเว็บไซต์มีการตรวจสอบ CSRF Token ที่ไม่ครอบคลุม
บางครั้งนักพัฒนาอาจเขียนโค้ดให้ตรวจสอบโทเค็นเฉพาะเมื่อคำขอส่งมาด้วยวิธี POST เท่านั้น
หากแฮกเกอร์ค้นพบว่าระบบอนุญาตให้ส่งพารามิเตอร์ทั้งหมดใน URL (ซึ่งปกติจะใช้กับ GET) และยังคงประมวลผลคำขอสำคัญได้ แม้ว่าจะเปลี่ยน Method จาก POST ไปเป็น GET
นั่นหมายความว่า การตรวจสอบโทเค็นซึ่งควรจะเกิดขึ้นในคำขอ POST จะถูกมองข้ามไปโดยสิ้นเชิงเมื่อคำขอนั้นถูกส่งมาในรูปแบบ GET
แฮกเกอร์ก็แค่สร้างลิงก์ที่บรรจุพารามิเตอร์ทั้งหมด รวมถึงข้อมูลที่จะใช้โจมตี และให้เหยื่อคลิก
เมื่อเหยื่อคลิกลิงก์ดังกล่าว เบราว์เซอร์จะส่งคำขอ GET พร้อมข้อมูลไปยังเว็บไซต์ที่เหยื่อล็อกอินอยู่ โดยที่ระบบไม่ทำการตรวจสอบ CSRF Token เพราะ “คิดว่า” เป็นแค่การเรียกดูข้อมูลธรรมดา
สองบรรทัด
ความเสียหายที่เกิดขึ้นและการป้องกัน
ผลที่ตามมาจากการโจมตีลักษณะนี้อาจรุนแรงมาก แฮกเกอร์สามารถบังคับให้ผู้ใช้งานเปลี่ยนรหัสผ่านเป็นของตนเอง เปลี่ยนที่อยู่อีเมล หรือแม้กระทั่งดำเนินการทางการเงินที่ผิดปกติได้
เพื่อป้องกันช่องโหว่นี้ นักพัฒนาจึงควรให้ความสำคัญกับการตรวจสอบความปลอดภัยที่เข้มงวดมากขึ้น
ควร ตรวจสอบ CSRF Token ทุกครั้ง ไม่ว่าคำขอจะส่งมาด้วยวิธีใดก็ตาม โดยเฉพาะอย่างยิ่งสำหรับฟังก์ชันที่เปลี่ยนแปลงข้อมูลสำคัญ
นอกจากนี้ การใช้ HTTP Method ให้ถูกวัตถุประสงค์คือสิ่งสำคัญ: ใช้ POST สำหรับการเปลี่ยนแปลงข้อมูล และ ใช้ GET สำหรับการเรียกดูข้อมูลเท่านั้น พร้อมกับการตรวจสอบที่รอบคอบและสม่ำเสมอในทุกจุดที่มีความอ่อนไหว
การทำความเข้าใจช่องโหว่และกลไกการโจมตีจะช่วยให้ผู้ดูแลระบบและนักพัฒนาสามารถสร้างเว็บไซต์ที่ปลอดภัยและน่าเชื่อถือยิ่งขึ้นสำหรับผู้ใช้งานทุกคน