什么可能会打乱我用JavaScript构造的查询字符串参数

What might be shufflling my query string parameters constructed in JavaScript?

本文关键字：查询 参数 字符串 JavaScript 什么      更新时间：2023-09-26

所以这可能是一个很长的，很长的机会，但我完全被什么可能导致这个问题难住了:

我正在交付一个客户端JavaScript，它解析页面上嵌入的某些参数，使用这些参数构建一个URL，并使用该URL注入一个iframe到页面中，如:

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

变成:

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

这工作得很好，我每天交付大约150万个请求。然而，我最近注意到，在每天大约3000个案例中，查询参数的值被打乱了，所以像这样的请求:

<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请求的单个错误URL。

我用来将对象转换为查询字符串的库是:query-string -但是查看源代码，我看不到任何潜在的那种错误，没有对没有对键做的值做任何事情(没有搞砸)。

有人遇到过类似的事情吗?这是什么奇怪的浏览器扩展?这是我的脚本与另一个库扩展原型的碰撞吗?这是恶意软件吗?这是我完全不知道的吗?我很感激你的任何提示，因为我真的很笨，这真的让我发疯了。

EDIT:我刚刚发现我们的另一个面向公众的服务目前正在被一个叫做"Burp Suite"的东西探测。看看他们的网站，我看到他们有一个叫做"有效载荷模糊"的工具，它似乎做了很多描述在这里:https://portswigger.net/burp/help/intruder_gettingstarted.html或这里:https://portswigger.net/burp/help/intruder_using.html#uses_enumerating -整个工具对我来说闻起来有点可疑，所以我这可能是值得进一步调查的东西。还有人听说过这个工具集吗?

从这一点来看没有太多要分析的，因为您正在寻找提示;这更像是一个长评论，而不是一个答案。

客户端浏览器(或机器)或web服务器上的恶意软件;或者是未知的爬虫引起的，这是不太可能的。在我看来，你的应用程序被攻击了。

看看;

  • 实际示例(在注释中)显示128位十六进制访问密钥正在被洗牌。(accessKey参数值)
  • 只有值被打乱，而不是键。
  • 你说，请求来自特定用户。
  • 你说，请求来自特定的浏览器客户端 (Firefox和Safari)。

检查/做什么;

    检查你的日志系统是否工作正常。如果您使用的是第三方的、可配置的记录器，这可能会把事情搞砸。(例子)
  • 复制:取完全相同的一组参数;使用相同版本的浏览器，看看结果是否相同。如果是这样，可能是浏览器版本问题，这是极不可能的。
  • 检查是否有其他 Firefox和Safari 用户(具有相同的版本)做而不是体验此
  • 既然你说这只是请求的一小部分，检查一下相应的请求是否一个接一个地发出。(相同类型的请求在不到一秒钟?)
  • 尝试跟踪请求的来源。它们来自你怀疑的来源吗?你能把来自不同请求的信息联系起来吗?多个ip组成一个子网?相同的IP使用不同的帐户?同一账号在短时间内使用不同ip ?
  • 有apache-头皮，mod_sec, log等工具来检查/分析大日志文件以提取可能的攻击。
  • 您还可以使用这里提到的一些技术来手动发现或阻止可疑请求。

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

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

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

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

我希望这对你有帮助。

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

对我来说，这种行为似乎极不可能源于您的或查询字符串代码。考虑到查询字符串值可以自由更改，我怀疑这就是正在发生的事情-请记住，这是0.2%的请求。

有几件事我要检查。你是否知道这些要求是来自其他网站、你自己的网站，还是直接提出的?你知道是否有任何源ip对应于已知的机器人或网络爬虫吗?这些请求是来自各种来源还是来自重复访问者的一小部分?

这是可能的机器人或网络爬虫是"轻微探测你的网站"或测试重复的页面或误导性参数。

有些机器人抓取你的网站，这是很正常的。如果你不想让他加载你的服务器，阻止请求IP

相关文章：