I've read through the previous discussion at
http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/d3147f8a4d6b792c#
I'm a little bit confused about inline scripting.
If I understand things correctly, the policy is designed to have some
protection against inline scripts which currently are not implemented
in the demonstrative "proof of concept" add-on that I'm playing with
to test my site.
I have some confusion though about how that is going to be
implemented.
The site I am developing uses very little JavaScript, only the forms
use JavaScript (I server side validate as well). Most of the functions
are defined in an external js file.
One of the functions is dynamically generated when the page is
requested, and put into a CDATA chunk in the head element of the
resulting xhtml. It's my form page, and the form page actually can
generate 4 different types of forms that have many fields in common,
the generated function is the validation script that calls externally
defined functions for the various fields on submit.
I suppose it would be possible to just put four different validation
functions that are very similar in an external file but it made more
sense at the time I wrote it to just dynamically generate the
validation script.
Does CSP allow functions to be defined in the head section of an xhtml
page?
Something else that struck out at me from that discussion was this:
------
Perhaps you should allow something like a single parameter-less
function invocation inside handlers, e.g. allow this:
<img id="img123" onClick="onclickhandlerfoo()">
Obviously you can't allow parameterized functions, as this will open
up security holes, e.g.
eval("something bad")
or
innocent_function(123,eval("bad stuff here"),456)
------
Almost all of my form fields have
onchange="somefunction()"
for pre post validation purposes.
Most of the time I don't pass any parameters but in some cases, I do
pass a parameter - the id of the field calling the function. The
parameter is hard coded, not variable (I don't even do this.id - I put
the actual element id in when the page is generated). IE - I have
fields for air temperature, surface temperature, water temperature,
body temperature - it makes sense to use the same validation function
for each one since each one has the same validation parameters - and
pass the id field to the function rather than having several functions
with the input id in the function.
Further down in the body I have a cdata section that does not define
functions but calls some functions with parameters (the form has a
select menu that is too big, people with javascript enabled get it
replaced with one menu that dynamically generates a second menu). I
can do it without using arguments, it will bloat the external js file
somewhat but it is doable.
Maybe for the form I shouldn't use CSP - the form does not display any
user input data, it just eats user input data, but if I can use CSP on
every page (once it is finalized) I would like to.
I'm not personally *that* worried about XSS in the site I'm putting
together since I designed the site using the php DOMDocument class for
every page (which does a good job of turning malicious input into a
proper xml text node) but I suppose any software has the potential of
being tricked.
Anyway, if the CSP is going to filter out inline JS that calls an
argument, it would be nice IMHO to be able to turn that policy off for
a specific page, such as a form. It sure would make it easier to
implement - and I suspect it will be better received by web devs if it
isn't a complete royal pain to port existing sites to use it.
I do as a user really appreciate that something like this is being
done, I always thought it strange that we freak about executing e-mail
attachments yet the web almost requires you to run scripts in your
browser from unknown sources.
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
