- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 12 Dec 2005 14:04:43 -0800
- To: www-svg@w3c.org
1) Section A.6.3, the Connection API for socket-level communication, is a serious security risk for browser-hosted implementations of SVG. It violates the browser security model, which only allows network interaction with the home host/port/protocol. A) Code in a web document is only allowed to access and read the contents of network resources from its original server (interpreted as combination of host, port and protocol). In particular, access to documents in other HTML frames, iframes and objects; and ability to perform a network transaction via XMLHttpRequest are so restricted. The socket API appears to have no such security restrictions and so would allow cross-site scripting (XSS) exploits. B) Even to the original host and port that the web page came from, raw socket networking is unsafe. Web pages are currently restricted to connecting only via a built-in implementation of the various network protocols that impose some restrictions. For example: coinsider a resource loaded from an http: URI. With raw socket access to port 80 on the origin host, a script could send an http request with a different "Host:" header, possibly accessing content on a different virtual server running on the same physical server. This is an XSS exploit. Note, these risks are mitigated to some extent compared to standard XSS by the fact that for http, the UA's cookies and authentication credentials would not be provided automatically. But there are still avenues of attack based on such things as the IP address and network location of the target machine. For example, information could be read from a firewalled "intranet" site and resent. Or spam mail could be sent automatically based on the user's IP allowing access to a particular restricted mail relay. I can write up more detailed scenarios if this would be helpful but I think the risks should be obvious to network security practitioners. For reasons A and B, the Connection API is unsafe to expose to web- hosted content. Therefore I recommend removing it, unless a resolution to the security issues is found. I could not think of an effective resolution myself. 2) Section A.7.19 the SVGGlobal object: regarding the getURL method, the spec says: "For security reasons, User Agents are encouraged to restrict the domains to which one may make such requests." I suggest making it more clear more clear that in practice these may be not just domain name restrictions but also restrictions on the port and scheme. 3) Networking APIs in general seem out of scope for a vector graphics format, especially one that is supposed to be Tiny. I know this has been mentioned before by others but it is still worth mentioning. 4) Definition of the methods and attributes global object does not belong in an SVG specification, since the global object is shared by all HTML/XML languages that a UA supports. These should be defined in a spec that is independent of any specific markup language. Regards, Maciej
Received on Monday, 12 December 2005 22:05:46 UTC