atom feed3 messages in org.w3.www-svgpotential security hole involving poi...
FromSent OnAttachments
Robert O'CallahanSep 24, 2008 9:09 pm 
Doug SchepersSep 25, 2008 11:41 pm 
Robert O'CallahanSep 26, 2008 3:07 pm 
Subject:potential security hole involving pointer-events, filters, foreignObject, cross-origin IFRAMEs, and elementFromPoint
From:Robert O'Callahan (
Date:Sep 24, 2008 9:09:03 pm

It seems that using clever combinations of SVG 1.1 features, untrusted content can capture the rendering of a third-party site ... depending on some very subtle stuff in the spec.

The idea is to start with image.svg which contains a <foreignObject> which contains an <iframe> of the site you wish to capture, say Then you wrap that foreignObject in a <filter> which uses <feColorMatrix> and <feComponentTransfer> to map some pixel values to alpha=0 and other pixel values to alpha=1. Then you create another document, say outer.svg, which contains <image src="image.svg" style="pointer-events:painted">. Then in outer.svg, using the non-SVG but common-in-Web-UAs DOM API "elementFromPoint", you can hit-test over <image> to see which pixels have nonzero alpha.

This could be used by some evil site to capture and transmit the contents of intranet sites or certain Web applications the user might auto-login to, so it's very serious. Fortunately I don't think this works in any UA yet; Firefox doesn't support pointer-events, Safari doesn't support <filter> and I believe Opera doesn't handle <foreignObject> in filters.

Now, pointer-events:painted says that alpha-value testing should only be applied to "raster images", and technically <image src="image.svg"> is not a *raster* image, so perhaps we can use that loophole to say that in fact pointer-events does not test alpha values for that image. But it feels strange for pointer-events to depend on the actual image type there, and it feels even worse for that to be the only defense against a serious security hole.

But I don't have any better ideas at the moment.