Question

所以这可能是一个漫长而长远的镜头，但我对可能导致此问题的原因感到十分困惑：

我正在提供客户端JavaScript，它解析嵌入它的页面上的某些参数，使用这些参数构建URL并使用该URL将iframe注入页面，如：

var queryParams = {
  param: 'foo'
  , other: 'bar'
};

变成了：

<iframe src="http://example.net/iframes/123?param=foo&other=bar"></iframe>

这工作得非常好，我每天发送大约150万个请求。然而，我最近注意到，在每天大约3.000个案例中，查询参数的值被洗牌，所以请求这样：

<iframe src="http://example.net/iframes/123?param=ofo&other=rba"></iframe>

从日志来看，这与特定用户有关，并且每个请求都会重新发生字符的混乱，因此当用户使用脚本浏览具有多个页面的网站时，我可以看到这样的序列：

108.161.183.122 - - [14/Sep/2015:15:18:51 +0000] "GET /iframe/ogequl093iwsfr8n?param=3a1bc2 HTTP/1.0" 401 11601 "http://www.example.net/gallery?page=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"
108.161.183.122 - - [14/Sep/2015:15:19:07 +0000] "GET /iframe/ogequl093iwsfr8n?param=a21b3c HTTP/1.0" 401 11601 "http://www.example.net/gallery?page=2" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"
108.161.183.122 - - [14/Sep/2015:15:19:29 +0000] "GET /iframe/ogequl093iwsfr8n?param=ba132c HTTP/1.0" 401 11601 "http://www.example.net/gallery?page=3" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"

401正在进行，因为服务器期望param=abc123。

我还注意到大多数错误都发生在Firefox和Safari中，而Google Chrome并未要求提供任何错误的网址。

我用来将对象转换为查询字符串的库是：query-string - 但是查看源代码我看不到那种类型的bug的可能性，没有什么可以做到的没有对键进行的值（没有弄乱）。

有没有人遇到类似的东西？这是一些奇怪的浏览器扩展吗？这是我的脚本与另一个扩展原型库的碰撞吗？这是恶意软件吗？这是我完全没有意识到的吗？我会感激任何提示，因为我真的很无能，而这真的让我发疯了。

编辑：我刚刚发现另一个面向公众的服务目前正在被称为“Burp Suite”。看看他们的网站，我看到他们有一个名为“Payload fuzzing”的工具，它似乎完成了这里描述的内容：https://portswigger.net/burp/help/intruder_gettingstarted.html或者这里：https://portswigger.net/burp/help/intruder_using.html#uses_enumerating - 整个工具闻起来半腥我，所以我可能值得进一步调查。有没有人听说过这个工具集？

Answer 1

从这一点来分析并不多，因为你正在寻找提示;这更像是一个长期评论而不是一个答案。

客户端浏览器（或计算机）或Web服务器上的恶意软件;或者一个未知的爬虫可能导致这种情况，这是不太可能的。对我而言，您的应用程序似乎受到了攻击。

让我们看看;

真实示例（在评论中）显示正在混洗128位十六进制访问密钥。（accessKey param的值）
只有值被洗牌，而不是键。
您说，请求来自特定用户。
您说，请求来自特定浏览器客户端（Firefox和Safari）。

检查/做什么;

检查您的日志记录系统是否正常工作。如果您使用第三方可配置记录器，这可能会搞砸。（example）
重现：使用相同的参数集;使用相同版本的浏览器，看看结果是否相同。如果是这样，它可能是浏览器版本的问题，这是非常不可能的。
检查是否有其他 Firefox和Safari 用户（使用相同版本） NOT 可以体验到这一点。
由于您说它只是一小部分请求，请检查相应的请求是否一个接一个地进行。（同样的请求在不到一秒钟内？）
尝试跟踪请求来源。它们来自您怀疑的来源吗？您能否将来自不同请求的信息相互关联？多个IP构成子网？使用不同帐户的相同IP？在短时间内使用不同IP的同一帐户？
有apache-scalp，mod_sec，lorg等工具可以检查/分析大型日志文件以提取可能的攻击。</ li>
您还可以使用here提到的一些技术来手动发现或阻止可疑请求。

Answer 2

我是Tomas，我是CLIQZ的软件工程师。

我们是德国初创公司，正在将搜索和创新隐私功能集成到浏览器中。这确实是我们的反跟踪功能的结果。在reddit和another question on stackoverflow中也提出了类似的问题。这两个帖子已经回答了，所以我在这里引用相同的答案：

CLIQZ反跟踪一般不会阻止跟踪，而只是跟踪单个用户 - 我们认为这违反了用户的隐私，因此不合适。与其他反跟踪系统不同，我们的系统不会完全阻止信号;因此，网站所有者能够获取合法用途的数据，例如计算访问次数。

为防止识别用户（例如，使用JavaScript哈希），CLIQZ Anti Tracking实际上会置换字符串。   。每当新的跟踪器显示在我们的数据中时，我们的系统最初将其视为用户识别跟踪器并更改字符串以预防性地保护我们的用户。我们的系统使用所谓的k-匿名技术。如果它看到多个用户在几天内独立显示的事件的相同字符串，则会将其置于合法的，非标识跟踪器的白名单中。将跟踪器列入白名单后，它将保持不变，网站所有者会看到原始字符串。换句话说，CLIQZ Anti Tracking仅暂时限制合法跟踪器的功能。一旦发现跟踪器不会侵犯我们用户的隐私，一切都会正常进行。隐私对我们来说非常重要，我们相信这项技术对于保护我们的用户免受窥探是必要的。

我希望这会有所帮助。

Answer 3

正如我在此处已提到Google Analytics Event Permutation 有一个特定版本（至少1.0.37）的Firefox附加组件＆＃34; Cliqz＆＃34;具有内置的反跟踪功能。

Answer 4

我似乎不太可能这种行为源于您的查询字符串代码。鉴于查询字符串值可以自由更改，我怀疑这是正在发生的事情 - 请记住，这是您的请求的0.2％。

我会检查一些事情。您是否知道这些请求是从其他网站，您自己的网站引用还是直接提交的？您是否知道任何源IP是否与已知机器人或网络爬虫相对应？请求是来自各种来源还是一小部分重复访问者？

机器人或网络抓取工具可能是"lightly probing your site"或测试重复的网页或误导性参数。

Answer 5

有些机器人会抓取您的网站，这很正常。如果您不希望他加载您的服务器，请阻止请求IP。

什么可能会改变我在JavaScript中构造的查询字符串参数？

5 个答案: