ความปลอดภัยในการพัฒนามือถือ: คืออะไร มีภัยคุกคามอะไรบ้าง และวิธีป้องกัน

ภัยคุกคามหลัก: OWASP Mobile Top 10

OWASP Mobile Top 10 คืออะไร

OWASP (Open Web Application Security Project) เป็นองค์กรไม่แสวงหาผลกำไรที่เผยแพร่การจัดอันดับช่องโหว่ด้านความปลอดภัยบนมือถือที่อันตรายที่สุด OWASP Mobile Top 10 คือรายการที่ช่วยให้นักพัฒนาเข้าใจว่าควรมุ่งเน้นอะไรก่อน ในเวอร์ชัน 2024 ปัญหาที่เกี่ยวข้องกับการจัดเก็บที่ไม่ปลอดภัย การตรวจสอบสิทธิ์ที่อ่อนแอ และการสื่อสารเครือข่ายที่ไม่ปลอดภัยเป็นผู้นำในการจัดอันดับ

M1: การจัดเก็บข้อมูลที่ไม่ปลอดภัย — ปัญหาที่พบบ่อยที่สุด: รหัสผ่าน โทเค็น และข้อมูลส่วนบุคคลยังคงอยู่ใน SharedPreferences, NSUserDefaults หรือไฟล์ในเครื่องโดยไม่มีการเข้ารหัส M2: การตรวจสอบสิทธิ์ที่อ่อนแอ — ขาดการตรวจสอบฝั่งเซิร์ฟเวอร์ รหัสผ่านที่อ่อนแอ M3: การสื่อสารเครือข่ายที่ไม่ปลอดภัย — ขาด HTTPS หรือการตรวจสอบใบรับรอง SSL ที่ไม่ถูกต้อง M4 และ M5 เกี่ยวข้องกับการเข้ารหัสและการใช้ API ที่ไม่ถูกต้อง

M6: การอนุญาตที่ไม่ปลอดภัย — ผู้ใช้สามารถเข้าถึงข้อมูลของผู้ใช้รายอื่นโดยการเปลี่ยน ID ในคำขอ M7: การฉีดโค้ด (SQL Injection, XSS) M8: การจัดการแอปพลิเคชัน — การบรรจุใหม่ การเปลี่ยนโค้ด M9 และ M10 — การรั่วไหลของข้อมูลผ่านไลบรารีของบุคคลที่สามและการวิศวกรรมย้อนกลับ สำหรับภัยคุกคามแต่ละอย่างเหล่านี้มีมาตรการตอบโต้ที่พิสูจน์แล้ว และที่ IT Sectr เราได้นำไปใช้ในทุกโครงการตั้งแต่ปี 2017

การโจมตีแบบ Man-in-the-Middle (MITM)

การโจมตี MITM เกิดขึ้นเมื่อผู้โจมตีดักจับการรับส่งข้อมูลระหว่างแอปพลิเคชันและเซิร์ฟเวอร์ สิ่งนี้เป็นไปได้ผ่านการปลอมแปลง DNS, ARP spoofing หรือการเชื่อมต่อกับเครือข่าย Wi-Fi ที่ไม่ปลอดภัย ใบรับรอง SSL/TLS และ Certificate Pinning ใช้สำหรับการป้องกัน

Certificate Pinning เป็นกลไกที่แอปพลิเคชันตรวจสอบว่าใบรับรองเซิร์ฟเวอร์ตรงกับใบรับรองที่เก็บไว้ล่วงหน้าในโค้ดแอปพลิเคชัน แม้ว่าผู้โจมตีจะเปลี่ยนใบรับรองผ่านพร็อกซี (เช่น Burp Suite) แอปพลิเคชันจะปฏิเสธการเชื่อมต่อ Pinning มีสองประเภท: Public Key Pinning และ Certificate Hash Pinning

การเข้ารหัสและแฮชชิ่ง: AES, RSA, SSL/TLS

การเข้ารหัสแบบสมมาตร: AES

AES (Advanced Encryption Standard) เป็นอัลกอริธึมการเข้ารหัสแบบสมมาตร ซึ่งเป็นรากฐานของความปลอดภัยของข้อมูลบนอุปกรณ์ AES ใช้คีย์เดียวกันในการเข้ารหัสและถอดรหัสข้อมูล AES รองรับคีย์ขนาด 128, 192 หรือ 256 บิต ในการพัฒนามือถือ AES-256 ใช้สำหรับเข้ารหัสข้อมูลบนอุปกรณ์: ไฟล์ แคช บันทึกในฐานข้อมูลท้องถิ่น

โหมด AES: GCM (แนะนำ) — ให้การตรวจสอบข้อมูล, CBC — โหมดพื้นฐานพร้อมการเชื่อมโยงบล็อก, ECB — ไม่ปลอดภัย ห้ามใช้ สำหรับ iOS AES สามารถใช้งานได้ผ่าน CommonCrypto (CCOptions) สำหรับ Android — ผ่าน Cipher ใน Java Cryptography Architecture (JCA) สำคัญ: คีย์การเข้ารหัสไม่ควรถูกเก็บไว้ในโค้ดแอปพลิเคชัน — ใช้ Keychain/Keystore

การเข้ารหัสแบบไม่สมมาตร: RSA — ใช้คู่คีย์ (สาธารณะและส่วนตัว) RSA ใช้สำหรับเข้ารหัสข้อมูลปริมาณน้อย — โดยปกติสำหรับการแลกเปลี่ยนคีย์แบบสมมาตรระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ความยาวคีย์ RSA ขั้นต่ำคือ 2048 บิต (แนะนำ 4096) บน iOS RSA สามารถใช้งานได้ผ่าน Security Framework (SecKeyCreateRandomKey) บน Android — ผ่าน KeyPairGenerator ใน Android Keystore

การแฮชชิ่งและ SSL/TLS

การแฮชชิ่ง (SHA-256, SHA-3) คือการแปลงข้อมูลที่ไม่สามารถย้อนกลับเป็นสตริงความยาวคงที่ แฮชใช้สำหรับตรวจสอบความสมบูรณ์ของข้อมูลและการจัดเก็บรหัสผ่าน สำหรับรหัสผ่าน ให้ใช้ bcrypt, scrypt หรือ Argon2 — SHA-256 ธรรมดามีความเสี่ยงต่อการโจมตีด้วยตารางสีรุ้ง SSL/TLS เป็นโปรโตคอลสำหรับเข้ารหัสการรับส่งข้อมูลเครือข่ายระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ มาตรฐานสมัยใหม่คือ TLS 1.3 ซึ่งให้ Perfect Forward Secrecy (PFS)

TLS 1.3 เร็วกว่ารุ่นก่อน: การจับมือใช้เวลาแบบไป-กลับหนึ่งครั้งแทนที่จะเป็นสองครั้ง บน Android เวอร์ชัน TLS ขั้นต่ำกำหนดค่าผ่าน SSLSocket บน iOS — ผ่าน ATS (App Transport Security) ซึ่งโดยค่าเริ่มต้นต้องการ TLS 1.2 หรือสูงกว่า ATS สามารถปิดใช้งานได้เฉพาะสำหรับโดเมนเฉพาะพร้อมเหตุผล

การจัดเก็บที่ปลอดภัย: Keychain และ Keystore

iOS: Keychain

Keychain (พวงกุญแจ) เป็นพื้นที่จัดเก็บที่ปลอดภัยใน iOS / macOS สำหรับรหัสผ่าน คีย์การเข้ารหัส ใบรับรอง และโทเค็น ข้อมูลใน Keychain ถูกเข้ารหัสด้วยคีย์ฮาร์ดแวร์ที่ไม่ซ้ำกันสำหรับแต่ละอุปกรณ์ การเข้าถึง Keychain ถูกควบคุมผ่าน Security Framework (SecItemAdd, SecItemCopyMatching) Keychain จะถูกล็อกโดยอัตโนมัติเมื่ออุปกรณ์ถูกล็อกและถูกเข้ารหัสโดยใช้ Secure Enclave

Android: Keystore

Android Keystore เป็นพื้นที่จัดเก็บระบบสำหรับคีย์การเข้ารหัส ซึ่งแยกจากแอปพลิเคชัน ตั้งแต่ Android 6.0 (API 23) Keystore ใช้การสนับสนุนฮาร์ดแวร์ (TEE — Trusted Execution Environment) บนอุปกรณ์ที่มีชิปความปลอดภัย คีย์ใน Keystore ไม่เคยออกจากพื้นที่ปลอดภัย — แอปพลิเคชันได้รับเพียง handle สำหรับการดำเนินการเข้ารหัสและลงนาม

SharedPreferences และ NSUserDefaults ไม่ได้ออกแบบมาสำหรับจัดเก็บข้อมูลที่ละเอียดอ่อน — พวกเขาเก็บข้อมูลในรูปแบบข้อความธรรมดา สำหรับการปกป้องข้อมูล ให้ใช้ EncryptedSharedPreferences (Android) หรือเข้ารหัสข้อมูลก่อนบันทึกลงใน UserDefaults (iOS) ที่ IT Sectr เรามักใช้ Keychain และ Keystore สำหรับโทเค็นการเข้าถึงและรหัสผ่าน

การตรวจสอบสิทธิ์: OAuth 2.0, JWT และไบโอเมตริกซ์

OAuth 2.0 และ OpenID Connect

OAuth 2.0 เป็นโปรโตคอลการอนุญาตแบบมอบหมายที่ให้การเข้าถึงทรัพยากรของผู้ใช้อย่างปลอดภัยโดยไม่ต้องส่งรหัสผ่าน ในแอปพลิเคชันมือถือ ที่ใช้บ่อยที่สุดคือ Authorization Code Flow กับ PKCE (Proof Key for Code Exchange) PKCE ป้องกันการดักจับรหัสการอนุญาต — ข้อกำหนดบังคับสำหรับแอปพลิเคชันมือถือ

OpenID Connect (OIDC) เป็นส่วนขยายเหนือ OAuth 2.0 สำหรับการตรวจสอบสิทธิ์ผู้ใช้ OIDC เพิ่ม ID Token ในรูปแบบ JWT ซึ่งมีข้อมูลผู้ใช้ (ชื่อ, อีเมล, id) ขั้นตอน OAuth 2.0 + OIDC รวมถึง: เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าเข้าสู่ระบบ รับรหัสการอนุญาต แลกเปลี่ยนรหัสเป็นโทเค็น (access + refresh + id) ใช้โทเค็นการเข้าถึงสำหรับคำขอ API

JWT: โทเค็นการเข้าถึง รีเฟรช และเซสชัน

JWT (JSON Web Token) เป็นรูปแบบโทเค็นที่กะทัดรัดและปลอดภัยสำหรับ URL ซึ่งประกอบด้วยการอ้างสิทธิ์ (claims) ในรูปแบบ JSON JWT ประกอบด้วยสามส่วน: ส่วนหัว (ประเภทและอัลกอริธึมลายเซ็น) เพย์โหลด (ข้อมูล) และลายเซ็น โทเค็นการเข้าถึงเป็นโทเค็นอายุสั้น (15-60 นาที) สำหรับการเข้าถึง API โทเค็นรีเฟรชเป็นโทเค็นอายุยาว (วัน/สัปดาห์) สำหรับรับโทเค็นการเข้าถึงใหม่โดยไม่ต้องเข้าสู่ระบบอีกครั้ง

โทเค็นเซสชัน เป็นแนวทางดั้งเดิมที่เซิร์ฟเวอร์เก็บเซสชันในฐานข้อมูลหรือ Redis และไคลเอ็นต์ได้รับตัวระบุแบบสุ่ม ในการพัฒนามือถือ JWT เป็นที่นิยมมากกว่า: ไม่จำเป็นต้องจัดเก็บเซสชันฝั่งเซิร์ฟเวอร์ มีข้อมูลทั้งหมดภายในตัวเอง และตรวจสอบได้ง่าย อย่างไรก็ตาม JWT ไม่สามารถเพิกถอนได้ทันที — นี่คือการประนีประนอมที่แก้ไขได้ด้วยอายุการใช้งานสั้นของโทเค็นการเข้าถึงและการใช้โทเค็นรีเฟรช

การตรวจสอบสิทธิ์แบบไบโอเมตริกซ์

Face ID และ Touch ID บน iOS, การตรวจสอบลายนิ้วมือบน Android — วิธีการตรวจสอบสิทธิ์แบบไบโอเมตริกซ์ที่ใช้ลักษณะทางกายภาพที่ไม่ซ้ำกันของผู้ใช้ บน iOS ไบโอเมตริกซ์ทำงานผ่าน LocalAuthentication (LAContext) บน Android — ผ่าน BiometricPrompt (Android 9+) หรือ FingerprintManager (เลิกใช้แล้ว) ไบโอเมตริกซ์ใช้สำหรับปลดล็อกแอป ยืนยันการชำระเงิน และเข้าถึงข้อมูลที่ได้รับการป้องกัน

ความแตกต่างที่สำคัญ: ไบโอเมตริกซ์เป็น UX ที่สะดวก แต่ไม่ใช่การแทนที่การตรวจสอบสิทธิ์ของเซิร์ฟเวอร์ หลังจากการตรวจสอบไบโอเมตริกซ์สำเร็จ แอปพลิเคชันควรรับโทเค็นการเข้าถึงจากเซิร์ฟเวอร์ บน Android ตรวจสอบให้แน่ใจว่าอุปกรณ์ใช้ไบโอเมตริกซ์ Class 3 (แข็งแกร่ง) ไม่ใช่เพียงการจดจำใบหน้าด้วยกล้อง (Class 1)

การป้องกันโค้ด: ProGuard, R8 และ Root Detection

การทำให้โค้ดสับสน: ProGuard และ R8

ProGuard เป็นเครื่องมือสำหรับทำให้โค้ดสับสน บีบอัด และเพิ่มประสิทธิภาพไบต์โค้ด Java สำหรับ Android ซึ่งเพิ่มความปลอดภัยของโค้ดต่อการวิศวกรรมย้อนกลับ R8 เป็นผู้สืบทอด รวมอยู่ใน Gradle ตั้งแต่ Android Studio 3.4 R8 ดำเนินการสี่อย่าง: การบีบอัด (ลบคลาสและเมธอดที่ไม่ได้ใช้) การเพิ่มประสิทธิภาพ (inline เมธอด ทำให้โค้ดง่ายขึ้น) การทำให้โค้ดสับสน (เปลี่ยนชื่อคลาสและเมธอดเป็นชื่อสั้น) และการตรวจสอบล่วงหน้า (ตรวจสอบไบต์โค้ด)

DexGuard เป็นเวอร์ชันเชิงพาณิชย์ของ ProGuard ที่มีการป้องกันเพิ่มเติม: การเข้ารหัสสตริง การทำให้ทรัพยากรสับสน การป้องกันการบรรจุใหม่ การควบคุมความสมบูรณ์ของ APK สำหรับโครงการส่วนใหญ่ R8 ก็เพียงพอแล้ว แต่สำหรับแอปพลิเคชันทางการเงินและธนาคาร DexGuard ให้การรักษาความปลอดภัยอีกชั้น R8 เปิดใช้งานผ่าน build.gradle: minifyEnabled = true และ proguardFiles

การตรวจจับ Root และ Jailbreak

Root Detection (Android) และ Jailbreak Detection (iOS) เป็นกลไกที่ตรวจสอบว่ามีการได้รับสิทธิ์ผู้ใช้ระดับสูงบนอุปกรณ์หรือไม่ บนอุปกรณ์ที่ถูกบุกรุก สามารถอ่านหน่วยความจำกระบวนการ ดักจับการรับส่งข้อมูล และเปลี่ยนโค้ดได้ สำหรับการตรวจสอบบน Android ใช้การมีอยู่ของไฟล์ไบนารี SU คีย์ลายเซ็นทดสอบ และแฟล็ก build ที่ไม่ได้มาตรฐาน

RASP (Runtime Application Self-Protection) เป็นเทคโนโลยีที่ปกป้องแอปพลิเคชันระหว่างการทำงาน RASP ตรวจจับความพยายามในการดีบัก การบรรจุใหม่ การฉีดโค้ด และยุติแอปพลิเคชันเมื่อตรวจพบภัยคุกคาม ตัวอย่างโซลูชัน RASP: Dexter, Guardsquare, Promon RASP ทำงานขณะรันไทม์และตอบสนองต่อความผิดปกติ — ต่างจากการทำให้โค้ดสับสนแบบคงที่ซึ่งป้องกันโค้ดก่อนการทำงาน

วิศวกรรมย้อนกลับ เป็นกระบวนการกู้คืนซอร์สโค้ดจากแอปพลิเคชันที่คอมไพล์แล้ว เครื่องมือ: JADX (ดีคอมไพเลอร์ APK), Ghidra, IDA Pro, Hopper การป้องกันวิศวกรรมย้อนกลับคือการรวมกันของการทำให้โค้ดสับสน การเข้ารหัสสตริง การตรวจสอบความสมบูรณ์ และ Root Detection ไม่มีการป้องกันที่สมบูรณ์ — เป้าหมายคือทำให้วิศวกรรมย้อนกลับมีต้นทุนสูงพอสำหรับผู้โจมตี