Security หรือ ความปลอภัยนั้น..ในปัจจุบันถือได้ว่า เป็นเรื่องสำคัญมาก ถ้าพูดถึง security บางคนก็อาจจะถึงการโดน hack ข้อมูล การถูก virus ต่างๆ ดังนั้น เจ้าสิ่งนี้แหละที่จะมาช่วยป้องกันปัญหาดังกล่าวให้หมดไป…
หลังจากที่ได้มีโอกาส ได้เข้าอบรมเรื่อง secure Development and Coding for Web Application โดย อ.อัมฤทธิ์ ทองทั่ว บทความนี้ ก็เลยขอยกหัวข้อ OWASP Top 10 Web Application Risk มาเล่าให้กันฟังนะคับ หากมีความผิดพลาดประการใดก็ขออภัยไว้ ณ ที่นี้ด้วย^^
ก่อนที่จะเข้าเนื้อหาหลัก ขอเกิ่นเพิ่มเติมอีกนิดนึงนะครับ เนื่องจาก Security เป็นเรื่องที่สำคัญมาก แต่แปลกที่คนส่วนใหญ่เลือกที่จะให้ความคำสัญกับมันเป็นลำดับที่สุดท้าย…จริงมั้ยครับ55+
จากภาพมาดูกันว่าหลังจากส่งโปรแกรม ขึ้น production แล้วแต่โปรแกรมดันเกิดช่องโหว่ ความเสียหายที่เกิดขึ้น ก็อาจจะประเมินค่าไม่ได้ หรืออาจจะมีค่าใช้รายมหาศาล หรือถ้าเจอตอนที่ deploy ก็ต้องกลับมาเขียนใหม่ test ใหม่ แต่ละขั้นตอนก็จะมีค่าใช้จ่ายของมัน หรือ manday ที่ต้องแลกมา ดังนั้น สิ่งที่ดีที่สุดคือ ควรจะเพิ่ม security มาตั้งแต่ ขั้นตอน design หรือ security requirements นั่นเอง
OWASP Top 10 Web Application Risk
A1 Injection
คือ การที่ระบบมีการนำค่าใน Input Field ต่างๆ มาต่อกันเป็น query string และนำไป execute โดยตรง และไม่ได้ผ่านการ validate จะทำให้ Hacker มีช่องทางในการเจาะระบบคือ การฝากคำสั่งบางอย่างผ่าน Input Field ต่างๆมานั่นเอง
ทางแก้คือ ควรมีการดัก Operator ต่างๆ เช่นพวก & ! = * เป็นต้น และทำ prepare statement ที่สำคัญ คือ อย่าเอา ข้อมูลมา concat string ตรงๆ เท่านั้นก็จะป้องกันได้
A2 Broken authentication
คือ การที่ระบบอนุญาตให้ผู้ใช้งานสามารถตั้ง password ที่ง่าย ต่อการเดา หรือเป็น password แม่แบบ อย่างเช่นตั้ง root root, admin admin เพราะ Hacker เยาก็จะมี tool ที่สามารถ ทดลองยิง brute-force ด้วย password แม่แบบ ก็สามารถ login ได้
ทางแก้คือ อย่าให้ผู้ใช้งานตั้ง password ที่ง่ายต่อการคาดเดา หรือ default password อาจจะมีหลอดที่แสดงความยากง่าย ของการตั้ง password เพื่อให้ผู้ได้ ตั้ง password ที่ strong และควร มี CAPTCHA เพื่อไม่ให้ Hacker สามารถกรอก password ได้บ่อยเกินไป มันก็จะช่วยทำให้ ลดความอยากลอง ของ hackerได้ แต่ไม่แนะนำให้ทำ user suspend เพราะมันมีเคสที่ hacker ทำ user suspend ทั้งระบบ ก้อถือว่าเป็นการโจมตีเหมือนกันนะ…
A3 Sensitive data exposure
คือ การที่ระบบเก็บข้อมูล password ตรงๆ แบบไม่มีการเข้ารหัสใดๆ หาก hacker สามารถเข้าระบบได้ ก็จะเห็นข้อมูลดังกล่าว และยิ้มเลย เป็นสิ่งที่เขาต้องการอยู่แล้ว หรือการที่เอาข้อมูลสำคัญๆ เช่น username , password ไปเก็บไว้ใน ไฟล์ config ตรงๆ เพราะหาก hacker สามารถเจาะระบบเข้ามาได้ เขาก็จะมองหาเจ้าไฟล์นี้ละ และสามารถเปิดอ่านได้แน่นอน หากเห็น username , password ก็มีโอกาสสูงที่จะถูกโจีมตีได้
ทางแก้คือ มีการ encrypt all sensitive data และบอกก่อนว่า หลายๆคนใช้วิธีการ encode password เพราะคิดว่า อะไรที่อ่านไม่ออก ก็จะคิดว่าปลอดภัยใช่มั้ย…55+แต่ที่จริงแล้ว การ encode กับ encrypt ไม่เหมือนกันนะ encode มันสามารถ decodeได้ ส่วน encrypt นั้นจะถอดรหัสได้ ถ้ามี key
A4 XML External Entities (XXE)
คือ การที่ version XML นั้นเก่าไป และตั้งค่า XML ที่ไม่ปลอดภัย จะทำให้เป็นช่องโหว่ในการอ่านไฟล์ หรือทรัพยากร system file อื่น ๆ ที่เป็นประโยชน์ต่อ hacker อาจจะทำให้ถูกโจมตีได้ เลวร้ายกว่านั้นคือ ต่อให้ระบบเราดีแค่ไหน หากมีระบบอื่นที่มีช่องโหว่ ก็ทำให้ hacker สามารถเจาะระบบที่มีช่องโหว่ และทะลุผ่านไปโจมตีระบบอื่นๆได้ด้วยเช่นกัน
ทางแก้คือ ให้ upgrade version ของ XML ทั้งหมดที่ใช้งานในแอปพลิเคชันโดยใช้ dependency checkers อัปเดต SOAP เป็น SOAP 1.2 หรือสูงกว่า ปิดใช้งานไม่ให้มีการแทรกหรือเพิ่มคำสั่ง XML จากภายนอกเข้าไปใน XML ได้และปิดการใช้งาน DTD ด้วยตามหลัก OWASP Cheat Sheet’XXE Prevention’
A5 Broken Access Control
คือ การที่ระบบขาดการเช็ค authorize roles permissionต่างๆ ทำให้ user ในระดับเดียวกัน สามารถเข้าถึงข้อมูลของอีกคนได้ด้วยการ เปลี่ยน path หรือ parameter
ทางแก้คือ ต้องมีการ ตรวจสอบ privilege , authorize การทำงานต่างๆ การเข้าถึง path ต่างๆ เช่นบางคนรู้ path ของไฟล์ ก็สามารถ ../../ ไปยังไฟล์ได้ตรงๆ และที่สำคัญคือควรปิด path ที่ไม่ได้ใช้งานออกไปด้วย
A6 Security Misconfiguration
คือ การที่ระบบขาดการ handling error ที่อาจจะเป็นประโชยน์ต่อ hacker แล้วทำให้รู้ว่า ผู้พัฒนานั้นใช้ framework หรือ database ค่ายไหน มีการดัก injection มั้ย จากรูปแรกก็จะเห็นได้เลยว่า เป็น query string ธรรมดา แบบนี้ก็เสร็จโจรนะคับ… ส่วนรูปที่สอง ก็จะบอก error แถมบอกอีกด้วยว่า เป็น Jboss 7.2.2 ง่ายเลย สิ่งที่ hacker จะทำก็คือ เอา ผลิตภัณฑ์นี้ ไปค้นหาได้ว่า ณ เวอร์ชั่นนี้ มีบัคอะไร ช่องโหว่อะไรที่สามารถโจมตีได้บ้าง
ทางแก้คือ ต้องมีการจัดการ handling error ปิด error message ให้แสดงเท่าที่จำเป็น หรือเปลี่ยน error message ด้วยการ redrict ไป page อื่น เพื่อไม่ให้ผู้ใช้งานดูตกใจและ จะยิ่งเป็นการเพิ่มความน่าเชื่อถืออีกด้วย
A7 Cross-Site Scripting (XSS)
ต้องบอกเลยว่าเรื่องนี้พบเห็นเป็นประจำ มันคือการ hacker พยายามฝาก script ที่เป็นอันตรายเข้าไป หรือ สร้าง iframe เพื่อแสดงผล หรือจำลอง ui บนเว็บให้เหมือนจริง เผื่อจะมีเหยื่อเข้ามากรอก email , password และข้อมูลก็จะถูกส่งไปยัง hacker ได้
ทางแก้คือ เพิ่ม input validaion ป้องกันการเอาคำสั่งไป render ใน body ได้ และไม่ควรเชื่อลิงค์ในรูปแบบ HTML Encoding เพราะมันถูกเปลี่ยนไปเป็นพวกตัว %20%74 เป็นต้น อาจจะเป็น hacker ที่ปลอม ui เผื่อดักเอาข้อมูล สำคัญได้ และควรตรวจสอบดูว่า เป็น https ด้วยหรือป่าว
A8 Insecure Deserialization
คือ การที่ระบบมีการแปลง object ไปเป็นรูปแบบต่างๆหรือที่เรียกว่า serialization นั้นจะทำให้ข้อมูลปลอดภัยมากยิ่งขึ้น แต่ที่จริงแล้ว มันสามารถ injection ตัว object ที่ serialize ได้เหมือนกัน ด้วย deserialize นั้น ก็จะทำ hacker สามารถเปลี่ยนสิ่งที่ถูก serialize เอาไว้เป็นคลาสที่ไม่ปลอดภัย และสามารถเรียกใช้งาน method ที่อันตรายได้
ทางแก้คือ จำกัด หรือ strict ข้อมูล ตรวจสอบหรือลายเซ็นดิจิทัลเพื่อให้แน่ใจว่าแหล่งข้อมูลที่เชื่อถือได้ หรือ อนุญาตให้ deserialize ข้อมูลสำหรับคลาสที่มีอยู่ในแอปพลิเคชันโดย ObjectInputStream ที่กำหนดเองด้วยคลาสเฉพาะ
A9 Using Components with Know Vulnerabilities
ข้อนี้หลายๆคนอาจจะมองข้ามก็เป็นได้ เพราะ มีความคิดว่า การที่ไปเรียกใช้ components ต่างๆ frameworks ต่างๆ libraries หรือ plugin อะไรพวกนี้ จะปลอดภัย แต่ที่จริงแล้ว ก็เป็นอีกช่องทางความเสี่ยงที่ทำให้ hacker สามารถโจมตีได้
ทางแก้คือ เรียกใช้งานพวก libraries หรือ plugin ให้น้อยที่สุดเท่าที่จำเป็น หากหลีกเลี่ยงไม่ได้จริงๆ ก็ควร upgrade libraries ต่างๆ patch ให้เรียบร้อย ให้ใหม่ล่าสุดอยู่เสมอ เพื่อป้องกันผลกระทบจากข้อนี้
A10 Insufficient Logging & Monitoring
คือ การที่ hacker กำลังพยายามเจาะระบบอยู่ แบบยิง brute force password เลย แต่ระบบมีการเก็บ log ไม่ละเอียดพอ หรือบอกไม่ชัดเจน ในขณะที่ข้อมูลกำลังตกอยู่ในอันตราย ก็จะทำให้ระบบสามารถถูกโจมตีได้ โดยที่ตรวจสอบ log แต่ไม่พบความผิดปกติใดๆ
ทางแก้คือ เนื่องจากข้อนี้มันคือ การบันทึกและเฝ้าติดตามตรวจสอบข้อมูล ก็ควรเก็บข้อมูล log ต่างๆให้ระเอียด ให้ครบทุก field ยิ่งดี เพื่อที่จะทำให้เราได้ทันระวังตัว และหาทางจัดการกับช่องโหว่นั้น ซึ่งในความเป็นจริงน้อยมากที่จะมีคนมานั่งดู log แบบนี้ อาจจะโดนโจมตีแล้วก็ได้นะครับ55+…สุดท้ายนี้ก็หวังว่าบทความนี้จะมีประโชยน์แก่ผู้อ่านไม่มากก็น้อยนะครับ ผิดพลาดประการณ์ใดก็ขออภัยไว้ ณ ที่นี้ด้วย…
