On 6/29/09 10:02 AM, Brandon Sterne wrote:
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.
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.
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
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
