1. 加密接口概述:从 HTTPS 到 API 加密

各位做渗透测试的兄弟,提到加密接口,你们第一反应是什么?

反正我最早听到这个词,脑子里蹦出来的就是 HTTPS。没错,HTTPS 是加密接口的“门面”,但你要觉得搞定一个 SSL/TLS 就完事了,那后面踩的坑可不少。

我这几年测过的接口,少说几百个。有的接口看起来加了密,实际上只是套层 TLS,业务数据还是裸奔;有的用了自定义加密算法,自己造了个轮子,漏洞比明文还多。所以第一节课,咱们先把基础概念捋清楚。

1.1 为什么接口需要加密?

说白了,接口就是数据流动的“水管”。如果不加密,中间任何一个人都能拧开阀门看里面的数据。密码、订单、身份证,全暴露了。

我遇到过一家金融公司,他们的 APP 和服务器之间走的 HTTP,以为内网没事。结果被中间人抓包,交易记录全被盗。那之后他们才老老实实上 HTTPS,还加了一层签名。

核心目标: 保证数据传输的 机密性(别人看不懂)、完整性(别人改不了)、身份认证(确定你是谁)。

1.2 HTTPS 与 SSL/TLS

HTTPS 不是新协议,它就是 HTTP 跑在 SSL/TLS 上。TLS 是现在的标准,SSL 已经过时了,但很多人还叫习惯了。

握手过程(简化版)

  1. 客户端发“你好”,附带支持的加密套件列表。
  2. 服务端选一套,发回证书(含公钥)。
  3. 客户端验证证书(CA 链、域名、有效期)。
  4. 生成临时的对称密钥,用服务端公钥加密发过去。
  5. 双方用对称密钥加密通信。
我提醒一句: 渗透测试时一定要检查证书验证是否严格。很多 APP 为了省事,直接 trust all,那你的 HTTPS 就是纸老虎。

常见加密套件

套件名称密钥交换认证加密MAC
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256ECDHERSAAES-128-GCMSHA256
TLS_RSA_WITH_AES_256_CBC_SHA256RSARSAAES-256-CBCSHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305ECDHEECDSACHACHA20-POLY1305Poly1305

你想想看,为什么推荐 ECDHE 而不是 RSA 密钥交换?因为 ECDHE 有前向安全性——即使私钥泄露,以前的会话也解不开。我在项目中见过只配 RSA 的银行,他们当时觉得够用,后来出了私钥泄漏事件,悔不当初。

1.3 协议版本与漏洞

  • SSL 2.0 / 3.0 — 别用了,漏洞成堆。我曾经在政府内网见过一个系统还开着 SSL 3.0,POODLE 攻击直接拿下。
  • TLS 1.0 / 1.1 — 虽然比 SSL 好,但 BEAST、Lucky13 等攻击依然有效。2020 年后主流浏览器已经禁用。
  • TLS 1.2 — 目前最广泛,但记得禁用弱加密套件(比如 CBC 模式 + SHA1)。
  • TLS 1.3 — 又快又安全,握手少一次往返,强制前向安全,推荐首选。
避坑: 我曾经测试一个支付接口,服务端声称支持 TLS 1.2,结果我扫出来它同时支持 TLS 1.0 和 EXPORT 级加密套件。降级攻击直接拿到会话密钥。所以不要只看版本号,一定要实际验证。

1.4 API 加密基础

HTTPS 只保住了传输层,但到了应用层,API 自身还需要加密和签名。不然呢?你服务器收到的请求到底是用户发的,还是中间人重放的?

对称加密 vs 非对称加密

类型优点缺点常见算法
对称加密速度快,适合大数据量密钥分发困难AES, DES, 3DES, SM4
非对称加密密钥管理方便,支持数字签名慢,不适合直接加密大块数据RSA, ECDSA, SM2

实际 API 设计常采用混合加密:用非对称加密传递对称密钥,再用对称密钥加密业务数据。典型的例子就是 HTTPS 的握手过程。

哈希与 HMAC

哈希函数用来保证完整性,但单纯哈希会被重放。所以需要 HMAC(带密钥的哈希)。

  • MD5 / SHA-1 — 不安全了,别再用了。我见过一个老系统还在用 MD5 签名,直接被我碰撞出来伪造请求。
  • SHA-256 / SHA-3 — 目前推荐,HMAC 时密钥要足够随机。

数字签名

非对称加密的另一种用法:私钥签名,公钥验证。API 中常用在请求防篡改和身份证明。比如微信支付的回调,就会用 RSA 签名验签。

1.5 一个典型的 API 加密流程

  1. 客户端生成对称密钥(或使用预共享的密钥)。
  2. 用服务端公钥加密这个对称密钥,放入请求头。
  3. 用对称密钥加密业务数据(如 JSON 体)。
  4. 对加密后的数据 + 时间戳 + 随机数做 HMAC 签名。
  5. 服务端收到后,先验签,再解密对称密钥,最后解密数据。
注意: 时间戳和随机数是防重放的关键。我见过有人只用了时间戳,结果攻击者在 5 分钟内重放请求,业务直接崩了。加上 nonce(一次性随机数)并在服务端做去重,才能完全堵住重放。

1.6 加密接口渗透测试关注点

前面说了这么多基础,最后咱们总结一下渗透时该盯哪儿:

  • 传输层: TLS 版本、套件强度、证书验证、中间人攻击风险。
  • 应用层: 加密算法选择(是否用了弱算法)、密钥管理(是否硬编码)、签名机制(是否可以绕过)、重放防护。
  • 自定义加密: 警惕轮子!我测过一个自创的“异或+Base64”加密,连密钥都是固定的,直接逆向破解。

好了,以上就是加密接口的概览。下面我用一张图把这些关系串起来,方便你脑子里有个全貌。

加密接口渗透测试 — 知识体系 加密接口 (API) 传输层 (HTTPS/TLS) 应用层 (API加密) TLS版本检查 套件强度 证书验证 加密算法 签名HMAC 防重放 渗透测试关注点 中间人攻击 降级攻击 重放攻击 密钥泄露/硬编码 重点:穿透 TLS 后,应用层加密才是真正的防线 不要只测 SSL/TLS,要深入业务加密逻辑

这张图把加密接口渗透测试的知识体系分成了两层,你可以当作以后测试时的检查清单。下一节课开始,我们会深入每个模块,包括怎么抓取加密流量、怎么破解弱加密、怎么伪造签名……

嗯,先消化今天的基础,后面有的是硬仗要打。