- From: Michaela Merz <michaela.merz@hermetos.com>
- Date: Wed, 19 Nov 2014 11:35:00 -0600
- To: public-webapps@w3.org
Yes - it establishes provenance and protects against unauthorized manipulation. CSP is only as good as the content it protects. If the content has been manipulated server side - e.g. by unauthorized access - CSP is worthless. Michaela On 11/19/2014 10:03 AM, ☻Mike Samuel wrote: > Browser signature checking gives you nothing that CSP doesn't as far > as the security of pages composed from a mixture of content from > different providers. > > As Florian points out, signing only establishes provenance, not any > interesting security properties. > > I can always write a page that runs an interpreter on data loaded from > a third-party source even if that data is not loaded as script, so a > signed application is always open to confused deputy problems. > > Signing is a red herring which distracts from the real problem : the > envelope model in which secrets are scoped to the whole content of the > envelope, makes it hard to decompose a document into multiple trust > domains that reflect the fact that the document is really composed of > content with multiple different provenances. > > By the envelope model, I mean the assumption that the user-agent > receives a document and a wrapper, and makes trust decisions for the > whole of the document based on the content of the wrapper. > > The envelope does all of > 1. establishing a trust domain, the origin > 2. bundles secrets, usually in cookies and headers > 3. bundles content, possibly from multiple sources. > > Ideally our protocols would be written in such a way that secrets can > be scoped to content with a way to allow nesting without inheritance. > > This can be kludged on top of iframes, but only at the cost of a lot > of engineering effort. > > On Wed, Nov 19, 2014 at 10:27 AM, Michaela Merz > <michaela.merz@hermetos.com> wrote: >> I don't disagree. But what is wrong with the notion of introducing an >> _additional_ layer of certification? Signed script and/or html would most >> certainly make it way harder to de-face a website or sneak malicious code >> into an environment. I strongly believe that just for this reason alone, we >> should think about signed content - even without additional potentially >> unsafe functionality. >> >> Michaela >> >> >> >> On 11/19/2014 09:21 AM, Pradeep Kumar wrote: >> >> Michaela, >> >> As Josh said earlier, signing the code (somehow) will not enhance security. >> It will open doors for more threats. It's better and more open, transparent >> and in sync with the spirit of open web to give the control to end user and >> not making them to relax today on behalf of other signing authorities. >> >> On 19-Nov-2014 8:44 pm, "Michaela Merz" <michaela.merz@hermetos.com> wrote: >>> You are correct. But all those services are (thankfully) sand boxed or >>> read only. In order to make a browser into something even more useful, you >>> have to relax these security rules a bit. And IMHO that *should* require >>> signed code - in addition to the users consent. >>> >>> Michaela >>> >>> >>> >>> On 11/19/2014 09:09 AM, Pradeep Kumar wrote: >>> >>> Even today, browsers ask for permission for geolocation, local storage, >>> camera etc... How it is different from current scenario? >>> >>> On 19-Nov-2014 8:35 pm, "Michaela Merz" <michaela.merz@hermetos.com> >>> wrote: >>>> >>>> That is relevant and also not so. Because Java applets silently grant >>>> access to a out of sandbox functionality if signed. This is not what I am >>>> proposing. I am suggesting a model in which the sandbox model remains intact >>>> and users need to explicitly agree to access that would otherwise be >>>> prohibited. >>>> >>>> Michaela >>>> >>>> >>>> >>>> >>>> >>>> On 11/19/2014 12:01 AM, Jeffrey Walton wrote: >>>>> On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz >>>>> <michaela.merz@hermetos.com> wrote: >>>>>> Well .. it would be a "all scripts signed" or "no script signed" kind >>>>>> of a >>>>>> deal. You can download malicious code everywhere - not only as scripts. >>>>>> Signed code doesn't protect against malicious or bad code. It only >>>>>> guarantees that the code is actually from the the certificate owner .. >>>>>> and >>>>>> has not been altered without the signers consent. >>>>> Seems relevant: "Java’s Losing Security Legacy", >>>>> http://threatpost.com/javas-losing-security-legacy and "Don't Sign >>>>> that Applet!", https://www.cert.org/blogs/certcc/post.cfm?EntryID=158. >>>>> >>>>> Dormann advises "don't sign" so that the code can't escape its sandbox >>>>> and it stays restricted (malware regularly signs to do so). >>>> >>>>
Received on Wednesday, 19 November 2014 17:35:11 UTC