Sunday, August 23, 2009

Why is requesting resources from other hosts such a big problem in Javascript?

Recently, I found out that Yarra Trams has published a web service interface for finding out information on tram arrival times. This is awesome, and I've been trying to think of cool little apps that I can write to take advantage of it. As I'm also playing with GWT at the moment, so perhaps I could do something that way... There is a problem however, in that the Same Origin Policy will block any attempts by my javascript code to access the webservice, as it will come from a different origin.

There's a couple of things that I could do about this:
  1. Ask Yarra Trams if they could host my work, but that kind of defeats the purposes of a mashup, doesn't it. Plus, to be honest, the chances of me ever coming up with something that they would want to host are minimal :)
  2. Write a proxy service that I host myself, and send any requests through it. This kind of seems pointless, as there is already a perfectly good webservice out there that I can use. Besides, if what I wrote ended up becoming popular, I'd be up for a bandwidth bill for all the traffic to the web service.
  3. Try and convince YarraTrams to use a cross site friendly interface, such as is provided by google data. Fat chance of that happening. Besides, there's nothing wrong with web services. This callback based approach seems like a hack, probably because it is.
  4. Use a new HTML5 extension called CORS which allows for fetching resources from other origins.
The first three options all are really really nasty. The fourth solution seems like it is perfect. It is specifically designed to allow for fetching resources from differing sites. It requires the destination server to include a header however that specifies what external domains are allowed to access it however, so it still won't work for me :(

I've been thinking about the SOP restrictions and how CORS works, and I must admit I'm confused. The restrictions that it places on requests just seem too over the top. I understand that it is important to stop XSS attacks, but there should be a way for the javascript programmer to explicitly state that (s)he understands the risks and he promises to treat the requested data as potentially dangerous so that he can use it. To require any form of server side change means that almost all mashup style applications can't operate correctly.

To come back to my example, if I want to perform a POST operation to a Web Service, which returns XML, which I then parse and use as data to, say, plot on a map, I can't see any security problem with allowing me to make a XMLHttpRequestObject request to go do exactly that. If I were to eval() the result, I could potentially open up my application to XSS attacks, but I'm not that stupid.

Now perhaps I haven't spent enough time thinking about this, but I don't see why we can't have an override flag on the XMLHttpRequestObject to allow us to disable the SOP for an individual request. That would give me the flexibility to decide where I want to perform an unsafe request and take the appropriate steps to make sure I don't get burned by the results. Perhaps the security experts out there can educate me as to what I've missed.
blog comments powered by Disqus