W3C home > Mailing lists > Public > public-web-security@w3.org > April 2011

Re: style-src and inline style

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 14 Apr 2011 16:01:15 -0700
Message-ID: <BANLkTi=SJNTNn2P5Gix-a4-OTBkGBCDXRQ@mail.gmail.com>
To: Collin Jackson <collin.jackson@sv.cmu.edu>
Cc: Brandon Sterne <bsterne@mozilla.com>, Bil Corry <bil@corry.biz>, gaz Heyes <gazheyes@gmail.com>, Daniel Veditz <dveditz@mozilla.com>, public-web-security@w3.org
On Thu, Apr 14, 2011 at 3:55 PM, Collin Jackson
<collin.jackson@sv.cmu.edu> wrote:
> On Thu, Apr 14, 2011 at 3:38 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Thu, Apr 14, 2011 at 1:51 PM, Brandon Sterne <bsterne@mozilla.com>
>> wrote:
>> > On 4/11/11 11:19 AM, Brandon Sterne wrote:
>> >> On 4/7/11 9:17 AM, Collin Jackson wrote:
>> >>> I'd like to suggest option 3, which is to block inline styles by
>> >>> default
>> >>> only if a style-src directive is present (authors can use style-src
>> >>> 'inline' if they want to use style-src with inline styles).
>> >>>
>> >>> Attaching default blocking behaviors to specific directives rather
>> >>> than
>> >>> to the entirety of CSP makes the spec more extensible and allows us to
>> >>> support a variety of use cases while still keeping policies simple.
>> >>
>> >> I think this is the best solution offered so far.  If there are no
>> >> objections, I'll make this change to the spec draft as well.
>> >
>> > I'm in the process of making this change, and I'm wondering how best to
>> > extend this to be consistent with script-src.
>> >
>> > The proposal is to disable inline style when style-src is present and
>> > only allow it when the 'inline' keyword is added to style-src.
>> >
>> > For script-src, however, adding the 'inline' keyword to script-src is
>> > less desirable than the disable-xss-protection options token we had
>> > previously (from the standpoint of conveying sufficient caution when
>> > enabling inline script).  One option would be to change 'inline' to
>> > 'inline-style' that only has an effect when declared inside style-src,
>> > and have a different keyword for inline script, potentially keeping
>> > 'disable-xss-protection'.  Yes, that would be less consistent
>> > syntactically, but it would preserve the "Foot Gun Here" element.
>> >
>> > Separately, it's somewhat less elegant to say that inline script is
>> > disabled when any of:
>> >
>> >  1. script-src
>> >  2. object-src
>> >  3. ...
>> >
>> > are present (rather than the single style-src directive), but I haven't
>> > really heard a better suggestion so far.
>>
>> One option is to say that inline script is disabled when script-src is
>> present (i.e., not triggering that restriction on object-src).  The
>> thought process is that you can't tell the "src" of inline script, so
>> script-src should block it.
>
> Should we disable inline objects (via data: URLs) when object-src is present
> (i.e., not triggering that restriction on script-src)?

We already do that.  The "data" scheme isn't likely to be on your whitelist.  :)

Adam
Received on Thursday, 14 April 2011 23:02:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 April 2011 23:02:14 GMT