W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

SVG 1.2 Tiny: Networking API issues

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 12 Dec 2005 14:04:43 -0800
Message-Id: <13CAD069-F8B0-4D17-B58F-0B0E3A7FC64A@apple.com>
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.

Received on Monday, 12 December 2005 22:05:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:05 UTC