Patch forthcoming.
Created attachment 53058 [details] Simple defense-in-depth patch.
I've not found a concrete problem due to this, but the area makes me nervous enough to have created this patch.
Comment on attachment 53058 [details] Simple defense-in-depth patch. That method on FrameLoader is very sketchy. Can't we operate on the SecurityOrigin directly? That won't be overridden in any funny ways.
The only way I can see for the sandbox flags on the FrameLoader to get overridden is if a parent HTMLFrameElement changes state. This will never happen to our temporary SVG loader, which has an SVG document at the root :) I like doing this on the FrameLoader because any other origins created from it will also inherit the same sandboxing state. For example, an SVG could contain an html:iframe element[*]. If we do a one-off patch up on the SecurityOrigin, I worry that a complicated & clever SVG could bypass it. [*] - this is pretty ugly in the <img> context. I may be changing things here, but for now we should assume these uglies exist.
Ah good, point. I'm worried that other consumers of this API will get confused. Can we make this a new bit field that always gets applied to the "natural" sandbox policy? That way it could survive updates.
Created attachment 53065 [details] Add new bitmap to make forced flags more sturdy :)
Comment on attachment 53065 [details] Add new bitmap to make forced flags more sturdy :) Very nice.
Can you cq+ it? I don't think my WebKit committer paperwork was processed yet ;-)
Comment on attachment 53065 [details] Add new bitmap to make forced flags more sturdy :) Clearing flags on attachment: 53065 Committed r57438: <http://trac.webkit.org/changeset/57438>
All reviewed patches have been landed. Closing bug.
I suggest calling these "forced sandbox flags" in the code, not "force sandbox flags". Maybe the names you ended up using in the patch were a typo?
Fixed in http://trac.webkit.org/changeset/57445