- From: Scott Helme <scotthelme@hotmail.com>
- Date: Thu, 17 Mar 2016 10:11:49 +0000
- To: public-webappsec@w3.org
- Message-ID: <BLU436-SMTP1400997F4D8F0837812865BD98B0@phx.gbl>
At first glance it seems like a 'require-sri' keyword that you could drop into default/script/style-src would be more straightforward. If 'require-sri' became a new directive would it be an on/off setting like 'upgrade-insecure-requests' or could you configure which resource types it applies to? Would you need to? Regards, Scott Helme / Information Security Consultant PGP Key <https://scotthelme.co.uk/contact/> https://scotthelme.co.uk https://report-uri.io https://securityheaders.io https://scotthel.me Twitter <https://twitter.com/Scott_Helme>Facebook <https://www.facebook.com/scott.helme>GooglePlus <https://plus.google.com/+ScottHelme/posts>YouTube <https://www.youtube.com/user/ScottHelme>LinkedIn <https://uk.linkedin.com/in/scotthelme>GitHub <https://github.com/ScottHelme/>Skype <scott.helme87> On 17/03/2016 09:55, Mike West wrote: > I'm fine with a `require-sri` source expression that could be added to > `script-src`, or a `require-sri` directive that stands on its own. > > I lean towards the latter because it feels a little strange to treat > this kind of requirement as a "source", and because having a separate > directive for this policy change probably fits better with CSP's > extensibility model (and is easily defined in a separate document from > CSP itself). If someone feels strongly about using the former I'd > probably accept a PR, though. :) > > -mike > > On Wed, Mar 16, 2016 at 7:11 PM, Scott Helme <scotthelme@hotmail.com > <mailto:scotthelme@hotmail.com>> wrote: > > I agree, I'd love to see some traction with this. > > Angular will soon be providing the appropriate script tags with > integrity values for each release: > https://github.com/angular/angular.js/issues/13968#issuecomment-181633726 > This makes deploying SRI a matter of copy and paste. > > SRI is much easier to deploy than CSP and only requires > maintenance when you change the script/style tag itself, CSP > requires ongoing knowledge and maintenance. > I think adoption of SRI will likely eclipse CSP relatively soon, > I'm betting with you, not against! > > Regards, > > > Scott Helme / Information Security Consultant > PGP Key <https://scotthelme.co.uk/contact/> > > > https://scotthelme.co.uk > https://report-uri.io > https://securityheaders.io > https://scotthel.me > > Twitter <https://twitter.com/Scott_Helme>Facebook > <https://www.facebook.com/scott.helme>GooglePlus > <https://plus.google.com/+ScottHelme/posts>YouTube > <https://www.youtube.com/user/ScottHelme>LinkedIn > <https://uk.linkedin.com/in/scotthelme>GitHub > <https://github.com/ScottHelme/>Skype <http://scott.helme87> > > On 16/03/2016 17:18, Neil Matatall wrote: >> What can we do to get this moving? No matter the form, I don't think >> there's any disagreement about whether or not this is valuable. We're >> starting to see a proliferation of SRI attributes included in example >> snippets for 3rd party assets. It's my gut instinct* that SRI has the >> possibility of eclipsing CSP in terms of adoption, but that's a >> different topic. It sounds like CSP bloat and SRI changes are the >> biggest hurdles. Something that may alleviate both concerns: >> >> block-non-sri-resources: stylesheets, scripts(, images, videos, unicorns) >> >> I would still love to see this as a part of CSP, especially if we're >> talking about adding something related to noopener >> https://twitter.com/mikewest/status/710025892970504193. Maybe this >> separate header value can also work as a directive, just remove [:,] >> >> * I'll take bets >> >> On Tue, Feb 16, 2016 at 5:44 AM, Patrick Toomey >> <patrick.toomey@github.com> <mailto:patrick.toomey@github.com> wrote: >>> On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com> <mailto:fbraun@mozilla.com> wrote: >>>> On 09.02.2016 19:35, Craig Francis wrote: >>>>> I'm forgetting the discussion a bit, but CSP already gives us: >>>>> >>>>> block-all-mixed-content >>>>> upgrade-insecure-requests >>>>> >>>>> Maybe we could keep it as just one directive: >>>>> >>>>> block-non-sri-resources >>>>> >>>>> Or am I missing the more advanced cases like saying SRI is required for >>>>> all JavaScript files, but not on CSS (doubt that is useful, as you might >>>>> as well do both)... or maybe in the future SRI could be added to images, >>>>> video, etc? >>>> We'd need to think about compatibility assuming SRI will expand to other >>>> tags. >>>> >>>> I would be surprised if nobody wanted a report-mode and a block-mode and >>>> a way to specify which subresources/elements should be subject to the >>>> policy. (The list of elements could be abbreviated with a short-hand >>>> form, e.g., "sri-v1" meaning scripts & styles.) >>>> >>>> I guess this level of complexity (and Mark Nottingham's comment about >>>> HPACK and entropy) warrants its own header? >>>> >>> I'm curious where the line should be drawn between extending CSP and adding >>> a new header? Not having been involved with CSP from day one, maybe this has >>> already been discussed. But, I feel like CSP is a natural place to >>> centralize on browser based security policies (like x-frame-options >>> migrating to frame-ancestors). Adding a new header for each and every new >>> good idea for browser security doesn't seem to scale. As has been mentioned >>> in this thread prior, it feels like we are starting to bump up against >>> practical size consideration issues. Whether the CSP header itself grows too >>> large or we end up adding 50 headers to each HTTP response, there is an >>> issue of bloat. It would be a shame to place some artificial cap on good >>> ideas based on concerns for adding too many new headers and/or stretching >>> the size of the CSP header. I personally feel like moving toward a >>> centralized policy/manifest/resource sounds like the best way to handle >>> this, but I think most of that discussion is best had over in the "header >>> size and policy delivery" thread. I just wanted to bring it up here since I >>> think the "where do we put it" discussion should be deferred until later, >>> since it seems like this is a general concern for almost anything new that >>> is proposed. > >
Received on Thursday, 17 March 2016 10:21:59 UTC