Clear
Lead Graphic Papers

Secure Website ด้วยการตรวจสอบข้อมูลที่ติดต่อกับผู้ใช้งาน (Input/Output Validation)

ผู้เขียน: พรพรหม ประภากิตติกุล
วันที่เผยแพร่: 16 ม.ค. 2555
ปรับปรุงล่าสุดวันที่: 16 ม.ค. 2555

Share on Facebook Share on Twitter Share on Google+

ปัญหาด้านความมั่นคงปลอดภัยของเว็บไซต์ในปัจจุบัน ถูกเผยแพร่ผ่านบทความและเว็บไซต์บนโลกอินเทอร์เน็ตนับครั้งไม่ถ้วน ด้วยการโจมตีแบบเดิมๆที่ยังคงได้ผลมาจนถึงทุกวันนี้ไม่ใช่เพราะเทคโนโลยีที่ทันสมัยขึ้น แต่เป็นเพราะการพัฒนาเว็บไซต์ที่ไม่มีประสิทธิภาพมากกว่า ยกตัวอย่างในกรณีข่าวที่เกิดขึ้นเมื่อไม่นานมานี้เรื่อง "One million pages infected by Lilupophilupop SQL injection" [1][2] ซึ่งจากการตรวจสอบของไทยเซิร์ตพบว่ามีเว็บไซต์ภายใต้การจดทะเบียนโดเมนเนมในประเทศไทย (.th) ได้รับผลกระทบจากกรณีดังกล่าวไม่น้อยกว่า 1 หมื่นเว็บไซต์ และจากข้อมูลที่ได้จากเว็บไซต์ SANS [3] พบว่าการโจมตีดังกล่าวเป็นการใช้เทคนิค SQL Injection [4][5] ซึ่งเป็นเทคนิคดั้งเดิมที่ใช้ในการโจมตีเว็บไซต์ต่างๆมานานแล้ว แต่ก็ยังคงใช้ได้ผลอยู่กับเว็บไซต์จำนวนมาก สาเหตุหลักๆที่วิเคราะห์ได้คือเว็บไซต์จำนวนมากที่ไม่มีการรักษาความมั่นคงปลอดภัยที่ดีพอและไม่มีการตรวจสอบข้อมูลที่ติดต่อกับผู้ใช้งาน จึงทำให้ผู้โจมตีสามารถส่งค่าอันตรายเข้าไปยังเว็บไซต์ได้อย่างง่ายดาย บทความนี้จะอธิบายถึงแนวทางการตรวจสอบข้อมูลที่ติดต่อกับผู้ใช้งานหรือที่เรียกว่า Input / Output Validation ซึ่งเป็นกระบวนการที่มีความสำคัญมากต่อการรักษาความมั่นคงปลอดภัยของเว็บไซต์และการป้องกันการโจมตีด้วยเทคนิค SQL Injection XSS [6][7] โดยหวังว่าจะช่วยให้เกิดการพัฒนาเว็บไซต์ที่มีความมั่นคงปลอดภัยมากยิ่งขี้นและช่วยลดสถิติของประเทศไทยในการการถูกโจมตีจากช่องโหว่ดังกล่าวสำเร็จ

Input / Output Validation คืออะไร

Input Validation เป็นการตรวจสอบข้อมูลที่ส่งมาจากผู้ใช้งาน ซึ่งข้อมูลดังกล่าวอาจอยู่ในรูปที่ผู้ใช้งานเห็นโดยตรง เช่น การลงทะเบียนสมัครเป็นสมาชิกเว็บไซต์ หรือเป็นการส่งข้อมูลในตัวแปรแบบซ่อนในเว็บไซต์ที่มีเนื้อหาแบบไดนามิก [8] โดยการตรวจสอบข้อมูลจากผู้ใช้งานสามารถเกิดขึ้นได้ที่ฝั่งผู้ใช้งานโดยตรง เช่น ใช้วิธีการตรวจสอบข้อมูลที่ส่งมาจากผู้ใช้งานด้วยภาษาจาวาสคริปต์ (Javascript) ที่ทำงานในฝั่งผู้ใช้งาน แต่ก็ยังพบว่าไม่สามารถช่วยป้องกันการโจมตีได้เท่าที่ควรเนื่องจากผู้โจมตีสามารถหลบเลี่ยงการตรวจสอบข้อมูลด้วยวิธีการดังกล่าวได้โดยไม่ยาก หรือใช้วิธีการตรวจสอบข้อมูลผู้ใช้งานที่ทำงานในฝั่งของเว็บไซต์ เพื่อให้แน่ใจว่าค่าที่ได้มีความถูกต้องก่อนส่งเข้าไปประมวลผลในฟังก์ชั่นหลักของเว็บไซต์ ซึ่งวิธีการนี้จะช่วยลดความเสี่ยงในการถูกเปลี่ยนแปลงฟังก์ชั่นการตรวจสอบข้อมูลได้ดีที่สุด เนื่องจากเป็นซอร์สโค้ดที่ถูกฝังอยู่ในฝั่งเว็บไซต์

Output Validation เป็นการตรวจสอบข้อมูลจากการประมวลผลของเว็บไซต์ก่อนจะนำออกมาแสดงผลในฝั่งผู้ใช้งาน ซึ่งการตรวจสอบข้อมูลดังกล่าวมีความสำคัญไม่แพ้การทำ Input validation โดยจุดประสงค์หลักคือเพื่อป้องกันการแสดงผลข้อมูลที่ไม่เหมาะสม เช่น ข้อมูลบัตรเครดิตในเว็บไซต์ที่มีการลงทะเบียนชำระเงินควรจะต้องมีการป้องกันการมองเห็นข้อมูลทั้งหมดโดยใส่สัญลักษณ์ที่บอกว่าเป็นการซ่อนข้อมูลบางอย่างเช่น สัญลักษณ์ Asterisk (*) [9] ข้อความแสดงความผิดพลาดต่างๆ (Error message) ซึ่งอาจจะเป็นข้อมูลที่เป็นประโยชน์แก่ผู้ไม่ประสงค์ดีในการวางแผนโจมตีเว็บไซต์ต่อไป หรือ แม้แต่การแสดงผลเนื้อหาในลักษณะที่อาจมีส่วนประกอบของสคริปต์อันตรายที่ส่งผลกับผู้ใช้งานบนเว็บไซต์ ซึ่งในกรณีนี้เว็บไซต์ที่ดีควรจะต้องมีการแปลงสัญลักษณ์พิเศษบางอย่างเพื่อไม่ให้เนื้อหาที่แอบแฝงด้วยสคริปต์อันตรายสามารถทำงานได้โดยอัตโนมัติในเว็บเบราว์เซอร์ของผู้ใช้งาน

ทำไมจึงต้องทำ Input / Output Validation

ในทุกเว็บไซต์มีโอกาสในการถูกโจมตีได้เท่าเทียมกันทั้งนั้น หากผู้ดูแลเว็บไซต์ลองตรวจสอบข้อมูลล๊อกไฟล์ (Logfile) ของการเรียกใช้งานเว็บไซต์ ก็อาจพบว่ามีการพยายามเรียกหน้าเว็บไซต์อย่างผิดปกติซ้ำๆในระยะเวลาไล่เรี่ยกัน นั่นเป็นเพราะผู้โจมตีส่วนใหญ่จะใช้วิธีการสุ่มเรียกเว็บไซต์โดยการพยายามส่งค่าอันตรายต่างๆ ทั้งที่ส่งค่าเป็นรายครั้งเพื่อทดสอบสมมติฐานบางอย่างที่ใช้ในการโจมตี หรือพัฒนาเป็นโปรแกรมอัตโนมัติเพื่อโจมตีเว็บไซต์ ซึ่งแท้จริงแล้วการทำ Input / Output Validation ไม่ได้เป็นอะไรที่ใหม่ เพียงแต่ผู้พัฒนาเว็บไซต์เองอาจไม่เคยสนใจหรือใส่ใจต่อการรักษาความมั่นคงปลอดภัยของเว็บไซต์เพียงพอหรือในบางรายอาจคิดว่าไม่จำเป็นต้องทำ แต่ถ้าลองพิจารณาถึงแนวโน้มและผลกระทบที่เกิดขึ้นจากการถูกโจมตีสำเร็จแล้วนั้นคงทำให้ผู้พัฒนาเว็บไซต์ต้องกลับมาคิดเสียใหม่ เนื่องจากปัจจุบันคงเป็นเรื่องที่หลีกเลี่ยงยากในการพัฒนาเว็บไซต์ต่อเทรนด์ของเว็บไซต์สมัยใหม่ที่ต้องการให้ผู้ใช้งานสามารถโต้ตอบกับเว็บไซต์ได้อย่างเสรี อย่างเช่นในเว็บไซต์ Facebook และในบางครั้งอาจจำเป็นต้องมีการซื้อขายทำธุรกรรมออนไลน์ซึ่งหากเว็บไซต์ไม่ได้มีกระบวนการป้องกันที่ดีก็คงยากที่จะทำให้เว็บไซต์ปลอดภัยจากการโจมตีและอาจเป็นผลให้เว็บไซต์หมดความน่าเชื่อถือไปในที่สุด

ปัญหาของการทำ Input / Output Validation

  • ผู้พัฒนาเว็บไซต์ไม่มีความตระหนักถึงความมั่นคงปลอดภัยของเว็บไซต์ ทำให้ไม่มีการวางแผนหรือการคาดการณ์ในเรื่องของการป้องกันการโจมตีในรูปแบบต่างๆ
  • ผู้พัฒนาเว็บไซต์ไม่มีความรู้และความเข้าใจถึงการทำ Input / Output Validation อย่างถูกต้อง ส่งผลทำให้เว็บไซต์ยังคงมีช่องโหว่ในการโจมตี
  • ผู้พัฒนาเว็บไซต์ไม่ต้องการปรับปรุงเว็บไซต์เพื่อการทำ Input / Output Validation เนื่องจากทำให้เกิดความยุ่งยากในการตรวจสอบข้อมูลที่ส่งมาจากผู้ใช้งานซึ่งมีอยู่เป็นจำนวนมาก
  • ในบางเว็บไซต์ที่เป็นการจ้างพัฒนาจากบริษัทภายนอก การทำ Input / Output Validation หรือปรับปรุงเว็บไซต์จะทำให้มีค่าใช้จ่ายเพิ่มเติม ส่งผลทำให้อาจไม่ได้รับการดูแลหรือส่งเสริม
  • ผู้พัฒนาเว็บไซต์ใช้ซอร์ฟแวร์บริหารจัดการเว็บไซต์เนื้อหาบนเว็บไซต์ (CMS) ซึ่งอาจไม่มีโมดูลการทำ Input / Output Validation ส่งผลให้เว็บไซต์มีความเสี่ยงต่อการถูกโจมตี

ข้อแนะนำในการทำ Input / Output Validation

ไทยเซิร์ตได้รวบรวมข้อมูลข้อแนะนำในการทำ Input / Output Validation โดยข้อมูลส่วนใหญ่เป็นข้อมูลที่รวบรวมมาจากเว็บไซต์ของ OWASP [10] ซึ่งเป็นเว็บไซต์ที่ให้ข้อมูลเกี่ยวกับการพัฒนาเว็บไซต์ให้มีความมั่นคงปลอดภัย ตามข้อมูลดังต่อไปนี้

1. อย่ากลัวการเปลี่ยนแปลง ในเว็บไซต์ที่มีการพัฒนาขึ้นแล้วและมีความคิดที่จะปรับปรุงเว็บไซต์ให้มีกระบวนการตรวจสอบข้อมูลที่ติดต่อกับผู้ใช้งาน นับว่าเป็นความคิดที่มาถูกทางแล้วในการป้องกันไม่ให้เกิดความเสียหายต่อเว็บไซต์ เพียงแต่การเปลี่ยนแปลงที่กล่าวอาจมีการวางแผนที่ดี และอาศัยความละเอียดรอบคอบในการดำเนินการ ซึ่งจะช่วยลดเวลาและความผิดพลาดที่เกิดขึ้นได้

2. ไม่ควรใช้จาวาสคริปต์ซึ่งทำงานในฝั่งผู้ใช้งานเป็นองค์ประกอบหลักในการตรวจสอบข้อมูลที่ส่งมาจากผู้ใช้งาน โดยหากมีการใช้งานจาวาสคริปต์ในกรณีดังกล่าว ควรต้องมีการตรวจสอบร่วมกับซอร์สโค้ดที่มีการประมวลผลในฝั่งเว็บไซต์ด้วย เพื่อป้องกันการเปลี่ยนแปลงกระบวนการตรวจสอบข้อมูลในฝั่งผู้ใช้งาน

3. การทำ Input / Output Validation จะต้องทำในทุกๆส่วนที่่มีการติดต่อกับผู้ใช้งานบนเว็บไซต์ ต้องไม่สุ่มทำเพียงส่วนใดส่วนหนึ่ง เพราะหากยกเว้นหรือลืมการตรวจสอบไม่ว่าจะส่วนใดก็ตาม นั่นหมายถึงการเปิดโอกาสให้ผู้โจมตีสามารถมีโอกาสโจมตีเว็บไซต์ได้สำเร็จ

4. ควรมีการกำหนดขอบเขตของตัวแปรและประเภทของตัวแปรที่ใช้ในเว็บไซต์ทั้งหมด เช่นตัวแปร A เป็นข้อมูลประเภท Text ตัวแปร B เป็นข้อมูลประเภท Number เพื่อใช้เป็นข้อมูลตั้งต้นสำหรับการพัฒนาฟังก์ชั่นการตรวจสอบข้อมูลจากผู้ใช้งาน โดยฟังก์ชั่นที่พัฒนาขึ้นจะต้องไม่ประมวลผลตัวแปรที่ไม่อยู่ในขอบเขตที่กำหนดไว้

5. ควรมีการกำหนดและตรวจสอบรูปแบบของข้อมูลที่อนุญาติ (Whitelist) และข้อมูลที่ไม่อนุญาติ (Blacklist) ให้ประมวลผลบนเว็บไซต์ โดยอ้างอิงจากข้อมูลในแต่ละตัวแปรว่ามีจุดประสงค์จะให้ใส่ข้อมูลใดบ้าง เช่น ข้อมูลอีเมล ควรจะมีการตรวจสอบรูปแบบของข้อมูลเฉพาะที่แสดงให้รู้ว่าข้อมูลที่ส่งมาจากผู้ใช้งานเป็นรูปแบบของอีเมลจริง เพื่อไม่ให้เกิดข้อผิดพลาดในการรับค่าผิดรูปแบบเข้ามาประมวลผลในเว็บไซต์ หรือกรณีที่ตัวแปรมีขอบเขตหรือรูปแบบการรับค่าจากผู้ใช้งานที่เปิดกว้างไม่มีรูปแบบที่แน่นอน เช่น ข้อมูลจากหน้ากระดานสนทนา ซึ่งเปิดให้รับข้อมูลแบบอิสระและมีความสุ่มเสี่ยงที่ผู้โจมตีจะส่งค่าอันตรายเข้ามาโจมตียังเว็บไซต์ เพราะฉะนั้นควรมีการพิจารณาค่าบางประเภท เช่น “<script>” โดยไม่ควรให้สามารถส่งค่าเข้ามาประมวลผลยังเว็บไซต์ได้

6. ควรมีการกำหนดและตรวจสอบความยาวของข้อมูลในแต่ละตัวแปร เพื่อตรวจสอบความผิดปกติในการส่งค่าจากผู้ใช้งานเข้ามาประมวลผลยังเว็บไซต์ เนื่องจากการส่งค่าอันตรายในบางครั้งจำเป็นต้องพิมพ์จำนวนมาก

7. ควรมีการพัฒนาฟังก์ชั่นการเข้ารหัสข้อมูลหรือที่เรียกว่า Encoding เพื่อใช้งานควบคู่ไปกับการตรวจสอบข้อมูลที่ส่งมาจากผู้ใช้งาน โดยจะช่วยลดความเสี่ยงที่ผู้โจมตีจะโจมตีโดยการแอบส่งค่าที่เป็นสคริปต์อันตรายเข้ามาประมวลผลยังเว็บไซต์ได้สำเร็จ

8. ในกรณีที่เว็บไซต์มีฟังก์ชั่นการอัพโหลดไฟล์ ควรมีการกำหนดและตรวจสอบประเภทของไฟล์ที่อนุญาติให้สามารถอัพโหลดเข้าไปประมวลผลยังเว็บไซต์ได้ ซึ่งสามารถตรวจสอบจากนามสกุลบนชื่อไฟล์ร่วมกับข้อมูลที่เว็บไซต์แสดงจากรายละเอียดของไฟล์ หรือในบางครั้งอาจจำเป็นต้องใช้งานฟังก์ชั่นหรือไลบรารี่เสริมในการตรวจสอบประเภทของไฟล์ เพื่อช่วยยืนยันความถูกต้องอีกครั้งหนึ่ง เช่น ฟังก์ชั่น fileinfo [11] ในภาษา PHP โดยจะช่วยลดความเสี่ยงที่ผู้โจมตีจะอัพโหลดไฟล์สคริปต์อันตราย เช่น Web shell [12][13] ขึ้นไปประมวลผลยังเว็บไซต์ได้สำเร็จ

9. ควรใช้งานกลไกการป้องกันการโจมตีจากโปรแกรมอัตโนมัติหรือบอทที่พยายามสุ่มค่าอันตรายมายังเว็บไซต์ โดยตัวอย่างของกลไลที่ได้รับความนิยมในปัจจุบัน เช่น Captcha [14] ถูกออกแบบมาเพื่อใช้ยืนยันว่าข้อมูลที่ถูกส่งมาเป็นข้อมูลจากผู้ใช้งานที่เป็นมนุษย์

10. ควรปิดการแสดงผลข้อมูลข้อผิดพลาดของเว็บไซต์ (Error Message) ในทุกๆกรณี เช่น การแสดงข้อผิดพลาดของเว็บไซต์ที่บ่งบอกว่าไม่สามารถเชื่อมต่อฐานข้อมูลได้ โดยการปิดการแสดงผลดังกล่าว เพื่อลดโอกาสที่จะทำให้ผู้ไม่หวังดีสามารถนำข้อมูลดังกล่าวไปใช้วางแผนโจมตีเว็บไซต์ต่อไปได้

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

12. ใช้ไลบรารี่ภายนอกที่มีความสามารถในการตรวจสอบข้อมูลที่ติดต่อกับจากผู้ใช้งาน ซึ่งจะช่วยลดเวลาและความผิดพลาดในการพัฒนาฟังก์ชั่นการตรวจสอบข้อมูลด้วยตนเอง โดยมีไลบรารี่ตัวอย่างที่ชื่อว่า ESAPI จากเว็บไซต์ OWASP ซึ่งมีข้อดีที่สนับสนุนการทำงานในหลากหลายภาษาเช่น PHP ASP.NET JAVA PYTHON และผู้ใช้งานสามารถศึกษาวิธีการใช้งานจากเว็บไซต์ผู้พัฒนาได้โดยตรง [15]

เอกสารอ้างอิง

1. http://thehackernews.com/2012/01/one-million-pages-infected-by.html
2. http://isc.sans.org/diary/Lilupophilupop+tops+1million+infected+pages/12304
3. http://www.sans.org/
4. http://www.unixwiz.net/techtips/sql-injection.html
5. https://www.owasp.org/index.php/SQL_Injection
6. http://www.acunetix.com/websitesecurity/xss.htm
7. https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
8. http://en.wikipedia.org/wiki/Dynamic_web_page
9. https://www.owasp.org/index.php/Output_Validation
10. http://www.owasp.com/index.php/Data_Validation
11. http://php.net/manual/en/book.fileinfo.php
12. http://www.thisislegal.com/tutorials/2
13. http://www.madirish.net/node/271
14. http://www.captcha.net/
15. https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Clear