MarkItUp not working
Kirill opened this issue · 18 comments
MarkItUp not working:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'".
Thanks Kirill. What is your browser environment? I am trying to replicate.
This is caused by CSP. I haven't tested myself, but using your plugin with Mantis 1.3 under Firefox should let you reproduce the issue.
Problem is here. You need to move your code to a separate file and include it with <script src=... > like you did for the libraries.
Kirill, could you verify correction? I installed Waterfox on my windows machine and I could not replicate (was getting no errors) I applied the changes suggested by dregad. I assume I have to turn on a security setting in my browser?
@bkraul, toolbar present, but images not loaded with such error.
Refused to load the image 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAQAAAC1+jfqAAAAwklEQ…ddoPKf/z2XAooCmwST9br71fbL90v2C+/n7edUoHpc4IYASlr8ehOQ9V8AAAAASUVORK5CYII=' because it violates the following Content Security Policy directive: "img-src 'self'
Kirill. I have made some changes in order to load assets in CSS without having to resort to base64 encoding. This was being done in order to satisfy the .htaccess restriction on the plugins folder in Mantis 1.3. I am now using plugin_page() in order to pull the CSS files and have their referenced assets flow through the plugin file model. Please let me know if this resolves the CSP issue. I still cannot get the CSP errors to happen in my browser. Thank you for your patience and your testing.
No problem. I glad that you extend BBCode and Highlight plugins :)
For now toolbar work.
What about color's?
Kirill, do you have a strict setting in your browser, and if so, how can I turn it on for mine? I run my mantis installation on an intranet. I don't know if that is the reason I am not seeing the errors. I suppose I can try it on a remote domain and see if I can replicate. I think its going to come down to adding a CSP header somewhere in order to allow this. Colors are an inline style because it depends on what the user types/chooses, including html colors.
@bkraul, sorry. I don't know. I have last version from git - branch master-1.2.x. installation from 6-8 yeas ago. I don't remember that I set more security for my installation of MantiBT or browser. And for this issue I install clean version of Waterfox on machine where Firefox not presented.
May be @dregad or @vboctor can comment this situation?
I installed mantis on a remote domain. I am now able to replicate the CSP errors. I am trying to figure out how to overcome this, as I am seeing that the proper policy is in place in the response:
I was also trying to find out if the mantis install adds these headers. I know there is
$g_custom_headers in the options, and it specifically says this:
/**
* An array of custom headers to be sent with each page.
*
* For example, to allow your MantisBT installation to be viewed in a frame in
* IE6 when the frameset is not at the same hostname as the MantisBT install,
* you need to add a P3P header. You could try something like
* 'P3P: CP="CUR ADM"' in your config file, but make sure to check that the
* your policy actually matches with what you are promising. See
* http://msdn.microsoft.com/en-us/library/ms537343.aspx for more information.
*
* Even though this is not recommended, you could use this setting to disable
* previously sent headers. For example, assuming you didn't want to benefit
* from Content Security Policy, you could add 'Content-Security-Policy:' to
* the array.
*
* @global array $g_custom_headers
*/I wonder if plugin_init would let me set a more relaxed CSP, but I don't know, it might just come down to having to set it in the mantis options.
Kirill. I looked and saw that the only way to make inline styles, such as
<span style="color: orange"> which is currently necessary to allow custom colors in bbcode, is being blocked by the CSP because it is an inline style. I see that there are also issues with the markitup previewer because it uses eval(). As of right now, I have only been able to make it work by adding this to the mantis config_inc.php file:
# --- Set content security policy ---
$g_custom_headers['CSP'] = 'Content-Security-Policy: default-src \'self\'; frame-ancestors \'none\'; connect-src \'self\'; style-src \'self\' \'unsafe-inline\'; script-src \'self\' \'unsafe-eval\'';I tried setting this on plugin_init, because there is an example here that sets a header. But seems the only way to override the Content-Security-Policy is by using the options. Obviously the setting I am sending allows everything from self, which I suppose is safe(er). But if you need to trust content from other places you would need to add the domains there.
@damien, would it be accurate to say that the options are limited in this respect?
I suppose I could create classes for colors to use and store them in a css, but then that would eliminate the freedom of using html color codes.
the setting I am sending allows everything from self, which I suppose is safe(er).
It is not safe... the CSP setting is called unsafe for a reason ;-) inline scripts, and to a lesser extent, styles, are vectors for fairly easy-to-implement XSS / man-in-the-middle attacks.
We implemented CSP to increase security, and this is basically disabling it... If your plugin requires such changes to operate, then I would strongly recommend adding a warning in your readme file, installation instructions and/or documentation to inform users of the potential risks.
create classes for colors to use and store them in a css
That would be an acceptable trade-off for increased security IMHO.
I was able to overcome the CSP limitations by using some of the recommended approaches here.
The only tradeoff was that the CSS styles for color and font size are now being applied on $(document).ready. This in order to allow for any color code / font size entered and not have to maintain a list of classes. The performance hit is as little as I could get it, by targeting specific spans by class name matching (ie. I iterate all spans with bbcolor-* classes and process the color that is included as part of the class name. Then the color is added as an attribute to the span element. This is no different than what prismjs is doing at runtime to colorize and highlight code.
Code for this is in bbcode_init.js.
I also modified markitup in order to not use eval() when using the previewer. As a result, I do not have to relax the CSP, per @dregad 's caution.
For now I test and it's work.
Thank you
@dregad quick question for you. Is it recommended/safe to reference plugin_file.php?file=... directly inside of CSS files included with a plugin?
.myclass { background-image: url("plugin_file.php?file=myplugin/myimage.png");In order to handle some of these problems I had to piece together php pages that would stream as CSS files, so that I could use the plugin_file() function, I don't really like that approach. I see that plugin_file() is ultimately turned into a plugin_file.php?file=... url, so I was wondering if that would be an encouraged practice.
I know @Kirill has suggested this on other projects.
Thank you in advance for your time.