Possibly another release blocker.
On 7th October 2020 I reported four security issues with the com_csp to @joomla/security the JSST. Im pleased to say that most were addressed back then including invalid data storage, persistent XSS and the ability to post reports for storage when the feature was disabled.
However one still remains unresolved and as the JSST have stated they are no longer interested in private reporting of security issues for Joomla 4, and that they should be posted here, and with the recent increase in com_csp fixes, I'm posting here now.
The problem is, the new com_csp, in detect mode, allows you to post UNLIMITED times to the report endpoint
This can allow an attacker to make your database huge, and ultimately your server will run out of disk space.
There is no rate limiting on the number of rows a single IP address can create.
Assumption: mySite.com is your own site. example.com is a made up domain name that can change each request.
Set up: Enable CSP with client = both or site, and Mode = detect.
Make a command line curl post:
curl --location --request POST 'http://mySite.com/index.php?option=com_csp&task=report.log&client=site' \
--data-raw '{ "csp-report": {
"document-uri": "http://example1.com/css/style.css",
"referrer": "",
"blocked-uri": "http://example1.com/css/style.css.css",
"violated-directive": "style-src cdn.mystyles.com",
"original-policy": "default-src '\''none'\''; style-src cdn.mystyles.com; report-uri /_/csp-reports"
}
}'
then change example1.com to example2.com and run the post again. Do this until you get to example100.com and then visit the Content Security Policy report log in Joomla admin and see all 100 reports.
Multiply this by X times... = a database that is huge, keep going, and you will eventually run out of disk space on the server.
No other place in Joomla allows the public to create unlimited rows in their database without authentication.
Implement rate limiting - possibly investigate the Symfony Rate Limiter Component
Implement arbitrary limits - make them up but make them sensible
implement some kind of time limited checksum in the report URL advertised with each request
Limit the number of reports that can ever be stored at one time. No one is ever going to need 1million reports in their database, they might never need 100... again an arbitrary limit could be guessed at
read and digest https://csper.io/blog/csp-report-filtering and take any things we can learn from people that have been here before us. Eg. Blacklists "his technique alone cuts out ~50% of the weird reports."
// Tagging @brianteeman @Fedik
Labels |
Added:
?
|
The fact that no one else is even testing it
I tested extensively in October 2020, and it was found lacking back then, as per my initial comments about the security issues I reported :-(
you were included in the people who tested and not the else ;)
For what its worth I do remember attending a presentation by scott helme at BSides a few years ago about only recording a fraction of the reports to prevent exactly what you are describing but I can't find it now.
Considering you can script this to flood the db table within seconds, only storing a fraction of those, will just delay the inevitable and not fix the issue :)
Still not found the info from the presentation but did find the solution to your reported issue by only reporting the issue for the specified host. See the description/explanation https://scotthelme.co.uk/fixing-mixed-content-with-csp/
I had this issue in my head also,
tbh I have no idea,
Limit the number of reports that can ever be stored at one time. No one is ever going to need 1million reports in their database, they might never need 100... again an arbitrary limit could be guessed at
yea, maybe some limitation would make sense
lipstick on a pig https://en.wikipedia.org/wiki/Lipstick_on_a_pig
Interesting stat from report-uri.com
21k sites generated 517 billion reports
btw, if your site have enabled Redirect component and "collect 404 url", you can do very similar,
just do request with random URL every time:
http://mySite.com/blabla/nonexistingpage1
http://mySite.com/blabla/nonexistingpage2
http://mySite.com/blabla/nonexistingpage3
...
...
...
http://mySite.com/blabla/nonexistingpage1000000
No other place in Joomla allows the public to create unlimited rows in their database without authentication.
so we already have that place
Seems we need the same fix for both com_csp, and system/redirect plugin
/faceplam
The saving grace here is that both issues are disabled by default on sites and are opt-in.
yea, maybe some limitation would make sense
$log_file_size_limit = 1000000; // bytes - once exceeded no further entries are added
well considering we are not logging to a file, but to a database, setting a log file size makes no sense :)
well considering we are not logging to a file, but to a database, setting a log file size makes no sense :)
I know, but one idea often leads to another.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-04 19:38:42 |
Closed_By | ⇒ | zero-24 |
its all a waste of effort. This component is clearly not suitable for core. The fact that no one else is even testing it shows that none of the testers think its something they would use and therefore will spend time testing.