我应该担心跟踪银行网站上的域吗？

2o7.net
demdex.net
omtrdc.net

#1 楼

看起来主站点正在将来自Adobe Marketing Cloud的脚本直接嵌入到页面中。这些脚本是从与主站点相同的服务器上加载的，看起来这些脚本使用XHR与外部服务器进行通信，并根据uBlock Origin的日志从demdex.net和2o7.net下载新脚本。

尤其是在银行无法控制的情况下，从第三方加载和执行新脚本是一个巨大的安全问题。从本质上讲，这些脚本可以完全控制该网站，包括阅读您输入的内容，更改提交的内容或显示的内容等。这些实质上是跨站点脚本，只是确保它们不是偶然发生的，而银行站点的开发人员明确邀请了这些脚本。第三方进行跨站点脚本编写。

虽然在没有输入敏感信息的站点上接受第三方服务的使用是可以接受的，但无论何时传输敏感信息或意外地使用敏感信息，绝对不能接受网站内容的更改（例如显示不同的帐户余额），并可能导致访问者进行不必要的操作。

#2 楼

银行场所几乎是单块的。银行在整体解决方案中通常依赖于数十甚至数百个第三方系统。您可能有一个供应商提供的银行托管服务商，另外两个或三个供应商提供的信用卡解决方案，另一个供应商提供的登录解决方案，另一个供应商提供的付款解决方案。将这些站点组合在一起的工作非常艰巨。

银行站点在前端也需要第三方的参与也并不罕见。范围可能从仅用于呈现日历控件的第三方库到提供用户行为分析和风险决策的系统。这些供应商中有许多通过内容分发网络（CDN）提供脚本和内容，这意味着文件可能来自第三方域。

这危险吗？有可能。如果第三方资源未通过子资源完整性进行验证，则黑客（通过中间人）甚至第三方本身（例如恶意员工）都可能对其进行修改。因此，任何在线银行实施都将自己托管内容（即，将第三方文件复制并粘贴到其自己的Web服务器上），或者在某些情况下，通过integrity节点或script节点的link属性来表示带有加密哈希的内容引用外部文件。在其他情况下，它们将链接到CDN，但会在SRI检查失败的情况下向本地文件提供回退行为（请参阅此StackOverflow问题）。


我应该担心跟踪吗银行网站上的域名？


请务必注意，在欧盟，欺诈性交易的费用由该机构承担。因此，在线银行安全的主要任务是保护银行，而不是您自己。

无论采用哪种架构OP，都可以肯定它通过了几层风险评估和审查，并且决定使用CDN来提供某些内容并不是一件容易的事。他们可能已经正确实施了该协议，并使用了一些SRI手段。您仍然可以担心，但担心应该最小化。

#3 楼

机会很小，但这可能是真正的威胁。最近（2017年4月），发现大型波兰银行之一（mBank）上的跟踪脚本（Gemius）与其他（标准）跟踪数据一起发送账户余额。预期的效果可能是捕获了导航（页面标题/部分），因此泄漏本身可能是偶然的。