मोबाइल सिक्योरिटी टेस्टिंग

यह क्यों ज़रूरी है

Phone पर company का नियंत्रण नहीं होता। वह खो सकता है, root किया जा सकता है (यानी पूरे system का access खोल दिया जाए) या backup से restore हो सकता है; वह public Wi-Fi से जुड़ता है; और कोई भी app package को खोलकर देख सकता है। App जो कुछ store करता है, भेजता है या दूसरे apps से लेता है, वह सब exposed है, और एक leaked token का मतलब account takeover हो सकता है।

ज़्यादातर first-line checks के लिए hacking skills नहीं चाहिए, और platform के नियम जानना ग़लत bug reports से बचाता है: जो app आपके proxy से बात करने से मना करता है, वह अक्सर बिल्कुल सही काम कर रहा होता है।

MASVS के control groups

MASVS अपने controls को आठ control groups में बाँटता है, जिनके नाम MASVS- prefix से शुरू होते हैं; MASTG बताती है कि Android और iOS पर इन्हें कैसे टेस्ट करें।

यह lesson storage, network और platform groups को टेस्ट करता है, जहाँ tester के आम tools असली defects पकड़ते हैं। आठों groups:

• MASVS-STORAGE: device पर sensitive data सुरक्षित रहता है और leak नहीं होता।
• MASVS-CRYPTO: मज़बूत algorithms, और app में कोई hard-coded key नहीं।
• MASVS-AUTH: login, sessions और authorization को back end लागू करता है; biometrics जैसे local checks सुरक्षित तरीके से होते हैं।
• MASVS-NETWORK: सही certificate validation के साथ TLS, और जहाँ risk माँगे वहाँ pinning।
• MASVS-PLATFORM: links, components, WebViews और screen का सुरक्षित इस्तेमाल।
• MASVS-CODE: untrusted input validate होता है; known vulnerabilities वाले components नहीं।
• MASVS-RESILIENCE: जहाँ risk माँगे, reverse engineering और tampering का विरोध।
• MASVS-PRIVACY: सिर्फ़ ज़रूरी data, जिसे user देख और नियंत्रित कर सके।

Local storage: device पर क्या बचा रहता है

App अपना data अपने sandbox में रखता है: Android पर shared_prefs की preference files, SQLite databases और files; iOS पर UserDefaults, files और databases। Sandbox दूसरे apps को बाहर रखता है, पर rooted phone, backup या debuggable build वाले व्यक्ति को नहीं (debuggable build यानी debug build, जिसमें run-as जैसे tools app की files तक पहुँच सकते हैं; release builds debuggable नहीं होते)। Data logs, clipboard और app-switcher screenshot में भी leak होता है।

MASVS-STORAGE को टेस्ट करना आसान है: sensitive data सिर्फ़ ज़रूरत पर store होता है, secrets iOS Keychain में रखे जाते हैं या Android Keystore में रखी key से encrypt होते हैं (ये दोनों platforms के protected stores हैं), logs में कुछ भी sensitive नहीं होता, और logout session का data हटा देता है। Encoding, encryption नहीं है: file में रखी Base64 string या signed JWT को file पाने वाला कोई भी पढ़ सकता है। Android QA build पर खुद देखें:

# Debuggable QA build, on a test phone or emulator you may use
adb shell run-as com.example.shop ls shared_prefs databases files
adb shell run-as com.example.shop cat shared_prefs/session.xml
#   <string name="refresh_token">eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOi...</string>
#   ^ a finding: a token in plain text

adb logcat -d | grep -i -E "password|token|bearer|otp"

# Release build: run-as must fail, because the build is not debuggable
adb shell run-as com.example.shop ls

आज़माएँ: Base64 डिकोडर आज़माएँ: JWT डिकोडर आज़माएँ: JWT एक्सपायरेशन चेकर

Worked example: Android app का HTTPS traffic पढ़ना

आपके पास अपनी team के shopping app को api.staging.shop.example के साथ टेस्ट करने की written permission है। Intercepting proxy एक tool है जो app और server के बीच बैठता है और हर request और response दिखाता है; intercepting proxies वाला lesson इसका set-up विस्तार से दिखाता है। उसका scope उन hosts का समूह है जिन्हें टेस्ट करने की आपको अनुमति है, इसलिए आप scope में सिर्फ़ यही host रखते हैं। उसका history हर captured request की सूची रखता है, ताकि आप बाद में कोई request ढूँढ सकें, उसे evidence के रूप में लगा सकें या replay कर सकें (यानी server को दोबारा भेज सकें)। Proxy आपके laptop पर चलता है और laptop के Wi-Fi address पर listen करता है, जैसे 192.168.1.20:8080। HTTPS पढ़ने के लिए proxy app का TLS connection खुद ख़त्म करता है और host के नाम का ऐसा certificate पेश करता है जिस पर उसकी अपनी certificate authority (CA) का signature होता है। इसलिए एक dedicated test phone पर आप यही address Wi-Fi proxy के रूप में डालते हैं और proxy का CA certificate user certificate के रूप में install करते हैं।

अब app connect नहीं कर पाता और proxy TLS handshake errors दर्ज करता है। यह Android का designed व्यवहार है: Android 7.0 (API level 24) से, जो apps इस level या ऊपर को target करते हैं, वे default रूप से सिर्फ़ system CAs पर भरोसा करते हैं, user के जोड़े CAs पर नहीं। सुरक्षित opt-in, जो नीचे दिखाया गया है, network security configuration में debug-overrides block है: यह सिर्फ़ debuggable build पर लागू होता है, इसलिए QA build आपके proxy CA पर भरोसा करता है और release build default पर रहता है। Traffic पढ़ने लायक होने पर जाँचें:

• हर request HTTPS इस्तेमाल करती है, images और SDKs समेत। Android 9 (API level 28) या ऊपर को target करने वाले apps default रूप से plain HTTP block करते हैं, इसलिए काम करती http:// call का आम तौर पर मतलब है कि किसी ने उस host के लिए cleartext allow किया है: इसे report करें।
• Tokens Authorization header में जाते हैं, URL में कभी नहीं, जहाँ servers उन्हें log कर लेते हैं।
• Logout के बाद पुराने token से request replay करने पर 401 Unauthorized मिलता है।

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <debug-overrides>          <!-- applies only when the app is debuggable -->
    <trust-anchors>
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

<!-- AndroidManifest.xml -->
<application android:networkSecurityConfig="@xml/network_security_config" ...>

आज़माएँ: HTTP हेडर पार्सर आज़माएँ: API ऑथेंटिकेशन टेस्टर

Certificate pinning अपेक्षित व्यवहार है

Certificate pinning, जिसे MASVS identity pinning कहता है, का मतलब है कि app अपने API hosts के लिए सिर्फ़ एक जाना-पहचाना certificate, public key या CA स्वीकार करता है। यह users को phone पर मौजूद malicious या अनचाहे CA से बचाता है, और आपके proxy को भी रोकता है: handshake fail होता है। Release build पर यह pass है, इसलिए "App मेरे proxy से नहीं चलता" एक ग़लत report है।

Pinning करनी है या नहीं, यह risk का फ़ैसला है जिसे team दर्ज करती है। जब app pinning करता है, तो bypass नहीं, व्यवहार टेस्ट करें:

• Proxy के ज़रिए pinned build साफ़ error के साथ connection refuse करता है, न crash होता है न plain HTTP पर retry करता है; proxy के बिना वह चलता है।
• Android release build user CA को वैसे भी reject करता है, इसलिए सिर्फ़ यह failure pinning साबित नहीं करता; ऐसा test build माँगें जो user CAs पर भरोसा करे पर pins रखे।
• Functional checks का traffic QA build से आता है: default रूप से Android, network security configuration की pins को debug-overrides के CAs पर लागू नहीं करता। App के code में लिखी pinning के लिए अलग debug switch चाहिए; उसे developers के साथ तय करें। Release build में pinning bypass करना specialist का काम है।
• पूछें कि pins कैसे rotate होते हैं: Android documentation हमेशा एक backup key रखने की सलाह देता है, वरना server पर key बदलते ही हर installed copy का connection तब तक कटा रहता है जब तक app update न आ जाए।

Platform interaction: links, components, WebViews और screen

MASVS-PLATFORM उस सब को cover करता है जिसका app operating system और दूसरे apps से लेन-देन करता है। हर उस entry point को, जिस तक कोई दूसरा app या web page पहुँच सकता है, untrusted input मानें; नीचे के commands deep link को वैसे खोलते हैं जैसे कोई दूसरा app खोलता।

• Deep links: कोई भी app shop://orders/1043 को किसी भी value के साथ खोल सकता है। Protected screen पहले login माँगती है, और फिर भी server दूसरे user का order refuse करता है। Android App Links और iOS Universal Links app के domain से verify होते हैं; shop:// जैसी custom scheme नहीं, और कोई दूसरा app वही scheme register करके link पा सकता है, इसलिए उसमें token जैसा कोई secret कभी नहीं जाना चाहिए।
• Exported components: Android की activities, services, receivers और content providers तभी exported होते हैं जब दूसरे apps को उनकी ज़रूरत हो, और तब वे जो मिलता है उसे जाँचते हैं।
• WebViews सिर्फ़ app के अपने या allow-listed pages load करते हैं, link parameter से लिया गया URL कभी नहीं।
• Screen: sensitive screens app-switcher preview में छिपी रहती हैं, और password fields masked रहते हैं।

# Android test device: open a deep link the way another app would
adb shell am start -W -a android.intent.action.VIEW \
  -d "shop://orders/1043" com.example.shop

# iOS simulator
xcrun simctl openurl booted "shop://orders/1043"

अक्सर पूछे जाने वाले सवाल

संदर्भ

• OWASP Mobile Application Security Verification Standard (MASVS)OWASP Foundationमोबाइल ऐप के लिए OWASP की सुरक्षा आवश्यकताएँ, storage, cryptography, authentication, network और platform interaction जैसे नियंत्रण समूहों में।
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationMASVS के साथ चलने वाला टेस्टिंग मैनुअल: मोबाइल ऐप सुरक्षा जाँचने की तकनीकें और टेस्ट केस।
• About App LinksAndroid Developers (Google)Android App Links: आपकी अपनी वेबसाइट के deep links जिन्हें सिस्टम Digital Asset Links फ़ाइल (assetlinks.json) से verify करता है, ताकि वे सीधे ऐप में खुलें।
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019मोबाइल टेस्टिंग पर ISTQB का specialist पाठ्यक्रम: ऐप के प्रकार, डिवाइस व प्लेटफ़ॉर्म की चुनौतियाँ, टेस्ट प्रकार और टूल।