Allow CSP on HTML <meta> tags
Axel Dahmen
(https://wiki.mozilla.org/Security/CSP/Spec#Source_Expression_List) and the
Talk (https://wiki.mozilla.org/Talk:Security/CSP/Spec)...
What I'm missing is a statement about allowing CSP directives in HTML <meta>
tags.
Use case:
---------
My provider just provides the ability to upload HTML and related content,
but they don't provide an option to manipulate the server's output to any
degree. So configuring HTTP response headers is not possible here. However,
I want to protect my web pages just like any other. So the only option I
would have to get CSP applied would be through using HTML <meta> tags.
Axel Dahmen
Axel Dahmen
---------------------------
"Axel Dahmen" <KeenT...@Newsgroup.nospam> schrieb im Newsbeitrag
news:Q_GdneEgtdZJ7RfW...@mozilla.org...
Bil Corry
CSP used to support <meta> policies, but was removed. You probably want to read through these:
http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/571f1495e6ccf822/cf15e2be59a72734?lnk=gst&q=meta#cf15e2be59a72734
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/c0f1a44e4fb98859/31465e3d46ccf806?lnk=gst&q=meta#31465e3d46ccf806
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/87ebe5cb9735d8ca/f9167000431aa6a4?lnk=gst&q=meta#f9167000431aa6a4
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/571f1495e6ccf822/5f75c00c023696bd?lnk=gst&q=meta#5f75c00c023696bd
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/87ebe5cb9735d8ca/87796e2d9caeb36f?lnk=gst&q=meta#87796e2d9caeb36f
There's probably more:
- Bil
Axel Dahmen
Actually I still can't find a fair reason for omitting the option of
allowing HTML <meta> tags to provide CSP directives.
* By means of the intersection algorithm, a <meta> CSP directive can only
tighten security but not loosen.
* Disallowing <meta> tags would cause a significant number of private
websites to not being able to use this security feature. Does someone really
want to exclude all these users from the spec? Just because it would cause
more effort implementing it? What's more important?
Regards,
Axel Dahmen
-------------------------
"Bil Corry" <b...@corry.biz> schrieb im Newsbeitrag
news:mailman.5921.1267370...@lists.mozilla.org...
Daniel Veditz
> Actually I still can't find a fair reason for omitting the option of
> allowing HTML <meta> tags to provide CSP directives.
>
> * By means of the intersection algorithm, a <meta> CSP directive can
> only tighten security but not loosen.
>
> * Disallowing <meta> tags would cause a significant number of private
> websites to not being able to use this security feature. Does someone
> really want to exclude all these users from the spec? Just because it
> would cause more effort implementing it? What's more important?
If we knew that there really were "all these users" clamoring to use
CSP it might be worth working through the complexities, but until we
get a working version out there we won't really know what works and
what doesn't in the real world. It is far, far easier to add <meta>
support later if we need it than to remove a feature if we decide
it's not working out.
Not too worried about injected <meta> tags, we just have to make
sure it can only restrict the page further (which we already have to
do to support multiple HTTP headers).
How do we handle a <meta> tag that comes after some content which a
policy should have regulated? If we decide to only honor <meta> tags
that "come first" then injecting such a header can disable CSP. If
we enforce CSP from that point on there's still page content that
avoided the policy. We could re-parse the entire page and enforce
things the second time around but the injection may have been able
to do its damage already.
This is not an academic question, I've seen a lot of pages with
malware content injected above the normal page content. Is "best
effort" CSP enforcement good enough? Would we be fostering a false
sense of security by supporting <meta>?
"effort" isn't why we cut it. The policy is designed to protect the
integrity of the content and it's much easier to reason about its
security properties and effectiveness when it's delivered external
to that content.
If CSP turns out to be an effective and accepted solution (no inline
scripts is pretty radical) and there's a need for <meta> support we
can add that during the standardization process. At the moment it's
hard to imagine who would benefit from it, though. Yes, I know there
are a lot of people who can't change their headers, but do those
people run web applications that could suffer from XSS and other
attacks CSP addresses?
-Dan Veditz
Axel Dahmen
> It is far, far easier to add <meta>
> support later if we need it than to remove a feature if we decide
> it's not working out.
I see. That is good to know. I was rather anxious that it may had been the
other way around.
> Not too worried about injected <meta> tags, we just have to make
> sure it can only restrict the page further (which we already have to
> do to support multiple HTTP headers).
I see. Yes, that is something I didn't think of yet... Sure, if a malicious
script gained access to the page it would lever existing CSP directives.
Good point..
Well, just brainstorming here, but CSP directives might be restricted to
only be considered if put before any other tag within <head>, during
parsing, before the <meta> directive becomes available to the DOM.
> This is not an academic question, I've seen a lot of pages with
> malware content injected above the normal page content. Is "best
> effort" CSP enforcement good enough? Would we be fostering a false
> sense of security by supporting <meta>?
Good question.
> At the moment it's hard to imagine who would benefit from it, though.
> Yes, I know there are a lot of people who can't change their headers, but
> do those people run web applications that could suffer from XSS and other
> attacks CSP addresses?
No, but it's the opposite way around: These users would be able to utilize
web services in pure client applications. That's the original idea behind my
vote. Please refer to Bugzilla Firefox suggestion #547437
(https://bugzilla.mozilla.org/show_bug.cgi?id=547437) for my original
suggestion on enabling XSS for client-only applications. This suggestion
would become obsolete with the help of CSP and <meta> tags.
Cheers,
Axel Dahmen