点击右上角【关注】发哥微课堂头条号，get更多相关技能~
引子：
上周拿到一个线上复测的项目，中间有一个明文传输问题，这个问题平时基本不记，客户那测试基本都是内网环境，上线基本都是 https。这个问题之前是这样测试的：抓包，如果内容是明文就记这个问题，这里存在很多的问题。
问题 1：线上环境 https 为什么抓到的包是明文
这个问题很容易搜到答案，原因在于 https 的加密是传输的过程，burp 拦截的数据包没有走到传输那一步，它只相当于拦截的浏览器的数据，相当于就是客户端。
https 抓包原理第一步，抓包程序将服务器返回的证书拦截，第二步，给客户端返回一个自己的证书，第三步，客户端发送的数据包程序用自己的证书解密，第四步，再用拦截的证书加密发送给服务器。
这就是为什么 burp 需要抓 https 的网站时，需要给浏览器导入自己证书的原因。这样，很自然的就会想到第二个问题。
问题 2：那明文传输问题应该怎么测
内网的测试环境基本不会 https，线上环境基本都是 https，如果有复测线上环境的情况，最简单的就是直接看 url 地址了，最明显不过。如果是 APP，没有 url 地址，那就直接抓包，可以使用 wireshark 抓包查看，如果嫌麻烦，直接到 burp 的 HTTP history 中查看 url 是否有 https 即可。
之前有一个误区，认为 burp 抓到的 https 包是乱码的，认为那就是 https 加密的结果。首先 https 加密后的内容，是在 burp forward 之后的，其次如果是 https 加密，消息头的内容也都是密文。如果之前有这样的误区，那么就会有第三个问题。
问题 3：burp 拦截的一堆乱码是什么
类似于上图，这个是因为编码的问题，其实它和图片上传拦截的数据包很像，那些乱码属于 application/octet-stream 类型，准确点应该是头部会有一个 Content-Type 字段值为 application/octet-stream。这个类型通常指二进制流，或者其他的一些文件内容，这些内容通常需要一些客户端打开，所以感觉 burp 还原几率很小。
图片中是有这个字段的，很多包是类似于这种乱码，但没有这个字段，是因为对于 tomcat 中间件，如果有未知类型的内容进行传输，则会默认使用 application/octet-stream 这种方式，这时候 burp 拦的就是那种乱码形式。
问题 4：关于修复问题
最终的修复方法还是使用 https。
之前看到的修复建议有写在前端使用 js 对敏感数据进行加密这种修复方式，严格来说，作用不是很大。假设有一个恶意攻击者发起了一个钓鱼 wifi，你连上了这个 wifi，去登录一个程序，这个程序对账号和密码进行了 js 加密，那么通过中间人拦截数据包后就不会显示明文，但作用并不大，其实还是相当于明文传输，把这个数据包发送服务器是没问题的，所以说作用并不大。
有人提出过类似的思路，js 加密敏感字段，后端接收值后在通过 md5 + 盐的方式进行数据库存储，那么对于后端来说接收的不管是明文还是进过 js 加密的密文，都是一样的，作用在于中间人拦包后获取不到明文，数据库被拖后很难还原密码这些。其实两端加密相当于没有加密。
但不能说前端 js 加密就没有用处，作用上一段说了，会起到一定的意义，例如支付宝不仅使用了 https，也使用了前端 js 加密，如下图：
所以，关于修复方法，必须使用 https，其次能结合前端 js 对敏感信息进行加密更好，如果业务要求高，像银行那样，可以同时使用客户端控件进行多重加密。
閱讀更多 發哥微課堂 的文章
