Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRI object support #210

Open
devd opened this issue Mar 8, 2015 · 8 comments
Open

SRI object support #210

devd opened this issue Mar 8, 2015 · 8 comments
Labels
Milestone

Comments

@devd
Copy link
Contributor

devd commented Mar 8, 2015

No current implementation supports it, but objects fall under the "code" banner and so would be nice to support. I would argue they are more important than styles.

Not sure if this should be in v1 or not, but this issue will track consensus if any.

@devd devd added the SRI label Mar 8, 2015
@devd devd added this to the SRI-v1-LC milestone Mar 8, 2015
@fmarier
Copy link
Member

fmarier commented Mar 9, 2015

For what it's worth, I'm not currently planning on adding support for <object> elements in the initial Firefox implementation.

@annevk
Copy link
Member

annevk commented Mar 9, 2015

object (and embed) are super complex as they can be either a browsing context or embedding context. I recommend tackling iframe first, then these more difficult contexts.

@devd
Copy link
Contributor Author

devd commented Mar 9, 2015

well, in terms of security though, embedded flash with allowSameDomain is far more powerful.

(that said .. I am leaning towards punting this to vNext)

@hillbrad
Copy link
Contributor

hillbrad commented Mar 9, 2015

Many object classes also have internal means to load additional code that
are not necessarily mediated through the browser, or not in a way that
these policies may reach. So as much as I want to see this, it may be too
much to tackle for v1 and maybe impossible to ever get reliably correct.

On Mon, Mar 9, 2015 at 10:36 AM Devdatta Akhawe [email protected]
wrote:

well, in terms of security though, embedded flash with allowSameDomain is
far more powerful.

(that said .. I am leaning towards punting this to vNext)


Reply to this email directly or view it on GitHub
#210 (comment).

@devd
Copy link
Contributor Author

devd commented Mar 10, 2015

yup .. but it is one of those key "dont want to trust CDN" use cases. That said, I agree we should drop it in v1 and look at this again for vnext. I would definitely argue (then) that this is more important to try than iframes or images.

@devd devd modified the milestones: SRI-next, SRI-v1-LC Mar 10, 2015
@hillbrad
Copy link
Contributor

Yeah, I'd love it to be able to do this, but that doesn't make it
realistic. Unless Flash updates to play better with these kinds of
policies, it's just going to get increasingly left out of scenarios that
require it.

On Mon, Mar 9, 2015 at 5:28 PM Devdatta Akhawe [email protected]
wrote:

yup .. but it is one of those key "dont want to trust CDN" use cases. That
said, I agree we should drop it in v1 and look at this again for vnext. I
would definitely argue (then) that this is more important to try than
iframes or images.


Reply to this email directly or view it on GitHub
#210 (comment).

@devd
Copy link
Contributor Author

devd commented Mar 10, 2015

well if you can load the flash file with integrity, you can manually confirm in your own code that you are not loading any other file without integrity.

Conversely, JS in SRIv1 can load other JS (bounded by CSP) that is not checked for integrity---we haven't really solved the "mandate all scripts from CDN to have SRI" anyhow.

@annevk
Copy link
Member

annevk commented Mar 10, 2015

@devd sure, Flash is powerful, but you cannot address just Flash as that would leave other capabilities of object unaddressed. Which is why I suggested starting with the simpler iframe.

@mozfreddyb mozfreddyb changed the title Should SRI support objects in v1? SRI object support Mar 23, 2015
mikewest pushed a commit to mikewest/webappsec that referenced this issue Jun 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants