Fix centered icons

docs/hooks/create_dynamic_tables.py

@@ -396,9 +396,9 @@ def on_page_markdown(markdown, page, **kwargs):
 
         for element in data:
             if element['video'].startswith("http"):
-                element['video'] = f"[:octicons-play-24: Video]({element['video']})"
+                element['video'] = f'<div style="text-align: center;">[:octicons-play-24: Video]({element["video"]})</div>'
             if element['slides'].startswith("http"):
-                element['slides'] = f"[:material-file-presentation-box: Slides]({element['slides']})"
+                element['slides'] = f'<div style="text-align: center;">[:material-file-presentation-box: Slides]({element["slides"]})</div>'
 
         return append_to_page(markdown, list_of_dicts_to_md_table(data))
 

tests-beta/android/MASVS-PLATFORM/MASTG-TEST-0x36.md

@@ -0,0 +1,131 @@
+---
+platform: android
+id: MASTG-TEST-0x36
+weakness: MASWE-xxxx
+type: [static, dynamic, network]
+available_since: 21
+deprecated_since: 29
+mitigations: [MASTG-MITIG-xxxx]
+---
+
+# Testing Enforced Updating (Android)
+
+Many mobile applications enforce updates to ensure users are on the latest
+version, typically for security and feature enhancements. However,
+if the enforcement mechanism is weak, attackers may bypass the update
+requirement and continue using outdated, vulnerable versions of the app.
+
+This test evaluates how an Android app enforces updates and  
+checks whether an attacker can bypass the mechanism through  
+static, dynamic, or network-based attacks.
+
+---
+
+## **1. Static Analysis: Reverse Engineering Update Mechanism**
+
+**Goal:** Identify how the app determines whether an update is required.
+
+1. **Decompile the APK** using JADX or Apktool:
+
+   ```bash
+   apktool d app.apk -o decompiled_app
+   jadx -d decompiled_app app.apk
+2. Search for update-related logic in the decompiled code:
+
+    ```bash
+    grep -Ri "update" decompiled_app
+3. Identify how the app determines whether an update is required. Look for:
+
+    - Hardcoded version checks (BuildConfig.VERSION_CODE)
+    - API calls to check for updates
+    - Update prompts in MainActivity.java
+
+## **2. Dynamic Analysis: Hooking Update Logic with Frida**
+
+**Goal:** Determine if the update check can be bypassed.
+
+1. Attach Frida to the Running App:
+
+    ```bash
+    frida -U -n com.example.app -e "console.log('Frida attached!')"
+2. Hook & Modify Update Functions:
+
+    ```javascript
+    Java.perform(function() {
+        var UpdateChecker = Java.use("com.example.app.UpdateManager");
+        UpdateChecker.isUpdateRequired.implementation = function() {
+            console.log("Bypassing update check...");
+            return false;
+        };
+    });
+3. Check If the App Still Requires an Update
+
+    - If the app allows continued usage without updating,
+      the update mechanism is weak and bypassable.
+    - If the app still forces the update, the check may be server-side,
+      which is more secure.
+
+## **3. Network Analysis: Modifying Update Responses**
+
+**Goal:** Determine if app relies on insecure network responses for updates.
+
+1. Intercept Update Requests Using Burp Suite or mitmproxy
+    Set up Burp Suite or mitmproxy to capture app traffic.
+
+    ```bash
+    mitmproxy -p 8080 -m transparent
+
+2. Modify the Update Response
+If the update check is done via an API call (e.g., GET /check_update),  
+intercept and modify the response:
+
+    ```json
+
+    {
+      "latest_version": "2.0.0",
+    "force_update": false
+    }
+
+Change "force_update": false to "force_update": true and  
+observe if the app still allows access.
+
+---
+
+## Obersevation
+
+After executing the test steps, analyze the results:
+
+## Secure Behavior (Pass)
+
+- The app strictly enforces updates and cannot be bypassed through
+  Frida or network attacks.
+- Update checks are performed server-side with cryptographic verification.
+- The app uses certificate pinning to prevent MITM attacks.
+
+## Insecure Behavior (Fail)
+
+- The app allows continued usage even after modifying responses.
+- Frida can disable the update requirement, indicating weak enforcement.
+- Update verification is completely client-side (e.g., hardcoded version checks).
+
+---
+
+## Mitigations
+
+To prevent bypassing enforced updates, implement the following security controls:
+
+- Perform update enforcement on the server side.
+- Digitally sign update responses to prevent tampering.
+- Use certificate pinning to prevent MITM attacks.
+- Store the latest version information in a secure location rather than  
+  hardcoding it in the app.
+- Implement a kill switch for outdated versions that enforces an update  
+  at the backend.
+
+---
+
+## References
+
+[Google Play In-App Updates](https://developer.android.com/guide/playcore/in-app-updates)
+[https://mas.owasp.org/](OWASP Mobile Security Testing Guide)
+[https://developer.android.com/privacy-and-security/security-tips](Securing Update Mechanisms in Mobile Apps)

tests/android/MASVS-CODE/MASTG-TEST-0025.md

@@ -1,13 +1,7 @@
 ---
-masvs_v1_id:
-- MSTG-PLATFORM-2
-masvs_v2_id:
-- MASVS-CODE-4
-platform: android
-title: Testing for Injection Flaws
-masvs_v1_levels:
-- L1
-- L2
+status: deprecated
+covered_by: [MASTG-TEST-0x25]
+deprecation_note: "This test has been replaced by MASTG V2 and is now covered in MASTG-TEST-0x25."
 ---
 
 ## Overview

tests/android/MASVS-CODE/MASTG-TEST-0x25.md

@@ -0,0 +1,175 @@
+---
+masvs_v1_id:
+- MSTG-PLATFORM-2
+masvs_v2_id:
+- MASVS-CODE-4
+platform: android
+title: Testing for Injection Flaws
+masvs_v1_levels:
+- L1
+- L2
+type: [static, dynamic]
+available_since: 21
+deprecated_since: 29
+weakness: 
+- MASWE-9
+- CWE-89
+---
+
+## Overview
+
+Injection flaws occur when an application processes **untrusted input** in a way that allows an attacker to **manipulate queries, execute unintended commands, or inject malicious code**. These vulnerabilities can lead to **data leaks, privilege escalation, or remote code execution**.
+
+In Android applications, injection flaws are often found in:
+
+- **SQL Queries** (SQL Injection)
+- **Command Execution Functions** (Command Injection)
+- **Inter-Process Communication (IPC) Mechanisms** (Intent Injection, ContentProvider exploitation)
+- **Web-based Components** (WebView JavaScript Injection)
+
+This test ensures that **all input sources are properly sanitized and validated** to prevent injection attacks.
+
+### Pre-requisites
+
+- Use **Frida, Burp Suite, or Drozer** for dynamic testing.
+- Test on **Android 10+** to account for security changes (e.g., Scoped Storage).
+- Review the **MASVS-CODE-4** section in the OWASP MASVS documentation.
+- Understand secure coding practices for input validation and query sanitization.
+
+## Static Analysis
+
+### Identifying Injection Vulnerabilities in Code
+
+Injection flaws often occur when **user input is directly concatenated** into SQL queries, system commands, or IPC mechanisms. The following areas should be examined in static analysis:
+
+1. **Database Queries (SQL Injection)**
+2. **Command Execution Functions (Command Injection)**
+3. **Inter-Process Communication (IPC) Exposure (Intent Injection, ContentProvider Exploits)**
+4. **WebView Misuse (JavaScript Injection)**
+
+### Example: SQL Injection via `ContentProvider`
+
+A common vulnerable IPC mechanism in Android is an **exported ContentProvider** that allows other apps to access a database. The following **incorrect implementation** is prone to SQL Injection:
+
+#### Vulnerable Code
+
+```xml
+<provider
+    android:name=".VulnerableContentProvider"
+    android:authorities="com.example.vulnerable.provider"
+    android:exported="true">
+</provider>
+```
+
+```java
+@Override
+public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
+    SQLiteQueryBuilder qb = new SQLiteQueryBuilder();
+    qb.setTables("students");
+
+    switch (uriMatcher.match(uri)) {
+        case STUDENTS:
+            break;
+
+        case STUDENT_ID:
+            // UNSAFE: Directly appending user input to SQL query
+            qb.appendWhere("_id = " + uri.getPathSegments().get(1));
+            break;
+
+        default:
+            throw new IllegalArgumentException("Unknown URI " + uri);
+    }
+
+    return qb.query(db, projection, selection, selectionArgs, null, null, sortOrder);
+}
+```
+
+#### Why is this code vulnerable?
+
+- It concatenates user input (uri.getPathSegments().get(1)) directly into an SQL query.
+- An attacker can inject malicious SQL code via the URI path, leading to SQL Injection attacks.
+- If exploited, an attacker can steal, modify, or delete data from the database.
+
+#### Secure Implementation
+
+```java
+@Override
+public Cursor query(Uri uri, String[] projection, String selection, String selectionArgs[], String sortOrder) {
+    SQLiteQueryBuilder qb = new SQLiteQueryBuilder();
+    qb.setTables("students");
+
+    switch (uriMatcher.match(uri)) {
+        case STUDENTS:
+            break;
+
+        case STUDENT_ID:
+            // SAFE: Using parameterized query to prevent SQL Injection
+            qb.appendWhere("_id = ?");
+            selectionArgs = new String[]{uri.getLastPathSegment()};
+            break;
+
+        default:
+            throw new IllegalArgumentException("Unknown URI " + uri);
+    }
+
+    return qb.query(db, projection, selection, selectionArgs, null, null, sortOrder);
+}
+```
+
+## Dynamic Analysis
+
+### Testing for Injection Flaws in a Running Application
+
+While static analysis helps identify potential injection vulnerabilities, dynamic testing allows you to **exploit and confirm** them in a running application.
+
+### Testing for SQL Injection using `adb shell`
+
+If an Android application exposes a vulnerable `ContentProvider`, you can **query it manually** from the command line.
+
+#### Step 1: Check for Exposed Content Providers
+
+Run the following command to list exported ContentProviders:
+
+```bash
+adb shell content providers
+```
+
+#### Step 2: Query the ContentProvider for Student Data
+
+```bash
+adb shell content query --uri content://com.example.vulnerable.provider/students
+```
+
+#### Step 3: Attempt SQL Injection
+
+```bash
+adb shell content query --uri content://com.example.vulnerable.provider/students --where "name='Bob' OR 1=1--"
+```
+
+### Exploiting SQL Injection using Frida
+
+Frida is a powerful tool for **runtime manipulation of Android apps**. You can use it to **hook and modify** database queries.
+
+#### Step 1: Attach to the Target Application
+
+```bash
+frida -U -n com.example.vulnerable.app -e "console.log('Frida attached!')"
+```
+
+#### Step 2: Intercept and Modify the Query
+
+```javascript
+Java.perform(function() {
+    var ContentProvider = Java.use("com.example.vulnerable.VulnerableContentProvider");
+    ContentProvider.query.implementation = function(uri, projection, selection, selectionArgs, sortOrder) {
+        console.log("Intercepted query: " + selection);
+        return this.query(uri, projection, "1=1--", selectionArgs, sortOrder);
+    };
+});
+```
+
+## References
+
+- [OWASP Mobile Top 10 - M7: Client Code Quality](https://owasp.org/www-project-mobile-top-10/ "OWASP Mobile Top 10")
+- [CWE-89: Improper Neutralization of Special Elements used in an SQL Command](https://cwe.mitre.org/data/definitions/89.html "CWE-89")
+- [SQL Injection Cheat Sheet](https://www.websec.ca/kb/sql_injection "SQL Injection Cheat Sheet")