Re: SVG 1.2 Tiny: Networking API issues

On Monday, December 12, 2005, 11:04:43 PM, Maciej wrote:


MS> 1) Section A.6.3, the Connection API for socket-level communication,  
MS> is a serious security risk for browser-hosted implementations of SVG.  
MS> It violates the browser security model, which only allows network  
MS> interaction with the home host/port/protocol.

MS> A) Code in a web document is only allowed to access and read the  
MS> contents of network resources from its original server (interpreted  
MS> as combination of host, port and protocol). In particular, access to  
MS> documents in other HTML frames, iframes and objects; and ability to  
MS> perform a network transaction via XMLHttpRequest are so restricted.

MS> The socket API appears to have no such security restrictions and so  
MS> would allow cross-site scripting (XSS) exploits.

I'm not sure why you say that there are no such security restrictions.
We don't mandate a particular security model because SVG can be used in
several different situations with differing needs, but we certainly warn
about security and allow whatever security model is appropriate to be
used.

For example, in section A.7.19 SVGGlobal

  User Agents may provide the user with means to interact with the
  request (e.g. to enter authentication information) but is not required
  to. For security reasons, User Agents are encouraged to restrict the
  domains to which one may make such requests. When enforcing such
  restrictions, the callback is called immediately with its
  AsyncURLStatus object's success field set to false and other fields
  set to null. Redirection responses (3xx HTTP codes) must not be
  exposed through the API but rather they must be processed internally
  according to the HTTP specification.

MS> B) Even to the original host and port that the web page came from,  
MS> raw socket networking is unsafe. Web pages are currently restricted  
MS> to connecting only via a built-in implementation of the various  
MS> network protocols that impose some restrictions.

The set of protocols available seems to vary, for example some user
agents support RTP and RTSP while others don't. In addition, some user
agents allow extensions that provide additional protocols.

MS> For example: coinsider a resource loaded from an http: URI. With raw  
MS> socket access to port 80 on the origin host, a script could send an  
MS> http request with a different "Host:" header, possibly accessing  
MS> content on a different virtual server running on the same physical  
MS> server. This is an XSS exploit.


MS> Note, these risks are mitigated to some extent compared to standard  
MS> XSS by the fact that for http, the UA's cookies and authentication  
MS> credentials would not be provided automatically. But there are still  
MS> avenues of attack based on such things as the IP address and network  
MS> location of the target machine. For example, information could be  
MS> read from a firewalled "intranet" site and resent.


Yes (although that could be done using straight HTTP as well)

MS> Or spam mail could be sent automatically based on the user's IP
MS> allowing access to a particular restricted mail relay. I can write
MS> up more detailed scenarios if this would be helpful but I think the
MS> risks should be obvious to network security practitioners.


MS> For reasons A and B, the Connection API is unsafe to expose to web- 
MS> hosted content. Therefore I recommend removing it, unless a  
MS> resolution to the security issues is found. I could not think of an  
MS> effective resolution myself.

The SVG user agent is allowed to impose whatever security policies
(such as same-host) it wants to. We could make that more explicit.

Your concerns wil be discussed in the WG, this is just an immediate
response to say we got the comment.


MS> 2) Section A.7.19 the SVGGlobal object: regarding the getURL method,  
MS> the spec says:

MS> "For security reasons, User Agents are encouraged to restrict the  
MS> domains to which one may make such requests."

MS> I suggest making it more clear more clear that in practice these may  
MS> be not just domain name restrictions but also restrictions on the  
MS> port and scheme.

Good advice, thanks.


MS> 3) Networking APIs in general seem out of scope for a vector graphics  
MS> format, especially one that is supposed to be Tiny. I know this has  
MS> been mentioned before by others but it is still worth mentioning.

It has, you are right. Allow me to make two points. Firstly, SVG isn't
just any graphics format; its a Web graphics format. Dynnamic graphics
constructed on demand and in real time from live network data is thus
directly in scope, as the charter makes clear. Secondly, the SVG spec
does not just define a format, it also defines conformance for a viewer
and a generator.


MS> 4) Definition of the methods and attributes global object does not  
MS> belong in an SVG specification, since the global object is shared by  
MS> all HTML/XML languages that a UA supports. These should be defined in  
MS> a spec that is independent of any specific markup language.

We agree that the potential for re-use of this object is high. Its
certainly already used by a lot of content, both SVG and XHTML; its not
standardised anywhere. Our options were

a) refuse to define it, look the other way and accept that all scripts
will in practice use this undefined global object

b) define "the" Global object (bad idea)

c) define our global object, but defer to a future general Global
object.


We chose the third option. The reason the spec says "SVGGlobal inherits
from the Global interface, which is currently defined to be empty" is
precisely because we expect a more general Global interface to be
defined. When that happens, we can simply defer to that specification
without affecting compatibility.




MS> Regards,
MS> Maciej





-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 13 December 2005 16:47:32 UTC