OWASP Top 10 2017 ความปลอดภัยขั้นพื้นฐานที่ต้องมี !!!

OWASP Top 10 จะเป็นการจำแนกความเสี่ยงด้านความปลอดภัยของ Web Applicaiton ส่วนใหญ่ ซึ่งการจัดอันดับก็จะอยู่บนพื้นฐานของ OWASP Risk Rating Methodology โดยจะมี 10 หัวข้อที่นิยมพบ ได้แก่

A1: Injection

การโจมตีแบบ Injection เกิดขึ้นได้จากหลายอย่างไม่ว่าจะเป็น Environment, Variables, Parameters, Web Services, User, และอื่น ๆ โดย Injection เกิดเมื่อ Hacker สามารถส่งข้อมูลที่ไม่ถูกต้องไปที่ Interpreter ได้

ปัญหาด้านนี้มักเกิดกับ Web Application ที่เก่าหรือไม่มีการพัฒนา อัพเดท Patch เพื่อแก้ไขช่องโหว่นี้ ซึ่งปัญหานี้มักจะเกี่ยวข้องกับ SQL, LDAP, XPath, NoSQL, Queries, OS commands, XML parsers, SMTP Headers, Expression Languages, และ ORM Queries ซึ่งปัญหานี้เราสามารถตรวจพบได้จาก Source Code ที่เขียนไม่ถูกต้อง โดยมีเครื่องมือพวก Scanner ที่ช่วยตรวจด้านนี้ให้เราใช้ได้ด้วย

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. การทำ Prepared Statement หรืออีกชื่อหนึ่งคือ Parameterised Query
2. การทำ Stored Procedure จะเป็นการเก็บ SQL query ไว้ที่ฐานข้อมูลและให้เว็บแอปพลิเคชันส่ง parameter มาให้ฐานข้อมูลเรียก SQL query ที่เก็บไว้มาทำงาน
3. Escaping User Input เป็นการตรวจสอบข้อมูลที่ได้รับมาจากผู้ใช้งาน แก้ไข หรือ ลบ ข้อมูลที่อาจจะเป็นอันตรายออกก่อนที่จะนำไปสร้างเป็น SQL query

A2: Broken authentication

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

1. ช่องโหว่ที่อนุญาตให้ผู้ใช้งานสามารถปลอมเป็นผู้ใช้งานคนอื่นได้
2. เว็บแอปพลิเคชันไม่ได้จำกัดจำนวนครั้งในการ login ที่ผิดพลาด
3. เว็บแอปพลิเคชันเก็บ password ในฐานข้อมูลเป็น plain-text
4. เว็บไซต์ที่ไม่ใช่ HTTPS
5. การทำงานของ forget password ไม่ปลอดภัย
6. ช่องโหว่ session fixation ที่ผู้ไม่หวังดีหลอกให้เป้าหมายใช่ session id ของตนในการ login เพื่อที่จะได้สิทธิ์ในการเข้าใช้งานของ ผู้ใช้งานคนนั้น

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. เข้ารหัสข้อมูลที่เป็นความลับเสมอ ทั้งข้อมูลที่เก็บอยู่ในฐานข้อมูลและข้อมูลที่ถูกส่งผ่านเครื่อข่ายคอมพิวเตอร์ ด้วย strong encrpytion algorithm
2. ใช้ HTTPS แทน HTTP ถ้าเป็นไปได้ เนื่องจาก HTTPS จะช่วยปกป้องข้อมูลไม่ให้ถูกดักจับระหว่างการส่งผ่านเครือข่ายอินเทอร์เน็ต
3. ไม่เก็บข้อมูลสำคัญบนเครื่องเซิร์ฟเวอร์ (ถ้าเป็นไปได้) ข้อมูลบางอย่าง เช่น credit card ไม่สมควรเก็บไว้ที่เซิร์ฟเวอร์ หากเป็นไปได้ให้ผู้ใช้งานกรอกข้อมูลใหม่ทุกครั้งจะเป็นการช่วยปกป้องข้อมูลความลับของผู้ใช้งานได้ดีกว่า
4. ให้สิทธิเท่าที่จำเป็นแก่ผู้ใช้งาน โดยข้อมูลไหนที่เป็นความลับต้องถูกจำกัดให้เข้าถึงได้เฉพาะผู้ที่เกี่ยวข้อง
5. แบ่งประเภทของข้อมูลอย่างชัดเจน เช่น ข้อมูล ลับ ลับมาก ลับสุดยอด เป็นต้น เพื่อให้การจัดการข้อมูลเหล่านี้เป็นไปอย่างมีประสิทธิภาพและรัดกุมยิ่งขึ้น

A3: Sensitive data exposure

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

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. เข้ารหัสข้อมูลที่เป็นความลับเสมอ ทั้งข้อมูลที่เก็บอยู่ในฐานข้อมูลและข้อมูลที่ถูกส่งผ่านเครื่อข่ายคอมพิวเตอร์ ด้วย strong encrpytion algorithm
2. ใช้ HTTPS แทน HTTP ถ้าเป็นไปได้ เนื่องจาก HTTPS จะช่วยปกป้องข้อมูลไม่ให้ถูกดักจับระหว่างการส่งผ่านเครือข่ายอินเทอร์เน็ต
3. ไม่เก็บข้อมูลสำคัญบนเครื่องเซิร์ฟเวอร์ (ถ้าเป็นไปได้) ข้อมูลบางอย่าง เช่น credit card ไม่สมควรเก็บไว้ที่เซิร์ฟเวอร์ หากเป็นไปได้ให้ผู้ใช้งานกรอกข้อมูลใหม่ทุกครั้งจะเป็นการช่วยปกป้องข้อมูลความลับของผู้ใช้งานได้ดีกว่า
4. ให้สิทธิเท่าที่จำเป็นแก่ผู้ใช้งาน โดยข้อมูลไหนที่เป็นความลับต้องถูกจำกัดให้เข้าถึงได้เฉพาะผู้ที่เกี่ยวข้อง
5. แบ่งประเภทของข้อมูลอย่างชัดเจน เช่น ข้อมูล ลับ ลับมาก ลับสุดยอด เป็นต้น เพื่อให้การจัดการข้อมูลเหล่านี้เป็นไปอย่างมีประสิทธิภาพและรัดกุมยิ่งขึ้น

A4: XML External Entities (XXE)

เป็นการโจมตีไปยัง XML Processor ด้วยการ Upload XML ที่ Hacker ส่งเข้ามาโจมตี หรือมีการดัดแปลง XML ให้ทำในสิ่งที่ไม่ประสงค์ดีกับระบบของเรา

ปัญหานี้มักจะถูกใช้ในการดึงข้อมูล การสั่งงานเครื่องระยะไกล การ scan ระบบภายใน และการโจมตีอื่น ๆ อีกมากมาย ซึ่งปัจจุบันส่วนใหญ่จะไม่ค่อยได้ใช้ XML กันเท่าไรแล้ว จะไปใช้พวก JSON กันมากกว่า

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. ให้ใช้รูปแบบข้อมูลที่ซับซ้อนน้อยลงใน JSON และหลีกเลี่ยงการเก็บข้อมูลที่มีความละเอียดอ่อน เช่น การเก็บข้อมูลผู้ใช้และรหัสผ่าน เป็นต้น
2. แก้ไขหรืออัพเกรด XML และไลบรารีของ XML ทั้งหมดที่ใช้งานในแอปพลิเคชันโดยใช้ dependency checkers อัปเดต SOAP เป็น SOAP 1.2 หรือสูงกว่า
3. ปิดใช้งานไม่ให้มีการแทรกหรือเพิ่มคำสั่ง XML จากภายนอกเข้าไปใน XML ได้
4. การทำ Application Whitelisting โดยการให้ผู้ดูแลระบบทำการกำหนด Application ที่ใช้งานอยู่ในระบบให้เป็น Whitelist และสั่งห้ามไม่ให้ระบบเรียกใช้งาน Application ที่อยู่นอกเหนือจากรายการเหล่านี้ขึ้นมาได้

A5: Broken Access Control

เป็นการโจมตีไปยังส่วนการควบคุมการเข้าถึง เป็นสิ่งที่ Hacker โจมตีเป็นหลัก โดยจะทำตัวเป็น User หรือ Admin ใดๆ หรือใช้สิทธิ์ของ User อื่น ๆ ในการ Create, Access, Update, หรือ Delete ข้อมูลต่าง ๆ ซึ่งส่งผลกระทบต่อข้อมูลในระบบเราแน่นอน

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. มีการบังคับให้ผู้ที่จะเข้าถึงข้อมูล เป็นผู้ที่มีสิทธิ์ในข้อมูลนั้น อาจจะเป็นการกำหนด Domain การเข้าถึงกับสิทธิ์ที่ควรจะเข้าถึงได้เท่านั้น
2. ปิดการใช้งาน Directory List ที่ Server และตรวจสอบว่า Metadata ไม่แสดงบนเว็บ
3. มี Log แจ้งเตือนผู้ดูแลระบบ หากมีการพยายามเข้าถึงข้อมูลโดยไม่ผ่านการตรวจสอบสิทธิ์
4. JWT Token ควรถูก Invalid หลังจากออกจากระบบ

A6: Security Misconfiguration

ช่องโหว่นี้เกิดจากเรา Configuration Software ในส่วนต่างๆในระบบไม่รัดกุม ตั้งค่าบางอย่างที่มากเกินจำเป็น หรือ Software ไม่มีการ Update เป็นเวลานาน ทำให้เกิดช่องทางในการโจมตีของผู้ไม่หวังดี

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. ตรวจสอบ Security Patch ของส่วนประกอบต่าง ๆ ของ Web Application ให้ดีและคอย Update Security Patch อยู่เสมอ
2. ปิดการใช้งาน Default User ของทุกส่วนประกอบของ Web Application เพราะ Default User จะตกเป็นเป้าหมายหลักของผู้ไม่หวังดี หากผู้ดูแลระบบลืมที่จะเปลี่ยน Password ของ Default User ก็เหมือนเป็นการเปิดประตูบ้านให้ใครก็ได้สามารถเข้ามาในระบบ ดังนั้น เพื่อเป็นการป้องกันความผิดพลาดนี้ การปิด Default User ของทุกส่วนประกอบ OS Database Web Application จะเป็นการปิดโอกาสช่องโหว่ประเภทนี้
3. ปิด Error Message ทั้งหมดที่จะแสดงให้คนทั่วไปได้เห็น หรือทำการเปลี่ยน Error Message ให้อยู่ในรูปแบบที่ผู้ดูแลระบบคนเดียวเท่านั้นที่เข้าใจ Error Message เปิดโอกาสให้ผู้ไม่หวังดีเรียนรู้เกี่ยวกับส่วนประกอบและเวอร์ชัน ซึ่งข้อมูลเหล่านี้ทำให้ง่ายแก่การหาช่องโหว่และแนวทางในการโจมตี

A7: Cross-Site Scripting (XSS)

เป็นช่องโหว่ที่เป็นอันตรายต่อผู้ใช้งาน Web Application เพราะเป็นช่องทางให้ผู้ไม่หวังดีสามารถขโมยข้อมูลที่เป็นความลับด้วยการใส่ JavaScript ลงไปใน Web Application เพื่อดึงข้อมูล Cookie หรือหลอกให้กรอกข้อมูลแล้วส่งไปให้ผู่ไม่หวังดี ทั้งที่ยังอยู่ในหน้าเว็บที่น่าชื่อถือ

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. วิธีการป้องกันช่องโหว่ประเภท XSS ที่ดีที่สุดคือการไม่นำข้อมูลที่ได้รับมาจากผู้ใช้งานมาแสดงผลใน Tag ที่เปิดโอกาสให้เรียกใช้งาน JavaScript ขึ้นได้มา
2. ในบางครั้งเราจำเป็นต้องนำข้อมูลที่ได้รับจากผู้ใช้งานมาแสดงผล การป้องกัน XSS มีเพียงวิธีเดียวคือการคัดกรองข้อมูลก่อนนำไปแสดงผล เพื่อให้มันใจว่าข้อมูลที่ได้รับมาไม่มี JavaScript ฝังอยู่ เราเรียกวิธีการนี้ว่า Data Sanitizing (การตัด Keyword หรือ Tag ออก) และ HTML Escaping (การ Encode อักขระพิเศษให้อยู่ใน Format ของ HTML Encode) ซึ่งในการทำ Sanitizing และ Escaping เป็นเรื่องยากมากในการทำขึ้นมาเอง ดังนั้นแนะนำว่าเราควรเลือกใช้ Library หรือ Function ที่ถูกเขียนโดยผู้เชี่ยวชาญจะปลอดภัยกว่า

A8: Insecure Deserialization

ช่องโหว่ที่เกิดจากการใช้ Serialize ที่ไม่มั่นคงปลอดภัยโดยจะเกิดเมื่อระบบได้ทำการ Deserialize ข้อมูลที่ถูกทำการ Serialized โดย Hacker

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. มีการ Checksums ความถูกต้องของข้อมูล หรือตรวจสอบ Digital Signatures เพื่อให้แน่ใจว่าแหล่งข้อมูลน่าเชื่อถือ
2. อนุญาตให้ Deserialize ข้อมูลสำหรับ Class ที่มีอยู่ใน Application โดยกำหนด ObjectInputStream เองด้วย Specific Class
3. ใช้ Java Serial killer แทน ObjectInputStream
4. มีการเก็บ Log ข้อมูลเกี่ยวกับ Exception จากการเกิดข้อผิดพลาดของ Deserialize
5. มีการ Monitoring Deserialization อยู่ตลอด และมีการแจ้งเตือนหาก Application มีการ Deseiralize อย่างต่อเนื่อง

A9: Using Components with Known Vulnerabilities

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

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. การป้องกันช่องโหว่ประเภทนี้สามารถทำได้โดยการหมั่นตรวจสอบช่องโหว่ที่เกิดขึ้นใหม่ ๆ ในแต่ละวัน แนวทางการจัดการกับช่องโหว่ประเภทนี้ดีที่คือ ให้ทำการ list ส่วนประกอบของเว็บแอปพลิเคชันทั้งหมดพร้อมทั่งเวอร์ชัน จากนั้นให้คอยเฝ้าตรวจสอบ CVE ใหม่ ๆ ที่ออกมาว่ามีช่องโหว่ใดที่อาจจะส่งผลต่อความปลอดภัยของเว็บแอปพลิเคชัน (ผู้ดูแลระบบอาจจะเข้าไปตรวจสอบ CVE ได้ที่ https://www.cvedetails.com/)
2. การใช้ Web Application Firewall ในการป้องกัน Web Application ซึ่งอาจจะสามารถช่วยปิดช่องโหว่ได้บางส่วน
3. Update Security Patch ให้กับส่วนประกอบที่มีช่องโหว่อย่างสม่ำเสมอ

A10: Insufficient Logging & Monitoring

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

ตัวอย่างการโจมตี

เป็นส่วนหนึ่งของเนื้อหาจากเอกสารที่ทาง Secure-D Center จัดทำขึ้น

แนวทางป้องกัน

1. ใช้ Centralized Log Management (CLM) เพื่อให้ข้อมูล Log มีศูนย์กลางในการจัดการได้ง่าย สามารถดูแลและวิเคราะห์ข้อมูล รวมไปถึงช่วยแก้ไขปัญหาได้อย่างรวดเร็ว
2. เพิ่มระยะเวลาการในการจัดเก็บ Log จากเดิมที่เป็น 30 วันหรือ 90 วัน ให้เปลี่ยนเป็นจัดเก็บมากกว่า 200 วันขึ้นไป เพราะจากการตรวจสอบกรณีที่โดนเจาะระบบส่วนใหญ่ผู้ไม่ประสงค์ดีจะใช้ระยะเวลาในการรวบรวมข้อมูลในการเจาะระบบมากกว่า 200 วันขึ้นไป
3. ตรวจสอบให้แน่ใจว่า ในทุกๆครั้งที่มีการเข้าใช้งาน มีความล้มเหลวในการเข้าถึงข้อมูล และมีการตรวจสอบ Input ที่ไม่ถูกต้อง ตัว Log ต้องสามารถเก็บบริบทของผู้ใช้งานได้เพียงพอต่อการนำมาตรวจสอบ เพื่อระบุบัญชีที่น่าสงสัยหรือสิ่งที่เป็นอันตรายได้

Reference

• https://www.facebook.com/hackandsecbook/posts/2777608048934548/
• เอกสารที่ทาง Secure-D Center จัดทำขึ้น โหลดได้ที่นี่ https://drive.google.com/file/d/1x6Xn4zZjrGsrPdrVRX98ZJKDr2MWKEvr/view?fbclid=IwAR2F_qH2rMQrxAc9EPiWAnOLdx6YcyTQv-P_Xoo29jBegt63F2phglgMuCw
• https://blog.tamacorp.co/%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B8%9B%E0%B9%89%E0%B8%AD%E0%B8%87%E0%B8%81%E0%B8%B1%E0%B8%99-sql-injection/