Hi all, When I get a newsletter (no matter the recipient or the source of the content) I get a warning to allow the content which I do click to allow. The problem is that images on the newsletter are not loading at all while of course they do exist on the proper paths. Right click open image in new tab works fine and displays the image. Same newsletter if I forward it to my gmail account looks as it should (loads the images). I thought in the first place that some of my modsecurity rules was causing this but I put all servers under detectiononly mode and still the same. Anyone with an idea?
Open the developer tools of your browser and go to console. Then load the mail and see if there are any errors in the console.
The errors are the same in all newsletter but is not true, it throws 404 for images but the url is correct and working fine if I call it direct: Code: Failed to load resource: the server responded with a status of 404 (Photo not found) and also: Code: Refused to load the image 'https://mydomain.com/uploadimages/image/username/travel.png' because it violates the following Content Security Policy directive: "img-src 'self' data:". Forwarding the same email to any gmail, yahoo etc account works fine, it is only under ISPconfig that throws the above and doesn't work.
Alright so there's a content security policy set for the domain you are reaching the webmail on. This prevents the image from being loaded. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP aswell. One fix might be to access the webmail on a separate site (webmail.example.com) that doesn't have a CSP set. See https://www.howtoforge.com/communit...roundcube-on-ispconfig-3-2.85483/#post-411229 which explains ow you can create te site.
@Th0m this is the default installation as per docs under https://controlpanelserver:8080/webmail I don't want to change the url as is been used from many clients so far. Is there any solution without adding a new virtual host /url ?
Set different csp headers for roundcube, you could do that in a .htaccess file for apache, or in vhost config for apache or nginx.
In /etc/apache2/sites-available/ispconfig.vhost comment out the "Header set Content-Security-Policy (...)" lines. But this will be overwritten on ISPConfig update. Though I think a better and future proof solution would be to create a separate website and communicate this to your customers (especially when they have issues like you report now). You can also set up a redirect for /webmail that goes to webmail.example.com.
I think you mean Roundcube You could unset it aswell: Code: nano /var/lib/roundcube/.htaccess at the top, add add Code: Header unset Content-Security-Policy
It would be better to set a csp that is appropriate for the application than to completely unset it because it different from what ispconfig uses. I haven't worked on determining what exactly is needed, but both http://roundcube-webmail.10982.n7.nabble.com/Content-Security-Policy-for-Roundcube-td14905.html and https://github.com/roundcube/roundcubemail/issues/6202 show policies being used by others, which would be a starting point.
@Jesse Norell from the first link they do have: Code: Header unset Content-Security-Policy Header always set Content-Security-Policy "default-src 'unsafe-inline' 'unsafe-eval'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self'; frame-src 'self'; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'" but even the user that is posted is not sure if the first line with the ‘unset’ is needed. Correct me if I'm wrong but all that content-security-policy can be grabbed from OWASP modsecurity rules as well if anyone have them in place.
These CSP headers are a separate thing from modsecurity rules, this is strictly the http server instructing the http client how to act. The correct, or best settings are applications specific, you can't just grab a random set. Well, you could and try and it might work, but it's better to understand what each setting specifies and choose the most secure option for the application. Eg. in roundcube, you will be opening/viewing html that comes in email from any random source, so you sure don't want to allow it to open script from a remote site (which would be allowed if CSP were completely unset), and you really don't want to allow inline script either, but if roundcube itself uses inline script (I don't know if it does), you would have to allow 'unsafe-inline' or roundcube wouldn't function right. A better solution would be to change roundcube to not use inline script itself, so it didn't require allowing it in CSP. And it might do that, I'm just tossing this out as an example. I've not dug into this for roundcube yet, though I'd like to look at it more, as it is an important security setting.
Actually per the notes in I think the first thread I linked to, it required unsetting the header (which in our case would be set for what ISPConfig uses) before setting a new value, so doing both was correct. I've not tried it.
