It was reported that the route /calendar/all/import is not protected against CSRF attacks and this could lead into Denial of Service attacks if the user makes a lot of requests to this route because it will run the calendar import functionality again and again, possibly crashing the site.
You can see this vulnerability by:
1. Enabling the module
2. Create a calendar
3. As an attacker, trick another user with the "administer search_api" permission to open this HTML:
<script>window.location = 'http://example.com/calendar/all/import';</script>
4. If the user opens the HTML, an import is triggered without any confirmation.
Add the _csrf_token as suggested here: https://www.drupal.org/docs/8/api/routing-system/access-checking-on-rout...
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
danrodComment #4
danrodThanks a lot to @prudloff for reporting this issue.
Comment #5
danrodComment #6
danrodAfter some thinking, I've decided to just disable the importing of all the calendar events at
/calendar/all/importand let the user to sync their own calendars at/admin/calendar, there's already a cron hook that imports all the events from all the calendars that can be run at midnight, and allowing the user to do it from/calendar/all/importit's an invitation for a potential DoS.Now, all the requests to
/calendar/all/importwill go to/admin/calendar.I still added CSRF tokens for importing single calendars, for example:
http://example.com/admin/calendar/1/import?token=Pe1Mz72klJE5yeV9xMaksh32Xj_Kl8FYH_yOyLnbW40Ready for review.
Comment #8
danrodComment #9
danrodI'll close this issue and mark it as "Fixed" for now, any anyone has any questions/concerns about this fix, please let me know and I'll re-open the task.
Comment #10
danrodComment #11
danrod