ความปลอดภัยคอมพิวเตอร์ในสมัยใหม่เปลี่ยนจากการโจมตี ช่องโหว่ของบริการต่างๆ หรือบั๊กของซอฟต์แวร์โดยตรงมาเป็นการโจมตีจากกระบวนก ารตรวจสอบความปลอดภัยที่ตามไม่ทันกับรูปแบบการใช้งาน ที่หลากหลายขึ้นเรื่อยๆ เช่น การใช้งานเว็บยุคใหม่ที่มีความซับซ้อน มีการวางไฟล์จากเซิร์ฟเวอร์จำนวนมากเข้ามาแสดงผลบนหน ้าเว็บเดียวกัน, มีการรันสคริปต์บนหน้าเว็บ, และมีการใช้งานเพื่อการทำงานสำคัญกว่าการเข้าอ่านเนื ้อหาบนเว็บไปอีกมากมาย
การโจมตีเว็บสามารถถูกโจมตีจากช่องโหว่เช่น Buffer Overflow ได้เช่นเดียวกันกับซอฟต์แวร์ทุกตัวในโลก แต่ช่องโหว่ที่เฉพาะสำหรับเว็บนั้นมีอยู่จำนวนหนึ่ง นับแต่บั๊กที่เปิดให้ผู้ใช้อัพโหลดสคริปต์ขึ้นไปรันบ นเว็บได้ด้วยตัวเอง ไปจนถึงการตรวจสอบสิทธิผู้ใช้ด้วยยูอาร์แอลเพียงอย่า งเดียว ทำให้เมื่อผู้ใช้แชร์ยูอาร์แอลไป เกิดเหตุการณ์ข้อมูลส่วนตัวรั่วไปได้อย่างง่ายดาย
แต่มีช่องโหว่ที่มีการใช้งานจริงและมักนึกไม่ถึงสองบ ั๊กได้แก่ Cross Site Request Forgery (CSRF) และ Cross Site Scripting (XSS) ที่ควรได้รับการกล่าวถึงเป็นพิเศษ ในตอนนี้จะอธิบายถึง CSRF ก่อน
Cross-Site Request Forgery

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


อ่านต่อ...