Content Security Policy questions / thoughts

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.
0
FunkyRes
2/16/2009 2:09:03 AM
mozilla.dev.security 649 articles. 0 followers. Post Follow

2 Replies
537 Views

Similar Articles

[PageSpeed] 19
Get it on Google Play
Get it on Apple App Store

OK - I really do need to be able to define a function in the head and
call a function with an argument.

The form allows for uploading files. Thus I set a random upload
identifier so that when submit is pressed and the form client side
validates, a new window pops up with the upload identifies so get the
progress of the upload from my server.

The only way to move that to an external js file is to make the
external js file dynamic and pass the upload identifier to it as a get
variable.

If that's what has to be done I suppose it has to be done, but there
really should be a way to white list inline javascript functions -
allow them if defined in the document head, and allow calling
functions with arguments - since the policy restricts where external
js can come from, the only functions that could be called are either
standard javascript functions or functions defined in an allowed js
file or the document head. Perhaps you could disallow javascript
arguments that call a url not in an allowed domain (but you probably
need to allow a url in the argument for things like opening up an
upload progress window)

0
FunkyRes
2/16/2009 7:54:43 PM
On Feb 16, 11:54=A0am, FunkyRes <Funky...@gmail.com> wrote:
> OK - I really do need to be able to define a function in the head and
> call a function with an argument.
>
> The form allows for uploading files. Thus I set a random upload
> identifier so that when submit is pressed and the form client side
> validates, a new window pops up with the upload identifies so get the
> progress of the upload from my server.
>
> The only way to move that to an external js file is to make the
> external js file dynamic and pass the upload identifier to it as a get
> variable.
>
> If that's what has to be done I suppose it has to be done, but there
> really should be a way to white list inline javascript functions -
> allow them if defined in the document head, and allow calling
> functions with arguments - since the policy restricts where external
> js can come from, the only functions that could be called are either
> standard javascript functions or functions defined in an allowed js
> file or the document head. Perhaps you could disallow javascript
> arguments that call a url not in an allowed domain (but you probably
> need to allow a url in the argument for things like opening up an
> upload progress window)

OK - I'm a bit embarrased, I think it is clear I'm not a web dev by
day ...
I can get the upload identifier externally by getElementById and
looking at the value.
I've got everything in that script external now and working peachy, so
everything in this post can be dis-regarded.
0
FunkyRes
2/17/2009 10:36:43 AM
Reply: