OWASP Top 10 2021 – 10 อันดับต้องเช็ค เพื่อเพิ่มความปลอดภัยให้เว็บ แอปพลิเคชัน

OWASP คืออะไร?

OWASP  หรือ Open Web Application Security Project  จัดตั้งโดย  OWASP Foundation เป็นองค์กรไม่แสวงหาผลกำไร ที่ให้ความรู้เพื่อเน้นเรื่องระบบความปลอดภัยในภาพรวมในหลายแง่มุมไม่ว่าจะเป็นการทดสอบแฮก การเขียนโค้ดให้ปลอดภัย และการกำหนดนโยบายหรือมาตรฐานด้านความปลอดภัยให้แอปพลิเคชันทั้งทางเว็บไซต์ และความปลอดภัยของแอปพลิเคชันทางโทรศัพท์มือถือ แต่ในบทความนี้เราจะเน้นไปที่ระบบความปลอดภัยทางเว็บไซต์

OWASP Top 10 คืออะไร ?

โครงการหนึ่งของ OWASP ที่จัดอันดับ 10 ความเสี่ยงทางด้านความปลอดภัย ซึ่งทุกๆ 4 ปีจะมีการจัดอันดับช่องโหว่ใหม่เพื่อให้องค์กรต่างๆ ทั่วโลกได้นำข้อมูลตรงนี้ไปใช้ปกป้องข้อมูลของตนเองได้อย่างถูกต้องและทันยุคทันสมัยต่อเหตุการณ์ต่างๆ ที่เกิดขึ้น โดยในช่วง 4 ปีที่ผ่านมา มีการเปลี่ยนแปลงอันดับยอดนิยมตามรูปด้านล่างซึ่งจะเห็นว่าเรื่องที่น่าจับตามองที่สุด คงจะเป็นเรื่อง Broken Access Control ที่ขึ้นมาจากอันดับ 5 กลายมาเป็นอันดับ 1 ซึ่งสิบอันดับปี 2021 มีดังนี้

1. A01-Broken Access Control

ข้อนี้เลื่อนจากอันดับ 5 มาเป็นอันดับ 1 ในปี 2021 เกิดจากสิทธิ์ในการใช้งานใน user ทำได้มากเกินกว่าที่ user level นั้นควรจะทำได้ เช่น ยังไม่ได้ Login แต่พิมพ์ URL ตรงเข้าในส่วนของ Admin เพื่อดูข้อมูลทั้งหมดของเว็บได้ หรือแก้ไข User id หรือ Unique id บางอย่างเพื่อเข้าถึงไฟล์ที่เราไม่ใช่เจ้าของได้อย่างง่ายดาย ลองคิดดูว่าถ้าระบบให้ upload รูปบัตรประชาชน และเราสามารถแก้ไขบางส่วนของ URL เพื่อไปแอบดูบัตรประชาชนคนอื่นในระบบได้จะน่ากลัวขนาดไหน โอ้โห! ไม่ดีแน่ๆ ขั้นเลวร้ายที่สุด อาจเข้าไปแก้ไขข้อมูลของ User คนอื่นในระบบได้ด้วยเพียงแค่แก้ URL ข้อนี้มักเกิดจากคนซน แก้ไข URL ไปในรูปแบบต่างๆ จนไปยุ่งกับข้อมูลของคนอื่นได้ ต้องระวังให้มาก

นอกจากเรื่องสิทธิ์จากการแก้ไข URL แล้ว ข้อนี้ยังรวมไปถึงการ config CORS ผิด ทำให้คนนอกสามารถ Access API จากเว็บภายนอกได้ ทั้งที่ไม่ควรจะ Access ได้ด้วยเช่นกัน

วิธีป้องกัน

กรณีใช้ Apache ต้องตั้งค่า .htaccess เพื่อป้องกันการเข้าถึง directory ต่างๆ โดยตรง และต้องมีการตรวจสอบสถานะ Login ในทุกๆ หน้าที่เป็นหน้าของสมาชิกเว็บ รวมถึงตรวจสอบว่าหน้านี้สิทธิ์ของ User คนนี้สามารถทำอะไรได้บ้าง อ่านได้ เขียนได้ ลบได้หรือไม่? ถ้าไม่ได้ต้องแสดงข้อความว่า Access Denied ตั้งแต่แรก อย่าปล่อยให้หลุดเข้ามาได้เด็ดขาด อันตรายเป็นอย่างมาก

2. A02-Cryptographic Failures

ข้อนี้เลื่อนจากอันดับ 3 มาเป็นอันดับ 2 ในปี 2021 และเพิ่มส่วนของการ encryption เข้ามาปัจจุบัน PDPA หรือพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลกำลังจะถูกบังคับใช้ในไม่ช้า การเข้าถึงข้อมูลส่วนตัวเช่น วันเกิด, เลขประจำตัวประชาชน, ข้อมูลสุขภาพ, เลขบัตรเครดิต เบอร์โทรศัพท์ ได้จากหน้าเว็บมีความ sensitive ที่สูงมาก หรือ database ไมไ่ด้ทำการ encrypt ข้อมูลเหล่านี้เอาไว้และถูก hack ออกไปจากไฟล์ backup ฐานข้อมูลได้ หากข้อมูลเหล่านี้ถูกเก็บไปใช้โดยผู้ไม่ประสงค์ดีจะมีความเสียหายสูง อาจถึงขั้นใช้ข้อมูลไปหลอก Call Center ว่าเป็นเจ้าของข้อมูลตัวจริงได้เลยทีเดียว ซึ่งส่งผลกระทบอย่างร้ายแรงได้เลย

ช่องโหว่นี้รวมถึงการไม่ได้เก็บข้อมูลรหัสผ่านแบบ Hash หรือใช้ Password Hashing Function ที่ล้าสมัยแล้วเช่น MD5, SHA1 และ password สามารถถูกใช้ฐานข้อมูล Rainbow Table ในการแกะ Hash ได้อย่างง่ายดาย

3. A03-Injection

ตกอันดับจากอันดับ 1 ตลอดกาลมานานลงมาเป็นอันดับ 3 แบ่งออกเป็นสองประเภทใหญ่ๆ คือ Injection ผ่าน Code ทั่วไปเช่น ช่องโหว่ยอดนิยมมากที่สุดคือ SQL Injection และ Injection ผ่าน XSS 

• ช่องโหว่ Injection มักเกิดจากการที่โปรแกรมของเราเปิดรับ Input ที่เป็น String จาก User เข้ามาทำงานในระบบ จากช่องทางใดก็แล้วแต่ ไม่ว่าจะเป็น Parameter ใน URL หรือ form แต่ User กลับส่ง String ที่เป็นคำสั่งประสงค์ร้ายมาทำให้ Compiler เข้าใจผิด คิดว่าเป็นคำสั่งที่ทางผู้สร้างกำหนดไว้เอง User จึงเข้าถึงข้อมูลที่ไม่ควรจะเข้าถึงได้หรือแก้ไขข้อมูลที่ไม่ควรจะแก้ได้ สุดท้ายจึงทำให้เป็นช่องโหว่เกิดขึ้น ตัวอย่าง SQL Injection คือ User ที่มีความรู้สามารถสั่งแก้ไขหรือลบ Table ใน Database ได้เลยทีเดียวหากปล่อยช่องโหว่นี้ไว้จะ ส่งผลกระทบอย่างร้ายแรงต่อฐานข้อมูลของ User คนอื่นๆ ในระบบ วิธีป้องกันคือต้องใช้ Prepared Statement ในการ Query SQL หรือใช้คำสั่ง Escape Command ที่ถูกออกแบบมาโดยเฉพาะในแต่ละภาษา เพื่อป้องกันการส่ง Command โดยตรงมารัน

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

ตัวอย่างการใช้ prepared statement

• ช่องโหว่ Injection ประเภทถัดมาคือ Cross Site Script โดยเป็นการแอบแทรก Code คำสั่งไปทำงานเช่นเดียวกัน แค่จุดประสงค์ปลายทางจะต่างออกไป คือการแทรกคำสั่ง javascript เพื่อขโมย Cookie ในการยืนยันตัวตนของ User คนอื่นมาสวมรอยเป็น User คนอื่นในการทำ action ใดๆ แทนทั้งหมด ซึ่งอันตรายพอๆ กัน การป้องกันสามารถตั้งค่า Cookie เป็นแบบ HTTP Only และ HTTP Secure เพื่อให้ Cookie ถูกเข้าถึงได้จาก Web Server เท่านั้นก็จะสามารถป้องกันช่องโหว่ตรงนี้ได้
• นอกจากนี้ยังมี Injection ในรูปแบบอื่นๆ อีกมากมาย เช่น
  • SQL Injection
  • NoSQL Injection
  • System Call Injection / OS Command Injection
  • LDAP Injection
  • Expression Language Injection
  • Eval
  • Path Manipulation

4. A04-Insecure Design

ช่องโหว่นี้เป็นช่องโหว่ใหม่ที่เพิ่มเข้ามา ไม่เคยถูกจัดอันดับติด 10 อันดับแรกมาก่อน คือการ Design ระบบ Architecture ที่ผิดพลาด ซึ่งไม่ใช่ปัญหาที่เกิดจากการ Implement ผิดวิธี หรือการออก Policy ที่ผิดพลาด เช่น

• เก็บข้อมูล Secret ใดๆ พวก api key, private key ไว้ที่ Client แม้ว่าจะมีการเข้ารหัสไว้แน่นหนาก็ตาม ควรเลี่ยงไปเก็บบน Server หากเป็นไปได้
• การอนุญาตให้แก้ไขข้อมูลสำคัญเช่น email โดยไม่ได้ถาม password ก่อน ทำให้บุคคลอื่นสามารถกด forgot password เพื่อตั้งค่ารหัสผ่านใหม่ได้ทันทีที่เซ็ตอีเมลใหม่ได้
• ใช้ระบบคำถามลืมรหัสผ่านที่ง่ายเกินไป เช่น วันเดือนปีเกิด ในการเข้าสู่ระบบเมื่อจำรหัสผ่านไม่ได้
• การ Design ที่ไม่ได้คิดเผื่อกรณีของ bot มาร่วมใช้งาน Software ด้วย เช่น การแจกเงินฟรีให้ account ใหม่ แล้วผู้ใช้สามารถปั๊ม account มาโอนเงินฟรีให้กับอีก account ได้ ทำให้บริษัทสูญเสียเงินจาก account เปิดใหม่เรื่อยๆ ไม่มีที่สิ้นสุดโดยไม่ได้กำไรจาก account พวกนี้เลย เป็นต้น

5. A05-Security Misconfiguration

เลื่อนจากอันดับ 6 ขึ้นมาเป็นอันดับ 5 การตั้งค่าผิด หรือลืมตั้งค่า ส่งผลให้มีช่องโหว่ที่ไม่ได้ตั้งใจหลุดออกไป เช่น

• Default Configuration หรือการใช้ค่า default ของซอฟต์แวร์โดยเฉพาะอย่างยิ่งฐานข้อมูล โดยไม่แก้ไข username และ password ก่อนใช้เลย (เช่น admin, admin หรือ password ว่างเปล่า) ส่งผลให้เดารหัสผ่านจาก google ได้ทันทีอย่างไม่ยากเย็นอะไร และเข้าถึงฐานข้อมูลได้เลย ซึ่งส่งผลเสียอย่างร้ายแรงมาก
• เปิด Error Message ออกแสดงบนหน้า Web Browser ทำให้ผู้ใช้ทั่วไปเห็น Code หรือ Query ที่ใช้อย่างชัดเจนโดยที่ยังไม่ได้พยายาม Hack อะไรเลย
• ตั้งค่า Config เป็น development mode แล้วนำ software version development ขึ้น production server สุดท้ายจึงทำงานได้ช้า และอาจไม่ได้เก็บ Error Log ลงไฟล์ ทำให้ย้อนมาดู Error ย้อนหลังไม่ได้
• Open cloud storage permission หรือตั้งค่า permission ผิด เช่น ตั้งค่าการเข้าถึง Amazon S3 เป็น Public ทั้งๆ ที่ค่า Default เป็น private ส่งผลให้ใครก็ได้เข้าถึงไฟล์บน S3 ของเราได้ทั้งหมด หากเป็นไฟล์รูปบัตรประชาชนขึ้นมาจะเป็นเรื่องใหญ่ทันที
• เปิด port หรือ permission ให้มากเกินความจำเป็น ยิ่ง port เยอะ ช่องโหว่ก็ยิ่งเยอะ
• OS, Frameworks, Libraries ไม่ได้ config ค่าให้ปลอดภัยตามคำแนะนำก่อนขึ้น production
• ไม่ได้ลบไฟล์ตัวอย่างหรือไฟล์ติดตั้งใน Production เช่น WordPress ส่งผลให้มีบุคคลภายนอกมาตั้งค่าทับ หรือใช้ช่องโหว่จากไฟล์ตัวอย่างในการเข้าถึงข้อมูลผู้ใช้

6. A06-Vulnerable and Outdated Components

ช่องโหว่นี้เป็นช่องโหว่ยอดนิยมสำหรับองค์กรที่มี Software เก่าแก่ใช้มาต่อเนื่องหลายปี และไม่กล้า Upgrade software ที่ใช้เพราะกลัวว่า Software เก่าแก่จะทำงานไม่ได้ เช่น หลายองค์กรยังคงใช้ Internet Explorer หรือ Windows XP ทั้งๆ ที่รู้ว่าหมดระยะเวลา Support Security patch มานานแล้ว Feature ใหม่ๆ ก็ไม่มี แต่ยังอดทนใช้ต่อ จึงเป็นความเสี่ยงที่เหมือนองค์กรรู้อยู่ แต่บางที่ทำเป็นไม่สนใจ แต่มันมีอยู่ สุดท้ายหากเกิดโดน hack ขึ้นมาก็อาจสูญเสียหลายอย่างมากมาย วิธีป้องกันคือต้องยอมลงทุน upgrade software ขององค์กรหรือยอมลงทุนสร้างใหม่หมด เพื่ออนาคตที่ดีกว่า 

7. A07-Identification and Authentication Failures

ช่องโหว่นี้คือการที่ hacker สามารถขโมย Identity ของผู้ใช้หรือเดาสุ่ม password จนถูกและเข้ายึด account ได้ ซึ่งเกิดได้จากหลายสาเหตุ เช่น

• เปิดให้ Brute Force username, password ได้ หรือลองกรอก password แบบสุ่มไปเรื่อยๆ จนกว่าจะถูก ซึ่งสามารถป้องกันได้ด้วยการ lock ห้ามกรอก password เกินจำนวนครั้งที่กำหนด
• ใช้ default password เหมือนกันทุก user 
• ใช้กระบวนการ forgot password ที่ไม่มีประสิทธิภาพ (ไม่ hash ) ทำให้ hacker ถ้าขโมยคำตอบของคำถามลืม password มาได้ ก็จะยึด account ได้ทันที
• password ไม่ได้ hash 
• cookies hi-jack จาก XSS
• access token hi-jack จากการไม่ใช้ https ในการรับส่งข้อมูล
• ส่ง session id ผ่าน URL จึงถูก log ไว้ทั้งเครื่อง client และเครื่อง server
• ค่า session ไม่ได้ถูกทำลายอย่างถูกต้องในกระบวนการ logout โดยเฉพาะอย่างยิ่งระบบ Single Sign-on tokens เมื่อ sign out จึงยังหลงเหลือ identity ให้ถูกขโมยไปใช้งานซ้ำได้

วิธีป้องกัน

• ใช้ Multi Factor Authentication เช่น SMS เข้าช่วยยืนยันตัวตนนอกจาก password
• ไม่ส่ง default password ที่เหมือนกันทุก user โดยเฉพาะอย่างยิ่ง admin
• เพิ่มระบบ Weak password check
• ระวังไม่ให้ระบบลืม password กลายเป็นช่องโหว่ในการขอรหัสผ่านหรือสุ่มรหัสผ่านได้ง่าย
• Limit หรือ delay หากมีการ Login พลาดหลายครั้ง
• Session ID ต้องไม่ถูกส่งผ่าน URL
• ต้องมีการทำลาย session อย่างถูกต้องหลัง logout, timeout

8. A08-Software and Data Integrity Failures

ส่วนนี้คือช่องโหว่ของการติดตั้ง software หรือการถูกสอดแทรก code บางอย่างให้มารันตอน integration โดยไม่ได้ตั้งใจ เช่น

• การ upgrade software โดยไม่ตรวจสอบความเข้ากันได้ของ software
• การทำ CI/CD pipelines ที่ไม่ได้มีการทดสอบการทำงานร่วมกัน หรือปล่อยให้คนนอกเข้าถึงได้
• ไม่ได้ทำการตรวจสอบ Digital Signature เวลาลง Software ใดๆ ว่ามาจากต้นทางตัวจริง
• Remote code execution
• การ Deserialize แล้ว code ส่วนของ function ที่เก็บค่ามาถูกรันไปด้วย

วิธีป้องกัน

• ไม่ใช้ software ที่ version ยังไม่ stable ใช้แต่ตระกูล LTS
• เลือกใช้ Linux OS ที่ Stable เช่น Debian / Centos
• checksum hashes file ที่ Download มาทุกครั้งก่อน install

(ตัวอย่าง: https://ubuntu.com/tutorials/how-to-verify-ubuntu#1-overview)

• ใช้งาน Software Repository ที่เชื่อถือได้เท่านั้น
• ห้ามไม่ให้มีการสั่ง Deserialization กับข้อมูลจากผู้ใช้เลยหากเป็นไปได้
• มีการ Review กระบวนการ CI/CD และการเปลี่ยน configuration ให้สิทธิ์เฉพาะบุคคลที่ควรเข้าถึงได้เท่านั้น ไม่ให้มีการแทรก code อันตรายเข้ามาได้

9. A09-Security Logging and Monitoring Failures

จากผลการวิจัยพบว่าเวลาที่ค้นพบการเจาะระบบมักจะมากกว่า 200 วันหลังเกิดเหตุไปแล้ว และมักพบโดยบริษัทภายนอกเสมอ ซึ่ง developer อาจไม่ได้ Log พฤติกรรมสำคัญๆ ให้ครบเช่น Login, Login Fail, Money Transfer หรือไม่มีการตั้งค่า Log Threshold ไว้ทำให้พลาดค่า log อันตรายบางตัวไปเพราะ Log เยอะเกินไป หรือ Application ไม่สามารถแจ้งเตือนเมื่อพบเหตุการณ์ผิดปกติได้ในระดับใกล้เคียง Real Time

วิธีป้องกัน

ควร Log พฤติกรรมสำคัญๆ ให้ครบ และเช็คให้แน่ใจว่า Log ถูก generate ใน format ที่ centralized log management  เข้ามาเก็บข้อมูลไปใช้ได้ง่ายเพื่อให้สามารถรวม Log มาอ่านได้ง่าย จะได้ไม่มีอะไรตกหล่นเพราะ Log กระจายอยู่หลายเครื่องมากเกินไป และต้องเก็บ Log แบบ Append Only เพื่อเก็บทุกเหตุการณ์ที่อาจเกิดเข้าไว้ด้วยกัน พร้อมระบบแจ้งเตือนเมื่อมีเหตุการณ์ผิดปกติเกิดขึ้น เพื่อให้หากมีเหตุไม่คาดฝันเราจะได้รู้ตัวและหาทางแก้ไขให้เร็วที่สุด

10. A10-Server-Side Request Forgery

ช่องโหว่นี้คือการปลอม request ฝั่ง server ซึ่งเกิดจากการอนุญาตให้มีการ fetch ข้อมูลจากฝั่ง server เองจากภายนอกมาใช้งาน เช่น

• https://public.example.com/proxy?url=google.com
• https://public.example.com/proxy?url=127.0.0.1:3306
• https://public.example.com/proxy?url=file://passwd

แล้วมีการใช้ script ในฝั่ง Server ยิงไปตาม parameter url ด้านบน ส่งผลให้สามารถเข้าถึงไฟล์ลับบน server ได้รวมถึงฐานข้อมูล ทั้งที่คนนอกไม่ควรจะเข้าถึงได้เลย

วิธีป้องกัน

ควรแยก server ที่ต้องมีการ fetch ข้อมูลออกไปอยู่คนละ network เพื่อป้องกันผลกระทบที่อาจเกิดขึ้น และตั้งกฎที่ Firewall ให้เป็น Deny by Default และ Validate ข้อมูลที่ Client กรอกมาก่อนทั้งหมดไม่ให้กรอก protocol หรือ url แปลกๆ เข้ามา บังคับ URL, port ที่ใช้งานได้ผ่าน Whitelist ที่กำหนดเท่านั้น ห้ามใช้ Blacklist

สรุป

จะเห็นได้ว่าช่องโหว่บางอย่างก็ไม่ได้ป้องกันยากมาก และช่องโหว่บางอย่างต้องการการป้องกันและตรวจสอบอย่างสม่ำเสมอ เพื่อไม่ให้ตกเป็นเหยื่อของ Hacker ที่มีรูปแบบการโจมตีใหม่ ๆ มาใช้โจมตีเสมอ เป็นหน้าที่ขององค์กรทุกแห่งที่มีข้อมูลของลูกค้าและข้อมูลความลับภายในองค์กรใด ๆ จะต้องศึกษาช่องโหว่เหล่านี้และพลิกแพลงหาทางป้องกันที่สอดคล้องกับนโยบายองค์กร โดยเลือกระดับความปลอดภัยที่เหมาะสมกับต้นทุนที่ต้องลงทุนทางด้าน Security และอาจจ้างตำแหน่งเฉพาะทางเช่น Chief Security Officer มาช่วยดูแลก็จะเป็นการแก้ปัญหาที่ยั่งยืนที่สุด เพราะช่องโหว่ใหม่ ๆ นั้นเกิดขึ้นทุกวัน หากข้อมูลขององค์กรคุณมีคุณค่า ก็ควรที่จะมอบหมายให้ผู้เชี่ยวชาญเฉพาะทางมาช่วยดูแลครับ