中间人劫持
中间人攻击的本质是在通信双方之间插入一个透明代理，在双方毫无察觉的情况下读取或篡改传输内容。 攻击成立的前提是通信路径上存在可控节点，且流量未经端到端加密保护。
中间人劫持原理
HTTP 明文传输的特性使得网络路径上的任何节点都可以读取和篡改流量。 HTTP 协议本身不提供任何机密性或完整性保证，数据以明文形式在网络中传输，路由器、交换机、运营商设备、公共 WiFi 热点上的任何一个节点都可以完整地读取请求和响应内容，并在转发前任意修改。
劫持的核心操作是替换，而不是破解。 攻击者无需破解任何加密，只需将目标内容替换为恶意内容后转发即可。插入广告、注入脚本、替换下载文件、窃取 Cookie，都属于这种替换操作的变体。
攻击手法
公共 WiFi 是实施中间人攻击成本最低的场景，攻击者只需搭建一个同名热点即可捕获全部流量。 咖啡馆、机场、酒店等场所的公共 WiFi 环境中，设备会自动连接到信号最强的同名热点，攻击者借此成为所有流量的中转节点，对 HTTP 流量拥有完全的读写权限。
ARP 欺骗将局域网内的流量劫持到攻击者设备，适用于有线或无线局域网环境。 ARP 协议没有认证机制，攻击者可以持续广播伪造的 ARP 响应，声称自己的 MAC 地址对应网关 IP，使局域网内其他设备将所有流量发往攻击者，由攻击者代为转发到真实网关，形成透明代理。
DNS 劫持通过控制域名解析过程将用户引导至攻击者控制的服务器，绕过网络路径层面的拦截限制。 攻击者通过入侵路由器修改其 DNS 配置、向 DNS 缓存注入伪造记录（缓存投毒），或在设备上植入修改系统 DNS 设置的恶意程序，使正常域名解析到恶意 IP，后续流量因此被引入攻击者的服务器。
SSL Strip 是一种将 HTTPS 降级为 HTTP 的中间人攻击，由安全研究员 Moxie Marlinspike 于 2009 年在 Black Hat DC 上公开演示。 攻击原理如下：攻击者首先通过 ARP 欺骗等手段介入通信路径，之后在用户与目标服务器之间分别维持两段独立连接——攻击者侧向服务器发起正常的 HTTPS 加密连接，而向用户侧仅建立 HTTP 明文连接。攻击者拦截服务器返回的所有 HTTPS 链接，将其重写为 HTTP 形式后再转发给用户，使用户始终在无加密信道上通信，而对服务器和用户双方都显得透明无异常。
BGP 劫持是互联网路由层面的中间人攻击，可以将全球范围内特定 IP 段的流量劫持到攻击者控制的网络。 BGP（边界网关协议）是互联网骨干路由协议，各自治系统通过它互相通告自己持有的 IP 前缀。BGP 协议本身缺乏强制认证机制，攻击者可以宣告不属于自己的 IP 前缀，使附近路由器将流量错误地发往攻击者网络。历史上已有多次有据可查的 BGP 劫持事件：2013 年针对美国多家金融机构和政府网络的流量曾被重路由至白俄罗斯；2014 年比特币矿池通信遭到 BGP 劫持被截获；2018 年有攻击者通过 BGP 劫持亚马逊 Route 53 的 DNS 流量，将用户引导至仿冒加密货币钱包网站。
运营商信道劫持是规模最大的中间人攻击形式，可以影响整个城市或地区的用户流量。 运营商骨干网上的设备天然处于所有用户流量的中转位置，一旦被利用（无论是技术入侵还是内部合谋），对 HTTP 流量的完全控制就意味着可以对海量用户同时实施劫持。
SSL Strip 历史案例
SSL Strip 工具发布后迅速暴露了 HTTPS 部署的最后一公里问题，推动了 HSTS 机制的普及。 2009 年演示时，大量网站虽然支持 HTTPS，但仍允许 HTTP 访问并依赖服务器端 301 跳转来引导用户。SSL Strip 在跳转发生之前就介入，使用户始终停留在 HTTP。由于用户浏览器地址栏未显示任何异常（当时浏览器不会对缺少 HTTPS 进行警告），攻击几乎不会引起注意。这一攻击的广泛传播直接促使 HTTP 严格传输安全（HSTS）机制成为主流防御标准，并推动了 HSTS Preload List 的建立。
运营商劫持案例
运营商体系内的从业者深知 HTTP 流量在传输层的零防护特性，绍兴黑产案展示了这一漏洞的商业化规模。
你曾经是否发现自己的微博突然多关注了几个人，甚至发布了几条广告微博？QQ突然被加入陌生群组？也许就是因为黑灰产团伙已经控制了你的账户，曾经绍兴警方就成功侦破过一件大案。
一家数百人的黑灰产集团，由近十家公司组成。并且还上市了，年营收达到上千万。该团伙创始人原本在运营商体系工作，后开始创业。由于当时各大网站和App都还是使用HTTP协议，导致在传输层毫无防护能力。
于是该团伙在2011年开始创业，通过和各地运营商建立合作，共建基于运营商流量的广告业务，实现劫持访问站点（插入推广Cookie获得抽成、增加其它站点访问量等）、插入广告、替换原有广告、替换下载的App等行为，通过广告的投放来赚取高额利益。到2016年左右，各大主流站点几乎都将通信协议升级为HTTPS，导致运营商能够劫持的流量不断下降，广告的展示与点击也随之下降，使得公司营收急剧缩水。营收仅187万，净利润2万元。
当年，以微博、公众号、头条号、直播为代表的新媒体开始崛起，于是该公司嗅到其中的机会，发现虽然各大主流互联网公司都实现了HTTPS，但其中还是存在一些非HTTPS的业务，比如一些资源链接、边缘业务、降级HTTP等。通过这些HTTP流量，可以抓取到用户的COOKIE信息。
拿到COOKIE信息，即拥有了该用户的账户权限，从而可以实现操控海量账户，在微博、微信、抖音等新媒体平台来进行精准营销、加粉丝、点赞、刷浏览量等方式盈利。优先为自己运营的新媒体账号加粉、刷量，并售卖加粉、刷量服务。通过该方法创造多个自媒体大V账号，2016年营收3028万元，净利润1053万元，并于2017年底在新三板上市。
虽然盈利颇丰，但其业务模式并不能见光。于是其在内部做了很多安全防护措施，包括使用匿名工具讨论敏感业务和技术问题，核心数据储存在海外，秒波IP池避免被追踪，对大V账号进行加白避免引起舆论，服务拥有应急程序能够自动清除。
SSL Pinning 绕过
Certificate Pinning 是移动端防止证书替换型中间人攻击的机制——应用内置了信任的证书或公钥哈希，仅接受与之匹配的服务端证书，Burp Suite 等代理工具的自签证书默认无效。攻击者绕过 Pinning 的主要路径：
越狱设备全局禁用：SSL Kill Switch 2 通过 Hook 系统层证书校验函数，全局禁用所有应用的 SSL 校验。需要越狱，部分应用有越狱检测。
Frida 动态插桩：向目标进程注入脚本，在运行时 Hook 证书校验函数使其永远返回成功。Objection 提供了封装命令 ios sslpinning disable。通常需要设备运行 Frida Server（需越狱），或通过重打包将 Frida gadget 注入 IPA。
重打包替换内置证书：适用于将证书文件硬编码在包内的应用（常见于 React Native/Cordova）。解压 IPA、替换 .cer/.pem 等证书文件或更新配置中的 SHA256 哈希，重签名安装。若应用有完整性自校验则替换后会崩溃。
修改 Info.plist：使用 TrustKit 等库的应用，将 Info.plist 中的 TSKEnforcePinning 从 true 改为 false 即可禁用，需重签名。
流量层透明拦截：Flutter 和 Xamarin 应用不遵守系统代理设置，标准 Burp 配置无效。替代方案是在共享网络链路上以 mitmproxy 透明拦截流量再转发给 Burp。
Hotspot 方法（macOS 互联网共享 + pf 透明代理）：上一条的完整 macOS 工具链：①Android/iOS 设备蓝牙共享网络给 MacBook；②MacBook 在"系统偏好 → 共享"中将"共享以下来源"设为蓝牙 PAN，"用以下方式共享"勾选 Wi-Fi；③iPhone 连接 MacBook 共享的 Wi-Fi；④macOS 用 pf 防火墙做透明转发——pf.rules 文件内容 rdr pass on bridge100 inet proto tcp from any to any -> 127.0.0.1 port 8080，然后 sudo pfctl -f pf.rules + sudo sysctl -w net.inet.ip.forwarding=1；⑤Burp 启用 invisible proxy（Proxy → Options → Request Handling）。这一链路在 Flutter / Xamarin 不走系统代理的场景下是唯一能拿到完整流量的工程方案。
MITMProxy 作为前置透明代理 + Burp 作为上游：处理 Burp 单独无法解密的复杂链路。brew install mitmproxy 安装后启动 mitmweb，编辑选项添加 mode: upstream: http://127.0.0.1:8888（Burp 监听端口）+ 启用 ssl_insecure: true，Burp 端设置上游代理指向 mitmweb。链路变成：iPhone → mitmproxy（透明代理 + 自身 CA）→ Burp（上游）→ 目标服务器。这种"双层代理"架构在 Flutter 双向证书认证等场景下特别有效。
硬编码 SHA256 哈希替换（Cordova 特有）：Cordova 应用通常在配置文件中硬编码服务器证书的 SHA256 哈希。攻击链：①解压 IPA 定位 pinning.json 等配置；②用 openssl 生成 Burp 证书的 SHA256：
openssl x509 -inform DER -in cacert.cer -out cacert.crt
openssl x509 -in cacert.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
③替换配置中的哈希值；④重签名安装。若应用有完整性自校验则替换后会崩溃——这是 Cordova 应用的常见弱点。
Info.plist 关键字补全：除 TSKEnforcePinning 外，常见可改的 Pinning 相关关键字还包括 NSRequiresCertificateTransparency（证书透明度检查）、NSAppTransportSecurity（含 NSAllowsArbitraryLoads 等子键，控制 ATS 策略）。把这些从 true 改为 false 即可禁用对应的检查或传输安全要求。
这些绕过路径说明 Pinning 只是纵深防御的一层：代码混淆使 Hook 定位更困难，运行时环境检测（越狱/Frida/调试器）可拒绝在受攻击环境运行，多层证书哈希校验提高替换难度，证书定期轮换缩短泄露后的可用窗口。
移动端非越狱全流量抓包
iOS 不越狱、无 root、应用沙箱隔离——这些约束让传统的"Hook 系统证书校验"路径失效。但 iOS 提供了系统级的 Network Extension API，允许用户安装 VPN Configuration 来代理所有设备流量。 利用这一机制，可以在不越狱的前提下捕获移动端的全部流量。这同样适用于 Android（用户级 CA 安装更宽松，限制更少）。
三件套：VPN 隧道 + 抓包 + 拦截
WireGuard：轻量级现代 VPN 协议，配置简单，性能优于 OpenVPN。iOS App Store 有官方客户端，支持导入配置文件。关键是它作为 iOS Network Extension 运行——所有 App 的流量都被强制经此 VPN 出口。
Wireshark：包级别的抓包工具。在攻击者主机上监听 VPN 端点接口，可以捕获从 iOS 设备流出的所有明文流量。
MITMProxy：HTTPS 拦截代理。配合 WireGuard 一起使用时，VPN 端点把流量转到 MITMProxy，由它解密 HTTPS 内容后转发到目标服务器。
典型操作流程
- iOS 端：安装 WireGuard App，导入配置（远端指向攻击者主机）。这一步会触发 iOS 的"VPN 配置安装"系统弹窗——这是该方法依赖用户主动授权的边界。
- 攻击者主机：启动 WireGuard 服务端，监听
wg0接口。同时启动 Wireshark 抓此接口。 - 目标 App 流量：从 iOS App 发出 → 经 WireGuard 加密隧道 → 攻击者主机 → 攻击者主机 WireGuard 客户端解密 → 进入 Wireshark/MITMProxy。
- HTTPS 拦截：MITMProxy 用自己的 CA 签发假证书给 iOS。iOS 端需要信任这个 CA（需要把 CA 证书导入 iOS 设置中的证书信任列表），否则 HTTPS 会被系统拒绝。
对 SSL Pinning 的影响
这一路径在网络层拦截流量，不依赖 Hook 应用进程——所以应用即使做了 Certificate Pinning，也只能拒绝"未被 Pin 的 CA"，无法阻止"被 Pin 的 CA 签发的伪造证书"。换言之，Pinning 对网络层透明代理的攻击路径无效——它的防护假设是"没有攻击者控制的 CA 能签出被信任的证书"，而网络层代理恰好绕过了这个假设。
检测与防御的边界
这种抓包方式依赖三个条件，缺一不可：
- 用户安装 VPN 配置：iOS 系统弹窗必须由用户主动确认，无法静默安装
- iOS 信任攻击者 CA：用户需要把 CA 证书加入"证书信任设置"，否则 HTTPS 直接失败
- 网络可达：iOS 设备需要能连接到攻击者主机（同一 WiFi 或公网 IP）
任何"用户没主动授权的零点击全流量抓包"在 iOS 上不存在。 这意味着对个人隐私的保护，最终落在"用户是否理解 VPN 配置的真实目的"和"是否被诱导信任未知 CA"。技术防御之外，用户教育是更关键的一道防线。
防御策略
HTTPS 强制跳转解决的是用户首次访问时以明文发起请求的问题。 当用户直接在浏览器输入域名时，默认会发起 HTTP 请求，服务器将其 301/302 跳转到 HTTPS。这个初始 HTTP 请求在跳转完成前是完全裸露的，攻击者可以在此时注入内容或劫持会话。
HSTS 解决的是浏览器缓存强制策略的问题，避免每次都依赖服务器的跳转响应。 当服务器在 HTTPS 响应中发送 Strict-Transport-Security 头后，浏览器会在指定时间内直接将所有到该域名的请求升级为 HTTPS，不再发出任何 HTTP 请求，从源头消除了降级劫持的可能。includeSubDomains 指令将这一保护扩展到所有子域名，HSTS Preload List 则将策略预置在浏览器中，使其无需任何首次访问即可生效。
Cookie Secure 标志防止 Cookie 通过 HTTP 信道传输，但存在子域名绕过的边界问题。 当某主域配置了 HSTS 但未启用 includeSubDomains 时，攻击者可以利用不存在的子域名（如 http://fake.example.com）配合 DNS 污染，触发浏览器发出 HTTP 请求，从而在请求头中携带并窃取主域的 Cookie。
Certificate Pinning 解决的是伪造证书欺骗客户端的问题。 即使攻击者在网络路径上部署了中间设备并持有受信任 CA 签发的证书，通过将预期的证书指纹或公钥固化在客户端代码中，客户端可以拒绝接受任何与预置指纹不匹配的证书，从而防止证书替换攻击。