บทที่ 16 · Part 3 — API & Mobile Security
Mobile Security Foundations
Mobile threat model, Keystore/Keychain, biometric, local data, deep links, WebView, backup/log/clipboard และ third-party SDK ตาม MASVS
mobile application ทำงานบนอุปกรณ์ที่เจ้าของควบคุม binary ถูกคัดลอก, runtime ถูก instrument, traffic ถูกสังเกต และ local storage ถูกดึงออกได้ในบางสภาวะ การซ่อน endpoint หรือฝัง API key ใน application จึงไม่สร้าง trust boundary ที่ backend เชื่อได้
Learning Outcomes
- สร้าง mobile threat model ที่แยก app, device, platform, network และ backend ได้
- ใช้ Android Keystore/iOS Keychain และ biometric เป็น key activation อย่างเหมาะสมได้
- ลดข้อมูลรั่วผ่าน storage, backup, log, clipboard, screenshot และ notification ได้
- validate deep/universal link และจำกัด WebView bridge/navigation ได้
- ประเมิน third-party SDK และรักษา server-side authorization boundary ได้
Mobile Client เป็น Untrusted Environment
สิ่งที่ attacker อาจทำได้:
- decompile/inspect binary และ bundled resources
- เปลี่ยน control flow หรือ hook function ตอน runtime
- เรียก backend API โดยไม่ผ่าน UI
- อ่าน local file/backup/log บนอุปกรณ์หรือ environment ที่ควบคุม
- ปลอม deep link/intent และ inter-app message
- แทรก proxy/certificate บน device ที่ควบคุม
- automate หลาย device/emulator
ดังนั้น mobile app ไม่ควรเป็น authority ของ price, role, transaction status, limit หรือ ownership และ secret ที่เหมือนกันทุก installation ถือว่าถูกแจกให้ attacker
วาด Mobile Trust Boundaries
boundary สำคัญคือ:
- app process กับ OS-backed secure storage
- app กับ other apps/deep links
- first-party code กับ third-party SDK
- device/network กับ backend
- local display/biometric กับ server transaction authorization
ใช้ MASVS เป็น Control Vocabulary
OWASP Mobile Application Security Verification Standard แบ่ง control ปัจจุบันเป็น:
- STORAGE — data at rest และ leakage
- CRYPTO — cryptographic functionality
- AUTH — authentication/authorization/session
- NETWORK — secure communication
- PLATFORM — platform interaction
- CODE — code quality/update/dependencies
- RESILIENCE — tampering/reverse-engineering resistance
- PRIVACY — transparency/minimization/control
MASVS ครอบคลุม mobile client ส่วน backend/API ต้องใช้ ASVS/API security เพิ่ม
Data Inventory บนอุปกรณ์
| Data | คำถาม |
|---|---|
| Access/refresh token | ต้อง persist หรือไม่, bound/revocable อย่างไร |
| Local cryptographic key | hardware-backed/non-exportable หรือไม่ |
| Account/statement cache | offline requirement, expiry, clear-on-logout |
| KYC/document/image | จำเป็นต้องอยู่ local หรือไม่ และ backup ได้ไหม |
| Analytics/crash data | SDK ส่ง field/identifier ใดไปที่ไหน |
| Notification content | lock screen เปิดเผยอะไร |
data minimization มีผลมากกว่าการเข้ารหัสทุกไฟล์ หากไม่จำเป็นต้องเก็บก็ไม่มี ciphertext/key lifecycle ให้ดูแล
Keystore และ Keychain
platform secure storage ช่วยจำกัด key/credential เมื่อใช้ API/policy ถูก:
- Android Keystore สามารถสร้าง key ที่ operation เกิดใน secure hardware ตาม capability
- iOS Keychain/Secure Enclave มี accessibility/access-control options
- key อาจกำหนดให้ต้อง user presence/biometric/device unlock
- hardware-backed ไม่ได้แปลว่า application/runtime ไม่มีทางสั่งใช้ key
- backup/migration/sync behavior ต้องเลือกตาม assurance และ recovery
เก็บ key/token reference ด้วย platform API ไม่สร้าง home-grown encrypted preferences ที่ key ฝังใน app
Secure Storage ไม่แก้ Compromised Session
ถ้า malicious code รันใน app context และระบบอนุญาตใช้ key โดยไม่มี fresh user verification attacker อาจขอ cryptographic operation ได้แม้ extract key material ไม่ได้
Biometric ต้องผูกกับ Cryptographic Operation
biometric success callback ใน UI ไม่ควรถูกส่งไป backend เป็น proof โดยลำพัง แนวทางที่แข็งแรงกว่า:
- key ถูกสร้าง/เก็บใน platform keystore
- key usage policy ต้อง user authentication ตาม threat model
- biometric/PIN activate key operation ผ่าน platform API
- backend verify cryptographic proof/challenge และ current transaction context
biometric เป็น activation factor ของ authenticator; template ควรอยู่ใน platform boundary และมี fallback/ re-enrollment/revocation behavior ที่ชัด
Local Storage, Cache และ Database
- เก็บเฉพาะข้อมูลที่ feature ต้องใช้ พร้อม expiry
- ใช้ platform file protection/encryption และ key separation ตาม data class
- clear account-scoped data เมื่อ logout/account switch
- cache key ต้องมี subject/tenant และไม่แชร์ผิด account
- ป้องกัน backup/sync ของไฟล์ละเอียดตาม platform configuration
- migration/error path ห้าม dump plaintext
- screenshot/test fixture ไม่ใช้ production data
database encryption ไม่ช่วยเมื่อ application ที่ authenticated อ่าน record ได้ จึงต้องมี access control, minimization และ runtime display protection ร่วมกัน
Leakage Surfaces ที่มักถูกลืม
Logging and Crash Reports
ห้าม log token, OTP, PIN, account/document details หรือ raw API payload Crash/analytics SDK อาจส่ง breadcrumb, screen title, URL และ custom field ออกนอก boundary ต้อง redact/configure/contract review
Clipboard
clipboard อาจถูก app อื่นอ่านหรือ sync ข้าม device ลดการ copy sensitive value, clear/expire เมื่อ platform รองรับ และอย่าใช้ clipboard ส่ง secret ระหว่าง component
Screenshots and App Switcher
หน้าที่มี secret/PII อาจต้องใช้ platform screen-capture protection หรือ privacy overlay ใน app switcher แต่ control เหล่านี้ไม่สมบูรณ์และมี accessibility/support trade-off
Notifications
lock screen อาจแสดงข้อความ จึงใช้ข้อความทั่วไปและให้เปิด app ที่ re-check session/authorization อย่าใส่ OTP พร้อม context ที่ทำให้ phishing ง่าย, account number เต็ม หรือ sensitive transaction detail
Deep Links และ Universal/App Links
deep link เป็น untrusted input ต้อง:
- exact validate scheme, host, path และ parameter
- ใช้ verified HTTPS universal/app links เมื่อเหมาะสม
- ผูก OAuth response กับ state/PKCE/nonce transaction
- custom scheme ถือว่า app อื่นอาจ claim ได้
- ไม่ทำ sensitive action ทันทีเพียงเปิด link
- re-check authentication, authorization และ current state
- ป้องกัน open redirect/path traversal และ log leakage
link ควรนำไปหน้า confirmation ที่โหลด authoritative data จาก backend ไม่เชื่อ amount/beneficiary จาก URL
WebView เป็น Browser ที่มี Bridge เพิ่ม
ความเสี่ยง:
- navigation ไป untrusted origin แต่ยังมี native bridge
- JavaScript interface expose privileged method
- file/content URL access กว้าง
- mixed content/TLS error ถูก bypass
- cookie/session แชร์กับ origin ไม่ตั้งใจ
- OAuth login ใน embedded WebView ถูกดัก credential
แนวทาง:
- ใช้ native UI หรือ system browser/custom tab เมื่อทำได้
- allowlist origin/navigation แบบ exact
- expose bridge ให้น้อยและ validate message schema/origin
- ปิด file/debug/mixed-content capability ที่ไม่ใช้
- ไม่ bypass TLS errors
- native OAuth ใช้ external user-agent ตาม RFC 8252
Network Communication
ทุก API call ใช้ TLS และตรวจ service identity ไม่ใช่เพียง “เปิด encryption”:
- ไม่มี trust-all/hostname bypass
- timeout, response size และ redirect policy
- credential ไม่ follow redirect ข้าม host
- token audience/scope จำกัด
- ไม่ส่ง sensitive field ใน URL/query โดยไม่มีเหตุผล
- handle captive portal/proxy/TLS failure แบบไม่ downgrade
certificate pinning และ app attestation เป็น advanced defense-in-depth พร้อม availability/rotation/bypass trade-off ซึ่งจะลงรายละเอียดในบทถัดไป
Third-Party SDK
SDK โฆษณา, analytics, crash, chat และ biometric/KYC อาจเข้าถึง process/network/data:
| Review Area | คำถาม |
|---|---|
| Data | เก็บ field/identifier อะไร ส่ง destination ใด |
| Permission | ขอ camera/contact/location/clipboard เกิน feature หรือไม่ |
| Code | native code, WebView, dynamic loading, dependency/update |
| Network | endpoint, TLS, certificate, redirect และ offline queue |
| Lifecycle | version/support/CVE/kill switch/removal |
| Governance | purpose, retention, user choice และ contract owner |
dependency scan อย่างเดียวไม่เห็น runtime collection ต้องทดสอบ network/storage และ review privacy behavior
Backend ต้องเป็น Authority
backend ต้องไม่เชื่อ:
is_rooted=false,biometric_passed=trueหรือ app version จาก client เป็นหลักฐานเด็ดขาด- hidden button/obfuscated endpoint เป็น authorization
- local balance/limit/fee เป็น authoritative
- device ID เป็น user identity
- attestation result เป็น proof ว่า transaction สุจริต
server ใช้ signal เหล่านี้ประกอบ risk decision แต่ตรวจ token, object authorization, transaction state, limit และ ledger invariant เองเสมอ
Testing Checklist
- mobile threat model รวม device/OS/other apps/SDK/network/backend/store
- ไม่มี shared secret/authorization truth ฝังใน binary
- data inventory ครอบคลุม token/cache/KYC/log/backup/notification
- key/credential ใช้ Keystore/Keychain policy ตาม assurance/recovery
- biometric activate cryptographic operation ไม่เชื่อ callback อย่างเดียว
- logout/account switch clear data/cache ที่เกี่ยวข้อง
- deep link exact validate และ sensitive action re-check backend state
- WebView จำกัด origin/navigation/bridge และไม่ใช้ native OAuth login
- third-party SDK มี data/permission/network/lifecycle owner
- backend เป็น authority ของ identity, authorization, amount, state และ ledger
สรุป
Mobile app เป็น client ที่ทำงานใน environment ซึ่งถูก inspect และเปลี่ยนได้ Platform secure storage, biometric, link validation และ leakage control ลดความเสี่ยง แต่ trust anchor ของเงิน/สิทธิ์ยังต้องอยู่ ที่ backend พร้อม server-side authorization และ transaction invariant