Content Security Policy discussion (link)
Sid Stamm
Some discussion about CSP has recently popped up on the mozilla wiki:
https://wiki.mozilla.org/Talk:Security/CSP/Spec
I'm posting the link here in case anyone interested hasn't seen it yet.
Comments are welcomed (both here and there).
Cheers,
Sid
Gervase Markham
> It's been brought up this morning on the WASC Web Security list too:
>
> http://www.webappsec.org/lists/websecurity/archive/2009-06/msg00086.html
The linked blogpost suggests using the page itself as an E4X document to
bypass the restrictions. Dead clever :-) Should we say that CSP also
requires the external JS files to be served with the right Content Type?
(application/javascript)? That would reduce the possibility of the
attacker using random content they've managed to create on the remote
server as a script file.
Gerv
Brandon Sterne
That is clever. Yes, I think you're right that we should enforce a
valid MIME type for the external script files. We probably also want to
whitelist application/json for sites utilizing JSON feeds.
-Brandon
Sid Stamm
> Gervase Markham wrote:
>> The linked blogpost suggests using the page itself as an E4X document to
>> bypass the restrictions. Dead clever :-) Should we say that CSP also
>> requires the external JS files to be served with the right Content Type?
>> (application/javascript)? That would reduce the possibility of the
>> attacker using random content they've managed to create on the remote
>> server as a script file.
>
> valid MIME type for the external script files. We probably also want to
> whitelist application/json for sites utilizing JSON feeds.
I agree that enforcing the types is a good idea. This is something we
should probably do in general (not just for CSP) as a form of sanity
check.
With regards to the nifty E4x self-referential attack... not only is the
MIME type different than 'text/javascript', but I think referencing the
body of the current document as the "src" of a script should be
considered /inline script/, and thus disallowed by the "no inline
scripts" CSP base restriction. If for some reason CSP supported this, I
would consider it a bug.
The code is not in an external file and mixed content (JS + HTML) is
dangerous... pretty much exactly what CSP is trying to separate. The
spec currently states "Script in files loaded from white-listed sources"
is allowed[0], and technically while this script is in a white-listed
source (the base HTML document), it's also an inline script. I think we
should change the allowed script statement from "Script in files loaded
from white-listed sources" to "Script /imported/ from /external/ files
hosted by white-listed sources". This makes more explicit that CSP
requires scripts to be separated from the data in the base HTML page.
-Sid
[0]
https://wiki.mozilla.org/Security/CSP/Spec#No_inline_scripts_will_execute
Gervase Markham
> That is clever. Yes, I think you're right that we should enforce a
> valid MIME type for the external script files. We probably also want to
> whitelist application/json for sites utilizing JSON feeds.
It does make you think, what other brokennesses can we fix along the way
while sites are opting in to this new model? Can we, for example,
enforce the correct MIME types for images too, and throw away all that
horrible sniffing[0]? How about feeds? ;-)
Gerv
pceelen
executable code within HTML files. I do agree that CSP enables web
developers to create more secure websites. In my view there is one
problem:
How is CSP going to prevent lousy web developers to include all their
dynamic content in Javascript files? I see a risk that webdevelopers
create empty HTML files and include all the content in generated
javascript files. (maybe future versions of web-frameworks will
support CSP like this??). In these situation CSP more or less shifted
the problem from *.html to *.js files.
Should we consider this situation? Or should we just ignore web
developers that do not understand the web standards?
To prevent this we should have some requirements about the static
nature of the js files. One mechanism that might implement this is
adding requirements for static js files by requiring code-signed
javascript files (is this possible at the moment?
http://www.mozilla.org/projects/security/components/signed-scripts.html
describes signed scripts, however it requires the creation of a
*.jar). In such a situation code signed javascript should be signed by
an offline key.
Daniel Veditz
> To prevent this we should have some requirements about the static
> nature of the js files. One mechanism that might implement this is
> adding requirements for static js files by requiring code-signed
> javascript files (is this possible at the moment?
> http://www.mozilla.org/projects/security/components/signed-scripts.html
> describes signed scripts, however it requires the creation of a
> *.jar). In such a situation code signed javascript should be signed by
> an offline key.
There is no cross-browser support for signed javascript. With the
current CSP the site will work perfectly well in browsers that don't
support CSP. CSP is already asking site authors to do a lot of work, but
since it works in all browsers sites can transition slowly (such as
writing new content to that standard, leaving old content alone). If CSP
requires separate content for CSP-supporting browsers it will never fly.
pceelen
> There is no cross-browser support for signed javascript. With the
> current CSP the site will work perfectly well in browsers that don't
> support CSP. CSP is already asking site authors to do a lot of work, but
> since it works in all browsers sites can transition slowly (such as
> writing new content to that standard, leaving old content alone). If CSP
> requires separate content for CSP-supporting browsers it will never fly.
I completely agree upon the backwards compatibility arguments, however
my original post was not about signed JS. It was more or less a
suggestion for a solution.
In my original post I tried to address the problem of a shift from XSS
in *.html to XSS in *.js. What if webdevelopers
create empty HTML files and include all the content in generated
javascript files?
1: Should we consider this situation?
2: Do you agree with this risk/problem or is it unlikely that it will
happen?
3: Are there any other technical solution to prevent/mitigitate this
risk?
In the current specs it appears that we are more or less assuming that
js files are more or less static...