文章总结： 文档强调API安全的重要性，指出HTTPS不足，提出三层防御方案：AES-256加密数据、RSA-2048交换密钥、SHA-256签名验证。详细描述了实现流程、性能优化和实际应用案例，如微信支付。建议实施混合加密、防重放机制和密码敏捷性，以应对数据泄露风险。 综合评分： 91 文章分类： WEB安全,应用安全,安全建设,解决方案,数据安全
生产级 API 加密的构建实用指南（从owasp开始）
原创
破天KK
KK安全说
2025年12月17日 20:26 北京
数字经济依赖于API，但大多数组织仍然面临着巨大的安全风险。根据Traceable AI发布的《2025年API安全状况报告》，过去两年中，57%的组织遭遇 过与API相关的数据泄露事件，其中73%的组织遭遇过三次或三次以上的此类事件。然而，尽管这一趋势令人担忧，但仍有近三分之一面向客户的API缺乏基本的加密措施。
这并非抽象的安全问题，而是直接关系到您的实际收益。到2025年，全球数据泄露的平均成本将达到444万美元，而在美国，由于监管罚款和检测费用的增加，成本飙升至创纪录的1022万美元。对于处理敏感支付数据的金融机构和医疗保健提供商而言，API安全不再是可有可无的，而是关乎生存的关键。
大多数团队面临的挑战并非复杂的理论，而是直接的执行。如何真正加密 API 数据？如何安全地交换加密密钥？如何在不影响性能的前提下防止请求篡改和重放攻击？本指南将介绍金融科技公司和支付处理商久经考验的模式，将对称加密、非对称加密和加密签名整合到一个可在生产环境中稳定运行的统一系统中。
为什么标准 HTTPS 还不够？
首先，我们要面对一个残酷的现实：尽管许多开发者认为HTTPS可以解决API安全问题，但它本身并不能做到。HTTPS保护的是客户端和服务器之间传输的数据——也就是传输层安全。但它无法阻止连接建立后应用层发生的威胁。
设想一个典型的入侵场景。攻击者拦截加密的 HTTPS 流量（可能性较小，但某些攻击途径并非不可能），通过其他漏洞访问您的服务器，或者利用社会工程手段窃取开发人员的凭据。这样一来，他们就可以在应用层修改 API 请求和响应，观察数据模式，重放合法请求以利用业务逻辑缺陷，并窃取存储在客户端代码中的 API 密钥。
这就是为什么 OWASP API 安全 Top 10（最近一次更新于 2023 年）始终将授权和身份验证漏洞列为前三大漏洞的原因。99% 的组织在过去 12 个月内报告了至少一起 API 安全事件，其中 95% 的攻击源自已认证的会话——这意味着攻击者绕过了基本身份验证，并以“合法”用户的身份进行操作。
HTTPS 提供基础。应用层加密、签名验证和时间戳验证构成安全屏障。
架构：三层防御
该解决方案结合了三种互补的加密技术，每种技术都针对特定的威胁：
对称加密（AES-256）对实际数据有效载荷进行加密。它的速度很快——基准测试显示，加密吞吐量可达 81.75 MB/s，解密吞吐量可达 1,481.69 MB/s，因此适用于大型有效载荷。问题在于：双方需要相同的密钥。如何在不可信的网络上安全地共享该密钥？
非对称加密（RSA-2048）解决了密钥分发问题。服务器持有私钥，客户端持有公钥。客户端使用公钥加密对称密钥——只有私钥持有者才能解密。缺点是：RSA 速度慢，加密速度仅为 3.30 MB/s，解密速度仅为 0.51 MB/s。因此，RSA 不用于加密实际数据，而仅用于加密 AES 密钥。
加密签名（SHA-256）确保数据完整性并防止篡改。即使攻击者无法解密您的数据，他们也可能尝试修改它。签名就像加密指纹——更改单个字节，签名就会失效。时间戳通过使旧请求过期来防止重放攻击。
这三层加起来就形成了业内所谓的“混合加密”——结合了对称加密和非对称加密的优势，同时减轻了它们各自的弱点。
用于互联网安全通信的TLS握手
系统工作原理：完整流程
想象一下，一个移动应用向您的 API 提交支付请求。以下是实际的流程：
步骤 1：客户端生成会话密钥
客户端会为本次请求生成一个新的 AES-256 密钥。这一点至关重要——每个请求都使用一个新的对称密钥。即使攻击者通过网络嗅探或代码检查等手段获取了该密钥，他们也只能解密本次请求，而无法解密过去或未来的请求。
// Java/Hutool 示例
String sessionKey = SecureUtil.randomString( 32 ); // 每个请求使用新的 AES 密钥
步骤二：密钥加密
客户端使用服务器的公钥 RSA 密钥（通常通过应用程序二进制文件分发或在应用程序初始化期间获取）来加密会话密钥：
String publicKey = "-----BEGIN PUBLIC KEY-----\n..." ; // 服务器的公钥
RSA rsa = new RSA ( null , publicKey);
String encryptedKey = rsa.encryptBase64(sessionKey, KeyType.PublicKey);
加密后的密钥以 (encrypt-key) 的形式放在请求头中ek。只有服务器的私钥才能解密它。
步骤三：数据加密
查询参数和请求正文均使用会话密钥进行加密：
AES aes = SecureUtil.aes(sessionKey.getBytes());
String encryptedQueryString = aes.encryptBase64(queryParams);
String encryptedBody = aes.encryptBase64(requestBody);
查询参数变为：?ciphertext=[encrypted_params]
正文变为：直接包含加密后的有效载荷。
步骤 4：签名生成
在发送之前，客户端会按照特定顺序连接未加密的查询字符串、当前时间戳、明文会话密钥（是的，就是未加密的密钥——这是故意的）和请求正文，然后使用 SHA-256 进行哈希运算，从而创建签名：
String toSign = queryString + timestamp + sessionKey + body;
String signature = SecureUtil.sha256(toSign);
此签名应放在sign页眉中。
步骤 5：发送请求
标题：
ek：[RSA encrypted session key]ts：[current timestamp in milliseconds]sign：[SHA256 hash]
身体：[AES encrypted payload]
步骤 6：服务器接收并验证
服务器按顺序执行以下检查：
- 时间戳验证：
ts从请求头中提取。如果时间戳超过（通常）5 分钟，则拒绝请求。这可以防止在数小时或数天后重放旧请求。 - 密钥解密：使用私钥进行解密
ek：
String sessionKey = rsa.decryptStr(encryptedKey); // 私钥解密
- 签名验证：使用解密后的会话密钥重建签名：
String toSign = queryString + timestamp + sessionKey + body;
String expectedSignature = SecureUtil.sha256(toSign);
if (!expectedSignature.equals(clientSignature)) {
return 401 ; // 签名不匹配
}
此验证机制可防止篡改和未经授权的请求。攻击者即使不知道会话密钥，也无法伪造有效的签名。
- 数据解密：使用会话密钥解密有效载荷：
String decryptedBody = aes.decryptStr(encryptedBody);
- 业务逻辑：处理已解密、已验证的请求。
- 响应加密：在返回响应之前，使用相同的会话密钥对响应进行加密。
对称加密与非对称加密（极简版）
性能影响和优化
直接的问题是：所有这些加密措施难道不会降低速度吗？
在2025年环境下测试的混合AES-RSA加密方案中，混合加密的平均加密时间为166.66毫秒，吞吐量为每秒66,469.75次加密；相比之下，混合AES-ECC的平均加密时间为790毫秒，吞吐量仅为每秒11,236.59次；混合AES-ElGamal的平均加密时间为964.83毫秒，吞吐量为每秒9,503.59次。AES-RSA混合方案的速度明显更快。
为什么？因为 RSA 只加密会话密钥（通常为 32-256 字节），而不是整个有效载荷。如果您要传输一个 1MB 的文件，您实际上是用快速的 AES（微秒级）加密 1MB 的数据，而用慢速的 RSA（毫秒级）加密 32 字节的数据。RSA 的开销可以忽略不计。
实际操作中：
- 每次请求的开销：加密操作需要 5-15 毫秒（取决于 RSA 密钥长度和硬件）。
- 吞吐量影响：对于小于 10MB 的典型 API 有效负载，影响可忽略不计
- 延迟影响：类似于增加一次网络跳转。
对于高吞吐量系统而言，真正的优化并非避免加密，而是并行化和硬件加速。现代 CPU 包含 AES-NI 指令集，可直接在芯片内部加速 AES 运算。TLS 1.3 目前已被 62.1% 的受访网站采用，这表明加密通信已成为基本要求，且性能损失极小。
实际应用：来自支付处理商的经验教训
微信支付是全球最大的移动支付平台之一，拥有数亿用户，它采用了类似的多层加密方案。其API根据集成点的不同，使用多种签名算法（MD5、SHA-256、RSA-2048），标准交易的RSA密钥长度为2048位。该平台要求所有API通信均使用HTTPS，并对支付金额和客户财务数据等敏感字段进行应用层加密。
从 MD5 到 SHA-256 再到 RSA-2048 的演进反映了金融科技行业安全态势的演变。MD5 的密码学安全性已被破解，不应再用于新的应用场景。SHA-256 提供强大的抗碰撞能力。RSA-2048 提供非对称加密保护，并具有约 112 位的对称加密强度——足以应对当前的威胁，尽管业界已开始向后量子算法迁移。
说到这里：美国国家标准与技术研究院 (NIST) 于 2024 年正式将 ML-KEM（后量子密码学的密钥封装机制）标准化，并于 2025 年 3 月选定了名为 HQC 的备用算法。国家安全系统必须在 2033 年前全面过渡到抗量子算法，高风险系统最早可在 2030 年完成过渡。虽然这不会立即影响当前的实现，但它表明各组织应在构建系统时考虑密码敏捷性——即无需重新设计整个系统即可更换算法的能力。
解答常见实施问题
问：客户端是否应该在代码中存储服务器的公钥？
不，不能直接以明文形式发送。公钥应该是：
- 存储在加密的 SharedPreferences/Keychain（平台安全存储）中
- 应用初始化时从服务器获取并缓存
- 定期轮换（每年或发生安全事件时）
- 尽可能通过证书绑定进行验证
即使公钥泄露，直接风险也仅限于此，因为每次请求都会使用新的会话密钥。拥有旧公钥的攻击者无法解密后续请求。
问：为什么签名中包含纯会话密钥？
这虽然微妙，但至关重要。通过将未加密的对称密钥混入签名中，您可以实现以下几个目标：
- 签名证明客户端知道会话密钥（没有会话密钥就无法签名）。
- 如果会话密钥被以某种方式提取出来，就可以检测到签名伪造，因为攻击者需要为修改后的数据重新生成有效的签名。
- 它在密钥和数据之间建立加密绑定。
这有时被称为“所有权证明”，并在零信任身份验证框架中得到广泛应用。
问：如何防止攻击者重放旧的请求？
三种机制：
- 时间戳验证：服务器会拒绝超过 5 分钟（或您设定的时间范围）的请求。这可以防止简单的重放攻击。
- 一次性会话密钥：即使捕获到旧的请求，它也使用不同的会话密钥。攻击者无法将其用于新的请求。
- 服务器端请求去重（可选但推荐）：对于支付等关键操作，将请求签名存储在缓存中，并拒绝重复请求 24 小时。这可以防止“如果客户端认为我的请求失败并重试”的情况，即合法的交易执行两次。
这三层防御结合起来使得重放攻击变得不切实际。攻击者需要：
- 在时间戳窗口内捕获实时请求
- 要么破解 RSA-2048（计算上不可行），要么窃取服务器的私钥。
- 在保持有效签名的前提下修改请求（这在密码学上是不可能的）
问：我们应该对回复进行加密吗？
当然。响应通常包含敏感信息，例如客户个人身份信息、交易详情和账户余额。对其进行加密可以确保即使在请求发送后连接遭到破坏，响应仍然保密。使用客户端生成的同一会话密钥。客户端可以解密它，因为它知道自己发送的密钥（使用 RSA 加密）。
问：那些需要可搜索或可建立索引的字段该怎么办？
这就是应用程序设计变得复杂的地方。如果对客户电子邮件地址进行加密，就无法通过电子邮件进行查询。可选项包括：
- 确定性加密：使用相同的密钥和算法为相同的明文生成相同的密文。然后对密文进行索引。缺点：如果明文域较小（例如，只有 500 个可能的值，攻击者可以测试所有 500 种加密方式），则容易受到某些攻击。
- 令牌化：将敏感值替换为非敏感令牌，并维护一个单独的加密查找表。搜索速度较慢，但安全性更高。
- 差分隐私：对数据进行加密，并使用无需解密的统计查询。即使加密数据泄露，也能提供隐私保障。
正确的选择取决于您优先考虑的是查询性能（确定性加密）还是隐私（令牌化或差分隐私）。对于支付系统而言，隐私通常是首要考虑因素。
2025 年 100 多项数据泄露统计数据和趋势
安全分析及局限性
这个系统很强大，但并非坚不可摧。了解它的局限性与了解它的优势同样重要。
它能防范什么：
- 中间人攻击：即使有人拦截了流量，也只能看到密文，不会泄露明文。
- 参数篡改：更改加密请求的任何部分都会使签名失效。
- 请求重放：时间戳会使请求过期。会话密钥会因请求而更改。
- 机器人抓取和未经授权的访问：如果不了解签名算法和私钥，自动访问将变得不可能。
- API密钥泄露：如果API密钥在代码中暴露，则损害仅限于该特定会话。攻击者仍然无法解密其他请求中的数据。
它无法防范的情况：
- 客户端泄露：如果移动应用被逆向工程或 Web 应用的 JavaScript 代码被分析，攻击者可以提取公钥并查看签名算法。他们无法解密数据（这需要服务器上的私钥），但可以观察数据模式并可能篡改请求。
- 应用逻辑攻击：加密无法阻止授权绕过。如果业务逻辑要求“更新任意用户的电子邮件地址”，加密也无济于事——攻击者仍然可以更改其他用户的电子邮件地址。
- 侧信道攻击：在安全级别极高的场景（例如军事、国家安全）中，攻击者可能通过计时、功耗或电磁辐射等手段窃取关键信息。标准的商用API通常不会成为此类攻击的目标。
- 量子计算机：目前的RSA-2048加密算法在面对足够强大的量子计算机时将变得不堪一击（虽然量子计算机的出现预计还需要10到20年，但目前尚不确定）。一些机构已经在计划向后量子算法迁移。
实际应用结论：该系统能有效应对 95% 的实际 API 威胁。剩余的 5% 通常需要根据您的威胁模型采取额外的控制措施（例如速率限制、行为分析、IP 白名单、设备认证）。
当前基准测试中的性能权衡：
TLS 1.3 是 HTTPS 的最新加密标准，与 TLS 1.2 相比，会话建立速度提升 5% 至 9%，性能稳定性提升 11% 至 38%。在此基础上添加应用层加密会增加一些开销，但远低于旧系统。关键在于：加密如今已成为基本要求。现代系统应默认使用加密通信，而非将其视为优化问题。
实现密码敏捷性
鉴于到 2033 年我们将迎来后量子密码时代，如何避免架构锁定？
设计原则：使算法可插拔
不要在整个代码库中硬编码 AES 和 RSA，而是创建抽象层：
interface SymmetricEncryption {
String encrypt ( String plaintext, String key);
String decrypt ( String ciphertext, String key);
}
class AES256 implements SymmetricEncryption { ... }
class ChaCha20 implements SymmetricEncryption { ... }
interface AsymmetricEncryption {
String encrypt ( String plaintext, String publicKey);
String decrypt ( String ciphertext, String privateKey);
}
class RSA2048 implements AsymmetricEncryption { ... }
class MLKem implements AsymmetricEncryption { ... }
你的 API 层并不关心使用哪种算法。随着新标准的最终确定，你可以随时切换实现方式。
版本控制和协商：
请求头中需包含一个crypto_version参数，用于指定您使用的算法集。服务器可以在过渡期间同时支持多个版本。到 2030 年，您一定会庆幸拥有这项基础设施。
监测与检测
加密会在传统监控中造成盲点。您无法看到流经 API 的数据。这意味着您需要不同的检测策略：
- 流量异常：检测来自异常 IP 地址或用户帐户的 API 调用突然增加的情况。时间戳验证可防止重放攻击，但来自新来源的协同请求可能表明凭据已被盗用。
- 签名失败：记录签名验证失败的情况。签名失败次数激增可能表明存在攻击或客户端配置错误。这种情况应触发警报。
- 解密失败：如果请求在通过时间戳和签名检查后仍然无法解密，则可能表明客户端存在漏洞或数据被篡改。无论哪种情况，都值得调查。
- 请求速率限制：实施基于用户和基于 IP 的速率限制。在 API 文档中明确规定限制条件。OWASP API 安全 Top 10 将不受限制的资源消耗列为关键风险——限制请求速率是一种简单的防御措施。
- 行为分析：基于合法流量训练的机器学习模型可以检测异常情况——例如不寻常的参数组合、异常时间的请求以及与用户历史记录不符的访问模式。这一层可以捕获通过加密验证的攻击。
成本效益的现实
实施该系统需要工程方面的投入：
- 密码库集成与测试
- 跨 Web、移动和桌面平台的客户端实现
- 服务器端验证逻辑
- 关键管理和轮换程序
- 文档和开发者教育
对于大多数应用程序，尤其是那些处理敏感数据（医疗保健、金融、个人信息）的应用程序而言，这项投资是合理的。而仅仅依赖 HTTPS 则会使应用层漏洞暴露在外，无法得到有效防御。对于低风险 API（无需身份验证的公共数据），更简单的方法就足够了。
结论：从理论到生产
API 数据加密并非纸上谈兵，而是抵御当今真实攻击的切实有效手段。金融科技行业已在数十亿笔交易中对这些模式进行了实战检验。OWASP API 安全十大漏洞始终将授权和身份验证失败列为首要问题——这并非因为这些概念新颖，而是因为实际应用仍存在不一致之处。
查看原文：《生产级 API 加密的构建实用指南（从owasp开始）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论