关于新浪视频随机被Chrome等浏览器汇报为钓鱼网站的分析

无聊研究了下为什么最近新浪视频会随机被Chrome报为钓鱼网站(导致A/B站这类引用视频源的站点也出现被封的信息)。

看来是新浪有一堆文件服务器提供下载与视频服务,但由于它们并不按服务类型分类,导致类似119.147.148.21等IP上除了提供视频文件外,还存在大量病毒文件(大多通过新浪文件分享服务上传,也有来自合作伙伴的文件)。最终导致新浪服务器部分IP的整体评分过低,被列为不安全域名。

至于为什么是随机发生,则是与新浪视频获取一段视频时转跳的方式有关,一般是先访问edge.v.iask.com然后转跳到特定的IP下。如果中彩到了Chrome认为不安全的IP上,自然就会出现警告了。

有趣的是,119.147.148.21的低评级似乎与域名d3.brcdn.cn密切相关,而它属于一家叫做宝软网的网站(baoruan.com,这大概也是为什么叫brcdn吧)。检查whois发现这家网站居然还由ns1.sina.com.cn负责解析,而它背后的注册人[email protected]手里似乎也有一大堆乱七八糟的钓鱼域名。新浪和这家厦门公司之间的关系有待挖掘。

值得一提,不同浏览器对待同样这个有“钓鱼嫌疑”的IP处理方式并不同。例如Firefox直接访问d3.brcdn.cn(转跳到119.147.148.21)会报错,但访问视频文件的链接并不会阻拦。而Chrome则是整个IP都黑名单了。

估计在Chrome修改评分算法或新浪修改文件服务器内容之前,这事还没完。

更新 2014-01-08:获得消息后,新浪技术人员从他们的CDN移除了这台服务器(可能还有别的服务器有类似问题,请自行汇报)。

更新 2014-01-11:在新浪人员自称服务器已经下线的今天,我仍在bilibili收到来自上述IP的警告。于是我蛋痛进一步调查了下(数据通过Fiddler收集,因为Chrome dev tool的网络收集有bug,会错过一些Flash发出的请求).

如图所示,首先可以确认的是,新浪并没有把这个IP给停用,之前列出的病毒软件地址依旧能访问,视频cache也会可能转跳到该IP上(尤其当那个IP被认为是速度最快的CDN节点),也是红屏警告继续存在的理由之一。

然后是B站的行为模式,所谓的黑科技,也就是secure.bilibili.tv下的独立播放器页面,目前会随机寻找两种不同的播放器(但外观看起来完全一致)。

  • 一种是他们和乐视云做的视频cache,acgvideo.com,播放器放在乐视云上,视频源也转存到自己的服务器上。
  • 另一种使用本地的播放器,转载up主(也可能是系统自动)发到新浪视频上的源(edge.v.iask.com,转跳CDN)。

值得一提,他们对优酷/土豆是有特别处理。例如说山本宽的Wake Up, Girls,本季是由优酷和土豆做正版授权放送,但由于这两个站点明确拒绝B站引用视频,所以进入黑科技页面依旧会随机选用上述两个视频源。

这就解释了我之前的疑问:为什么我明明在看优酷/土豆的源,却会随机弹出新浪IP被封的警告。答案是,B站没在用优酷/土豆的源(但是用了他们的视频)。

至于解决办法,我实在看到太多新手说到Chrome里“禁用恶意软件保护”。这样做只会让你的浏览器变得不安全。合理的做法是——

  • 去正版放送的视频源上看,肯定不报错。
  • 在红屏时,直接点击那个不起眼的“高级”链接,然后就有暂时无视这个警告的选项了(Firefox也有类似选项,只是字更小罢了)。

Author: 店长

The Master of BitInn

10 thoughts on “关于新浪视频随机被Chrome等浏览器汇报为钓鱼网站的分析”

  1. 火狐安卓版,直接访问上面的视频文件链接也会被阻拦
    很奇怪,安卓版跟电脑版的黑名单不一样

  2. 这个是sina躺枪吧。。。

    之前为了抓B站视频写下载器简单看了一下这个CDN边缘是怎么来回跳的。

    sina应该(99.99%)用了网宿(ChinaNet)的CDN。他们的CDN节点遍布全球,相当适合sina视频这种网站,而且技术积累也相当不错。

    举一个实例:

    无论是谁(A/B/sina自己)解析视频真实地址(vid->URL)。得到了这个地址,估计是网宿CDN的边缘地址:
    http://edge.v.iask.com/123557717.hlv?KID=sina,viask&Expires=1389283200&ssig=uoYS0MDSlU

    然后发送GET,收到一个302,转到:

    http://edge.v.iask.com.lxdns.com/123557717.hlv?KID=sina,viask&Expires=1389283200&ssig=uoYS0MDSlU&corp=2
    (lxdns.com ,名字用了龙讯,其实就是网宿旗下的。进入系统,等待分配最优主机)

    继续GET,又是一个302:

    http://120.39.183.37/edge.v.iask.com/123557717.hlv?KID=sina,viask&Expires=1389283200&ssig=uoYS0MDSlU&corp=2&wshc_tag=0&wsiphost=ipdbm
    (这是最后的地址了,东西就在这台服务器上。)

    估计是,由于获取内容并不通过域名检验来源,而且为了省钱,网宿并没有使用大量IP地址,不会像Cloudflare或Google一口气就包整个C段啥的。

    但是,由于CDN并不关心传输了是什么东西(业务上会分,服务器有优化,但是并不关心具体内容),这个IP在复用的时候,被某钓鱼网站摊上了。在举报后,Google直接将所有到这个IP的连接都扔进了黑名单。但是CDN在分配节点的时候不知道,于是所有在上面来回跳转后遇到黑名单IP的人都躺枪了。。。

    解决办法:

    1)网宿预先审查将分发的内容,将钓鱼站清理出去,同时找Google说明情况。肯定治本。
    但是我不喜欢审查。。。作为基础服务提供商,我认为其审查网络内容是很不明智的,同时也是对互联网信息自由流动的侵犯。
    或者
    2)网宿向Google报上自己所有的IP段,要求白名单处理。听起来很奇怪,但是既然Cloudflare没听说过这种现象,那么肯定是有过什么协商。Cloudflare上面的钓鱼站更多,但是没听说他们的IP被黑名单。
    也能一劳永逸,毕竟作为中国最大的CDN,网宿是可以与国际顶级CDN,例如Akamai,Amazon Cloudfront等齐名的大公司。

    至于普通用户:
    顺手点一下“举报误判”,人多了,Google自然会发现不对劲的。

    无辜躺枪的A/B站:
    A站。。。不评论
    B站。。。不是有自己的CDN么?用自己的CDN顶上吧。

  3. 最近看新浪的时候nod32也会报警,通知里只记得iask,我原来以为是和盗版文档之类的有关,看了这文章大概也是同样的缘故?

Comments are closed.