XML News from Monday, May 29, 2006

John Cowan tells me I'm all wrong about the Authorizing Read Access to XML Content Using the <?access-control?> Processing Instruction 1.0:

Here's the scenario. You surf to a web page containing an applet (Java or Flash or whatever) downloaded from foo.com. Your browser will run that applet, but will only trust it to access content hosted on foo.com. This is good for security on your system -- a malicious applet can't grab confidential content from your behind-the-firewall servers and pipe it back to the applet's host -- but it makes the applet rather inflexible: any public data it needs to read has to be mirrored on its host.

Now comes this specification, and tells the browser that if the document contains <?access-control allow="foo.com"?>, then the browser should let the applet read that document just as if the document resided on foo.com. It has absolutely nothing to do with whether browsers at foo.com can themselves read the document or not -- anyone can read the document by running trusted code. The PI says that this document can be read even by untrusted code from specific sources.

It's also possible to use wildcards in the access-control PI to allow access by applets from anywhere, or from a set of hosts.

That's a little more sensible, but only a little. This is still a security problem. First of all, it allows the web page to say that it's OK to use applets (or JavaScript, or whatever) to launch a DOS attack on it. Secondly the limitations on applets talking to third party hosts aren't just for the protection of the third party hosts. They exist to protect the client system too. I'm not sure a client should routinely trust an applet to talk to server X because server Y says it's OK.