ASP。 NET ScriptManager 安全问题
ASP. NET ScriptManager security issue
我在 aspx 页面中放入以下代码以启用基于 AJAX 的请求：
<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
然而，在使用 Fortify 扫描代码时，它抱怨说这会带来安全风险
Explanation:
Microsoft AJAX.NET (Atlas) uses JSON to transfer data between the server and the client. The framework produces responses comprised of valid JavaScript that can be evaluated using a tag and is therefore vulnerable to JavaScript hijacking [1]. By default, the framework use the POST method to submit requests, which makes it difficult to generate a request from a malicious tag (since tags only generate GET requests). However, Microsoft AJAX.NET does provide mechanisms for using GET requests. In fact, many experts encourage programmers to use GET requests in order to leverage browser caching and improve performance.
An application may be vulnerable to JavaScript hijacking if it: 1) Uses JavaScript objects as a data transfer format 2) Handles confidential data. Because JavaScript hijacking vulnerabilities do not occur as a direct result of a coding mistake, the Fortify Secure Coding Rulepacks call attention to potential JavaScript hijacking vulnerabilities by identifying code that appears to generate JavaScript in an HTTP response.
Web browsers enforce the Same Origin Policy in order to protect users from malicious websites. The Same Origin Policy requires that, in order for JavaScript to access the contents of a web page, both the JavaScript and the web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. JavaScript hijacking allows an attacker to bypass the Same Origin Policy in the case that a web application uses JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional web applications are not.
The most popular format for communicating information in JavaScript is JavaScript Object Notation (JSON). The JSON RFC defines JSON syntax to be a subset of JavaScript object literal syntax. JSON is based on two types of data structures: arrays and objects. Any data transport format where messages can be interpreted as one or more valid JavaScript statements is vulnerable to JavaScript hijacking. JSON makes JavaScript hijacking easier by the fact that a JSON array stands on its own as a valid JavaScript statement. Since arrays are a natural form for communicating lists, they are commonly used wherever an application needs to communicate multiple values. Put another way, a JSON array is directly vulnerable to JavaScript hijacking. A JSON object is only vulnerable if it is wrapped in some other JavaScript construct that stands on its own as a valid JavaScript statement.
并推荐如下：
Recommendations:
All programs that communicate using JavaScript should take the following defensive measures: 1) Decline malicious requests: Include a hard-to-guess identifier, such as the session identifier, as part of each request that will return JavaScript. This defeats cross-site request forgery attacks by allowing the server to validate the origin of the request. 2) Prevent direct execution of the JavaScript response: Include characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a tag to witness the execution of the JavaScript. The best way to defend against JavaScript hijacking is to adopt both defensive tactics.
我仍然不太确定这个 ScriptManager 如何引入安全风险，以及如何解决它？
不幸的是，我目前所在的国家/地区禁止Google，因此我很难提供参考资料来支持我的声明，但这是您需要知道的。
JavaScript 劫持（也称为 JSON 劫持）是一个过时的安全问题，当 fortify 抱怨它时你不应该把它当回事。简而言之，JavaScript 劫持是很久很久以前的一个问题，当时 Web 浏览器还非常不成熟并且不包含它们今天所包含的防御措施。这些浏览器现在可以防止它，因此您无需再做任何事情。 It just is not a security issue any more（参见 link）。
最重要的是，Fortify 提供 ("hard-to-guess identifier") 以防止出现此问题的指导是无稽之谈。该指南来自 Fortify 员工撰写的一份旧研究论文，由于缺乏其他方法来防止攻击，它在当时是有道理的。通常，您永远不应该将 json 发送到 JavaScript eval() - 仅此一项就足以阻止 JavaScript 劫持，即使浏览器没有阻止它。
在 Fortify 文档中，他们提供了对有关 JavaScript 劫持的原始论文的参考。当我第一次看到同样的问题时，我被这个问题所困扰，以至于我花了一周的时间试图理解它并实现它（与论文中的示例相同）——在 Chrome、Firefox 和IE，并发现 none 这些攻击尝试有效。然后我做了更深入的工作，找到了上面的 link 和其他关于为什么 JavaScript 劫持不再是安全问题的内容。
您使用 Fortify 的次数越多，就越会发现很多荒谬的误报，不幸的是，这是最难理解的误报之一。 MicroFocus 没有兴趣更新他们的规则：当人们试用 Fortify 并发现它产生了很多其他工具没有出现的结果时，人们会购买 Fortify，因为他们认为它会因为这些发现而变得更好。事实恰恰相反：它并没有更好，它只是出现了更多无用的误报，这让使用该工具的人感到烦恼。但使用该工具的人通常不是做出购买决定的人，这就是 MicroFocus 没有动力更新规则的原因——误报对他们有利，可以产生更多的销售额！
我在 aspx 页面中放入以下代码以启用基于 AJAX 的请求：
<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
然而，在使用 Fortify 扫描代码时，它抱怨说这会带来安全风险
Explanation:
Microsoft AJAX.NET (Atlas) uses JSON to transfer data between the server and the client. The framework produces responses comprised of valid JavaScript that can be evaluated using a tag and is therefore vulnerable to JavaScript hijacking [1]. By default, the framework use the POST method to submit requests, which makes it difficult to generate a request from a malicious tag (since tags only generate GET requests). However, Microsoft AJAX.NET does provide mechanisms for using GET requests. In fact, many experts encourage programmers to use GET requests in order to leverage browser caching and improve performance.
An application may be vulnerable to JavaScript hijacking if it: 1) Uses JavaScript objects as a data transfer format 2) Handles confidential data. Because JavaScript hijacking vulnerabilities do not occur as a direct result of a coding mistake, the Fortify Secure Coding Rulepacks call attention to potential JavaScript hijacking vulnerabilities by identifying code that appears to generate JavaScript in an HTTP response.
Web browsers enforce the Same Origin Policy in order to protect users from malicious websites. The Same Origin Policy requires that, in order for JavaScript to access the contents of a web page, both the JavaScript and the web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. JavaScript hijacking allows an attacker to bypass the Same Origin Policy in the case that a web application uses JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional web applications are not.
The most popular format for communicating information in JavaScript is JavaScript Object Notation (JSON). The JSON RFC defines JSON syntax to be a subset of JavaScript object literal syntax. JSON is based on two types of data structures: arrays and objects. Any data transport format where messages can be interpreted as one or more valid JavaScript statements is vulnerable to JavaScript hijacking. JSON makes JavaScript hijacking easier by the fact that a JSON array stands on its own as a valid JavaScript statement. Since arrays are a natural form for communicating lists, they are commonly used wherever an application needs to communicate multiple values. Put another way, a JSON array is directly vulnerable to JavaScript hijacking. A JSON object is only vulnerable if it is wrapped in some other JavaScript construct that stands on its own as a valid JavaScript statement.
并推荐如下：
Recommendations:
All programs that communicate using JavaScript should take the following defensive measures: 1) Decline malicious requests: Include a hard-to-guess identifier, such as the session identifier, as part of each request that will return JavaScript. This defeats cross-site request forgery attacks by allowing the server to validate the origin of the request. 2) Prevent direct execution of the JavaScript response: Include characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a tag to witness the execution of the JavaScript. The best way to defend against JavaScript hijacking is to adopt both defensive tactics.
我仍然不太确定这个 ScriptManager 如何引入安全风险，以及如何解决它？
不幸的是，我目前所在的国家/地区禁止Google，因此我很难提供参考资料来支持我的声明，但这是您需要知道的。
JavaScript 劫持（也称为 JSON 劫持）是一个过时的安全问题，当 fortify 抱怨它时你不应该把它当回事。简而言之，JavaScript 劫持是很久很久以前的一个问题，当时 Web 浏览器还非常不成熟并且不包含它们今天所包含的防御措施。这些浏览器现在可以防止它，因此您无需再做任何事情。 It just is not a security issue any more（参见 link）。
最重要的是，Fortify 提供 ("hard-to-guess identifier") 以防止出现此问题的指导是无稽之谈。该指南来自 Fortify 员工撰写的一份旧研究论文，由于缺乏其他方法来防止攻击，它在当时是有道理的。通常，您永远不应该将 json 发送到 JavaScript eval() - 仅此一项就足以阻止 JavaScript 劫持，即使浏览器没有阻止它。
在 Fortify 文档中，他们提供了对有关 JavaScript 劫持的原始论文的参考。当我第一次看到同样的问题时，我被这个问题所困扰，以至于我花了一周的时间试图理解它并实现它（与论文中的示例相同）——在 Chrome、Firefox 和IE，并发现 none 这些攻击尝试有效。然后我做了更深入的工作，找到了上面的 link 和其他关于为什么 JavaScript 劫持不再是安全问题的内容。
您使用 Fortify 的次数越多，就越会发现很多荒谬的误报，不幸的是，这是最难理解的误报之一。 MicroFocus 没有兴趣更新他们的规则：当人们试用 Fortify 并发现它产生了很多其他工具没有出现的结果时，人们会购买 Fortify，因为他们认为它会因为这些发现而变得更好。事实恰恰相反：它并没有更好，它只是出现了更多无用的误报，这让使用该工具的人感到烦恼。但使用该工具的人通常不是做出购买决定的人，这就是 MicroFocus 没有动力更新规则的原因——误报对他们有利，可以产生更多的销售额！