mantis 1.3: Content Security Policy

[aavagyan]

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

[atrol]

Draconian CSP?
It should be draconian, but it isn't at the moment, see https://www.mantisbt.org/bugs/view.php?id=21263

[aavagyan]

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.

[atrol]

You are basically disabling usage of JavaScript in mantis.

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.

So instead of doing proper user input validation you prefer to keep mantis 'old-style' - html only.

Not complete sure what you mean with it.
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/

[aavagyan]

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.

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.
...
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).

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?

I agree that this is the way forward (to be able to while-list plugin JS) for future versions of MantisBT.

Thank you.

[atrol]

@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

[aavagyan]

@atrol,

Thanks a lot. This is going to help all plugin developers. Obviously plugin developers should try to minimize change to standard - default setting.

[atrol]

Obviously plugin developers should try to minimize change to standard - default setting.

Plugin developers should not just try to minimize changes to standard, they should not change the standard.
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.

[aavagyan]

@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.

[atrol]

This is what I see at https://github.com/mantisbt/mantisbt/bl ... avatar.php

Code: Select all

	function csp_headers() {
		if( config_get( 'show_avatar' ) !== OFF ) {
			http_csp_add( 'img-src', self::getAvatarUrl() );
		}
	}

No call of function header()

[aavagyan]

You are right - I had older version.