I have been too slow to get to this! The security experts at Fortify Software have recently discovered a new Web 2.0-specific security vulnerability that may affect some sites passing JSON-encoded data to the client, and I got some nudges from both coworkers and customers to investigate this deeper.

So, what is this vulnerability all about?

In short, you have to be extra careful when using HTTP GET requests to stream JSON-encoded data to the client. You may be thinking that you are using ASP.NET's authentication mechanism and you are conveniently hidden behind the session and forms authentication cookie, but that may not be the case. Imagine that there is an HTTP handler that will serve GET requests and return JSON to the client. The client is your secured ASPX page and you can't get to it without passing through the login page. The JSON handler checks if the user is authorized before sending the data too. But what happens if a malicious site tricks you into visiting it after you have visited the trusted site? That malicious site can request data from the JSON handler if it knows the correct URL. URL's are not hard to guess and remember, you are coming from the trusted site, so you have an authentication cookie set. That means the malicious site can read your mail, get to your files, and do even nastier stuff.

Normally you can't request URL's from a different domain using an XMLHttpRequest object -- the browser just won't let you. You can't access frames that host documents from another domain either. All that is a part of the "Same Origin Policy" that ensures that you are to touch stuff coming from your own domain only. There is a way to circumvent that policy though! You can insert a <script> tag with a "src" attribute pointing to another domain. You can get only scripts from that domain, but JSON-encoded data is valid JavaScript that can be accessed after being pulled in the attacker's document.

Am I vulnerable?

Your site is vulnerable if it allows streaming JSON data from HTTP GET requests without taking extra measures to prevent requests from unauthorized locations. The extra measures can be really simple: you can inject something that will make the script invalid and unparseable and then strip it on the client before evaluating that or you can switch to POST requests or add extra HTTP request headers and check if the headers are present on the server.

Are telerik's controls exploitable?

You face some risk when using RadTreeView and RadComboBox and their LoadOnDemand feature. Those controls do HTTP GET requests and an attacker can use the mechanism above and get the text contents of your tree nodes and combo items. If you are displaying sensitive data in there, please disable that feature, and contact our support guys. They will get you a hotfix build that has this security hole closed.

The rest of the controls do HTTP POST requests and are not exploitable.

About the Author

Stefan Rahnev

Stefan Rahnev (@StDiR) is Product Manager for Telerik Kendo UI living in Sofia, Bulgaria. He has been working for the company since 2005, when he started out as a regular support officer. His next steps at Telerik took him through the positions of Technical Support Director, co-team leader in one of the ASP.NET AJAX teams and unit manager for UI for ASP.NET AJAX and Kendo UI. Stefan’s main interests are web development, agile processes planning and management, client services and psychology.

Related Posts


Comments are disabled in preview mode.