[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources



Hi Ben,

Great breakdown.

On Sep 26, 2013, at 9:34 AM, Ben Adams <thundercat@illyriad.co.uk> wrote:

> Hi Max
> 
> While I like the idea of being able to use a rendered html element as a texture; I'm not completely sure I understand the extension's intent or the lock-down and security issues that be involved.
> 
> As I understand it, it deals with direct resources (image, video) and suggests composite resources (html)
> 
> There a five classes of direct resource:
> 	• Own domain resources - no issue
> 	• Cross-domain images or video  - can already be used with the appropriate http headers; and this works well, otherwise there would be a big problem trying to use a cdn for anything.
> 	• Local resources - can also be used if the user uploads or dragdrops, or via getUserMedia for cameras.
> 	• Domain accessible resources without cors headers; which are accessible by your domain, either public or with auth, so don't present a restricted resource security risk, - can be proxied either same-domain or with cors headers attached.
> 	• Restricted resources - can only be accessed with appropriate authentication; note if these resource have the appropriate cors headers, and the domain they are used on is valid by the headers they are type 2; if your domain has access to them (server-side) they are type 4.
> So for direct resources it would only be type 5 (when its not 2 or 4) that this extension would be the only workaround?

Correct.

Regarding direct resources, I'm mostly interested in solving #2, when the appropriate HTTP headers are not present. I have the impression that this happens more often than authors would like.

Overall, I'd like this extension to lay the foundation for a follow-up extension which would allow arbitrary HTML content, aka "composite resources".

> 
> For composite resources; html based, there are three main categories:
> 	• Accessible via javascript
> 	• Texture resources - as above, but with the inclusion of object, iframe etc
> 	• Personal - like whether a link has been visited
> 	• Category 1: Is no greater security risk in the WebGL context; as the WebGL is run from Javascript and it would be easier for example to just innerHTML the whole document from the Javascript.
> 
> 	• Category 2: Could work within the cross-domain framework and the origin-clean flag; but you probably shouldn't be taking images of a users' LOB flash, silverlight, or an iframe with their PayPal or bank statement. 
> 
> 	• Category 3: should never be exposed outside the appropriate security context (e.g. a browser extension/plugin explicitly for managing your history etc)
> I'd very much welcome an html render to texture or use html element as texture source; but think it could be done with looser security restrictions; and caveats for example:
> 
> :visited always rendered as :link , if they do not evaluate to the same style there may be a performance impact as any pre-rendered html for display cannot be re-used. Optimising for whether :visited links are in view may allow timing attacks.

In discussions related to CSS Custom Filters (aka CSS Shaders), the W3C considered this idea of selectively rendering content in order to prevent timing attacks. The W3C decided not to go down that path for two reasons:
1) The set of "security sensitive" renderings is difficult to define and can change over time as more web platform features appear. This could result in a security "whack a mole" exercise over time and potentially incompatible renderings between UAs. Some examples besides visited links include: (a) cross-domain iframes, (b) file input fields with rendered file paths, and (c) spellcheck underlines in text inputs.
2) If an author wants to animate an HTML element starting with its initial rendering, the element's rendering may change when the animation begins, causing a strange and unexpected visual "pop".

In the W3C wiki page regarding CSS Shaders Security [1], this approach is briefly discussed in section "Method C (Fallback): Anonymous Rendering and CORS".

Personally, I agree with these arguments.

> 
> Equally I'm not sure I understand the use-cases for allowing relaxed security on type 5 resources (where they are not 2 or 4)?

Me either :)

> 
> 
> Kind regards
> 
> Ben Adams
> @ben_a_adams

Thanks for the feedback!
Max

[1]: http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security

> 
> On 26 September 2013 01:21, Max Vujovic <mvujovic@adobe.com> wrote:
> 
> Hi Oliver,
> 
> I'm suggesting the behavior defined in the proposal link:
> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_security_sensitive_resources/
> 
> The "Errors" section provides most of the explicit definitions of behavior. Please let me know if any sections need clarification.
> 
> - Max
> 
> On Sep 25, 2013, at 5:02 PM, Oliver Hunt <oliver@apple.com> wrote:
> 
> > Can you please describe exactly what this extension would entail?  We need explicit definitions of behaviour to be able to reasonably assess a proposal like this.
> >
> > —Oliver
> >
> > On Sep 25, 2013, at 4:50 PM, Max Vujovic <mvujovic@adobe.com> wrote:
> >
> >>
> >> Hi all,
> >>
> >> I'd like to propose an extension that allows WebGL to process security sensitive content. In summary, the extension allows authors to upload cross-origin resources as textures and run a restricted shading language on their content. The shading language is restricted in order to prevent timing attacks. Authors can use both regular and security sensitive content in the same WebGL context.
> >>
> >> The concept of security sensitive resources can be used to bring HTML content into WebGL in a future extension.
> >>
> >> Here is a link to proposal:
> >> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_security_sensitive_resources/
> >>
> >> This proposal is related to the discussion last November:
> >> https://www.khronos.org/webgl/public-mailing-list/archives/1211/msg00058.html
> >>
> >> I think enabling custom, accelerated effects on arbitrary content opens a whole world of creative possibilities on the web platform.
> >>
> >> Feedback welcome!
> >>
> >> Thanks,
> >> Max
> >> -----------------------------------------------------------
> >> You are currently subscribed to public_webgl@khronos.org.
> >> To unsubscribe, send an email to majordomo@khronos.org with
> >> the following command in the body of your email:
> >> unsubscribe public_webgl
> >> -----------------------------------------------------------
> >>
> >
> 
> 
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
> 
> 


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------