Re: SVG 1.2 Tiny: Networking API issues

On Dec 13, 2005, at 8:47 AM, Chris Lilley wrote:

> 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.

The comment you cite below appears to only apply to getURL and  
postURL. the section on Connection does not mention that security  
restrictions are even allowed, let alone mandated. However, as far as  
I can tell *no* set of restrictions would make this API safe for web  
content. I think this is a major concern.

> 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.

Without the Connection mechanism, browser-hosted implementations are  
restricted to URL access, meaning that the user agent performs the  
protocol handshake and data transfer in asafe way. Being able to talk  
raw protocol allows new exploits as exemplified below.

>
> 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)

I'm not sure which "that" you meant, but neither of the above  
scenarios is possible using the http networking mechanisms in current  
web browsers, because of the XSS restrictions. You are not allowed to  
set the "Host:" header, and you are not allwed to access a remote  
resource on another host in a way that allows you to read the contents.

> 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.

I believe same-host would be insufficient, since the host may be  
running other other services on different ports; in the web security  
model this would be considered a different security domain. Even same  
host+port would be insufficient, due to the examples in B.  
Furthermore, same host+port is not workable when the original host 
+port needs to be accessed via a proxy server. Direct access to the  
host would not work, and giving access to the proxy server instead  
would allow bypass of the security restrictions.

As far as I can tell, only disallowing entirely would be safe for  
content loaded from the web. I do not think the spec should define  
features that are insecure by design. Saying the user agent could add  
its own security policy seems inadequate if the only known secure  
policy would be to turn the feature off.

> 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.

I do not see the tragedy of leaving this stuff unstandardized until  
it can be brought to the proper venue. That would not preclude  
vendors from implementing it. The global object namespace is a scarce  
resource and you can't really say these additions are just for SVG.  
In practice a user agent that supports CDF will have to provide a  
global object that has the union of all methods and attributes  
required by different languages.

In particular the network and timer APIs in SVG are significantly  
different from the de facto standard APIs for this in HTML content  
(XMLHttpRequest, setTimeout/setInterval). Would a general standard  
ultimately have to support both? Would the de facto standard just be  
replaced by the SVG design (still effectively forcing UAs to support  
both)? I do not think such concerns have been addressed.

I do not have the same objections to "parent" and "document" since  
these match the de facto standards, nor to "binaryToString" or  
"stringToBinary" since these do not overlap existing UA functionality  
and seem useful.

Regards,
Maciej

Received on Tuesday, 13 December 2005 21:59:28 UTC