当前位置:网站首页>论文阅读:The Chain of Implicit Trust: An Analysis of the Web Third-party Resources Loading
论文阅读:The Chain of Implicit Trust: An Analysis of the Web Third-party Resources Loading
2022-04-21 06:35:00 【就叫昵称吧】
文章目录
The Chain of Implicit Trust: An Analysis of the Web Third-party Resources Loading
1 背景&目的
web是一个互相连接的服务的复杂集合,网站从各种第三方(例如广告、跟踪、分析服务,CDN等)导入一系列外部资源。而后者,即第三方也会从其他域名处加载资源。因此对于每个网站来说,这创建了一条依赖链,由第一方和传递连接的第三方之间的隐式信任形式为基础。
本文就从这个依赖链出发,对网络中的依赖链进行了大规模的研究
2 相关概念
网站会从大量的第三方域名加载资源,例如广告、跟踪服务等。而第三方还会从其他域名加载资源,因此就有以下概念:
- 依赖链(dependency chain):第一方引用第三方域名,而第三方又额外加载其他域名上的内容,这样便构成了一条依赖链
- 显示信任(explicit trust):第一方与其直接引用的第三方构成显示信任关系
- 隐式信任(explict trust):第一方与第三方额外引用的域名之间构成隐式信任关系
例如bbc.om,它从widgets.com加载了JavaScript代码,而这个代码执行时,又从ads.com加载了额外的内容,这时候bbc.com就是第一方网站,它显示信任widgets.com,隐式信任ads.com。在依赖链中,widgets.com可以表示为第一层,ads.com可以表示为第二层。
第一方网站在域名依赖链下加载的资源上缺乏可见性,会导致安全问题,例如DDoS攻击或勒索活动。
本文将第三方域名分类为良性的和可疑的两类。
3 数据集
3.1 数据收集
使用基于Chromium的无头浏览器爬取Alexa-top 200K的网站,可以根据网络请求跟踪资源的依赖关系。第一方可能会触发多个依赖链,也就是说形成树的结构,本文的第三方请求识别方法是对比二级域名,如果二级域名不一样就考虑为第三方。而子域名则不考虑是第三方。本文使用Mozilla Public Suffix和tldextract来消除网站子域名和country-specific子域名之间的歧义(例如player.bbc.com和bbc.co.uk)。
最后得到11287230条URL,其中包含6806494个不同的外部资源,对应68828个第三方二级域名和196940个第一方二级域名。
3.2 数据丰富
本文使用了VirusTotal提供的对第三方URL进行了检测,目的是为了找出恶意的内容。还收集域名的WebSense类别(VirusTotal记录API提供的),同时消除依赖链中的无效URL,最后收集到的是196940个第一方网站,以及68828个第三方域名
4 信任链
4.1 网站是否依赖隐式信任?
第一方加载的外部资源中位数是27个。下标展示了在每个Alexa排名区间的网站加载显式和隐式信任第三方的百分比。

95%的网站都会加载外部资源,91%的网站加载外部JS代码。50%的网站确实依赖隐式信任。在更受欢迎的网站中,形成依赖链的倾向略高一些,换句话说即是,越流行的网站越是倾向于更多地依赖隐式信任的第三方。
隐式信任的第三方会出现在链中的各个位置,下图展示了所有第一方网站链长的累积分布函数(按照第一方网站类别进行划分)

80%的网站依赖链长度都不超过3,但是每个类别的网站大概都会导入2%的超过3级及以上的外部资源。极端例子还有包含38层的链长
4.2 链中存在着哪些对象?
本文对资源进行了分类,分为4种主要类型。
- Image
- JavaScript
- Data(包括HTML、JSON、XML、plain text files)
- CSS/Fonts
下表展示了4种资源类型在每一层上的数量分布情况

本文检查了托管这些资源的第三方域名的类别,下图展示了链中每一层第三方类别的构成。

可以看到无论是哪一层,广告占比都是最多的
5 可疑链
5.1 链中是否包含可疑方?
下表显示了使用几个VTscore阈值将第三方分类为可疑的第三方的比例。保守认为VTscore为10的是可疑的。

16%的第一方隐式信任了可疑的JS。
5.2 可疑方有多普遍?
下图展示了每个第一方引用的第三方资源的累积分布函数,24.8%的第一方页面包含了至少3个被标记为可疑的第三方。

即使只有1.6%的第三方被标记为可疑,但是他们至少分散到了三分之一的网站中。下标展示了top10提供可疑js的第三方

有趣的是google-analytics.com,调查发现它是因为加载了一个叫sf-helper.net的第三方,这个第三方分发adware和spyware,后来2018年9月发现这个域名已经不再加载了,下图展示了google-analytics.com变好之后累积分布图

这有效地突出了高中心性第三方被允许加载更多资源的影响:一个网站的感染可以立即影响大部分网站。
5.3 可疑第三方有多流行?
流行是指Alexa的排名。本文发现有几个可疑第三方排名在top 100内。
下图展示了第一方域名(根据Alexa排名)引入的可疑js代码数量,可见第一方域名在大于2层的时候引入了很多可疑js。

下图展示了由可疑第三方(根据Alexa排名)导致而受影响的第一方域名的数量。

这些发现表明,各种第三方恶意JS内容是来自各种,不一定是“模糊”的第三方域名。
5.4 可疑第三方一般在哪一级存在?
下表展示了加载了至少一个VTscore大于10的网站的比例。
大多数被分类为可疑的资源位于依赖链的第1级,它们被第一方显示信任。这表明网站运营商并没有完全监控他们的第三方资源。更重要的是,可疑内容会通过隐式信任导入。在这种情况下,第一方可能不知道他们的存在。
下图显示了在每一层每一个可疑第三方网站类别的分布。

下图显示了专门针对可疑JS资源的域名类别的细分。

6 总结
本文发现超过40%的网站确实依赖于隐形信任,本文发现了一些不常见的隐式信任第三方。这可能会增加攻击面
版权声明
本文为[就叫昵称吧]所创,转载请带上原文链接,感谢
https://blog.csdn.net/qq_39378221/article/details/114583332
边栏推荐
猜你喜欢
随机推荐
NP, OSPF route aggregation
IGMP_华为
类和对象的相关知识
龙讯系列视频转换,LT9211、LT8918,功能:lvds转BT656,lvds转mipi(CSI\DSI)RGB转MIPI(DSI\CSI) BT656\601\1120转HDMI1.4\DVI
Blue Bridge Cup -- sequence sequencing problem
Convergencewarning: Free failed to converse, increase the number of iterations Solutions
【网络协议】为什么要学习网络协议
关于平衡二叉树
PIM-DM
Clock IC, ins5101a, I2C low-power RTC real-time clock chip, replace hym8563, replace (NXP) PCF8563, tcs8563, I2C low-power RTC real-time clock chip
Use the security vulnerability detection tool Metasploit to lift the telnet login right of the target metasploitabile2
Using Wireshark to restore pcap data stream to picture file
【C#】单例模式的实现方案
Solving 0 / 1 knapsack problem by dynamic programming
OSPF多区域
策略模式(2.28-3.6)
NP and OSPF default routes
NP, OSPF virtual link
Ruiyuan ry8132 and ry9140 DCDC are mainly replaced by tps563200 and tps563201 of Ti, mp1471 and mp1653 of Xinyuan, and details of sy8104 power chip of silijie
Detailed explanation of the whole evolution process and architecture design of large websites









