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

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参数值)
• 只有值被洗牌而不是键.
• 你说,请求来自特定用户.
• 你说,请求来自特定的浏览器客户端(Firefox和Safari).

要检查/做什么;

• 检查您的日志系统是否正常工作.如果您使用的是第三方可配置记录器,这可能会搞砸.(例子)
• 再现:采用相同的参数集; 使用相同版本的浏览器,看看结果是否相同.如果是这样,它可能是一个浏览器版本的问题,这是不太可能的.
• 检查是否有其他没有经历过此操作的Firefox和Safari 用户(具有相同版本).
• 由于您说它只是请求的一小部分,请检查相应的请求是否一个接一个地进行.(同样的请求在不到一秒钟内？)
• 尝试跟踪请求的来源.它们来自您怀疑的来源吗？您能否将来自不同请求的信息相互关联？多个IP构成子网？使用不同帐户的相同IP？同一帐户在短时间内使用不同的IP？
• 有一些工具,如apache-scalp,mod_sec,lorg,用于检查/分析大型日志文件以提取可能的攻击.
• 您还可以使用此处提到的一些技术手动发现或阻止可疑请求.

Answer 2

我是Tomas,我是CLIQZ的软件工程师.

我们是一家将搜索和创新隐私功能集成到浏览器中的德国初创公司.这确实是我们的反跟踪功能的结果.还有一个类似的问题是关于reddit和另一个关于stackoverflow的问题.两篇文章都已经回答了,所以我在这里引用相同的答案:

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

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

我希望这有帮助.

Answer 3

正如我已经在这里提到的Google Analytics 事件排列， 有一个特定版本（至少 1.0.37）的 Firefox 插件“Cliqz”内置了反跟踪功能。