JSON无法解决的问题：为什么这么严重？ [英] JSON unparseable cruft: Why so serious?

问题描述

在阅读了这个问题之后，为什么google / facebook等添加了无法解析的问题：

• while（1）;


• for（;;）;


• &&& START&&& ...&&&&&&&


• 1和3合并

他们的JSON回复，我已经明白了动机。但是我仍然不清楚为什么使用这种相对复杂的机制，当使用类似的效果时可以实现类似的效果，例如

• 添加一个额外的）开头用于渲染整行无效且语法错误


• 将JSON包装在评论中

现在，似乎这对无限循环和（怪异的）语法错误的额外保护将是绕过旧的和允许的javascript解析器，但我似乎无法找到任何表明这种情况的参考文献。还有另一个 SO问题甚至消除而（1）; 解决方法（说明1可能被破坏）并拒绝另一种形式 {}&& 的解决方法，但不解释原因或引用任何来源。

其他参考：

• http://code.google.com/p/fbug/issues/detail?id=369


• http://prototypejs.org/learn/json ，这表明将JSON包装在 / * - secure-\ n ... * /

解决方案

我认为有几个与无法解析的形式相关的细节：

• {}&& 为日期添加前缀 JSON 解析器（显然&例如在老年人的道场rsions）未将 JSON 字符串验证为有效的 JSON 语法。我知道的所有 JSON Parser库现在都进行验证，但这篇博客文章从2008年开始表明所述版本的dojo将允许 JSON.parse json通常，虽然 eval 会失败，这样可以方便地防止 JSON 劫持。




• 而使用 Number 原型可以使（1）无效，通过将 0 指定为 1 的值。



• <;> for（;;）和而（1）都会导致被劫持网站崩溃，这样做可以增加保护，因为任何脚本的每次进一步执行都可以有效地停止而不会出现错误。这很重要，因为错误定义并不标记javascript中脚本执行的结束，而（;;）的确保没有脚本无论如何都是在它之后执行的。这是为了防止（afaik假设）攻击者通过利用 window.onerror 中的弱点成功拦截脚本错误，覆盖 eval ，或代理错误对象实例化（如覆盖 Error.prototype 的构造函数）。
  
  
  

  更新

  
  
  

  还有这个关于security.stackexchange的问题建议不要使用 for（;;）或而（1）因为可以暗示您的网站是DoS攻击客户端CPU或触发恶意软件扫描程序。我没有看到现代浏览器存在严重的DoS问题，因为它们运行沙盒并且基于每个选项卡基础。但它肯定是旧版浏览器的问题。恶意软件扫描程序是一个真正的问题，可能会将您的网站报告为攻击。




• &&& START&&& ; （和相应的&&&&&&& 标签）使得在客户端接收json的解析更容易而不仅仅是使用）或可能无意中关闭的评论，并可能提高可读性和安全性。程序员的可见性。在评论中包装只是一种变体，因为它提供 / * 开始和 * / 结束标记。在我看来，在开始和结束时有一个清晰明确的标记有助于注意到残骸的意义。使用评论并没有真正提供。

After reading this question as to why google/facebook etc. add unparseable cruft like:

• while(1);
• for(;;);
• &&&START&&& ... &&&END&&&
• 1 and 3 combined

to their JSON responses, I have understood the motivation. But I am still not clear as to why such relatively complex mechanisms are used, when similar effects could be achieved with things like

• adding an extra ) at the beginning for rendering the entire line invalid with a syntax error
• wrapping the JSON in comments

Now, it seems that this added protection of an infinite loop and (weird) syntax error would be to get around older and permissive javascript parsers, but I cannot seem to find any references indicating that this is the case. There is another SO question that goes on to even diss the while(1); workaround (stating the 1 can be clobbered) and reject another workaround of the form {}&&, but doesn't explain why or cite any sources.

Other references:

• http://code.google.com/p/fbug/issues/detail?id=369
• http://prototypejs.org/learn/json, which suggests a wrapping the JSON in /*-secure-\n...*/

解决方案

I think there are several details relevant to the forms of unparseable cruft:

• {}&& prefixing dates back to JSON Parsers (apparently & for example Dojo in older versions) not validating the JSON string as valid JSON Syntax. All the JSON Parser libraries I know of do validation nowadays, but this blog post from 2008 suggests that the said versions of dojo would allow to JSON.parse the json normally, while eval would simply fail, which would give you convenient protection against JSON hijacking.

• while(1) can be made ineffective using the Number prototype, by assigning 0 as 1's value.

• for(;;) and while(1) both have the effect to crash the hijacked site, which does insofar add to the protection as every further execution of any script is effectively stopped without error. This is important because an error by definition does not mark the end of script execution in javascript, while a for(;;) makes sure no script whatsoever is executed after it. This is to prevent (afaik hypothetical) situations where an attacker successfully intercepts script errors by exploiting weaknesses in window.onerror, overwriting eval, or proxying error object instantiation (like overwriting the constructor of Error.prototype).

  UPDATE

  There is also this question on security.stackexchange suggesting not to use for(;;) or while(1) since it can be implied your site is DoS-attacking the clients CPU or triggering malware scanners. I do not see a serious DoS problem with modern browsers, since they run sandboxed and on a per-Tab Basis. But it sure is a problem with older browsers. The malware scanners are a real problem and may report your site as attacking.

• &&&START&&& (and a corresponding &&&END&&& tag) make the parsing on the client side receiving the json easier than just using ) or comments that may be closed unintentionally, and may improve readability & visibility for the programmer. Wrapping in comments is just a variation of that, since it provides the /* start and the */ end tag. In my opinion, a distinct and clear mark at the start and the end helps noticing the meaning of the cruft. Using Comments is not really providing that.

这篇关于JSON无法解决的问题：为什么这么严重？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！