苏州做网站的哪个公司比较好,可以接单包工的平台,公司网站做的太难看,铜陵网站建设价格前言 最近在前端异常监控系统中#xff0c;发现一些异常信息#xff0c;从中做了一些分析#xff0c;得到一些体会#xff0c;因此作文。
发现异常 某天早上打开监控系统发现#xff0c;当天凌晨1点过测试环境有2个前端上报的异常#xff0c;报错的原因都是由于没有获取…前言 最近在前端异常监控系统中发现一些异常信息从中做了一些分析得到一些体会因此作文。
发现异常 某天早上打开监控系统发现当天凌晨1点过测试环境有2个前端上报的异常报错的原因都是由于没有获取到 url 中的参数比如正常的地址应该是 www.xx.com?a1b2, 但是实际访问的是 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 中内嵌一些 h5h5 的参数中需要带上一些识别身份的 token。 如果说、我们没有使用 https黑客在中间层监听了我们的请求就能获取到我们的数据甚至对方万一得到了 token还能获取更多我们的隐私信息。 这就给重放攻击提供了安全漏洞。 那么防御重放攻击有什么办法呢 常用的办法有两种 1加随机数保障只被使用一次但是需要额外空间存储历史使用过的值 2加时间戳不用额外保存信息但是需要同步时间但同步时间并不能达到各种情况下的准确。 总之大概方向就是需要一个参数来判断是否失效。 为什么 https 保障安全 网上文章很多这里就不做一一解释了简单说两点https 利用非对称加密和对称加密、保障数据安全利用数字证书做双向身份校验、保障不被钓鱼。 抓包工具为什么能抓取 https 以前知道抓包工具通过一定配置就能抓取到 https 请求这样一想那 https 是不是就不安全啊抓包工具都能拦截到。 首先我们需要先了解它的原理才能做下一步分析。 抓包工具抓取 https 的原理是利用抓包工具做中间代理人和客户端建立信任连接以后再代客户端去向服务端发送和接受请求达到中间商的效果这样抓包工具既能看到数据客户端也能正常使用。
以下是抓包工具抓取 https 的流程拷贝的他人的总结也不知道最初是谁写的因为网上太多同样的了作者勿怪无法署名 客户端向服务器发起HTTPS请求 Charles拦截客户端的请求伪装成客户端向服务器进行请求 服务器向“客户端”实际上是Charles返回服务器的CA证书 Charles拦截服务器的响应获取服务器证书公钥然后自己制作一张证书将服务器证书替换后发送给客户端。这一步Charles拿到了服务器证书的公钥 客户端接收到“服务器”实际上是Charles的证书后生成一个对称密钥用Charles的公钥加密发送给“服务器”Charles Charles拦截客户端的响应用自己的私钥解密对称密钥然后用服务器证书公钥加密发送给服务器。这一步Charles拿到了对称密钥 服务器用自己的私钥解密对称密钥向“客户端”Charles发送响应 Charles拦截服务器的响应替换成自己的证书后发送给客户端 至此连接建立Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥之后就可以解密或者修改加密的报文了 所以前提是客户端需要选择信任并安装 Charles 的证书否则抓包工具也无法拦截 https在互联网上大部分恶意脚本程序想要抓取用户数据也大都是和抓包工具一样的工作原理所以 https 还是比较安全的。 未使用 https 记得以前公司还没使用 https 的时候可能大家都经历过恶心的流量劫持我们自己在线上环境使用都挺正常的时不时其他地区的同事会告诉我们说页面上漂浮了一个按钮点开就跑到其他地方去了。 甚至说有些注入的代码有问题导致我们的界面也出现了问题当时各种研究后最后的办法就是上 https 到现在就再也不用担心这个问题了。 现在一些浏览器访问非 https 的页面都会提示不安全平时也看得到一些他人的网站都还是没用 https进去就会报警告。 也如我们发现的重放攻击这些安全问题确实存在于网络中甚至无人能避免所以没用 https 的站点还是快点升级吧
