CDN劫持检测app是一款非常不错的页面广告代码检测拦截服务软件,直接使用该软件输入网址,浏览网页;发现广告,上报劫持;操作简单又实用,需要的可以下载CDN劫持检测app使用!
(下载地址自行搜索解决)
下面是防劫持思路
1.采用https协议加密请求
2.隐藏http请求的特征,例如使用对称加密算法加密整个url。
https可以说是防止劫持的终极思路,但是https多了ssl握手的过程,会耗费一定的时间和性能。必须要考虑到时间影响和CDN节点的性能影响。另外https一般分为两种,一种是传统https(合用证书),一种是https sni。
目前的主流是https sni,但是市面上还残留着一些老旧版本的浏览器,因此再选用的时候务必确认好具体的业务需求。
URL加密也是经常用来防止劫持的做法。市面上的各大手机应用商店都采用了这种做法。相较于https,url加密的兼容性更好,并且对CDN节点带来的解密额外负担可以忽略。但是url加密需要CDN节点的密切配合。
一般的做法是选中一种对称加密算法,调用加密后的url。用户向CDN节点发起请求,CDN节点会解密url,获取真实的url并且响应给用户。由于劫持方一般通过对url进行匹配决定是否进行劫持,因此这种url加密的方式也可以很好的防止劫持。
3. CDN提供商内部防劫持
CDN提供商一般会将直接提供给用户请求访问的节点称为边缘节点。但大多数CDN的边缘节点并非直接就回源机了,一般会有中间层,如果回源压力较大的话,可能会有多级中间层。
CDN提供商内部的劫持便是指发生在边缘节点到各级中间层之间的劫持。由于CDN提供商内部一般采用自建DNS回源,不会使用运营商的本地dns,基本不会存在dns劫持的情况。因此要考虑的主要是http劫持这块。并且由于劫持的内容可能会被缓存到cdn节点,进而导致访问这个CDN节点的用户都被间接劫持,因此CDN提供商内部发生的劫持影响范围更广,更加严重。
各家CDN提供商内部的防劫持方式各部相同,CDN内部完全可以打隧道,私有协议加密以及https加密各种方式来防止劫持。
一般比较常用的也是https加密,比较简单高效。至于url加密要考虑到缓存共享,并且加密的url一般是定期变化的,如果直接缓存加密的url的话会浪费缓存空间,降低命中率导致用户体验下降。当然也可以用户到CDN节点解密下,CDN节点回源加密下,但是会增加复杂度。
4. CDN提供商回源防劫持
处于安全性和灵活性的考虑,较大厂商的CDN源机一般是选择自建,而不是完全托管在CDN厂商。尤其是源机要防止一些代码特殊处理的时候。
因为CDN频道具体回源的IP都是CDN厂商后台配置,走内部DNS。因此CDN提供商回源机这块也几乎不存在dns劫持。
而http防劫持的方式也与CDN提供商内部房劫持类似。最简单可行的方式也是https,源机变动的较小。当然CDN提供商也可能提供其他的一些防劫持方案,需要源机进行一些配合修改之类。
5. 检测HTTP劫持的方法
在维护CDN过程中,确认http劫持的方式较为简单。可以直接请求测试,观察响应header,响应内容以及CDN节点的日志,三者对比基本就可以确定。
但是确认到劫持后,如何收集更多的证据,跟正确的运营商管局保障则比较麻烦。因为从用户到最终的目的服务器中间经过了很多跳的路由节点,任何一跳都有可能被劫持。
没有明确的证据,各省的运营商可能相互之间互相推诿,最终报障无疾而终。
其实结合网络层的TTL字段,我们可以大致判断出来劫持是发生在哪两跳路由之间。
正常情况下数据包初始发出的时候为了防止ip包在网络中的无限循环,会定义一个ttl,即最大路由转发次数。每经过一跳,该跳就会将ttl的值减一,如果ip包在到达目的ip前,ttl减少为的话,就会被路由丢弃掉。
我们基于上面的原理,可以发送一种特殊的http请求包,我们设置从ttl为1开始发送请求,然后逐渐增加。正常情况下终点跳前不应该有响应的,但是如果还未到达目的服务器这一条,就已经有响应了。我们就可以根据设置的ttl大小,结合mtr/tracert路由信息判断劫持发生的具体位置。
http_hijack_check检测工具:https://github.com/zhxiaom5/http_hijack_check
6. 总结
在用户通过CDN下载资源过程中,各个阶段都有可能发生劫持,要做好防劫持,必须各个阶段都有所准备,而不仅仅是用户到CDN节点这一段。
对于DNS劫持,比较有效的方式是随机域名和HTTPDNS。
而对于HTTP劫持的话,则可以采用URL加密以及HTTPS来处理。
在线上环境中必须考虑业务的实际需求,综合考量,搭配多种防劫持方式来取得最好的防劫持效果。