前言

　　最近在前端异常监控系统中，发现一些异常信息，从中做了一些分析，得到一些体会，因此作文。

发现异常

　　某天早上打开监控系统发现，当天凌晨1点过测试环境有2个前端上报的异常，报错的原因都是由于没有获取到 url 中的参数，比如正常的地址应该是 www.xx.com?a=1&b=2, 但是实际访问的是 www.xx.com%3Fa%3D1%26b%3D2。 很明显路径被 encode 了，导致程序没有拿到参数。

　　2个异常的访问路径是不一样的，并且以上2个地址  decode 之后再访问，能够正常打开页面，参数全部都是正确的。 这些访问的 url 是我们在做跳转的时候，入口配置的，我们的逻辑中不会 encode，这个地方非常让人疑惑，为什么会出现这样的请求，猜测很可能是人为修改了再访问的。 后来把参数获取出来，去查询一些信息，发现这条请求是都来自于我们的测试同学的账户，但是私下询问过，1点过同事根本什么都没有做。 也排除了有其他人用他手机访问的情况。 再对参数里的信息做查询，发现这2个参数对应的数据是在2个多月前，我们项目测试阶段的数据，这就更奇怪了，2个月前的版本我们已经没有再测试了，同事也很久没有访问过这几个入口。 是不是有人在刷我们的页面，但为什么几个参数都是如此精确，都是正确的。 

　　一定有其他人在访问。因为各方面情况看起来都很不正常：

　　　　1. 凌晨1点过访问的

　　　　2. 访问路径被 encode 了

　　　　3. 数据是测试同事的，他自己却没有访问过。

　　　　4. 访问的地址的数据都是2个月前生成的，如果有三方黑客获取到了访问记录之后，延迟到最近批量访问也符合行为逻辑

　　再看看上报的其他异常信息，更奇怪了，浏览器的版本无从得知，User-Agent 只有 Go-http-client/1.1 ， 怎么看都像是爬虫脚本在做请求。 说到爬虫，爬虫一般会针对已知的接口进行数据拉取，以获取他人的信息； 又或者不停的遍历不同的路径，查找可访问的路由（隐藏的后门），路径遍历很容易发现，如果有日志的话，就能看到很多 404， 大量的访问一些奇怪的路径。 那我们遇到的，是前期通过某种方式拦截到我们的网页请求，收集起来，到一定时间再去访问，这种方式叫做：重放攻击。

　　我们在服务器又查询了 IP 等一些相关的信息，发现有几个 IP 时不时的在做这样的访问攻击，而且也看得出对方很谨慎，没有同时做大批量的请求。 又发现了更多的异常行为，首先比如一个 www.x.com/page 的页面路径，它使用 post 方法去请求了一次。 

　　所有的异常数据，被访问的路径都是测试环境的地址，使用的 http，而我们的正式环境使用的 https，对方似乎并没有能力获取到 https 的请求。 通过查询这几个 IP 在正式环境访问，又发现了一条记录，而刚好这条记录的访问地址没有 https（因为有时候，我们的开发自己可能会手动把 https 改成 http 去访问）。  到目前的结论是黑客方的监听是和我们的项目环境没有关系的，只是因为我们正式环境使用了 https 他才没有获取到。

　　最初以为只是一个同事的手机被监听了，但是因为又出现了另一个同事的请求，所以觉得爬虫在路由器层拦截的概率更大，而且刚好这两个同事有一个用的是安卓，有一个用的是苹果，所以看起来所有的设备都有命中的可能。 但是如果是公司路由器的问题，那为什么目前为止就只发现了两个同事的访问被爬取了，这些网页其他同事也都访问过，而且频率也不低。 对方的策略具体是什么，到底在哪里拦截的，我有点束手无策了。 而后询问过另一个同事后，得知对方大概是在20多天前访问的，爬虫访问的记录全部集中在这几天。 种种迹象表明确实是前期收集了一段时间，这两天才开始出来集中访问的。

　　前面通过查询 IP，发现爬虫的服务器都在国内，但是对方也可能隐藏掉了真实 IP 。 如果对方的行为对公司造成了伤害，也许可以进一步去查对方服务器归属人。 但是因为从对方访问量和攻击程序来说，对我们几乎没有伤害。 甚至能感觉到对方不是定向要攻击我们。 看起来更像是对方的程序游离在互联网上，收集到了什么，就干点什么的意思。

安全问题

　　再来说说安全性问题，我们常常在访问 url 的时候，带上一些参数，比如在 app 中，内嵌一些 h5，h5 的参数中需要带上一些识别身份的 token。 如果说、我们没有使用 https，黑客在中间层监听了我们的请求，就能获取到我们的数据，甚至对方万一得到了 token，还能获取更多我们的隐私信息。 这就给重放攻击提供了安全漏洞。

　　那么防御重放攻击，有什么办法呢？ 常用的办法有两种

　　（1）加随机数保障只被使用一次，但是需要额外空间存储历史使用过的值；

　　（2）加时间戳，不用额外保存信息，但是需要同步时间，但同步时间并不能达到各种情况下的准确。 总之大概方向就是需要一个参数，来判断是否失效。

为什么 https 保障安全

　　网上文章很多，这里就不做一一解释了，简单说两点，https 利用非对称加密和对称加密、保障数据安全；利用数字证书做双向身份校验、保障不被钓鱼。

抓包工具为什么能抓取 https

　　以前知道抓包工具通过一定配置就能抓取到 https 请求，这样一想，那 https 是不是就不安全啊，抓包工具都能拦截到。 首先我们需要先了解它的原理，才能做下一步分析。 

　　抓包工具抓取 https 的原理是利用抓包工具做中间代理人，和客户端建立信任连接以后，再代客户端去向服务端发送和接受请求，达到中间商的效果，这样抓包工具既能看到数据，客户端也能正常使用。

以下是抓包工具抓取 https 的流程（拷贝的他人的总结，也不知道最初是谁写的，因为网上太多同样的了，作者勿怪，无法署名）

1. 客户端向服务器发起HTTPS请求

2. Charles拦截客户端的请求，伪装成客户端向服务器进行请求

3. 服务器向“客户端”（实际上是Charles）返回服务器的CA证书

4. Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）

5. 客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）

6. Charles拦截客户端的响应，用自己的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）

7. 服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应

8. Charles拦截服务器的响应，替换成自己的证书后发送给客户端

9. 至此，连接建立，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了

　　所以前提是客户端需要选择信任并安装 Charles 的证书，否则抓包工具也无法拦截 https，在互联网上大部分恶意脚本程序，想要抓取用户数据，也大都是和抓包工具一样的工作原理，所以 https 还是比较安全的。

未使用 https ？

　　记得以前公司还没使用 https 的时候，可能大家都经历过恶心的流量劫持，我们自己在线上环境使用都挺正常的，时不时其他地区的同事会告诉我们说，页面上漂浮了一个按钮，点开就跑到其他地方去了。 甚至说有些注入的代码有问题，导致我们的界面也出现了问题，当时各种研究后，最后的办法就是上 https， 到现在就再也不用担心这个问题了。 现在一些浏览器访问非 https 的页面，都会提示不安全，平时也看得到一些他人的网站都还是没用 https，进去就会报警告。 也如我们发现的重放攻击，这些安全问题确实存在于网络中，甚至无人能避免，所以没用 https 的站点，还是快点升级吧！