ช่องโหว่ประเภท Cross-site Request Forgery (CSRF)

transfer_p2pCross-site Request Forgery (CSRF) เป็นช่องโหว่ที่น่าสนใจเป็นอันดับต้น ๆ เพราะว่าเป็นช่องโหว่ที่สามารถพบเจอได้ง่าย สามารถสร้างความเสียหายให้กับผู้ใช้งานได้โดยที่ไม่ต้องใช้เทคนิคที่ซับซ้อน  CSRF เคยถูกจัดให้อยู๋ในอันดับที่ 5 ใน OWASP TOP 10 2010 และถูกลดลำดับลงมาให้อยู่ในอันดับ 8 ใน OWASP TOP 10 2013 อันเนื่องมาจากความตื่นตัวของผู้พัฒนาเว็บแอปพลิเคชัน ในบทความนี้จะอธิบายถึงการทำงานและ YouTube case study ของช่องโหว่ประเภท CSRF

 

Cross-site Request Forgery (CSRF) คืออะไร

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

การทำงานของ CSRF

CSRF เป็นช่องโหว่ที่ผู้ไม่หวังดีส่ง HTML หรือ JavaScript ให้เว็บเบราเซอร์ของเหยื่อส่ง HTTP request เพื่อไปกระทำการบางอย่างที่อาจจะเป็นอันตรายต่อผู้ใช้งาน หลักการของ CSRF เป็นตัวอย่างดังรูป

Screen Shot 2559-01-21 at 11.15.28 AM

ขั้นตอนการโจมตีเป็นดังคำอธิบายในภาพคือ

1. user ทำการ login เพื่อทำธุรกรรมการเงินปกติ

2. server ตอบกลับว่า login สำเร็จ

3. user ทำการเข้าเยี่ยมชมเว็บไซต์ www.attacker.com (อาจจะเกิดจากการที่ attacker ส่งลิงค์ให้ หรือเว็บไซต์อื่น redirect มา)

4. www.attacker.com ทำการสร้าง link ที่ใช้ในการโอนเงิน ส่งไปให้กับเว็บเบราเซอร์ของ user

5. เว็บเบราเซอร์ทำการ redirect ไปตาม link ที่ www.attacker.com ส่งมา www.somebank.com ทำการโอนเงินไปให้กับ attacker เนื่องจากเป็น request ที่ถูกส่งมาจาก user ที่ทำการ login อยู่ในระบบแล้ว

ในขั้นตอนของการ redirect attacker อาจจะใช้เทคนิคที่แนบเนียนกว่านั้นโดยการใช้ <img> tag ดังตัวอย่างด้านล่าง

<img src="http://www.somebank.com?send_money_to=attacker_account&amount=10000000></img>

ซึ่งผู้ใช้งานก็จะเห็นเป็นเพียงรูปภาพที่โหลดไม่ขึ้น อย่างไรก็ตามเว็บเบราเซอร์ของผู้ใช้งานจะทำการส่ง HTTP request ไปที่ URL ดังกล่าว ยิ่งไปกว่านั้น attacker ยังสามารถสร้าง JavaScript ที่ใช้ในการส่ง HTTP POST กรณีที่การโอนเงินนั้นรับคำสั่งแบบ POST จากแบบฟอร์ม

YouTube CSRF case study

YouTube_logo_2013.svg

YouTube เคยเป็นเว็บไซต์ที่มีช่องโหว่ประเภท CSRF อยู่เต็มเว็บไซต์ โดย attacker สามารถทำการเพิ่ม video ของตนเองเข้าไปใน favorite ของ user หรือทำการสั่งงานให้เว็บเบราเซอร์ทำการ subscribe channel ของตนเองโดยอัตโนมัติเพียงแค่หาทาง redirect user มาที่ website ของตนเอง

ตัวอย่าง <img> tag ที่ใช้ในการ add video เข้า favorite ของผู้ใช้งาน

<img src="http://youtube.com/watch_ajax?
action_add_favorite_playlist=1&video_
id=[VIDEO ID]&playlist_id=&add_to_favorite=
1&show=1&button=AddvideoasFavorite"/>

แนวทางการในการป้องกัน CSRF

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

1. Synchronizer Token Pattern

Synchronizer Token Pattern (STP) เป็นวิธีที่ OWASP แนะนำสำหรับการแก้ปัญหาเรื่องช่องโหว่ CSRF หลักการทำงานของ STP คือ เมื่อผู้ใช้งานทำการ login (เริ่ม session ใหม่) ให้ทำการสร้าง random string ขึ้นมา 1 ชุดทุกครั้ง และเมื่อผู้ใช้งานจะทำการส่งคำสั่งสำคัญ เช่น การโอนเงิน ให้ทำการใส่ random string ที่ผูกกับ session มาด้วย วิธีการนี้ทำให้ attacker ไม่สามารถโจมตีผู้ใช้งานด้วย CSRF ได้เนื่องจาก attacker ไม่ทราบ random string ของผู้ใช้งาน

Screen Shot 2559-01-21 at 12.54.22 PM

2. HTTP referer header

HTTP referer เป็น field ใน HTTP request ที่ใช้ในการบอกว่า request ที่ถูกส่งมานั้นมาจาก URL อะไร การตรวจสอบ HTTP referer จะสามารถป้องกัน CSRF ได้เนื่องจาก หาก attacker เป็นคน redirect เว็บเบราเซอร์มา HTTP referer จะเป็น URL ของ attacker ดังนั้น เว็บแอปพลิเคชันไม่ควรที่จะทำตามคำขอ

ข้อเสีย HTTP referer header

อย่างไรก็ตาม HTTP referer มีข้อเสียคือ ในบางกรณี plugin บางชนิดของเว็บเบราเซอร์จะไม่ใส่ HTTP referer มาพร้อมกับ HTTP request ทำให้ไม่สามารถตรวจสอบได้ว่า request นั้นถูกส่งมาจากที่ไหนทำให้ผู้ใช้งานที่ใช้ plugin บางประเภทไม่สามารถใช้งานเว็บไซต์ได้

3. Re-authentication & CAPTCHA

Re-authentication เป็นกระบวนการที่ให้ผู้ใช้งานทำการใส่ password อีกครั้งเพื่อยืนยันการส่งคำสั่งที่สำคัญ เช่น การโอนเงิน การทำ re-authentication สามารถป้องกัน CSRF ได้ผลดีมาก เนื่องจากผู้ที่ส่งคำสั่งจำเป็นต้องรู้ password

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

ข้อเสีย Re-authentication & CAPTCHA

แม้ว่า Re-authentication และ CAPTCHA จะเป็นวิธีที่ใช้ในการป้องกัน CSRF ได้เป็นอย่างดี แต่เป็นการสร้างความลำบากให้กับผู้ใช้งานเพราะต้องกรอก password หรือใส่ CAPTCHA ทุกครั้งที่มีการส่งคำสั่ง ซึ่งมีผลกระทบต่อความง่ายต่อการใช้งาน (user experience)

สรุป CSRF

Cross-site Request Forgery (CSRF) เป็นช่องโหว่ที่เกิดจากการที่ผู้ไม่หวังดีทำการสั่งให้เว็บเบราเซอร์ของเหยื่อส่งคำสั่งไปให้กับเว็บแอปพลิเคชัน CSRF สามารถสร้างผลกระทบต่อผู้ใช้งานอย่างร้ายแรง เช่น การโอนเงินจากบัญชีผู้ใช้งานไปยังบัญชีอื่นโดยที่ผู้ใช้งานไม่ได้ยินยอม แนวทางการป้องกัน CSRF ที่ดีที่สุด (สำหรับ user) คือการใช้ Synchronizer Token Pattern ปัจจุบัน เว็บแอปพลิเคชันได้ตระหนักถึงความร้ายแรงของ CSRF และได้มีการใช้มาตรการในการป้องกัน ทำให้ปัจจุบันเว็บแอปพลิเคชันมีช่องโหว่ประเภทนี้น้อยลงเรื่อย ๆ

อ้างอิง

1. Cross-Site Request Forgeries: Exploitation and Prevention

2. HTTP Request fields

3. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet


Leave a Reply