ความปลอดภัยเป็นเรื่องสำคัญสำหรับ product ทางการเงิน!

เพราะความปลอดภัยของ user เป็นเรื่องสำคัญ

ทำความรู้จัก OWASP Top 10 Mobile Application Security Risks (2024) กัน

.

ด้วยความที่แอดมินเพจนี้ทำ fintech product ก็ต้องถูกอบรมเรื่อง security ตลอด ๆ แล้วชอบดอง content เรื่องนี้ตลอดเลย

กับมาตรฐาน security ที่หลาย ๆ ที่ใช้กัน คือ OWASP นั่นเอง

แล้วมันคืออะไร? แล้วมีอะไรบ้าง? รวมถึงฝั่ง mobile app มีอะไรบ้าง?

.

🔵 OWASP คืออะไร?

OWASP ซึ่งย่อมาจาก Open Worldwide Application Security Project เขาเป็นองค์กรไม่แสวงหาผลกำไร (non-profit organization) ที่ให้ความรู้เกี่ยวกับการทำให้ระบบคอมพิวเตอร์มีความปลอดภัยมากยิ่งขึ้นนั่นเอง

โดยแต่ละปีทาง OWASP จะประกาศ Top 10 list ขึ้นมา ซึ่งของปี 2025 เป็นฝั่ง web application ที่เขามี update เรื่อง security ก่อนหน้านี้ในปี 2017 และปี 2021

ส่วนของแอพมือถือที่เราจะพูดถึงนี้เป็น Top 10 list ในปี 2024 มีอัพเดตก่อนหน้านี้ในปี 2014 และ 2016

นอกจากตัว web และ mobile แล้ว ยังมีตัวอื่น ๆ อย่าง API security, cloud-native, LLM AI, Privacy โดยเขาจะอัพเดตพวกนี้ทุก ๆ 3 - 4 ปี โดยจะมีหัวข้อเดิม หรือหัวข้อเดิมที่รวมกัน และหัวข้อใหม่ ให้เราได้อัพเดตกัน ตัว ranking เรียงจาก impact ผลกระทบ ความบ่อยที่เจอ

.

🔵 OWASP Top 10 Mobile Application Security Risks (2024)

แล้ว OWASP Mobile Top 10 (2024) มีอะไรบ้าง?

🗒️ M1: Improper Credential Usage (การจัดการ Credential ไม่เหมาะสม)

⚠️ ความเสี่ยง: เกิดจากการ Hardcode ข้อมูลสำคัญ เช่น API Key, Token หรือรหัสผ่านไว้ใน Source Code หรือไฟล์การตั้งค่า ซึ่งทำให้ผู้โจมตีสามารถทำ Reverse Engineer เพื่อขโมยข้อมูลไปใช้ในการโจมตีระบบหลังบ้านได้

🔧 ทางแก้: ห้ามเก็บ Credential ไว้ใน Code โดยเด็ดขาด ควรใช้กลยุทธ์การ Rotate API keys/Tokens อย่างสม่ำเสมอ และใช้การยืนยันตัวตนที่แข็งแกร่ง เช่น Multi-factor authentication

🗒️ M2: Inadequate Supply Chain Security (ความปลอดภัยของ Supply Chain ไม่เพียงพอ)

⚠️ ความเสี่ยง: ช่องโหว่ที่เกิดจาก Third-party Library หรือ SDK ที่ไม่ปลอดภัย รวมถึงกระบวนการ Build และการกระจายแอปฯ หากผู้พัฒนาต้นทางถูกโจมตี แอปฯ ของเราจะได้รับผลกระทบไปด้วย

🔧 ทางแก้: เลือกใช้เฉพาะ Library/SDK ที่ น่าเชื่อถือและผ่านการตรวจสอบแล้ว พร้อมทั้งหมั่นอัปเดต Patch และตรวจสอบช่องโหว่ (CVE) ในส่วนประกอบภายนอกอย่างสม่ำเสมอ

🗒️ M3: Insecure Authentication/Authorization (ระบบยืนยันตัวตน/สิทธิ์ไม่รัดกุม)

⚠️ ความเสี่ยง: การออกแบบระบบที่หละหลวมทำให้ผู้โจมตีสามารถ Bypass Authentication หรือทำ Privilege Escalation (ยกระดับสิทธิ์จากผู้ใช้ทั่วไปเป็นผู้ดูแลระบบ) เพื่อเข้าถึงฟังก์ชันสำคัญได้

🔧 ทางแก้: ควร ตรวจสอบสิทธิ์ที่ฝั่ง Server-side เสมอ และไม่ควรส่งสถานะสิทธิ์ (Roles/Permissions) จากฝั่ง Client ไปยังระบบหลังบ้านโดยตรง

🗒️ M4: Insufficient Input/Output Validation (การตรวจสอบข้อมูลเข้า/ออก ไม่เพียงพอ)

⚠️ ความเสี่ยง: แอปฯ เชื่อใจข้อมูลจากแหล่งที่ไม่ได้รับการยืนยัน (เช่น ค่าจาก Dropdown หรือ Input จากผู้ใช้) นำไปสู่การโจมตีประเภท SQL Injection, Command Injection หรือ Cross-site Scripting (XSS)

🔧 ทางแก้: ทำการ Validate และ Sanitize ข้อมูล ทั้งฝั่งขาเข้าและขาออกอย่างเข้มงวด ทั้งในระดับ Client และ Server เพื่อความปลอดภัยสูงสุด

🗒️ M5: Insecure Communication (การสื่อสารที่ไม่ปลอดภัย)

⚠️ ความเสี่ยง: การส่งข้อมูลผ่าน HTTP หรือ Protocol ที่ล้าสมัย ทำให้ผู้โจมตีสามารถดักจับข้อมูล (Sniffing) หรือทำ Man-in-the-Middle (MITM) เพื่อแก้ไขข้อมูลระหว่างทางได้

🔧 ทางแก้: ใช้ HTTPS/TLS ที่เป็นมาตรฐานล่าสุดเสมอ และควรทำ Certificate Pinning เพื่อป้องกันการถูกสวมรอยผ่าน Certificate ปลอม

🗒️ M6: Inadequate Privacy Controls (การควบคุมความเป็นส่วนตัวไม่เพียงพอ)

⚠️ ความเสี่ยง: การขอเข้าถึงข้อมูลส่วนบุคคล (PII) มากเกินจำเป็น หรือการจัดการสิทธิ์การเข้าถึงไม่ดี นำไปสู่การขโมยอัตลักษณ์หรือละเมิดกฎหมายความเป็นส่วนตัว

🔧 ทางแก้: ขอ Permission เท่าที่จำเป็น แจ้งวัตถุประสงค์ให้ชัดเจน และปฏิบัติตามกฎหมาย เช่น PDPA หรือ GDPR โดยลดการเก็บข้อมูลที่ระบุตัวตนผู้ใช้ให้เหลือน้อยที่สุด

🗒️ M7: Insufficient Binary Protections (การป้องกันไฟล์ Binary ไม่เพียงพอ)

⚠️ ความเสี่ยง: หากไฟล์แอปฯ (Binary) ไม่มีการป้องกัน ผู้ไม่หวังดีจะสามารถทำ Reverse Engineering เพื่อขโมยทรัพย์สินทางปัญญา หรือแก้ไข Code เพื่อปลดล็อกฟีเจอร์ที่ต้องจ่ายเงิน

🔧 ทางแก้: ใช้เทคนิค Binary Obfuscation เพื่อให้ Code อ่านเข้าใจยาก และทำ Integrity Checks เพื่อตรวจสอบว่า Code ถูกดัดแปลง (Tamper) หรือไม่

🗒️ M8: Security Misconfiguration (การตั้งค่าความปลอดภัยผิดพลาด)

⚠️ ความเสี่ยง: การตั้งค่าความปลอดภัยพื้นฐานไม่เหมาะสม เช่น เปิดโหมด Debug ทิ้งไว้ หรือให้สิทธิ์แอปฯ มากเกินไป (Over-privileged) ซึ่งเป็นการเปิดช่องทางให้ผู้โจมตี

🔧 ทางแก้: ยึดหลัก Least Privilege โดยขอสิทธิ์เท่าที่แอปฯ ต้องใช้จริง ปิดโหมด Debug ในเวอร์ชัน Production และตั้งค่าพื้นฐานให้มั่นคงปลอดภัย

🗒️ M9: Insecure Data Storage (การจัดเก็บข้อมูลไม่ปลอดภัย)

⚠️ ความเสี่ยง: การเก็บข้อมูลสำคัญ (Sensitive Data) ไว้ใน Local Storage โดยไม่มีการเข้ารหัส หรือเก็บไว้ในที่ที่แอปฯ อื่นเข้าถึงได้ง่าย

🔧 ทางแก้: ใช้การเข้ารหัสที่แข็งแกร่ง และจัดเก็บข้อมูลใน Secure Storage ของระบบปฏิบัติการ เช่น Keychain (iOS) หรือ Keystore (Android)

🗒️ M10: Insufficient Cryptography (การเข้ารหัสข้อมูลที่ไม่ได้มาตรฐาน)

⚠️ ความเสี่ยง: การใช้ Algorithm ที่เก่าหรือล้าสมัย (เช่น MD5, SHA1), ความยาว Key ไม่เพียงพอ หรือกระบวนการจัดการ Key ที่ไม่ดี

🔧 ทางแก้: เลือกใช้ Algorithm ที่เป็นมาตรฐานสากล (เช่น AES, RSA ความยาวสูง) มีการทำ Key Rotation และห้ามสร้างระบบเข้ารหัสขึ้นเอง (Custom Crypto)

.

🔵 ถ้าเทียบกับปี 2016 มีอะไรเปลี่ยนแปลงไปบ้าง?

ห่างกัน 8 ปี แน่นอนว่าเปลี่ยนเยอะแน่นอน โดย

- เปลี่ยนจุดโฟกัส: ย้ายจากความปลอดภัยระดับ Code Quality ไปเน้นเรื่อง Credential และ Supply Chain แทน

- M1 (ใหม่): ให้ความสำคัญสูงสุดกับการป้องกัน Hardcoded Secrets และการหลุดของ API Keys

- M2 & M6 (ใหม่): เพิ่มการตรวจสอบช่องโหว่จาก Library ภายนอก และการจัดการ Privacy (PDPA/GDPR)

- การยุบรวม: รวมเรื่อง Auth/Authz (M3) และการป้องกันการแกะโค้ด (M7) เข้าด้วยกันเพื่อให้จัดการง่ายขึ้น

- ลำดับที่ลดลง: เรื่อง Storage (M9) และ Cryptography (M10) อันดับตกลงเพราะ OS สมัยใหม่มีระบบช่วยจัดการดีขึ้น

- คำแนะนำ: นักพัฒนาควรเลิกฝัง Password ในแอป, ตรวจสอบ SDK ที่นำมาใช้ และเข้มงวดเรื่องการรับส่งข้อมูล

ทั้งหมดก็จะประมาณนี้แหละ

#รวมเรื่องไอที #ไอทีน่ารู้ #รอบรู้ไอที #programmer #developer