Translated ['src/mobile-pentesting/ios-pentesting/ios-pentesting-without

src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md

@@ -8,7 +8,7 @@
 
 然而，这并不像简单地提取 IPA、使用该权限重新签名并将其刷回设备那么简单。这是因为 FairPlay 保护。当应用程序的签名更改时，DRM（数字版权管理）密钥会 **失效，应用程序将无法工作**。
 
-在旧的越狱设备上，可以安装 IPA，**使用你喜欢的工具进行解密**（例如 Iridium 或 frida-ios-dump），然后将其提取回设备上。不过，如果可能，建议直接向客户端请求解密后的 IPA。
+在旧的越狱设备上，可以安装 IPA，**使用你喜欢的工具进行解密**（例如 Iridium 或 frida-ios-dump），然后将其提取回设备上。尽管如此，如果可能，建议直接向客户端请求解密后的 IPA。
 
 ## 获取解密的 IPA
 
@@ -25,7 +25,7 @@
 
 ### 解密应用程序
 
-为了解密 IPA，我们将安装它。然而，如果你有一部旧的越狱 iPhone，可能其版本不被该应用程序支持，因为通常应用程序只支持最新版本。
+为了解密 IPA，我们将安装它。然而，如果你有一部旧的越狱 iPhone，可能其版本不被应用程序支持，因为通常应用程序只支持最新版本。
 
 因此，为了安装它，只需解压 IPA：
 ```bash
@@ -52,7 +52,7 @@ ideviceinstaller -i no-min-version.ipa -w
 
 关于证书和签名配置文件，Apple 通过 Xcode 为所有账户提供 **免费的开发者签名配置文件**。只需创建一个应用并配置一个。然后，通过导航到 `Settings` → `Privacy & Security`，配置 **iPhone 以信任开发者应用**，并点击 `Developer Mode`。
 
-使用重新签名的 IPA，现在可以在设备上安装它以进行渗透测试：
+使用重新签名的 IPA，现在可以将其安装到设备上进行渗透测试：
 ```bash
 ideviceinstaller -i resigned.ipa -w
 ```
@@ -66,7 +66,7 @@ ideviceinstaller -i resigned.ipa -w
 2. 导航到 **设置 → 隐私与安全 → 开发者模式** 并将其切换为开启。
 3. 设备将重启；输入密码后，您将被要求 **开启** 开发者模式。
 
-开发者模式在您禁用它或清除手机之前保持激活，因此此步骤每个设备只需执行一次。[Apple 文档](https://developer.apple.com/documentation/xcode/enabling-developer-mode-on-a-device) 解释了安全隐患。
+开发者模式保持激活状态，直到您禁用它或清除手机，因此此步骤每个设备只需执行一次。[Apple 文档](https://developer.apple.com/documentation/xcode/enabling-developer-mode-on-a-device) 解释了安全隐患。
 
 ### 现代侧载选项
 
@@ -93,7 +93,7 @@ frida -U -f com.example.target -l my_script.js --no-pause
 
 ### 使用 MobSF 进行自动化动态分析（无越狱）
 
-[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) 可以使用相同的技术 (`get_task_allow`) 在真实设备上对开发签名的 IPA 进行插桩，并提供带有文件系统浏览器、流量捕获和 Frida 控制台的 Web UI【】。最快的方法是通过 Docker 运行 MobSF，然后通过 USB 连接你的 iPhone：
+[MobSF](https://mobsf.github.io/Mobile-Security-Framework-MobSF/) 可以使用相同的技术 (`get_task_allow`) 在真实设备上对开发者签名的 IPA 进行插桩，并提供带有文件系统浏览器、流量捕获和 Frida 控制台的 Web UI【†L2-L3】。最快的方法是通过 Docker 运行 MobSF，然后通过 USB 连接你的 iPhone：
 ```bash
 docker pull opensecurity/mobile-security-framework-mobsf:latest
 docker run -p 8000:8000 --privileged \

src/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

@@ -2,6 +2,99 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**查看帖子 [https://portswigger.net/research/http-2-downgrades](https://portswigger.net/research/http-2-downgrades)**
+HTTP/2通常被认为对经典请求走私免疫，因为每个DATA帧的长度是明确的。**这种保护在前端代理将请求“降级”到HTTP/1.x并转发到后端时消失**。当两个不同的解析器（HTTP/2前端和HTTP/1后端）试图达成一致，确定一个请求结束和下一个请求开始的位置时，所有旧的不同步技巧都会回归——加上一些新的技巧。
+
+---
+## 为什么会发生降级
+
+1. 浏览器已经支持HTTP/2，但许多遗留的源基础设施仍然只理解HTTP/1.1。
+2. 反向代理（CDN、WAF、负载均衡器）因此在边缘终止TLS + HTTP/2，并**将每个请求重写为HTTP/1.1**以供源使用。
+3. 翻译步骤必须同时创建`Content-Length` **和/或** `Transfer-Encoding: chunked`头，以便源可以确定主体长度。
+
+每当前端信任HTTP/2帧长度**但**后端信任CL或TE时，攻击者可以迫使它们不一致。
+
+---
+## 两种主要原始类
+
+| 变体 | 前端长度 | 后端长度 | 典型有效负载 |
+|---------|-----------------|-----------------|-----------------|
+| **H2.TE** | HTTP/2帧 | `Transfer-Encoding: chunked` | 嵌入一个额外的分块消息主体，其最终的`0\r\n\r\n`*未*发送，因此后端等待攻击者提供的“下一个”请求。 |
+| **H2.CL** | HTTP/2帧 | `Content-Length` | 发送一个*较小*的CL而不是实际主体，因此后端读取超出边界的下一个请求。 |
+
+> 这些在精神上与经典的TE.CL / CL.TE相同，只是用HTTP/2替换了其中一个解析器。
+
+---
+## 识别降级链
+
+1. 在TLS握手中使用**ALPN**（`openssl s_client -alpn h2 -connect host:443`）或**curl**：
+```bash
+curl -v --http2 https://target
+```
+如果出现`* Using HTTP2`，则边缘支持H2。
+2. 通过HTTP/2发送故意格式错误的CL/TE请求（Burp Repeater现在有一个下拉菜单可以强制使用HTTP/2）。如果响应是HTTP/1.1错误，例如`400 Bad chunk`，则证明边缘将流量转换为下游的HTTP/1解析器。
+
+---
+## 利用工作流程（H2.TE示例）
+```http
+:method: POST
+:path: /login
+:scheme: https
+:authority: example.com
+content-length: 13      # ignored by the edge
+transfer-encoding: chunked
+
+5;ext=1\r\nHELLO\r\n
+0\r\n\r\nGET /admin HTTP/1.1\r\nHost: internal\r\nX: X
+```
+1. **前端** 精确读取了 13 字节（`HELLO\r\n0\r\n\r\nGE`），认为请求已完成并将其转发给源。
+2. **后端** 信任 TE 头，继续读取直到看到 *第二个* `0\r\n\r\n`，从而消耗了攻击者第二个请求的前缀（`GET /admin …`）。
+3. 剩余部分（`GET /admin …`）被视为排队在受害者后面的 *新* 请求。
+
+用以下内容替换走私请求：
+* `POST /api/logout` 以强制会话固定
+* `GET /users/1234` 以窃取特定于受害者的资源
+
+---
+## h2c 走私（明文升级）
+
+2023 年的一项研究表明，如果前端将 HTTP/1.1 的 `Upgrade: h2c` 头传递给支持明文 HTTP/2 的后端，攻击者可以通过仅验证 HTTP/1.1 的边缘隧道 *原始* HTTP/2 帧。这绕过了头部规范化、WAF 规则甚至 TLS 终止。
+
+关键要求：
+* 边缘不变地转发 **两个** `Connection: Upgrade` 和 `Upgrade: h2c`。
+* 源升级到 HTTP/2，并保持允许请求排队的连接重用语义。
+
+缓解措施很简单——在边缘剥离或硬编码 `Upgrade` 头，WebSockets 除外。
+
+---
+##  notable real-world CVEs (2022-2025)
+
+* **CVE-2023-25690** – Apache HTTP Server mod_proxy 重写规则可以链式用于请求拆分和走私。（在 2.4.56 中修复）
+* **CVE-2023-25950** – HAProxy 2.7/2.6 在 HTX 解析器错误处理管道请求时发生请求/响应走私。
+* **CVE-2022-41721** – Go `MaxBytesHandler` 导致剩余的主体字节被解析为 **HTTP/2** 帧，从而启用跨协议走私。
+
+---
+## 工具
+
+* **Burp Request Smuggler** – 自 v1.26 起，它自动测试 H2.TE/H2.CL 和隐藏的 ALPN 支持。在扩展选项中启用“HTTP/2 探测”。
+* **h2cSmuggler** – Bishop Fox 的 Python PoC 用于自动化明文升级攻击：
+```bash
+python3 h2csmuggler.py -u https://target -x 'GET /admin HTTP/1.1\r\nHost: target\r\n\r\n'
+```
+* **curl**/`hyper` – 手动构造有效负载：`curl --http2-prior-knowledge -X POST --data-binary @payload.raw https://target`。
+
+---
+## 防御措施
+
+1. **端到端 HTTP/2** – 完全消除降级转换。
+2. **单一长度真相来源** – 在降级时，*始终* 生成有效的 `Content-Length` **并且** **剥离** 任何用户提供的 `Content-Length`/`Transfer-Encoding` 头。
+3. **路由前规范化** – 在路由/重写逻辑 *之前* 应用头部清理。
+4. **连接隔离** – 不要在用户之间重用后端 TCP 连接；“每个连接一个请求”可以抵御基于队列的攻击。
+5. **剥离 `Upgrade` 除非是 WebSocket** – 防止 h2c 隧道。
+
+---
+## 参考文献
+
+* PortSwigger Research – “HTTP/2: The Sequel is Always Worse” <https://portswigger.net/research/http2>
+* Bishop Fox – “h2c Smuggling: request smuggling via HTTP/2 clear-text” <https://bishopfox.com/blog/h2c-smuggling-request>
 
 {{#include ../../banners/hacktricks-training.md}}