Content Security Policy (CSP) settings and calender.js

[Prasad Muley]

Hey All,

       I need to set Content security policy settings in http headers.  I've referred content-security-policy and Mozilla CSP links.

I've set it according these links.

models/db.py

CSP_SETTINGS = "default-src 'self' ; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"

#settings to http headers

response.headers['Content-Security-Policy'] = CSP_SETTINGS

#setting CSP for firefox

response.headers['X-Content-Security-Policy'] = CSP_SETTINGS

#setting CSP for Chrome,Safari and IE

response.headers['X-WebKit-CSP'] = CSP_SETTINGS

#table

db.define_table('Person', 

                          Field('FName', 'string', notnull=True),

                          Field('LName', 'string', notnull=True),

                          .

                          .

                          Field('DOB', 'date'),

                          format="%(FName)s %(LName)s")

 Web2Py internally uses calender.js for 'date' field.

The problem is  calender.js uses "eval" function and CSP settings are giving an error on chrome.

 Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'"

 [ Please find attachment.] 

I've two options as:

 1) Modify calender.js or use other date plugin 

 2) Add 'unsafe-eval' in CSP settings.

Any suggestions? 

[Niphlod]

I don't get what you're asking for. If you choose to create your own policy and part of your application uses something that your own policy discards, there's nothing web2py can do.

[Dave S]

On Tuesday, December 30, 2014 7:32:15 AM UTC-8, Niphlod wrote:

I don't get what you're asking for. If you choose to create your own policy and part of your application uses something that your own policy discards, there's nothing web2py can do.

If it were me, I'd be asking for suggestions that either

a) modify the policy in a way that maintains security but allows the calendar.js to work
  (this would likely be a suggestion from someone with experience with security policies)

b) suggest a way to remove the dependency on 'eval'
 (this would likely be a suggestion from someone with experience swapping js files under web2py)

It's possible that there's a fundamental conflict, though, that makes either type of suggestion difficult.

/dps

[Niphlod]

On Tuesday, December 30, 2014 8:35:23 PM UTC+1, Dave S wrote:

On Tuesday, December 30, 2014 7:32:15 AM UTC-8, Niphlod wrote:

I don't get what you're asking for. If you choose to create your own policy and part of your application uses something that your own policy discards, there's nothing web2py can do.

If it were me, I'd be asking for suggestions that either

a) modify the policy in a way that maintains security but allows the calendar.js to work
  (this would likely be a suggestion from someone with experience with security policies)

 

the policy is a single-line header with no possibility to set "per-file" policies, i.e. allow eval for just calendar.js
 

b) suggest a way to remove the dependency on 'eval'
 (this would likely be a suggestion from someone with experience swapping js files under web2py)

The scaffolding app "adoptes" a calendar widget that is not forced upon anybody (web2py is a python framework to make apps, and the scaffolding app is not a solution for every problem). If "eval" in calendar.js is such a threat that the app (or the coder) can't take, he should evaluate another widget.

[Dave S]

On Tuesday, December 30, 2014 12:00:01 PM UTC-8, Niphlod wrote:

On Tuesday, December 30, 2014 8:35:23 PM UTC+1, Dave S wrote:

On Tuesday, December 30, 2014 7:32:15 AM UTC-8, Niphlod wrote:

I don't get what you're asking for. If you choose to create your own policy and part of your application uses something that your own policy discards, there's nothing web2py can do.

If it were me, I'd be asking for suggestions that either

a) modify the policy in a way that maintains security but allows the calendar.js to work
  (this would likely be a suggestion from someone with experience with security policies)

 

the policy is a single-line header with no possibility to set "per-file" policies, i.e. allow eval for just calendar.js

Is there a lesser setting that allows eval without allowing too much of other "threats"?  Could changing to that setting
be justified to management (aside from the IE defense:  "The normal user has a working visit if we do it that way").
 

 

b) suggest a way to remove the dependency on 'eval'
 (this would likely be a suggestion from someone with experience swapping js files under web2py)

The scaffolding app "adoptes" a calendar widget that is not forced upon anybody (web2py is a python framework to make apps, and the scaffolding app is not a solution for every problem). If "eval" in calendar.js is such a threat that the app (or the coder) can't take, he should evaluate another widget.

So the OP  should be able to  strip out calendar.js, and substitute another?  Does someone in the community have pointers to a good choice, especially one that can be slid in easily?  Are there already examples at web2pyslices.com?  (My quick scan only came across an unanswered question at
<URL:http://www.web2pyslices.com/slice/show/1525/how-to-get-the-drop-down-date-selector-by-default>)


/dps

[Niphlod]

Is there a lesser setting that allows eval without allowing too much of other "threats"?  Could changing to that setting
be justified to management (aside from the IE defense:  "The normal user has a working visit if we do it that way").
 

no, there isn't. either you allow eval "for all" or you don't.

 

So the OP  should be able to  strip out calendar.js, and substitute another?  Does someone in the community have pointers to a good choice, especially one that can be slid in easily?  Are there already examples at web2pyslices.com?  (My quick scan only came across an unanswered question at
<URL:http://www.web2pyslices.com/slice/show/1525/how-to-get-the-drop-down-date-selector-by-default>)

Everyone can...the question is, did anybody try before looking into pre-baked solutions or any app MUST come from a general cut&paste of the internet :-P ? This carries a different widget that is compatible with bs3 https://github.com/niphlod/cs_monitor_plugin

 

[Dave S]

On Wednesday, December 31, 2014 12:39:44 AM UTC-8, Niphlod wrote:

Everyone can...the question is, did anybody try before looking into pre-baked solutions or any app MUST come from a general cut&paste of the internet :-P ? This carries a different widget that is compatible with bs3 https://github.com/niphlod/cs_monitor_plugin

I can't  speak for the OP, but since I'm still climbing the learning curve on web apps, I need a lot of hand-holding (and this group has helped me out a lot).

/dps