[#32983] - [4.0] Improve CSP, second attempt
- Closed
- 4 May 2021
- Medium
- Build: 4.0-dev
- # 32983
- Diff
- Fedik:csp-fix1
User tests: Successful: 0 Unsuccessful: 0
Summary of Changes
It seems most confusing part of CSP is "mode" selection, especially when it set to "auto".
So I have dropped mode selection, and "auto-header" generation (we can review it in future).
And turned the CSP component to User configurable.
Also Reporting configuration was changed. Now it possible to enable reporting and "report-only" in separated options.
This allows to collect Reports for live site with enabled "Content-Security-Policy" header.
New CSP workflow:
- Enable CSP component, this also will enable reporting.
- Set up CSP rules (in component config).
- Navigate through the site, visit different pages.
- Go to CSP reports page in the backed, and check if here any report.
- Adjust CSP rules (in component config), or fix blocked content, and clean up the report list.
- (optionally) turn of the "Report"
Testing Instructions
Before you begin: make sure your test site domain not localhost or IP
Apply patch.
Enable CSP in component configuration.
Make sure "Client" is Site
Make sure "Report" is Enabled.
Make sure "Report-Only" is Off.
step 0
Visit to the site, make sure it is working, nothing broken.
And the CSP report is empty.
step 1
Add 2 rules in CSP component configuration.
default-src: 'self'
img-src: 'self'
step 2
Create a custom HTML module, with background, with some text and with an external IMG:
<img src="https://picsum.photos/300/300" width="300" height="300" />
Check the module on the site.
The module will not show images.
step 3
Got to the CSP report page, in backend.
administrator/index.php?option=com_csp&view=reports
You should see at least 2 blocked elements: 'unsafe-inline' and https://picsum.photos/300/300
step 4
Update CSP rules in the component configuration, to next:
default-src: 'self' 'unsafe-inline'
img-src: 'self' picsum.photos *.picsum.photos
Visit to the site and check that the module is working.
Clean up the report and make sure there no more blocked elements: 'unsafe-inline' and https://picsum.photos/300/300 after further Site navigation.
Documentation Changes Required
Yes, the CSP documentation page need to be updated, to reflect the changes.
Additionally need to warn User that the editor may add inline style so he/she may need to add 'unsafe-inline'.
And that CSP and localhost not a best friends.
@zero-24 please review
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_csp Language & Strings Front End Plugins |
until core is completely reviewed it will have to be used
For the site the only issue for it is the mod_custom background,
and it is fixed in separated PR.
But for the Administrator, yes, that true.
UPD:
Default CSP config pointed to "Site".
Probably this should be noted in documentation.
For the site the only issue for it is the mod_custom background,
and it is fixed in separated PR.
If only that was true. Navigate the site (with sample data) and watch the errors in the browser console
Ah yea got it.
Right, it can come from the editor, well then it should be really noted in documentation.
upd: I have removed that warning from description.
But note: the default rules is empty (after this PR), so it should not break anything, by just enabling CSP.
We basically gives to User a tool, he/she free to decide what he/she will allow.
Right, it can come from the editor,
and core outputs such as tags
richard67
-
Add 2 rules in CSP component configuration.
default-src: 'self'
img-src: 'self'
Without doing anything else I visited the frontend
And the reports page has 25 items
ouch, that new, something "localhost" related,
I do not have such error because I have "virtual domain"
I need to ask google :)
It seems that for localhost testing you have to allow localhost domain,
the rule should be not self, but self localhost or self http://localhost this need to test
upd: this also something that need to add to documentation
Just another reason why this entire component is not suitable for core
It seems that localhost untrusted in CSP by default. (https://stackoverflow.com/a/50472608/1000711)
If all your previous test also was on localhost, that may explain everything ;)
btw, I would say that "Step 1" of your test was successful,
because now you can see why and where it filed, and what to do (compared to "before patch")
If you familiar with "hosts" file ( /etc/hosts ) you can try add virtual domain :
127.0.0.1 localhost brianteeman.local
then open your site with brianteeman.local/joomla-path/ url
I have updated description.
If all your previous test also was on localhost, that may explain everything ;)
Never got as far as setting up any directives :)
| Labels |
Added:
?
?
|
||
note: test fails because JS code style, not related to this PR
Add/include contentsecuritypolicy:1 to the showon of Report-Only?
good point, I will update
| Labels |
Added:
?
|
||
If tested with a clean Cassiopeia local - not on locahost but on a virtual Domain.
I find this CSP-function very important for Joomla 4 and have also been able to implement everything I wanted. However, I also think that not everything is crystal clear for users. Perhaps you agree with me on the points I mention below. I find that everything can be explained with a hint.
But first:
- After install, the plugin was active and the component was inactive as default.
The headers after install:
To make it short: The test scenarios you described in the intro comment worked for me fine.
Moreover I noticed the following.
- I was confused by the fact that the setting of some headers are possible in two places in the plug-in. The upper one (in the picture) overwrites the lower one. It is still
x-frame-options SAMEORIGIN.I had expected the opposite.
- It is in my eyes not self-explanatory which setting is taken when I activate the component and set
content-security-policy default-src 'self' img-src 'self'in the plugin.
For example: I set this in the plugin
and this in the component
I expected, that the picture from picsum.photos is not loaded. But it was loaded. This are the headers:
If I deactivate the component, the picture is hidden and the headers are from the plugin:
- There is also no hint in the component that the plugin must be activated. In my opinion this would be good. Especially in connection with point 2 . The result of point 2 led me to the thought that the plugin might not be necessary for the component. But if I activate the component and deactivate the plugin, I only see the header from the .htaccess.
- We need documentation, that explains, what I should enter into the field of the Plugin, if I use
Force Http Headers. I have to look into the code, to know, what is the value forReport-to
okay, I see, then I close this one
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-04 20:01:29 |
| Closed_By | ⇒ | Fedik | |
| Labels |
Added:
?
Removed: ? |
||
Yes thanks for all the support and effort you put into this here.
until core is completely reviewed it will have to be used