Mobile Hardening & Testing

mobile application ที่ผ่าน automated scan อาจยังเก็บ refresh token ใน backup หรือยอมรับ deep link ที่ปลอม transaction context ได้ ขณะเดียวกัน root detection ที่ถูก bypass ไม่ได้แปลว่า assessment ล้มเหลว เพราะ control นี้ควรถูกใช้เป็น signal/defense-in-depth ตั้งแต่ต้น

ใช้ OWASP Mobile Artifacts ให้ถูกหน้าที่#

ตั้งแต่ MASVS 2.0 ไม่มี normative verification levels L1/L2/R แบบเดิมใน MASVS แล้ว เอกสารหรือ vendor report ที่ยังใช้ชื่อดังกล่าวต้องระบุว่าอ้างรุ่น/แนวคิดเก่า ไม่ควรถูกนำมาเทียบ กับ MASVS/MASTG ปัจจุบันโดยตรง

Assessment เริ่มจาก Scope และ Architecture#

assessment ที่มีคุณภาพควรมี:

• app/version/build digest และ platform versions
• architecture/data flow/threat model
• source + build configuration เมื่อทำ open-book assessment
• test accounts/roles/states และ backend environment ที่ได้รับอนุญาต
• MASVS requirements/MASTG tests ที่เลือกพร้อมเหตุผล
• out-of-scope, constraints และ residual uncertainty
• evidence ที่ reproducible โดยไม่เก็บข้อมูลจริงเกินจำเป็น

black-box test อย่างเดียวอาจไม่เห็น key configuration, backup rule, code path และ build flag Open-book assessment มักให้ assurance สูงกว่าเพราะใช้ source/design ร่วมกับ runtime verification

Static Analysis#

ตรวจ artifact/source/config โดยไม่รัน app:

• hardcoded secret, endpoint และ debug flag
• manifest/entitlement/permission/exported component
• backup/data protection configuration
• insecure API/crypto/storage usage
• WebView bridge/navigation policy
• dependency/native library/version
• signing/debug symbol/build variant
• privacy declaration และ SDK inventory

decompiler output ไม่เท่ากับ source เดิม และ automated finding ต้องยืนยัน reachability/context

Dynamic Analysis#

รัน app ใน test environment แล้วสังเกต:

• files/database/preferences/keychain behavior
• network/TLS/redirect/payload
• log, clipboard, screenshot, notification, backup
• deep links, intents, URL schemes, app links
• WebView navigation/bridge
• authentication/session/recovery/account switch
• offline/error/update state
• behavior เมื่อ device assurance เปลี่ยน

ทดสอบ negative path และ state transition ไม่ใช่เปิดทุกหน้า 1 ครั้ง

Runtime Instrumentation และ Reverse Engineering#

ภายใต้ระบบที่ได้รับอนุญาต เทคนิคเหล่านี้ใช้ยืนยันว่า control อยู่ตรงไหนและ bypass แล้ว impact เท่าไร:

• inspect/hook method และ cryptographic call
• เปลี่ยน return value ของ local checks
• trace data ก่อน/หลัง encryption
• inspect native/managed code และ embedded resource
• repack/sign test build ใน isolated environment
• automate API โดยไม่ผ่าน UI

ผลที่สำคัญไม่ใช่ “พบว่า app ถูก reverse ได้” เพราะ client อยู่ใน attacker-controlled environment แต่คือ bypass local control แล้ว backend ยอมรับ action ที่ไม่ควรหรือข้อมูลใดรั่ว

Obfuscation และ Anti-Tamper#

obfuscation ลด readability และเพิ่มต้นทุน reverse engineering แต่ไม่เปลี่ยน secret ใน app ให้ปลอดภัย

ประเมิน:

• symbol/string/control-flow protection ตาม risk
• reflection/serialization/native compatibility
• mapping file custody สำหรับ crash/debug
• build reproducibility และ supply-chain integration
• performance/accessibility/support impact
• bypass cost เทียบกับ asset lifetime

anti-debug, integrity check และ hook detection ถูก patch/hook ได้ จึงใช้ delay/detect/telemetry ไม่ใช่ authorization gate ชั้นเดียว

Root และ Jailbreak Detection#

signal อาจมาจาก file/process/package, writable path, sandbox anomaly, API behavior และ attestation แต่ทุก signal มี false positive/negative และ bypass ได้

แนวใช้:

• รวมหลาย signal พร้อม confidence/reason
• ตัดสินที่ backend ตาม action/risk
• degraded mode แยก read-only/low-risk/high-risk ตาม policy
• ไม่เปิดรายละเอียด detection ทั้งหมดใน error
• monitor bypass/false-positive และมี support/appeal path
• ห้ามใช้ผล not rooted เป็น proof ว่า device ปลอดภัย

policy ที่ block ทั้ง app อาจกระทบ accessibility/incident access จึงต้องมี human-owned decision

App Attestation#

attestation ให้ statement เกี่ยวกับ app/device instance ตาม assurance ของ platform/provider เช่น app identity, signing/install source, device integrity หรือ nonce binding

server-side flow ควร:

1. ออก random challenge ผูก session/action
2. client ขอ attestation จาก platform
3. server verify chain/signature, app identity, challenge, time และ verdict
4. ป้องกัน replay/cache ตาม protocol
5. รวมผลกับ user auth, transaction, behavior และ device history
6. กำหนด allow/step-up/review/deny ด้วย versioned policy

attestation ไม่พิสูจน์ว่าผู้ใช้สุจริต, app ไม่มี runtime compromise หรือ transaction ถูกต้อง

Certificate Pinning เป็น Trade-off#

TLS certificate validation ผ่าน trusted PKI เป็น baseline Pinning เพิ่ม restriction ว่า connection ต้องตรง key/certificate set ที่ app คาด

ประโยชน์:

• ลด MITM บางเส้นทางเมื่อ trust store/user CA ถูกเปลี่ยน
• ตรวจผิดปลายทางบางกรณี

ความเสี่ยง:

• certificate/key rotation ผิดทำให้ app ทุกเครื่อง offline
• app รุ่นเก่าไม่มี pin ใหม่
• emergency CA/key compromise recovery
• proxy/enterprise/accessibility/testing conflict
• bypass บนอุปกรณ์ที่ attacker ควบคุม

ถ้าใช้ ต้องมี backup pins/overlap, version rollout, telemetry, expiry/kill-switch design ที่ไม่สร้าง remote downgrade และซ้อม rotation ก่อน production Pinning ไม่แทน TLS hostname validation

Secure Update และ Downgrade#

update chain ต้องรักษา:

• artifact/signing identity และ store/distribution channel
• version/build monotonic policy ตาม risk
• provenance จาก source/build ถึง package
• dependency/SDK/native library inventory
• rollback ที่ได้รับอนุมัติและไม่พากลับสู่ vulnerable build เงียบ ๆ
• response เมื่อ signing key/release compromise
• minimum supported version แบบ staged พร้อม customer impact

app signature บอกว่า package มาจาก key ใด ไม่พิสูจน์ว่า source/build ปลอด malware และ backend ต้อง enforce minimum protocol/security capability เมื่อ client เก่าไม่ปลอดภัย

Testing Backend Assumptions#

mobile assessment ต้องลองข้าม local UI/control แล้วเรียก API โดยตรง:

• เปลี่ยน amount/beneficiary/role/device verdict
• replay token, deep link, attestation และ transaction proof
• เรียก hidden/deprecated endpoint
• ใช้ session หลัง logout/recovery/device removal
• ข้าม biometric/root/version check
• ส่ง concurrent request และ malformed third-party data

ถ้า backend authorization/invariant ถูกต้อง การ bypass client check อาจเพิ่ม fraud signal แต่ไม่ควร ให้สิทธิ์หรือทำเงินผิด

Automated Tools มีขอบเขต#

automation ช่วย inventory pattern ซ้ำ แต่มี false positive/negative และไม่พิสูจน์ requirement ที่ต้องเข้าใจ state/business flow รายงานควรแยก:

• observation: พบอะไร
• evaluation: ขัด requirement ใดภายใต้ context ใด
• exploitability/impact: bypass แล้วเกิดอะไร
• evidence: artifact/version/steps
• remediation/verification: แก้และ retest อย่างไร

คำว่า “MASVS certified” ต้องมี scheme/scope/version/evidence ชัด ไม่ควรสร้างตรารับรองจาก scanner

Test Matrix#

ทุก finding ต้อง map ทั้ง client control และ backend impact

Review Checklist#

• baseline ระบุ MASVS 2.1.0/MASTG 2.0.0 และไม่ใช้ L1/L2/R แบบปัจจุบัน
• scope ระบุ artifact digest, platform, roles, environment และ evidence policy
• static + dynamic + runtime/reverse tests ครอบคลุม threat model
• obfuscation/root/anti-debug เป็น resilience signal ไม่ใช่ trust anchor
• attestation verify challenge/app/time/replay ฝั่ง server และรวม signal อื่น
• pinning มี backup/overlap/rotation/emergency test
• update verify signing/provenance/version และมี compromise response
• backend tests bypass client UI/check และยังรักษา authorization/invariant
• automation finding ถูก validate ด้วย context/evidence
• report แยก observation, requirement, impact และ residual uncertainty

Further Reading#

• OWASP Mobile Application Security Project
• OWASP MASVS 2.1.0
• OWASP MASTG 2.0.0
• OWASP MAS Testing Profiles