0
Undo
Votes
I think I found a security-relevant design problem with Jevents calendars, namely the integration of Google calendars as described here: https://www.jevents.net/docs/jevents/item/authorisation-icals-and-google-imports
In order to update the calendars, you have to call a URL like so:
https://<YOUR-URL-HERE>/index.php?option=com_jevents&icsid=2&task=icals.reload
First off, instead of calling that URL by a cron task, it would be better to do this with a "Get Request" via the Joomla Task Scheduler (https://magazine.joomla.org/all-issues/march-2022/get-to-know-the-new-joomla-task-scheduler).
But note that this URL is externally accessible and contains a nearly static "icsid", probably 2 if you only have one calendar. Thus, the URL for a DOS attack is easy to guess.
As there is no authentication on this URL whatsoever, so anyone can call it as often as they like.
In order to fix this, there are four levels of better security for this in ascending order:
1. At least, the icsid should not be sequentially assigned, but random, to obfuscate the URL. This can be achieved by users by changing the icsid in the corresponding database table to a random id.
2. The task or the whole component could be protected by a password or token.
3. If the cron scheme must be kept at all, the job should not be called by accessing a URL, but provided by the component as a PHP script that is only accessible from the host itself. By doing this, a cron job would not call "curl", but PHP with the script path, thereby avoiding an accessible URL.
4. The best way to fix this IMHO is to provide a task for the component that can be activated in the Joomla Task Scheduler and to avoid URLs and cron altogether.
On a side note: There are other "tasks" provided by the component like "day.listevents", which I saw flashing by when I tried this. I did not look into any further, but those may be prone to similar attack vectors as well, as they seem also to be unprotected.
In order to update the calendars, you have to call a URL like so:
https://<YOUR-URL-HERE>/index.php?option=com_jevents&icsid=2&task=icals.reload
First off, instead of calling that URL by a cron task, it would be better to do this with a "Get Request" via the Joomla Task Scheduler (https://magazine.joomla.org/all-issues/march-2022/get-to-know-the-new-joomla-task-scheduler).
But note that this URL is externally accessible and contains a nearly static "icsid", probably 2 if you only have one calendar. Thus, the URL for a DOS attack is easy to guess.
As there is no authentication on this URL whatsoever, so anyone can call it as often as they like.
In order to fix this, there are four levels of better security for this in ascending order:
1. At least, the icsid should not be sequentially assigned, but random, to obfuscate the URL. This can be achieved by users by changing the icsid in the corresponding database table to a random id.
2. The task or the whole component could be protected by a password or token.
3. If the cron scheme must be kept at all, the job should not be called by accessing a URL, but provided by the component as a PHP script that is only accessible from the host itself. By doing this, a cron job would not call "curl", but PHP with the script path, thereby avoiding an accessible URL.
4. The best way to fix this IMHO is to provide a task for the component that can be activated in the Joomla Task Scheduler and to avoid URLs and cron altogether.
On a side note: There are other "tasks" provided by the component like "day.listevents", which I saw flashing by when I tried this. I did not look into any further, but those may be prone to similar attack vectors as well, as they seem also to be unprotected.
meyergru
set the post as Critical priority — 1 year ago
We have implemented an option to include a secure key in the anon-update URL for the next release. This has not been reported as an issue historically
Implementing the execution in the joomla task scheduler is probably a good idea though the timeliness of execution relies on sufficient visitors reaching your site to trigger the artificial cron.
other tasks such as day.listevents etc. are core to the public facing performance of JEvents and if you are concerned about impact of these on site performance then you can make your calendar accessible to logged in users only or use page caching in Joomla
Implementing the execution in the joomla task scheduler is probably a good idea though the timeliness of execution relies on sufficient visitors reaching your site to trigger the artificial cron.
other tasks such as day.listevents etc. are core to the public facing performance of JEvents and if you are concerned about impact of these on site performance then you can make your calendar accessible to logged in users only or use page caching in Joomla
JEvents Club members can get priority forum support at the Support Forum. As well as access to a variety of custom JEvents addons and benefits. Join the JEvents club today!
If the task scheduler is not triggered because of lack of site visitors, then nobody needs an updated calendar in the first place.
What I meant was that such internal functions should never be exposed through a URL. As I wrote, I have not looked into what other functions are available which could have adverse side-effects. If, for example, there were additional API functions that can modify settings, delete items or something similar, they could be exploitable, and potentially not merely for DOS attacks.
What I meant was that such internal functions should never be exposed through a URL. As I wrote, I have not looked into what other functions are available which could have adverse side-effects. If, for example, there were additional API functions that can modify settings, delete items or something similar, they could be exploitable, and potentially not merely for DOS attacks.
- Page :
- 1
There are no replies made for this post yet.