Re: Content Security Policy discussion (link)
After reading the specs, it is clear that the main aim is to prevent 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. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy discussion (link)
On 26/06/09 22:42, Bil Corry wrote: 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy discussion (link)
Gervase Markham wrote: On 26/06/09 22:42, Bil Corry wrote: 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 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 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy discussion (link)
On 29/06/09 18:02, Brandon Sterne wrote: 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 [0] http://tools.ietf.org/html/draft-abarth-mime-sniff-00 ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy discussion (link)
Sid Stamm wrote on 6/26/2009 11:44 AM: 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). 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 - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
