W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2013

Re: [webappsec] POLL: Getting CSP 1.1 to LCWD

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 1 Oct 2013 16:03:59 -0600
Message-ID: <CACQ=j+cSjebo3C0M=hjKQab7JZOHYdjdTZzyJ0q6R95q6bBRjQ@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Oct 1, 2013 at 3:51 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On 10/1/2013 1:46 PM, Glenn Adams wrote:
> > "Privilege escalation vulnerabilities are common in Firefox, and
> > comprise roughly a third of the critical vulnerability advisories. [...]"
> >
> > I can't comment on the age of this report or whether the same concerns
> > remain active, but it is sufficient to cause me to be concerned about
> > this as an attack vector.
>
> That seems to be a concern about Firefox, not add-ons.
>
> > In my commenting here, I am representing Cox, who, as a commercial video
> > service provider, is required to meet regulatory requirements about
> > presenting Emergency Alert Messages to end users while they are actively
> > using this service. Failure to do everything reasonably possible to
> > present an Emergency Alert could have liability consequences.
>
> The internet in general and the World Wide Web in particular are not a
> video service. How does this requirement apply in any way?
>

I'm afraid I left out background info here. Cox and many commercial video
service providers (think Cable, Satellite, and traditional Broadcasters of
television services) are using the Web Platform to deliver television
content using Web technologies. Some of these companies, such as Cox,
Comcast, BBC and others, are members of the W3C, and are participating in
WG processes to ensure that their needs and concerns are adequately
represented.

In creating a television user interface using the Open Web Platform, these
companies are often not exempted from requirements they encounter when
using other mediums for transmission. In the U.S. at least, Emergency Alert
Services are part of such requirements.

In analyzing the security aspects of the Web Platform, CSP has been
identified as a useful and important technology for mitigating unintended
failure of such services, however, the ability for a compromised
third-party add-on/extension to inject script has been identified as a
potential security threat.

Upon closely reading CSP, it was determined that CSP not only didn't
address this, but appears to encourage UAs to expose what we consider to be
a relevant attack surface.

So, to specifically answer your question, if a compromised third-party
add-on injects script (as recommended by CSP) and that script somehow
prevents or alters a web page's function to prevent or change the
presentation of an Emergency Alert Message, then there can be serious
consequences for the user as well as the television service provider using
the Web Platform to deliver these services.


>
> > It seems reasonable on our reading of CSP that it do a better job of
> > reducing exposure to attacks from compromised add-on script injection,
>
> I'd worry far more about malicious addons than compromised ones. The
> former is a reality, but CSP isn't going to help that problem.
>

Well, if CSP enabled authors to declare that addons should not inject
script and the end user doesn't override that declaration, then we believe
CSP could help.


>
> > Again, I'm attempting to find a better balance than that suggested by
> > current CSP specification text, which states "a CSP policy /should
> > not/ interfere with the operation of user-supplied scripts such as
> > third-party user-agent add-ons". I believe this is too open-ended and
> > that reasonable technical options exist to better protect both end user
> > and content author.
>
> My eventual plan for Firefox is to let an add-on specify a CSP
> whitelist. This lets the add-ons do what the user presumably want them
> to do but by default means add-ons will respect CSP. The explicit steps
> to override CSP can then be reviewed and won't accidentally introduce
> issues. Although perhaps not as wide open as the spec implies I think
> that fits with the spirit of the spec ("should not", not "must not").
>
> -Dan Veditz
>
>
Received on Tuesday, 1 October 2013 22:04:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC