ASP. NET ScriptManager security issue

Question

I put the following code to enable AJAX based request in the aspx page:

<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>

However, upon scanning the code using Fortify, it complains that this poses a security risk

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.

And the recommendations as follows:

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.

I'm still not quite sure on how this ScriptManager can introduce security risk, and how to resolve it?

Answer 1

Unfortunately I am currently in a country that blocks Google so it is hard for me to provide references to backup my claims, but here's what you need to know.

JavaScript hijacking (also known as JSON hijacking) is a dated security issue, and you should not take it seriously when fortify complains about it. In short, JavaScript hijacking was an issue a long, long time ago when web browsers were very immature and did not contain the defences that they contain today. These browsers now protect against it, so there is nothing more you need to do. It just is not a security issue any more (see link).

Most importantly, the guidance Fortify gives ("hard-to-guess identifier") to preventing the issue is nonsense. That guidance comes from an old research paper written by Fortify employees, and it made sense at the time due to lack of other ways of preventing the attack. Generally you should never send json into a JavaScript eval() -- and that alone would be enough to stop JavaScript hijacking even had browsers not prevented it.

In the Fortify documentation, they provide a reference to the original paper on JavaScript hijacking. When I first saw the same issue, I was so bothered by this issue that I spent a week trying to understand it and implement it (the same example as in the paper) -- trying it on Chrome, Firefox, and IE, and finding that none of those attack attempts worked. Then only did I did deeper and find the link above and others about why JavaScript hikjacking is not a security issue any more.

The more you use Fortify, the more you are going to find a lot of nonsensical false positives, and unfortunately this is one of the most painful ones to understand. MicroFocus has no interest in updating their rules: when people trial Fortify and find that it turns up lots of results that other tools do not turn up, people buy Fortify under the assumption that it is better because of such findings. The truth is the opposite: it is not better, it is just turning up more useless false positives that are an annoyance to people who use the tool. But the people who use the tool are usually not the people making the purchasing decision, which is why MicroFocus has no incentive to update the rules -- false positives are working in their favour to generate more sales!