Seguridad sa Mobile Development: ano ito, anong mga banta ang umiiral at kung paano ipagtanggol

Mga Pangunahing Banta: OWASP Mobile Top 10

Ano ang OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) ay isang non-profit na organisasyon na naglalathala ng ranggo ng mga pinakamapanganib na kahinaan sa mobile security. Ang OWASP Mobile Top 10 ay isang listahan na tumutulong sa mga developer na maunawaan kung ano ang dapat unahing pagtuunan. Sa bersyon 2024, ang mga problemang may kaugnayan sa hindi secure na pag-iimbak, mahinang authentication at hindi secure na komunikasyon sa network ang nangunguna sa ranggo.

M1: Hindi Secure na Pag-iimbak ng Data — ang pinakakaraniwang problema: ang mga password, token at personal na data ay nananatili sa SharedPreferences, NSUserDefaults o mga lokal na file nang walang encryption. M2: Mahinang Authentication — kakulangan ng pag-verify sa panig ng server, mahihinang password. M3: Hindi Secure na Komunikasyon sa Network — kakulangan ng HTTPS o maling pag-verify ng SSL certificate. Ang M4 at M5 ay may kaugnayan sa cryptography at maling paggamit ng API.

M6: Hindi Secure na Awtorisasyon — maaaring ma-access ng isang user ang data ng ibang user sa pamamagitan ng pagpapalit ng ID sa isang kahilingan. M7: Pag-iniksyon ng Code (SQL Injection, XSS). M8: Pagmamanipula ng App — repackaging, pagpapalit ng code. M9 at M10 — pagtagas ng data sa pamamagitan ng mga third-party library at reverse engineering. Para sa bawat isa sa mga bantang ito, may mga napatunayang kontra-mekanismo, at sa IT Sectr, inilalapat namin ang mga ito sa lahat ng proyekto mula noong 2017.

Mga Pag-atake ng Man-in-the-Middle (MITM)

Ang MITM attack ay nangyayari kapag ang isang umaatake ay humarang sa trapiko sa pagitan ng application at server. Ito ay posible sa pamamagitan ng DNS spoofing, ARP spoofing o pagkonekta sa isang hindi secure na Wi-Fi network. Ginagamit ang mga SSL/TLS certificate at Certificate Pinning para sa proteksyon.

Ang Certificate Pinning ay isang mekanismo kung saan ini-verify ng application na ang certificate ng server ay tumutugma sa isang paunang naka-imbak sa code ng application. Kahit na palitan ng umaatake ang certificate sa pamamagitan ng proxy (hal. Burp Suite), tatanggihan ng application ang koneksyon. Ang Pinning ay may dalawang uri: Public Key Pinning at Certificate Hash Pinning.

Encryption at Hashing: AES, RSA, SSL/TLS

Simetriko Encryption: AES

AES (Advanced Encryption Standard) ay isang simetriko encryption algorithm, ang pundasyon ng seguridad ng data sa device. Gumagamit ang AES ng parehong susi para sa pag-encrypt at pag-decrypt ng data. Sinusuportahan ng AES ang mga susi na 128, 192 o 256 bits. Sa mobile development, ang AES-256 ay ginagamit para sa pag-encrypt ng data sa device: mga file, cache, mga tala sa lokal na database.

Mga Mode ng AES: GCM (inirerekomenda) — nagbibigay ng authentication ng data, CBC — pangunahing mode na may chain ng block, ECB — hindi secure, huwag gamitin. Para sa iOS, ang AES ay magagamit sa pamamagitan ng CommonCrypto (CCOptions), para sa Android — sa pamamagitan ng Cipher sa Java Cryptography Architecture (JCA). Mahalaga: ang encryption key ay hindi dapat kailanman i-imbak sa code ng application — gamitin ang Keychain/Keystore.

Asimetriko Encryption: RSA — gumagamit ng pares ng mga susi (pampubliko at pribado). Ang RSA ay ginagamit para sa pag-encrypt ng maliit na halaga ng data — karaniwang para sa pagpapalitan ng simetriko key sa pagitan ng client at server. Ang minimum na haba ng RSA key ay 2048 bits (4096 inirerekomenda). Sa iOS, ang RSA ay magagamit sa pamamagitan ng Security Framework (SecKeyCreateRandomKey), sa Android — sa pamamagitan ng KeyPairGenerator sa Android Keystore.

Hashing at SSL/TLS

Hashing (SHA-256, SHA-3) ay isang hindi maibabalik na pagbabago ng data sa isang string na may nakapirming haba. Ang mga hash ay ginagamit para sa pag-verify ng integridad ng data at pag-iimbak ng password. Para sa mga password, tiyaking gumamit ng bcrypt, scrypt o Argon2 — ang plain SHA-256 ay mahina laban sa mga rainbow table attack. SSL/TLS ay isang protocol para sa pag-encrypt ng trapiko sa network sa pagitan ng client at server. Ang modernong pamantayan ay TLS 1.3, na nagbibigay ng Perfect Forward Secrecy (PFS).

TLS 1.3 ay mas mabilis kaysa sa mga nauna nito: ang handshake ay tumatagal ng isang round trip sa halip na dalawa. Sa Android, ang minimum na bersyon ng TLS ay naka-configure sa pamamagitan ng SSLSocket, sa iOS — sa pamamagitan ng ATS (App Transport Security), na bilang default ay nangangailangan ng TLS 1.2 o mas mataas. Ang ATS ay maaari lamang i-disable para sa mga partikular na domain na may katwiran.

Secure na Pag-iimbak: Keychain at Keystore

iOS: Keychain

Keychain (Keychain) ay isang secure na imbakan sa iOS / macOS para sa mga password, encryption key, certificate at token. Ang data sa Keychain ay naka-encrypt gamit ang isang hardware key na natatangi sa bawat device. Ang pag-access sa Keychain ay kinokontrol sa pamamagitan ng Security Framework (SecItemAdd, SecItemCopyMatching). Ang Keychain ay awtomatikong nagla-lock kapag naka-lock ang device at naka-encrypt gamit ang Secure Enclave.

Android: Keystore

Android Keystore ay isang system storage para sa cryptographic keys, na nakahiwalay sa application. Simula sa Android 6.0 (API 23), ang Keystore ay gumagamit ng hardware support (TEE — Trusted Execution Environment) sa mga device na may security chip. Ang mga susi sa Keystore ay hindi kailanman umaalis sa secure na lugar — ang application ay tumatanggap lamang ng handle para sa encryption at signing operations.

SharedPreferences at NSUserDefaults ay hindi idinisenyo para sa pag-iimbak ng sensitibong data — nag-iimbak sila ng impormasyon sa plain text. Para sa proteksyon ng data, gamitin ang EncryptedSharedPreferences (Android) o i-encrypt ang data bago i-save sa UserDefaults (iOS). Sa IT Sectr, palagi kaming gumagamit ng Keychain at Keystore para sa mga access token at password.

Authentication: OAuth 2.0, JWT at Biometrics

OAuth 2.0 at OpenID Connect

OAuth 2.0 ay isang delegated authorization protocol na nagbibigay ng secure na access sa mga mapagkukunan ng user nang hindi nagpapadala ng password. Sa mga mobile application, ang pinakakaraniwang ginagamit ay ang Authorization Code Flow na may PKCE (Proof Key for Code Exchange). Pinipigilan ng PKCE ang pagharang ng authorization code — isang mandatoryong kinakailangan para sa mga mobile application.

OpenID Connect (OIDC) ay isang extension sa ibabaw ng OAuth 2.0 para sa authentication ng user. Ang OIDC ay nagdaragdag ng ID Token sa format na JWT na naglalaman ng impormasyon ng user (pangalan, email, id). Ang daloy ng OAuth 2.0 + OIDC ay kinabibilangan ng: pag-redirect ng user sa pahina ng pag-login, pagkuha ng authorization code, pagpapalit ng code para sa mga token (access + refresh + id), paggamit ng access token para sa mga kahilingan sa API.

JWT: Access, Refresh at Session Token

JWT (JSON Web Token) ay isang compact na format ng token na ligtas para sa URL na naglalaman ng mga claim sa format na JSON. Ang JWT ay binubuo ng tatlong bahagi: header (uri at algorithm ng lagda), payload (data) at lagda. Ang Access Token ay isang panandaliang token (15–60 minuto) para sa access sa API. Ang Refresh Token ay isang pangmatagalang token (araw/linggo) para makakuha ng bagong access token nang hindi na kailangang mag-login muli.

Session Token ay isang tradisyonal na diskarte kung saan iniimbak ng server ang session sa isang database o Redis, at ang client ay tumatanggap ng random na identifier. Sa mobile development, ang JWT ay mas gusto: hindi ito nangangailangan ng pag-iimbak ng session sa panig ng server, naglalaman ng lahat ng impormasyon sa loob mismo at madaling i-verify. Gayunpaman, ang JWT ay hindi maaaring bawiin agad — ito ay isang kompromiso na nalulutas sa pamamagitan ng maikling buhay ng access token at paggamit ng refresh token.

Biometric Authentication

Face ID at Touch ID sa iOS, Fingerprint Auth sa Android — mga biometric authentication method na gumagamit ng natatanging pisikal na katangian ng user. Sa iOS, gumagana ang biometrics sa pamamagitan ng LocalAuthentication (LAContext), sa Android — sa pamamagitan ng BiometricPrompt (Android 9+) o FingerprintManager (hindi na ginagamit). Ginagamit ang biometrics para sa pag-unlock ng app, pagkumpirma ng mga pagbabayad at pag-access sa protektadong data.

Mahahalagang nuances: ang biometrics ay isang maginhawang UX, ngunit hindi kapalit ng server authentication. Pagkatapos ng matagumpay na biometric verification, ang application ay dapat kumuha ng access token mula sa server. Sa Android, tiyaking suriin na ang device ay gumagamit ng Class 3 (Strong) biometrics, hindi lamang camera-based na pagkilala sa mukha (Class 1).

Proteksyon ng Code: ProGuard, R8 at Root Detection

Obfuscation: ProGuard at R8

ProGuard ay isang tool para sa obfuscation, compression at optimization ng Java bytecode para sa Android, na nagpapataas ng seguridad ng code laban sa reverse engineering. Ang R8 ay ang kahalili nito, na naka-integrate sa Gradle mula noong Android Studio 3.4. Ang R8 ay nagsasagawa ng apat na gawain: compression (tinatanggal ang mga hindi nagamit na klase at pamamaraan), optimization (ini-inline ang mga pamamaraan, pinapasimple ang code), obfuscation (pinapalitan ang pangalan ng mga klase at pamamaraan sa mga maiikling pangalan) at pre-verification (pagsusuri ng bytecode).

DexGuard ay isang komersyal na bersyon ng ProGuard na may pinahusay na proteksyon: encryption ng string, obfuscation ng resource, proteksyon laban sa repackaging, kontrol ng integridad ng APK. Para sa karamihan ng mga proyekto, sapat na ang R8, ngunit para sa mga application sa pananalapi at pagbabangko, ang DexGuard ay nagbibigay ng karagdagang antas ng seguridad. Ang R8 ay pinagana sa pamamagitan ng build.gradle: minifyEnabled = true at proguardFiles.

Root at Jailbreak Detection

Root Detection (Android) at Jailbreak Detection (iOS) ay mga mekanismo na sumusuri kung ang mga pribilehiyo ng superuser ay nakuha sa device. Sa mga nakompromisong device, posibleng basahin ang memorya ng proseso, harangin ang trapiko at palitan ang code. Para sa pagsusuri sa Android, ginagamit ang presensya ng SU binary file, test signature key at hindi karaniwang build flag.

RASP (Runtime Application Self-Protection) ay isang teknolohiya na nagpoprotekta sa application sa panahon ng pagpapatupad. Nakikita ng RASP ang mga pagtatangka sa debugging, repackaging, pag-iniksyon ng code at tinatapos ang application kapag may nakitang mga banta. Mga halimbawa ng RASP solution: Dexter, Guardsquare, Promon. Ang RASP ay gumagana sa runtime at tumutugon sa mga anomalya — hindi tulad ng static obfuscation, na nagpoprotekta sa code bago ang pagpapatupad.

Reverse Engineering ay ang proseso ng pagbawi ng source code mula sa isang compiled application. Mga tool: JADX (APK decompiler), Ghidra, IDA Pro, Hopper. Ang proteksyon laban sa Reverse Engineering ay isang kombinasyon ng obfuscation, string encryption, integrity checking at Root Detection. Walang kumpletong proteksyon — ang layunin ay gawing sapat na mahal ang reverse engineering para sa umaatake.