How can I secure an icalendar (.ics) subscription?

Question

I have a multi-user website and want to publish an individual icalendar subscription file (.ics) for each user.

Our apache server is configured to only provide access over https.

One method I have considered is, when the user first asks for their subscription URL, generate a long, random secret key and include that in the URL. A hash of that key would then be stored in the database. Example: https://site.com/calendar/user_id/dQXeCgtiOmZ5lAXoedmujiuA47VmCgA5OIfE6vZ8BhJT3Rxh20b9Ci.ics

All pages in our cakephp app require the user to be logged in (expect the login page obviously). I would configure the ics file to also not require the user to be logged in, but to only display when the correct secret key (tested against the hash) was supplied.

Are there any drawbacks to this method?

Is there a different method that I should be using?

I have seen examples of people including basic authentication in the subscription URL, but that sounds like it would be worse. Example: https://user:[email protected]/calendar/user_id

This is being deployed in a school environment, so the iCalendar subscriptions contain fairly mundane things such as class timetables and assignment due dates, but I still want to keep it secure.

Answer 1

The drawback to adding non-expiring secrets to urls is that they may 'leak' to other systems. Anything that reads an iCalendar feed will not really consider the feed url itself to be very sensitive, and these urls may be stored in parts of the system that other applications may read.

The iCalendar feeds may be cached, so cached copies of that feed + their secrets may live in local browser caches, corporate network caches and other intermediaries.

When a user clicks a url like that for the first time, browser toolbars may log the request and send it to external services as well.

That's just a few vectors. Using basic auth is not worse, just don't embed it in the url and require from the user to type their password again.

I can't decide for you whether any of this is an acceptable risk though. We do use secret urls for some stuff.