Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

October 28, 2007

Sanitizing SVG

For, perhaps obvious, reasons, I’ve been thinking again about sanitizing SVG. My most recent changes to the HTML5lib Sanitizer was to ensure that in constructions like

<rect width='0' height='0' fill='url(...)'/>

the referenced URL is a same-document reference, rather than one that pulls in an external resource from Lord-Knows-Where.

The white-list of elements and attributes in the HTML5lib Sanitizer is the union of a list for MathML that I came up with, and a list for SVG from Sam Ruby. I didn’t really put much thought into Sam’s list. But, once one starts thinking about things, one does start to wonder.

Is

<image xlink:href='http://bad.com/evil.svg'/>

really safe1?

Update:

Of course it’s not safe, as my little example for Anne (viewable only in Opera 9.5beta, but the same problem exists, mutatis mutandis, for <svg:image>) demonstrates. I’ve updated Instiki and the HTML5lib Sanitizer, accordingly.

SVG is a gargantuan Specification. Even thinking about the security implications of Sam’s limited subset makes my head hurt.

1 On similar grounds, while I consider the standard <img src='http://bad.com/ugly.jpg'/> element fairly safe, I have to wonder at the wisdom of the decision in Opera 9.5beta to allow SVG in (X)HTML <img> elements.

Posted by distler at October 28, 2007 11:50 PM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1482



7 Comments & 1 Trackback

SVG in <img>

SVG in <img> has no extra options over PNG or JPEG. Scripting is disabled, for one.

Posted by: Anne van Kesteren on October 29, 2007 1:51 AM | Permalink | Reply to this

Re: SVG in <img>

SVG in <img> has no extra options over PNG or JPEG. Scripting is disabled, for one.

I’m sorry, Anne. I call

rectangle of doom

Posted by: Jacques Distler on October 29, 2007 9:20 AM | Permalink | PGP Sig | Reply to this

Re: SVG in <img>

That is what we call a bug. :-) Sorry for not replying earlier on.

Posted by: Anne van Kesteren on January 29, 2008 6:16 AM | Permalink | Reply to this

Re: Sanitizing SVG

I could go either way on this one. In my mind, there is a subtle but important distinction between malicious and merely mischievous. Really bad things can happen when you syndicate javascript as content so that when it ultimately executes it runs in the security context of the destination instead of the source. Syndicating a link to the content gives the browser a chance to make decisions such as the one that Anne indicates that the Opera beta does based on knowledge of the true source.

All of that is moot, however, if there is a browser which is known to support svg image elements but does not take adequate precautions. Do you know of one, or is this concern merely theoretical?

Posted by: Sam Ruby on October 29, 2007 7:53 AM | Permalink | Reply to this

Not inline

In my mind, there is a subtle but important distinction between malicious and merely mischievous.

I’m not sure I catch the practical distinction between “malicious” and “mischievious.”

While I agree that being able to insert inline javascript is worse than being able to get “foreign,” unsanitized content loaded, the latter is not without hazard. There’s a reason why <iframe> and <object> are not on the list of allowed elements.

All of that is moot, however, if there is a browser which is known to support svg image elements but does not take adequate precautions. Do you know of one, or is this concern merely theoretical?

The above example, visible in the current Opera 9.5beta, was found — by a total noob — in 10 minutes of hacking around before I had digested my morning coffee.

As my wife will attest, I can barely tie my shoes before my morning coffee.

Be afraid, be very afraid.

Posted by: Jacques Distler on October 29, 2007 9:29 AM | Permalink | PGP Sig | Reply to this

Re: Sanitizing SVG

By malicious, I meant things like uploading your cookies or contents of your hard drive.

By mischievous, I meant things like popping a window with the word “bullshit” on it. :-)

In any case, I agree with sanitizing svg:image. I have seen a few svg images that make use of it, but they seem to be the exception rather than the norm. (I often use svg:image while I am developing my images, but remove this element when done.)

Posted by: Sam Ruby on October 29, 2007 1:23 PM | Permalink | Reply to this

The difference is…

By malicious, I meant…

By mischievous, I meant …

“Malicious” is “mischievous” with a caffeine headache.

The <image> element is now sanitized.

On to the rest of the list, shall we?

(It goes without saying that HTML5lib-sanitized content is not safe for consumption by Opera 9.5beta.)

Posted by: Jacques Distler on October 29, 2007 2:18 PM | Permalink | PGP Sig | Reply to this
Read the post Sanitizing SVG
Weblog: Musings
Excerpt: Thinking about safety.
Tracked: October 29, 2007 2:58 PM

Post a New Comment