Tags:
Node Thumbnail

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

การโจมตีเว็บสามารถถูกโจมตีจากช่องโหว่เช่น 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)

Get latest news from Blognone

Comments

By: pairojcd
iPhoneWindows PhoneAndroidWindows
on 11 November 2012 - 23:43 #504762

พอเข้าใจได้

By: EThaiZone
ContributorAndroidUbuntuWindows
on 12 November 2012 - 00:36 #504809
EThaiZone's picture

CSRF ปัจจุบัน PHP Framework หลายตัวจะมีความสามารถป้องกันตรงนี้มาแล้ว หลักการก็คล้ายๆ กันคือสร้าง hash นำมาเป็น input ประเภท hidden เพื่อใช้ตรวจสอบการส่งค่าไปมา แน่นอนระบบพวกนี้ควรใช้เป็นกรณีไปเพราะมันจะมีผลกับการตรวจ ajax ด้วย (เคยตกม้าตายมาแล้ว) ดังนั้นดูให้ดีก่อนใช้


มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB

By: sudloa
ContributoriPhoneWindows PhoneAndroid
on 12 November 2012 - 08:16 #504873 Reply to:504809

พอแนะนำตัวอย่างเคสที่ว่าได้ไหมครับ
เป็นกรณีศึกษาให้ท่านอื่นๆครับ

By: lew
FounderJusci&#039;s WriterMEconomicsAndroid
on 12 November 2012 - 18:09 #505084 Reply to:504873
lew's picture

ในบทความมีลิงก์ของ Django ก็เป็นตัวอย่างหนึ่งครับ


lewcpe.com, @wasonliw

By: uranium.dioxide
iPhone
on 12 November 2012 - 02:15 #504837

ผมใช้ unixtime เพื่อเป็นค่า referrer ครับ

By: sudloa
ContributoriPhoneWindows PhoneAndroid
on 12 November 2012 - 08:33 #504877
รวมกึงเฟรมเวิร์คหลักๆ
รวมกึง -> รวมถึง
By: Charin Tapang
ContributorAndroidRed HatUbuntu
on 12 November 2012 - 09:42 #504901 Reply to:504877
Charin Tapang's picture

อันนี้ด้วยครับ ขอ งเว็บ -> ของเว็บ

By: hisoft
ContributorWindows PhoneWindows
on 12 November 2012 - 09:46 #504904 Reply to:504877
hisoft's picture
  • ใช้ขอ งเว็บ

ขอ ง -> ของ

By: games2532
ContributoriPhoneWindows PhoneAndroid
on 12 November 2012 - 17:49 #505081 Reply to:504877

รวมถงเฟรมเวิร์คหลักๆ ตัวอย่างเช่น Django

รวมถง > รวมถึง

By: Neopom
iPhoneAndroid
on 12 November 2012 - 08:33 #504878

ตัวอย่างง่ายๆครับ

Ref: https://www.owasp.org/index.php/Top_10_2010-A5

By: PaPaSEK
ContributorAndroidWindowsIn Love
on 12 November 2012 - 14:10 #505024
PaPaSEK's picture

ขอคำแนะนำครับ

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

ปล. อย่าง Drupal นี่ก็มีการป้องกัน CSRF นะ

By: lew
FounderJusci&#039;s WriterMEconomicsAndroid
on 12 November 2012 - 15:46 #505055 Reply to:505024
lew's picture

"โดยทั่วไป" ไม่เจาะจงครับ แต่ไม่มีอะไรห้ามไม่ให้เจาะจง

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


lewcpe.com, @wasonliw

By: PaPaSEK
ContributorAndroidWindowsIn Love
on 12 November 2012 - 17:02 #505068 Reply to:505055
PaPaSEK's picture

ขอบคุณครับ

แสดงว่าถ้าแฮกเกอร์ทำ social engineer มาดีๆ ก็มีโอกาสที่จะเจาะจงตัวบุคคลได้มากขึ้นถูกมั้ยครับ

By: IP127001
iPhoneWindows PhoneAndroidUbuntu
on 13 November 2012 - 00:36 #505302
IP127001's picture

ดูซีรี่ย์เกาหลีเรื่อง "Ghost" กันหรือยังครับ มันเข้ากับยุคสมัยมากเลยนะครับ ดูแล้วประเทืองปัญญา
นางเอกสวยครับอิอิ พระเอกเก่งเว่อร์ อุอุ