logo标签列表

什么可能导致我在JavaScript中构建的查询字符串参数被打乱？

javascriptfirefoxsafariquery-stringbrowser-extension
17

这可能是一个很长很大的挑战，但我完全被困扰住了，不知道是什么原因导致了这个问题：

我正在提供客户端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没有请求任何错误的URL。

我正在使用的库将对象转换为查询字符串是：query-string - 但是查看源代码后，我没有发现任何可能导致此类错误的问题，对值做的任何事情都对键（未被搞砸的键）进行了处理。

有人遇到过类似的情况吗？这是一种奇怪的浏览器扩展程序吗？这是我的脚本与另一个扩展原型的库冲突吗？这是恶意软件吗？这是我完全不知道的东西吗？如果有任何提示，我会非常感激，因为我真的很无助，这让我很疯狂。

编辑：我刚刚发现我们的另一个公共服务正在被称为“Burp Suite”的工具探测。看一下他们的网站，我看到他们有一个名为“Payload fuzzing”的工具，似乎可以做到这里描述的事情：https://portswigger.net/burp/help/intruder_gettingstarted.html 或这里：https://portswigger.net/burp/help/intruder_using.html#uses_enumerating - 整个工具对我来说有点可疑，所以我认为这可能是值得进一步调查的事情。有其他人听说过这个工具集吗？

1
嘿，queryParams的值是从哪里获取的？如果它们是从网页上获取的，那么很容易被翻译工具或机器人等任何东西修改。 - jjbskir
1
你有没有办法将它们移出DOM？ - jjbskir
1
你能给一些混乱的键值参数的真实例子吗？ - Onur Yıldırım
1
@OnurYıldırım 其中一个参数被称为“accesskey”，包含一个32个字符的字母数字值，例如acdeeaa9c89ef9b63cdf62810c25d32c，在请求iframed文档时会被洗牌成2a0edd3a6f93ae2c21cc5b9c86dc8e9f。请参见此fiddle：http://jsfiddle.net/tvjzsvnq/，以证明它是相同的一组字符。 - m90
1
根据您的问题和评论，我完全同意Onur的看法；有人正在攻击您的服务并故意搞乱参数以获取对敏感（即别人的）数据的访问权限。我认为没有理由怀疑系统中存在漏洞。我可能只会确保记录尝试使用无效访问密钥获取数据的操作，并在短时间内出现多个此类请求时向管理员发送警报。（然后管理员可以完全阻止来自相关IP地址的访问或采取其他措施。） - MJV
显示剩余9条评论
5个回答
7

从这个角度来看，没有太多可以分析的内容。既然你在寻找提示，这更像是一条长评论而不是一个答案。

可能是客户端浏览器（或机器）上的恶意软件，或者您的Web服务器上的未知爬虫导致了这种情况，但这种情况不太可能。对我来说，似乎您的应用程序正在遭受攻击。

让我们看一下；

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

要检查/执行的操作；

  • 检查日志记录系统是否正常工作。如果您使用可配置的第三方记录器，则可能会搞砸事情。（示例）
  • 重现：使用完全相同的参数集；使用相同版本的浏览器，看看结果是否相同。如果是，则可能是浏览器版本问题，这是极不可能的。
  • 检查是否有其他Firefox和Safari用户（具有相同版本），他们没有经历过这种情况。
  • 由于您说只有少量请求，请检查是否在另一个请求之后立即进行相应的请求。（在不到一秒钟的时间内进行相同类型的请求？）
  • 尝试跟踪请求的来源。它们来自您怀疑的来源吗？您能否将不同请求的信息联系起来？多个IP形成子网？同一IP使用不同帐户？在短时间内使用不同IP的同一帐户？
  • 有一些工具，例如apache-scalp、mod_sec、lorg，可用于检查/分析大型日志文件以提取可能的攻击。
  • 您还可以使用此处提到的一些技术手动识别或阻止可疑请求。
6
我是Tomas，是CLIQZ的软件工程师。
我们是一家德国初创公司，正在将搜索和创新的隐私功能整合到浏览器中。这确实是我们的反跟踪功能的结果。类似的问题也被提出在reddit和stackoverflow上的另一个问题。这两篇文章都已经回答了这个问题，所以我会在这里引用相同的答案。
CLIQZ反跟踪系统并不是为了完全阻止跟踪，而是只防止单个用户被追踪——我们认为这是侵犯用户隐私的行为，因此是不恰当的。与其他反跟踪系统不同的是，我们的系统并不完全阻止信号；因此，网站所有者可以获取合法使用的数据，例如计数访问量。
为了防止用户被识别（例如使用JavaScript哈希），CLIQZ反跟踪确实对字符串进行了置换。每当新的跟踪器出现在我们的数据中时，我们的系统最初将其视为用户标识跟踪器，并更改字符串以预防性地保护我们的用户。我们的系统使用所谓的k-匿名技术。如果它在几天内多次独立地发现具有相同字符串的事件，则将其放入合法的、非标识跟踪器的白名单中。一旦跟踪器被列入白名单，它就会保持不变，网站所有者会看到原始字符串。换句话说，CLIQZ反跟踪仅暂时限制合法跟踪器的功能。一旦确定跟踪器不会侵犯我们用户的隐私，一切都会像往常一样运作。隐私对我们非常重要，我们认为这项技术是保护用户免受监视的必要手段。
希望这可以帮助你。
嗨@tomas，我们正在使用查询字符串参数来调整网站上的图标颜色，例如在某些主题中它将是红色，而在某些主题中它将是蓝色。是否有任何方法可以解决这个问题以合法的方式？ - Dirk Boer
3
谢谢。我可以确认这个扩展也在洗牌我们的参数。你看过这个扩展的代码了吗？你能理解什么时候一个 token 会在这里被认为是一个 badToken 吗：https://gist.github.com/m90/e9df0576ac6f06f864f2？ - m90
当我们找到实际执行洗牌操作的代码行时，我们感到很高兴。我认为我们不想进行更多的调查了... - M. Röder
我认为我明白了我们的情况：脚本检查查询字符串令牌，当它遇到一个超过8个字符的重复值时，它会假定这是一个跟踪标识符：https://gist.github.com/m90/e9df0576ac6f06f864f2#file-badtokens-js-L36 - 糟糕的是，在我们的情况下，这是通过GET传递的API密钥... - m90
@m90 在看到其他用户发送相同的令牌之前，它只会假定它是一个标识符。之后，您的跟踪器将被添加到白名单中，您将收到正常的数据。因此，它可以在技术上拦截不发送用户标识符的合法跟踪器的信号，但仅是暂时性的。 - tomas
0

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

事实是，从UA字符串来看，它似乎是一个普通的浏览器，并且所有的流量都来自不同的IP。因此，这很不可能只是“一些机器人”。 - m90
UA字符串很容易被伪造，因此它不是一个真正好的指标。 - Armando Canals
0

我觉得这种行为与你的查询字符串代码没有关系，这对我来说似乎非常不可能。考虑到查询字符串值可以自由地更改，我怀疑这就是发生的事情 - 请记住，这只占你请求的0.2％。

有几件事情我会检查。你是否知道这些请求是从其他网站引用、你自己的网站还是直接发起的？你是否知道任何源IP是否对应已知的机器人或网络爬虫？这些请求来自各种来源还是重复访问者的小子集？

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

机器人和网络爬虫不应该使用UA字符串来标识自己吗？所有记录的请求都使用真实浏览器的UA字符串。 - m90
好的想法；因此我们排除了明显的网络爬虫（除非有什么奇怪的事情发生，但你应该能够检查IP地址）。但对于其他机器人来说并不是决定性的，因为你可以设置UA字符串 - 例如搜索漏洞的机器人不会自称。 - Ninjakannon
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接