As a web developer you’re always told you need to keep up to date on the latest and greatest technologies. Usually this is for creating applications which can take advantage of new technologies to deliver a better experience to your users. However, I think there is another angle to this, in particular; Code Rot. Code rot is basically where code becomes ignored, neglected or the environment in which it operates evolves and changes into something that was not foreseen when the code was originally created. In some cases code rot can lead to vulnerabilities.

I like to consider myself a “web guy”. I keep up to date on what the browser vendors are doing and generally keep track of specifications and how web developers are using the new abilities granted to them. As most people in the web community know by now, the Cross Origin Resource Sharing (CORS) specification has pretty much dominated over the competing Uniform Messaging Policy (UMP) specification. CORS was put forward as a safe method of easing the restrictions of the Same Origin Policy. CORS has now become widely adopted by browser implementers and can be used to transfer content across different domains, effectively loosening the Same Origin Policy so two servers can communicate easier.

So what is a “Web” example of code rot leading to vulnerabilities? Recently, I’ve found numerous cases of web developers passing in client supplied input into an XMLHttpRequest (XHR) object without checking or validating the URL. Some developers like to take information from the URL such as a URL fragment, or query parameter and then pass this as the URL value into the XHR Object’s open method. The response from this request would usually be content that is either evaluated or injected into the DOM of the current page in an asynchronous manner. Usually, this would not be a problem because requests were restricted to the same domain, so the worst that could happen is someone could load (or cause the page to not load) content from that very same site. However, with the advent of CORS, this now becomes a serious liability.

This example of code rot can even be found in systems designed to train web application developers in how to design secure applications. You will notice the text in the below image: “XHR requests can only be passed back to the originating server.” You can quickly assume this application was created prior to the CORS specification becoming commonplace.

In this example, the WebGoat developer is taking the value from the “Enter a URL” box and passing it directly into the XMLHttpRequest object’s open method:

xmlHttp.open("GET",document.getElementById("requestedURL").value,true);

Prior to CORS and provided they trust the content on their site, this wouldn’t be considered a serious issue. With CORS however, the XHR object will now be able to send requests to third party sites. In the above example it does this by sending a preflight request to veracode.com which tells the browser; webgoat.veracode.com wants to read your data, do you allow it? If veracode.com responds with an “Access-Control-Allow-Origin: *” header, then a secondary request is made by the browser (from webgoat.veracode.com) and the data is extracted from the veracode.com site. If veracode.com was hosting malicious html or script code, and depending on how the victim page handles that response data, we could easily find our site becoming a victim to Cross Site Scripting attacks.

A similar issue to the one above was found way back in July 2010 and was used to exploit a facebook.com sub-domain. For more information on that particular issue I suggest you read Matt Austin’s blog post about it, as it captures the issue perfectly: http://m-austin.com/blog/?p=19.

My goal here is to not blame CORS or any other browser specification or implementation but rather highlight an issue that is easy to forget about. Code rot isn’t just about letting your code deteriorate and become unusable; it’s also about understanding your security posture and how to meet the demands of a changing environment.

So next time you see a cool new feature in a Browser or a Framework think to yourself, is my code still OK?

Veracode Security Solutions

Veracode Security Threat Guides