为什么Cloudfront在我的网络应用程序中加载脚本? (我不用它) [英] Why is Cloudfront loading scripts in my web app? (I don't use it)

查看:98
本文介绍了为什么Cloudfront在我的网络应用程序中加载脚本? (我不用它)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用广泛的jQuery管理安全的PHP / MySQL Web应用程序。今天,我们的应用程序日志中出现了一个奇怪的错误:

I manage a secured PHP/MySQL web app with extensive jQuery use. Today, a strange error popped up in our app's logs:

JS Error: Error loading script:
https://d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js

我们没有使用亚马逊的Cloudfront CDN在我们的应用程序当我转到无法加载的URL时,这些是唯一的内容:

We are not using Amazon's Cloudfront CDN in our app. When I go to the URL that failed to load, these are the only contents:

if(typeof _GPL.ri=='function'&&!_GPL.isIE6){_GPL.ri('_GPL_r')}_GPL.rl=true;

用户的用户代理字符串是:

The user's user agent string is:

Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

请注意:我不是触发此错误的用户。这是触发它的数千名用户之一。我无法控制客户端计算机。

Please note: I am not the user who triggered this error. It was one of our thousands of users who triggered it. I do not have control over the client machine.

有谁知道这里发生了什么?这是某种XSS攻击吗?

Does anyone know what's going on here? Is this some sort of XSS attack?

** 更新 **

看来我并不是唯一一个在他们的网站上发现过这种异常现象的人。我发现此报告具有相同的确切行为,这似乎表明代码是无害,但仍无法解答它来自何处。

It appears I'm not the only one who has discovered this anomaly on their website. I found this report of the same exact behavior, which seems to indicate the code is harmless, but still no answers as to where it came from.

此外,我发现这个类似代码的pastebin ,似乎是某种广告脚本。再次,并非十分有用。

In addition, I found this pastebin with similar code, that appears to be some sort of advertising script. Again, not terribly helpful.

** 更新2 **

更多上下文:webapp使用多个第三方jQuery插件,但没有任何第三方分析。所有脚本都托管在我们自己的服务器上,对我们所有代码的审核都没有为cloudfront提供匹配。

More context: The webapp uses several third party jQuery plugins but no third party analytics of any kind. All scripts are hosted on our own server, and an audit of all our code provides no matches for "cloudfront".

此应用程序已投入生产约4年,这是这样的任何活动的第一个也是唯一一个实例。它之前或之后都没有发生过,所以我怀疑我是否能够重现它。

This app has been in production for about 4 years, and this is the first and only instance of any activity like this. It has not happened before or since, so I doubt I'll be able to reproduce it.

我感兴趣的是它是否是某种攻击。如果是的话,我想知道如果它已经没有堵塞,如何插入它试图利用的漏洞。

What I'm interested in is if this is some sort of attack. If it is, I want to know how to plug the hole it's trying to exploit if it's not plugged already.

推荐答案

免责声明:我不是安全分析师/专家,您的问题只是引起了我的兴趣;)

Disclaimer: I'm not a security analyst/expert, your issue simply sparked my interest ;)

警告:虽然我分享了最初的结论,即代码本身可能是无害的,底层技术肯定也可以(ab)用于恶意意图,所以在自己调查时请小心。

Warning: While I share the initial conclusion that the code itself is probably harmless, the underlying technology can most certainly be (ab)used for malicious intents as well, so please take care when investigating this yourself.

您已经自己找到了相关证据 - 进一步搜索我发现另一个pastebin drop ,它更具可读性,所以我用它来解释(虽然乍一看另一个也允许这样做格式化后)。

You already found the relevant evidence yourself - searching further I found another pastebin drop, which is more readable, so I'm using this for the explanation (though at first sight the other one would allow this as well after formatting).

该片段包含具有以下主要功能的JavaScript片段:

The snippet features JavaScript fragments with the following major functionality:


  • 第13行用各种项目初始化变量 _GPL 供以后使用,例如:各种常量`,辅助函数,浏览器兼容性和实际有效负载,例如:

  • Line 13 initializes the variable _GPL with all sorts of items for later use, e.g. various constants`, helper functions, browser compatibility stuff and actual payloads, for example:


  • Line20定义一个空 basdeCDN ,第21行定义了一个 fCDN ,恰好是有问题的一个( d15gt9gwxw5wu0.cloudfront.net

  • Line20 defines an empty basdeCDN, line 21 defines a fCDN, which happens to be the one in question (d15gt9gwxw5wu0.cloudfront.net)

第261行定义了一个函数 removeScripts(),,它依次使用第266行的findScript(),第277行还附有 insertJS() - 他们各自的意图很明显

line 261 defines a function removeScripts(), which in turn uses findScript()from line 266, further accompanied by insertJS() on line 277 - their respective intend is obvious

第270行定义了函数 loadDomainRules(),它似乎是生成您在日志中找到的URL的函数 - 请参阅附录下面的代码片段

line 270 defines function loadDomainRules(), which seems to be the one generating the URL you have found in your logs - see appendix below for the code snippet


  • 扣除:即使没有下面收集的进一步证据,命名和功能强烈提示on r.js 是一个JavaScript文件,提供为手头的域专门组装/生成的自定义JavaScript

  • Deduction: Even without further evidence gathered below, the naming and functionality strongly hints on r.js being a JavaScript file serving custom JavaScript specifically assembled/generated for the domain at hand

第100行定义了一个函数 loadGeo(),确实引用了某种广告服务器( ads2srv.com ) - 请参阅下面的附录中的代码段

line 100 defines a function loadGeo(), which references some kind of an ad server indeed (ads2srv.com) - see appendix below for the code snippet

第368行最后定义了一个函数 i(),它提供了关于所有这些的可能来源的最明确的线索,即一些 Yontoo客户端 Yontoo API - 请参阅下面的附录以获取代码段

line 368 finally defines a function i(), which provides the most definite clues regarding the likely origin of all this, namely the notion of some Yontoo Client and Yontoo API - see appendix below for the code snippet

提取的线索 Yontoo客户端 Yontoo API 很容易导致 Yontoo ,一个应用程序平台,允许您控制您每天访问的网站,即它听起来像 Userscripts.org ,见什么是Yontoo应用程序?

The extracted clues Yontoo Client and Yontoo API easily lead to Yontoo, an Application Platform that allows you to control the websites you visit everyday, i.e. it sounds like a commercialized version of Userscripts.org, see What is a Yontoo App?:


Yontoo是一个自定义的浏览器插件,
增强了底层网站

Yontoo is a browser add-on that customizes and enhances the underlying website

我在哪里可以使用它?

Yontoo适用于网络上的任何网站,但
功能来自名为Yontoo Apps
的单独应用程序具体功能取决于您在哪个网站

Yontoo works on any site on the Web, although the functionality comes from separate applications called Yontoo Apps which provide specific functionalities depending on what site you are on.

[强调我的]

现在,查看应用市场中的当前列表,轻松演示,为什么这可能用于<罢工>可疑不透明广告,例如,尽管页脚中的所有信任标志和印章都是。

Now, looking at the current listings in their App Market easily demonstrates, why this might be used for questionable nontransparent advertizing as well for example, all the trust signs and seals in their footer notwithstanding.

另一个引用可以更深入地了解功能以及它如何产生您遇到的问题:

Another quote provides more insight into the functionality and how it might have yielded the issue you've encountered:


Yontoo [...]是一个
的浏览器插件,用于创建虚拟图层,可以编辑为
创建已进行更改的外观到底层的
网站。 [...]
如果您在网站上看到需要申请或工具,那么您可以免费创建

Yontoo [...] is a browser add- on that creates virtual layers that can be edited to create the appearance of having made changes to the underlying website. [...] If you see a need for an application or tool over a website, then you are free to create!

所以有人显然已经访问了你的网站,并通过Yontoo客户端(如果它实际上允许最终用户使用)或者可用的应用(用于分析的代码段引用了第379行中的下拉交易应用),这触发了 d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js 的创建,以存储这些规则,以便在下次网站访问中重复使用。

So somebody apparently has visited your site and created some custom domain rules for it by means of the Yontoo client (if it actually allows this for end users) or one of the available apps (the snippet used for analysis references the Drop Down Deals app in line 379 for example), which triggered the creation of d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js to store these rules for reuse on next site visit in turn.

由于某些安全漏洞(见下文结论),此URL或相应的JavaScript代码段必须已注入应用程序的JavaScript代码中(例如,通过跨站点脚本(XSS)确实),并在某个时刻依次触发了日志输入错误。

Due to some security flaw somewhere (see conclusion below) this URL or a respective JavaScript snippet must have been injected into JavaScript code of your application (e.g. by means of Cross-site scripting (XSS) indeed), and triggered the log entry error at some point in turn.

如前所述我分享了初步的结论,即代码本身可能是无害的,尽管底层技术肯定可以(ab)用于恶意意图,因为它本身就是用客户端JavaScript进行模拟,即用户允许代码来自第三方服务与他每天使用和信任的网站(尤其是数据)进行交互 - 你的情况就是这方面已经出现问题的明显证据。

As mentioned upfront already, I share the initial conclusion that the code itself is probably harmless, although the underlying technology can most certainly be (ab)used for malicious intents as well due to its very nature of mocking with client side JavaScript, i.e. a user allows code from a 3rd party service to interact with sites (and especially data) he uses and trusts every day - your case is the apparent evidence for something gone wrong already in this regard.

I没有调查Yontoo的安全架构(如果有的话),但是也无法立即在他们的网站上找到关于这个重要主题的任何信息(例如在他们的支持部分)中,这对于像这样的恕我直言的技术来说几乎是不可接受的,所有的尽管如此,信任标志和封条在他们的页脚中。

I haven't investigated the security architecture (if any) of Yontoo, but wasn't able to find any information regarding this important topic immediately on their website either (e.g. in their Support section), which is pretty much unacceptable for a technology like this IMHO, all the trust signs and seals in their footer notwithstanding.

另一方面,用户确实从例如安装第三方脚本当然, Userscripts.org 始终是微调Stack Exchange上的用户体验;)

On the other hand, users do install 3rd party scripts from e.g. Userscripts.org all the time of course, not the least for fine tuning the user experience on Stack Exchange as well ;)

请相应地做出自己的判断!

Please make your own judgment accordingly!

您可以在下面找到分析中引用的代码片段(I在不破坏布局或语法高亮的情况下,无法在列表中内联它们:

Below you can find the code snippets referenced in the analysis (I've been unable to inline them within the lists without breaking the layout or syntax highlighting):

loadDomainRules()

function () {
    if (location.host != "") {
        var a = location.host.replace(RegExp(/^www\./i), "");
        this.insertJS(this.proto + this.fCDN + "/js/" + a + "/r.js")
    }
    this.loaded_domain_rules = true
}

loadGeo()

function () {
    var cid = this.items.e6a00.get("geo.cid");
    var updatetime = this.items.e6a00.get("geo.updatetime");
    if (!cid || (cid && updatetime && (Math.floor((new Date()).getTime() / 1000) - parseInt(updatetime)) >= 259200)) {
        this.insertJS(((this.proto == 'https://') ? 'https://s.' : 'http://') + 'ads2srv.com/tb/gc.php?json&cb=_GPL.setGeoAndGo')
    } else {
        this.vars.cid = this.items.e6a00.get("geo.cid");
        this.vars.rid = this.items.e6a00.get("geo.rid");
        this.vars.ccid = this.items.e6a00.get("geo.ccid");
        this.vars.ip = this.items.e6a00.get("geo.ip");
        this.loadCC();
        this.loadDomainRules()
    }
}

i()

i()

function () {
    if (typeof YontooClient != 'undefined') YontooClient = {};
    if (typeof yontooAPI != 'undefined') yontooAPI = {};
    if (typeof DealPlyConfig != 'undefined') {
        DealPlyConfig.getBaseUrl = function () {
            return "https://d3lvr7yuk4uaui.cloudfront.net/items/blank.js?"
        };
        DealPlyConfig.getCrownUrl = function () {
            return "https://d3lvr7yuk4uaui.cloudfront.net/items/blank.js?"
        }
    }
    this.rm(this.ri, ['dropdowndeals', 'Y2LeftFixedCurtain', 'gbdho', 'bdca', 'dealply-toast-1', 'pricegong_offers_iframe', 'SF_VISUAL_SEARCH', 'batAdRight', 'batAdBottom', 'batAdMiddle_0', 'batAdMiddleExt1_0', 'batAdRight2', 'invisiblehand-iframe', 'scTopOfPageRefinementLinks', 'sf_coupon_obj']);
    this.rm(this.rc, ['yontoolayerwidget', 'dealply-toast', 'imb-ad']);
    this.rm(this.ric, [
            ['productbox', 'g'],
            ['related-searches', 'related-searches-bing']
        ]);
    this.rm(this.rtn, ['MIVA_AdLink', 'itxtrst', 'kLink', 'FAAdLink', 'IL_AD', 'skimwords-link'])
}

这篇关于为什么Cloudfront在我的网络应用程序中加载脚本? (我不用它)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆