https防止中间人攻击？

Question

在客户端受信任中间人证书的情况下，https请求如何防止中间人攻击？

目前我使用Fiddler抓包工具生成证书并信任，可以抓到https响应内容的

Answer 1

SSL Pinning 就是专门应对这种攻击的，简单来说就是服务端与客户端约定好只用什么证书，客户端拿到响应后看看它的证书是不是之前约定好的，如果不是就当作不认识丢弃报错

Answer 2

我之前做过这种功能，我是后端Java,前端是JS (微信，支付宝，百度小程序，APP,web端口)

简单思路如下：
1.前端和后端约定一个密钥的生成方式
最好是通过单次请求上的，Header内容,请求参数，响应内容中的某些字符生成

2.选择一种对称加密方式（非对称也行，看你）

3.后端响应写到前端前，对响应报文加密,使用步骤1的密钥(后端响应拦截器实现)

4.前端接收到响应，解析数据前先解密,使用步骤1的密钥(前端响应拦截器实现)

通过以上步骤：

• 在浏览器的开发者工具里，响应报文就是加密的，一串密文
• 抓包后得到的也是一串密文

除非这个人有密钥，否则以上两种方式的响应内容他解不出来

不能避免：

• 这个人通过debug前端源码的方式得到解密后的文本
• 通过脚本注入的方式得到原文，例如油猴插件等脚本将代码注入到前端解密操作的函数调用后

关键点(难点):

• 如果算出这个密钥？

  首先，密钥不能通过请求网络传输，因为请求的这个接口人家就能抓包，直接得到密钥
  其次，你的密钥要定期变化，不能写死。否则得到一次，后面全暴露了
  我当时是根据请求头里面的一些固定header的内容加上固定字符串编码得到的，里面加了版本号，每次发布大版本前，改掉版本号，这样可以新旧兼容，也能定期自动更新

• 报文加密算法怎么选？

  我当时是AES加密算法，对称加密,只有一个密钥（偏移量写死的），如果是RSA这种非对称加密，第一步生成密钥对，难度加大，当然被破解难度升高

• 解密的拦截器和密钥生成算法怎么保证安全？

  因为前端的代码是可见的，包括小程序，攻击者直接就能拿到源代码，代码都有了，人家就能写出来
  我当时的办法是，前端JS源代码混淆,类似这种 https://www.jsjiami.com/

• 如何动态按照接口加密

  对项目中所有接口加密确实更安全，但是有例外 ，而且影响性能，尤其是大数据接口
  我当时是黑名单机制，不加密的接口拉黑，维护在后端，前端5分钟拉取一次
  针对文件下载类，二进制流式接口，GIZ响应压缩等都要单独处理，加密只能针对文本响应类接口

• 团队内部保密?

  我们当时有一个小伙，觉得这些代码有学习的价值，离职前将代码上传到github,人走了，后来被攻击者发现,系统遭到攻击，我们报警后，查到这个人，领导私下联系让删除了, 连夜更新了大版本号

除了上面不能避免的两点，配合上HTTPS，基本问题解决了。

Answer 3

你客户端都受信任了,其实就相当于你告诉了银卡卡密码了。他肯定能看到你的响应内容的，但是如果通过某些加密算法将请求与响应内容进行加密，或者请求进行加签，进行重放、防篡改策略，他就算能看到具体请求内容，也不能直接分析请求和使用请求了

Answer 4

证书钉扎（Certificate Pinning） 通常是最有效的做法。原因如下：
1.直接验证： 证书钉扎将服务器的公钥或证书直接嵌入到客户端应用中，这意味着即使中间人伪造了证书，客户端也会因为证书不匹配而拒绝连接。
2.防止伪造： 即使中间人拥有受信任的中间人证书，由于客户端只信任预先嵌入的证书或公钥，伪造的证书将无法通过验证。
3.提高安全性： 这种方法可以显著提高安全性，特别是在移动应用和高安全性需求的场景中。
不过，比如证书更新时需要更新客户端应用。在实际应用中，需要结合其他方法，如双向认证和使用最新的TLS版本，以确保全面的安全性。

Answer 5

我写爬虫的，只要是请求，想抓包肯定是都可以抓到的，问题不在你服务器端，而在客户端，客户端向服务器端发送请求会经过抓包软件，所以是没有办法避免的,但是可以对重要数据加密