mantis 1.3: Content Security Policy
Moderators: Developer, Contributor
mantis 1.3: Content Security Policy
Dear Atrol,
As i understand mantis 1.3 implements (draconian) Content Security Policy's style-src 'self' and script-src 'self'. I already spent hours trying to figure out how to made MantisStats run under it. I'm not sure it will work out. So I wonder... did you check what kind of impact on plugins will have introduction of this policy before going for it?
Thank you,
Avetis
As i understand mantis 1.3 implements (draconian) Content Security Policy's style-src 'self' and script-src 'self'. I already spent hours trying to figure out how to made MantisStats run under it. I'm not sure it will work out. So I wonder... did you check what kind of impact on plugins will have introduction of this policy before going for it?
Thank you,
Avetis
Mantis Statistics Plugin: https://www.mantisstats.org
Re: mantis 1.3: Content Security Policy
Draconian CSP?
It should be draconian, but it isn't at the moment, see https://www.mantisbt.org/bugs/view.php?id=21263
It should be draconian, but it isn't at the moment, see https://www.mantisbt.org/bugs/view.php?id=21263
Re: mantis 1.3: Content Security Policy
In my (empty) installation CSP is definitively working. Disabling in-line css is not a problem, disabling remote js is not a bit problem too, but disabling inline JavaScript is a serious issue. You are basically disabling usage of JavaScript in mantis. There is no (normal) way to use any advanced JavaScript. I can bring you example of google analytics - something, which every site has. You need to add CSP rule exception to get it working. Similar exceptions are needed for any other non-trivial JavaScript - which obviously you are not going to add. Modern web applications are full of non-trivial JavaScript, there is no way around it. So instead of doing proper user input validation you prefer to keep mantis 'old-style' - html only.
Mantis Statistics Plugin: https://www.mantisstats.org
Re: mantis 1.3: Content Security Policy
I don't understand what you mean with this. We are using JavaScript in Mantis.aavagyan wrote:You are basically disabling usage of JavaScript in mantis.
What I see until now is, that there is a need for a new event that allows plugins to add their own headers.
Maybe you can invest some time and open a PR for it?
At the moment you could set $g_custom_headers to add your own headers.
Not complete sure what you mean with it.aavagyan wrote:So instead of doing proper user input validation you prefer to keep mantis 'old-style' - html only.
JavaScript is no proper input validation, it's just additional input validation on client side for user's convenience and to have less server traffic.
It's not a replacement of server side validation.
JavaScript validation might be 'old-style' quite soon, at least for common use cases.
The new HTML5 validation methods are supported in modern browsers. Why write JavaScript code (which can be disabled by users) if just a bit HTML5 does the same in a even better way?
https://www.w3.org/TR/html5/forms.html# ... validation
http://www.456bereastreet.com/archive/2 ... put_types/
Re: mantis 1.3: Content Security Policy
You define $t_script_src = "script-src 'self'" in http_api, which disables usage of in-line JavaScript. This effectively sets usage of JavaScript to very minimum. If you need illustration to my statement - even google analytics won't work (something, which everyone is using) in such setup. To make it work, you need to white-list it.atrol wrote:I don't understand what you mean with this. We are using JavaScript in Mantis.
What I see until now is, that there is a need for a new event that allows plugins to add their own headers.
Maybe you can invest some time and open a PR for it?
At the moment you could set $g_custom_headers to add your own headers.
...
JavaScript is no proper input validation, it's just additional input validation on client side for user's convenience and to have less server traffic.
...
The change (Content Security Policy) was definitely made to increase security against XSS/CSRF - something, which is normally done by having proper input validation and not by introducing such Content Security Policy.
Although changing $g_custom_headers is not great and no-one is going to like making such change in order to be able to run a plugin, this looks to be the only solution for the moment (there are tricks to store JS in hidden form fields and then run these, but this is too ugly).
I agree that this is the way forward (to be able to while-list plugin JS) for future versions of MantisBT.atrol wrote:What I see until now is, that there is a need for a new event that allows plugins to add their own headers.
Maybe you can invest some time and open a PR for it?
Thank you.
Mantis Statistics Plugin: https://www.mantisstats.org
Re: mantis 1.3: Content Security Policy
@aavagyan,
starting with Mantis version 1.3.1 there is a new event EVENT_CORE_HEADERS to add headers
https://github.com/mantisbt/mantisbt/co ... c7ada3a9d9
You can use function http_csp_add to add a header
https://github.com/mantisbt/mantisbt/co ... 6911a4dc5a
starting with Mantis version 1.3.1 there is a new event EVENT_CORE_HEADERS to add headers
https://github.com/mantisbt/mantisbt/co ... c7ada3a9d9
You can use function http_csp_add to add a header
https://github.com/mantisbt/mantisbt/co ... 6911a4dc5a
Re: mantis 1.3: Content Security Policy
@atrol,
Thanks a lot. This is going to help all plugin developers. Obviously plugin developers should try to minimize change to standard - default setting.
Thanks a lot. This is going to help all plugin developers. Obviously plugin developers should try to minimize change to standard - default setting.
Mantis Statistics Plugin: https://www.mantisstats.org
Re: mantis 1.3: Content Security Policy
Plugin developers should not just try to minimize changes to standard, they should not change the standard.aavagyan wrote:Obviously plugin developers should try to minimize change to standard - default setting.
The nice way for plugins would be to do it in a way that adds the minum that's needed to get the functionality.
E.g. we call just http_csp_add( 'img-src', self::getAvatarUrl() ); in our own Gravatar plugin that comes with Mantis.
Re: mantis 1.3: Content Security Policy
@atrol,
Thank you for you response. In gravatar plugin, which you referred too (version shipped with MantisBT 1.3.1) I see this:
=====================
...
function hooks() {
return array(
'EVENT_USER_AVATAR' => 'user_get_avatar',
'EVENT_LAYOUT_RESOURCES' => 'csp_headers',
);
}
/**
* Add Content-Security-Policy for retrieving Avatar images.
*
* @return void
*/
function csp_headers() {
# Policy for images: Allow gravatar URL
if( config_get( 'show_avatar' ) !== OFF ) {
# Set CSP header
header( "Content-Security-Policy: img-src 'self' " .
self::getAvatarUrl() );
}
}
...
=====================
I think that line "...header( "Content-Security-Po..." is killing whole CSP. Or not?
Thank you.
Thank you for you response. In gravatar plugin, which you referred too (version shipped with MantisBT 1.3.1) I see this:
=====================
...
function hooks() {
return array(
'EVENT_USER_AVATAR' => 'user_get_avatar',
'EVENT_LAYOUT_RESOURCES' => 'csp_headers',
);
}
/**
* Add Content-Security-Policy for retrieving Avatar images.
*
* @return void
*/
function csp_headers() {
# Policy for images: Allow gravatar URL
if( config_get( 'show_avatar' ) !== OFF ) {
# Set CSP header
header( "Content-Security-Policy: img-src 'self' " .
self::getAvatarUrl() );
}
}
...
=====================
I think that line "...header( "Content-Security-Po..." is killing whole CSP. Or not?
Thank you.
Mantis Statistics Plugin: https://www.mantisstats.org
Re: mantis 1.3: Content Security Policy
This is what I see at https://github.com/mantisbt/mantisbt/bl ... avatar.php
No call of function header()
Code: Select all
function csp_headers() {
if( config_get( 'show_avatar' ) !== OFF ) {
http_csp_add( 'img-src', self::getAvatarUrl() );
}
}
Re: mantis 1.3: Content Security Policy
You are right - I had older version.
Mantis Statistics Plugin: https://www.mantisstats.org