请求参数加密是否有意义？

最近新项目处于测试后期，已经给公司的诸多领导进行了演示，得到了一些调整建议和优化方向。其中有一位“懂技术”的领导说，你们请求的参数都写在了url里，这要是被有心之人看到，客户的数据就不安全，而且我在看你们网站的时候，按F12就能看到你们所有的请求参数，尤其是账号登录的时候，账号密码都能看的清清楚楚，这太危险了…给你们提个建议，所有的参数都要做加密，前端把数据加密后发给后端。这样可以保证系统的安全性，其他领导听了之后差点鼓掌，就按X总的说的，赶紧去改…
最后的结果是为数不多的测试时间还要去弄加解密。害~

虽然领导的担忧是出于对数据安全的重视，但他的观点可能存在一些技术上的误解。

1. HTTPS 已经确保了数据传输的安全性

  • 关键点 ：HTTPS（HTTP over TLS/SSL）已经对传输层进行了加密，确保了数据在传输过程中不会被窃听或篡改。

  • 详细解释 ：

    • HTTPS 使用 TLS/SSL 协议对客户端和服务器之间的通信进行加密。

    • 即使攻击者能够截获网络流量，也无法解密 HTTPS 传输的数据。

    • 虽然通过浏览器开发者工具（F12）看到请求参数，这些参数在传输过程中是加密的，不会泄露给第三方。

2. 浏览器开发者工具（F12）显示的是本地数据

  • 关键点 ：浏览器开发者工具（F12）显示的是客户端本地的请求数据，而不是网络传输中的数据。

  • 详细解释 ：

    • 浏览器开发者工具显示的是浏览器在发送请求之前或接收响应之后的数据。

    • 这些数据在传输过程中已经被 HTTPS 加密，攻击者无法通过网络截获。

    • 如果攻击者能够访问用户的设备并打开开发者工具，那么安全问题已经超出了网络传输的范畴。

3. URL 参数的安全性

  • 关键点 ：URL 参数在 HTTPS 下是加密的，但确实存在一些潜在风险。

  • 详细解释 ：

    • HTTPS 加密 ：URL 参数在传输过程中是加密的，不会被中间人窃听。

    • 浏览器历史记录和日志 ：URL 可能会被保存在浏览器历史记录、服务器日志或第三方引用中，导致敏感信息泄露。

    • 解决方案 ：

      • 对于敏感信息（如密码），应使用 POST 请求并将参数放在请求体中，而不是 URL 中。

      • 对于非敏感信息，URL 参数在 HTTPS 下是安全的。

4. 加密参数的额外成本

  • 关键点 ：对请求参数进行额外加密会增加开发和维护成本，且收益有限。

  • 详细解释 ：

    • HTTPS 已经足够 ：在大多数场景下，HTTPS 已经能够提供足够的安全性。

    • 额外加密的局限性 ：

      • 加密和解密过程会增加前端和后端的计算开销。

      • 密钥管理会增加复杂性，如果密钥泄露，安全性反而会降低。

    • 适用场景 ：

      • 对于极端敏感的数据（如支付信息），可以考虑额外加密。

      • 对于大多数场景，HTTPS 已经足够。

5. 总结

  • HTTPS 已经足够 ：在大多数场景下，HTTPS 已经能够确保数据传输的安全性。

  • URL 参数的局限性 ：URL 参数可能会被记录在浏览器历史记录或服务器日志中，因此不适合传输敏感信息。

  • 改进方案 ：将敏感信息放在请求体中，并使用 HTTPS 加密传输。

  • 建议 ：如果你的领导也提出了这样的需求，拿这篇文章怼他。