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

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

แต่มีช่องโหว่ที่มีการใช้งานจริงและมักนึกไม่ถึงสองบั๊กได้แก่ Cross Site Request Forgery (CSRF) และ Cross Site Scripting (XSS) ที่ควรได้รับการกล่าวถึงเป็นพิเศษ ในตอนนี้จะอธิบายถึง CSRF ก่อน

Cross-Site Request Forgery

Cross Site Request Forgery (CSRF) เป็นการโจมตีไปยังตัวผู้ใช้ของเว็บที่ไม่ได้รักษาความปลอดภัยดีพอ โดยทั่วไปแล้วเว็บจำนวนมากมักรักษาความปลอดภัยด้วยการสร้าง คุกกี้ระหว่างกระบวนการล็อกอิน เมื่อผู้ใช้เข้าใช้หน้าต่างๆ ในเว็บก็จะตรวจสอบหมายเลขในคุกกี้ (หมายเลขคุกกี้เพื่อตรวจสอบผู้ใช้นี้เองก็มีประเด็นความปลอดภัยอยู่ เช่นการสร้างเลขไล่ไปเรื่อยๆ ทำให้ผู้ใช้สามารถเดาคุกกี้ยืนยันตัวตนของคนอื่นๆ ได้) หากหลังจากมีคุกกี้ยืนยันตัวตนแล้ว ผู้ใช้สามารถส่งฟอร์มเพื่อสั่งการบนเว็บได้โดยตรง เช่น การส่งเมล หรือการสั่งโอนเงิน ฟอร์มเหล่านี้มักรับค่าได้จากตัวยูอาร์แอลโดยตรง ทำให้แฮกเกอร์มีโอกาสที่จะสร้างเว็บแล้วฝังโค้ดที่แทรกยูอาร์แอล เช่น แท็ก <img> หรือ <iframe> ที่สามารถใส่ src เป็นยูอาร์แอลอะไรของเว็บอื่นๆ ได้ จากการเขียนโปรแกรมเว็บที่บ่อยครั้งไม่มีการแยกระหว่างค่าที่ได้จากการ POST ฟอร์ม และการ GET ผ่านยูอาร์แอล หรือแม้กระทั่งการใช้ POST เพียงอย่างเดียวก็อาจมีบางหน้าเว็บที่ถูกฝังสคริปต์เพื่อสั่งให้ POST ฟอร์มได้

ปัญหา CSRF ดูจะไม่ใช่ปัญหาที่ซับซ้อนนัก แต่ในความเป็นจริงมันเคยสร้างปัญหาให้เป็นวงกว้างมาหลายครั้ง

• The New York Times: เว็บ NYTimes.com เคยมีบริการ "Email This" บนเว็บไซต์ของตัวเองโดยไม่มีการป้องกัน เมื่อคนร้ายทำยูอาร์แอลสร้างคำสั่งให้ส่งอีเมลไปยังเหยื่อ แล้วนำไปวางบนเว็บชื่อดัง ซึ่งส่วนมากมักยอมรับให้วางรูปด้วยแท็ก กันอยู่แล้ว ประกอบกับเว็บ NYTimes เป็นเว็บชื่อดัง มีผู้ใช้จำนวนมาก ที่ล็อกอินทิ้งเอาไว้ ปัญหานี้ได้รับการแก้ไขเมื่อวันที่ 1 ตุลาคม 2008 ที่ผ่านมา
• ING Direct: บริการที่น่ากังวลเมื่อเป็นบริการทางการเงิน มีผู้พบช่องทางการ POST โดยที่ผู้ใช้ไม่รู้ตัว ทำให้โอนเงินเข้าไปยังบัญชีคนร้ายได้ แม้ว่าเบราว์เซอร์จะมีการป้องกันไม่ให้จาวาสคริปต์ไปเรียก "อ่าน" ข้อมูลจากโดเมนที่ไม่ตรงกับของตัวเองได้ แต่กลับอนุญาตให้ส่ง request ไปยังเว็บต่างโดเมนได้ กรณีเช่นนี้การส่ง request ไปก็สร้างความเสียหายได้แล้ว
• YouTube: เว็บดังอย่าง YouTube เองก็เคยถูกโจมตีด้วย CSRF เช่นกัน จากยูอาร์แอลของการเพิ่มวิดีโอเข้า playlist ที่ไม่มีการตรวจสอบล่วงหน้า และมี playlist พิเศษที่ทำให้ชื่อเป็น add_to_favorite ทำให้แฮกเกอร์สามารถเพิ่มวิดีโอที่ต้องการโปรโมทเข้าไปยังผู้ใช้ทุกคนได้

การป้องกัน

กระบวนการป้องกันป้องกัน CSRF แบ่งออกเป็นการป้องกันจากฝั่งเซิร์ฟเวอร์และฝั่งของผู้ใช้เอง

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

ในฝั่งของผู้ใช้นั้น เราสามารถลดความเสี่ยงที่จะถูกโจมตีจาก CSRF ได้ด้วยการระมัดระวังการเข้าหน้าเว็บที่มีความเสี่ยงสูง เช่น เว็บแจกโปรแกรมเถื่อน, หรือเว็บภาพโป๊ทั้งหลาย เราสามารถติดตั้งส่วนเสริม NoScript สำหรับไฟร์ฟอกซ์ หรือ ScriptNo สำหรับ Chrome รวมไปถึงการใช้โหมด Inconito หรือ Private Browsing ในเบราว์เซอร์ทุกตัว เพื่อป้องกันไม่ให้เว็บที่มุ่งร้ายอาศัยการที่เราล็อกอินเว็บที่มีช่องโหว่ CSRF ได้

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

ที่มา - Cross-Site Request Forgeries: Exploitation and Prevention (PDF), Robust Defenses for Cross-Site Request Forgery (PDF)