Thursday, October 11. 2007
Secure RSS with DrProject
Situation: DrProject has a very useful timeline feature, which shows all the activity (tickets opened/closed, source control checkins, wiki edits, etc) relating to a project. To make things even better, there is also an option to export this feed as RSS (now, [this is also slightly broken][960], but that's another story).
Problem: If students are using DrProject to manage a marked project, there should be no way that students in one group can see the timeline another group. From the web interface, this is handled by the standard authentication mechanism... But there is no standard mechanism for authenticating RSS feeds. And, even if there was, students should not be giving their CDF passwords to online news reading services (both because the service might do Something Bad with it and because people should not be in the habit of giving out their credentials).
Current solution: Turn off RSS.
That's a really crappy solution.
What can be done?
Well, Andrew Louis and I were talking about it yesterday, and we were discussing a few of the different mechanisms used by similar web pages.
Flickr, for instance, assigns each user an arbitrary ID. After they register a name, there is no way to see this ID. If you manage to find a person's ID (either before they register a name or through some other means), there is nothing stopping your from taking a look at any of their feeds (take a look at the photos from my contacts!). Ok, so that's a pretty crummy solution.
Facebook is a bit more interesting. It assigns each feed a random ID. To view a feed, you need to know both the user's ID (easy to get) and the random ID (hard to get): http://utoronto.facebook.com/feeds/friends_status.php?id=1658670036&key=c16adb2zcd&format=rss20.
But this isn't quite good enough. If someone gets hold of the secret key, it's all over.
So what can we do?
Well, else can we use to tell the difference between you and me? What about the headers our newsreaders send? The IP block our request originates from? How frequently we check the feed?
Ok, so it might be tricky to implement a frequency-checking heuristic... But it would be easy to say "hhmm... Last time you checked this feed, you used Google Reader. But this time your User-agent tells me that you are curl. Something's up!"
When a user wants to read an RSS feed, they are given a URL with a unique key. The first time that feed is accessed, the User-agent string (and possibly other headers) are recorded. On subsequent requests, the values are compared and if there is a significant change (for some value of "significant") [edit] and the old key will be invalidated. The legitimate user will be asked to re-validate the next time they download the feed.[/edit]
This will not make attacks impossible, but will certainly frustrate them, because the attacker must get the headers right on the first try. [edit] If they get it wrong, they will have to wait for the legitimate user to get a new key, find that key, then try again. [/edit]
Problems:
- What if someone checks their feed from both an online service (such as Google Reader) and a newsreader on their laptop?
They just generate two keys -- I don't see any reason that one user should not have more than one key associated with them. - What if the headers change from less sinister actions?
No problem -- getting a new key will be a matter of a couple of clicks. - But doesn't that mean all the old items will be marked unread?
Yes. Is there a way to fix that? - Isn't there still a possibility of attack?
Yes, it is possible. But, hopefully, it will be hard enough to thwart casual attackers.
So, any comments?
Postscript 0: What about OpenID?
It looks really neat. In theory, it would solve this problem. In practice, though, there are two issues:
- Added complexity -- we would either have to build an OpenID server into DrP or rely on an external server.
- Limited support -- at the moment, only a handful of readers have support for OpenID (Google Reader being, I believe, a notable exception)... And we don't quite have the market share to change that. At least not yet
Another potential problem is if someone doesn't protect their subscriptions on a service like bloglines. If someone sees the protected feed and adds it, there wouldn't even be a second request to the feed coming from bloglines.
Also, to nitpick about Flickr, the userid comes up in more places than you might imagine and it's definitely not intended to be private. Its role in the feed URI is as a unique id (especially important since you can change your display name and flickr url). Flickr understands that this is not a secure feed so friends-only photos and private correspondence will never show up in your feeds.
Ah, that's a good point... That the online readers will only download one copy of the feed, then distribute that to all the subscribers.
Drat, there goes this idea.
If security is such a concern, send an email for each timeline update instead. The gmail interface makes reading entries at least as easy as any RSS reader.
That's not a bad idea, but there are many people (me) who don't use GMail.
That said, there is an option to send an email when tickets are changed, so I suppose that it could make sense to send them for other things.
What about the simple solution of forcing HTTPS and include clear notice about privacy before handing over a RSS URL (ie. to make sure DrP users don't blog, digg, etc it).
Have I missed something here? Dave Cooper
The problem is malicious attackers.
Suppose you left your computer logged in (although we all know that you would never do that 
) and someone grabbed the feed URL. That's the sort of thing we're trying to protect against.
Hmm. Physical access is a huge breach of security anyway.
There needs to be a demarcation of what is acceptable security in Dr Project. Maybe that could be configurable?
HTTPS + HTTP authentication sounds like something easy to implement.
That is true... But physical access is NotOurProblem™.
What do you mean by "there needs to be a demarcation of what is acceptable security in DrP"? Is that "big scary messages" demarcation? Or check boxes in the admin interface that say something like: "Security level: [ ] Open source project [ ] College project course [ ] Windows Kernel"?
And the problem with HTTP auth is that many readers don't support it. When I pointed Google Reader to an authenticated zone, it said something like "feed not available" (now, this is just fine with me... I'm not much for web apps doing things that desktop apps should do. But Greg uses Google Reader 
)
Now, because it would be easy to implement, I may Just Do It some time... Especially if I'm going to be using DrP next semester
"Suppose you left your computer logged in (although we all know that you would never do that ) and someone grabbed the feed URL. That's the sort of thing we're trying to protect against."
Maybe it's just me, but I don't think an RSS feed link being stolen is the one of the main concerns in that situation.
David Cooper
"If [attackers] get [the key] wrong, they will have to wait for the legitimate user to get a new key, find that key, then try again."
That fixes one problem by creating another. An attacker could deny service (disable legitimate feeds) by setting up a script that frequently uses wrong keys.
That said, users should at least have the ability to generate new keys.
Quicksearch
Archives
Links
Categories
Syndicate This Blog
Powered by
