Re: Content Security Policy discussion (link)

[pceelen]

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 - Relaxed Restrictions Mode(s)

[Bil Corry]

FunkyRes wrote on 7/1/2009 5:43 AM: 
 A library of function examples that do things cross platform in a
 fully CSP compliant way would be a godsend, and IMHO preferable to
 taking the easy way out and loosening up the enforcement.

I personally use jQuery to abstract the cross-platform issues:

http://jquery.com/


- Bil

___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Re: Content Security Policy - Relaxed Restrictions Mode(s)

[Jonas Sicking]

FunkyRes wrote:

On Jun 22, 4:15 pm, Brandon Sterne bste...@mozilla.com wrote:

Some sites have shared the desire to use some features of CSP, but not
all of them at once.  For example, a site may want to utilize the
content loading features of CSP to help prevent data exfiltration, but
they may not want to be subject to the JavaScript restrictions which are
enabled by default (no inline script, no eval, etc.).

We have made two additions to the spec that we think will address these
needs:

1. Sites can opt-out of no inline scripts by adding the inline
keyword to their script-src directive.
2. Sites can opt-out of no code from strings by adding the eval
keyword to their script-src directive.

These additions may enable some sites, who would otherwise be deterred
by the JS restrictions, to adopt CSP in a limited fashion early, and
later do a full implementation as resources permit.

Cheers,
Brandon


One thing I would find greatly beneficial is examples of how to do
things properly in a cross browser compliant way.

For example, for form validation - form onsubmit=return checkform
() just works.
I've figured out (I think) how to properly attach most events
externally - like onchange, onclick, etc. - but whenever I try to
attach something to the submit event of a form, the script runs but
then the form data is posted to the action page regardless whether it
returns true or false. It just works with the inline onsubmit
attribute.

Part of the problem is IE and Firefox have different ways to attach
events, but I think there must be some concept I just don't get about
how the submit event works that isn't a problem with inline.


If you do:

myForm.onsubmit = function() {
  return checkform();
}

I think it should work. Otherwise

myForm.addEventListener(submit, function(event) {
  if (!checkform()) {
event.preventDefault();
  }
}, false);

should work in any browser that implements DOM-Events. Unfortunately IE 
does not yet.


/ Jonas
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security