RSS “security”

I was on a call the other day with some folks in the industry, and someone made a comment to the effect of “we really need to come up with some kind of solution for securing RSS feeds – then we can really do some cool stuff.” Before I could get on my soapbox, someone else on the call concurred with the first person.  When I mentioned that this stuff has been figured out already, and started describing the existing widely-used mechanisms, they were both a bit surprised, and suggested I write something about it.  So here we go. :-)

There has been much talk about “RSS security”. The problem is, that’s such a vague term, and you can’t really make much progress until you actually break that down into what you really mean. So let’s give that a shot.

When most folks are talking about security with RSS, they tend to mean three things (or any combination of these):

authentication

authorization

encryption

Let’s take these topics one at a time.

Authentication – this basically means that you want to be able to identify the user who is requesting your feed. There are well-known solutions here – in particular, the tried-and-true HTTP authentication mechanisms, including Basic and Digest. These are the same authentication mechanisms we use on the internet for subscriber-only web sites, and they are equally applicable to RSS.  Behind the firewall, you could add NTLM/Kerberos authentication for Windows networks.

Most mature RSS aggregation tools (NewsGator Online, NewsGator Outlook edition, FeedDemon, NetNewsWire, lots of others) support these widely-accepted authentication mechanisms.

And for those using Windows servers, I’ve even written some sample code for .NET that implements these protocols on the server side, without using the built-in IIS implementation with Active Directory.

Authorization – this means that once you know who the user is, should they be allowed to access the content they are requesting?  This is the easy part…once you’ve authenticated the user requesting the feed, you know who they are, so you can now decide whether they should be allowed to access the content.  Again – just like regular web sites.

Encryption – this means that if someone is watching my network with a network sniffer of some sort, or they’ve managed to insert themselves in the network path between the client and server, then they would be able to see the content going by…so we encrypt it.  The easy way to do this is with SSL – again, exactly how we do it for regular web sites.  And this is usually as easy as adding a certificate to your web server(s), and changing your URL to https.

Piece of cake. Use the mechanisms that have been around for 10+ years securing web content, and you won’t go wrong.

“But wait,” you say. The authentication and encryption mechanisms I mention above are tied to HTTP.  What if you want to transport a feed via some other protocol?

Well then you’d have to think of something else.  You’d likely see what authentication mechanisms are supported by your new transport of choice, and leverage those.  Hmm.

My advice for now?  Don’t worry about it.  RSS today is transported via HTTP.  Sure, you could use other protocols – but almost no one does.  This same argument came up some time ago about SOAP web services…a lot of work went into making sure everything was portable enough to deliver SOAP messages through any arbitrary transport.  But in real life?  Almost no one is doing it.

We don’t need more protocols. We don’t need yet another encryption standard. We don’t need yet another authentication mechanism. Use what works today – it’s proven itself already.

I’m going to write some more about this in the next few days – first, about how an online aggregator should and shouldn’t implement this, and what to watch out for as a user.  There have been some serious problems in the past with flawed implementations of authenticated feed handling, and it’s caused some problems in the community for users…so I’ll write about that as soon as I get a chance.

22 Comments

22 thoughts on “RSS “security””

  1. From RSS security to Web 2.0 security

    a title=’Greg Reinacker’s post on RSS “security”‘ href=”http://www.rassoc.com/gregr/weblog/archive.aspx?post=775″>Greg Reinacker’s post on RSS “security” is timely for me. I’m also having similar conversations with people wondering how to secure RSS. The key point to keep in mind is that RSS uses…[more]

    Reply ↓
  4. Securing Feeds

    Greg Reinacker of NewsGator has as smart post about security in XML feeds where he makes a strong argument for reusing prior art: My advice for now? Don’t worry about it. RSS today is transported via HTTP. Sure, you could…[more]

    Reply ↓
  5. RSS and Security

    As RSS becomes more popular, it’s inevitable that people will begin talking about security and companies will release “secure RSS related products.”  Before the feeding frenzy on RSS and security begins, it’s useful to step back and think about what is already in place and available.  Greg Reinacker – the founder / CTO of NewsGator – takes a crack at this in his recent post titled “RSS ‘security’”….[more]

    Reply ↓
  6. Web services security and RSS

    At least one web services security vendor recently made some noise about securing RSS. Why this is interesting, beyond the fact that RSS & blogs are good for generating press articles, we can’t tell. But Greg Reinacker offers a perspective in his blog on …[more]

    Reply ↓
  8. More on Secure RSS

    Following on from my previous post, Greg Reinacker of Newsgator fame, has posted his thoughts on how to secure RSS feeds. His conclusion, RSS is transported over HTTP, and mechanisms for authentication, authorisation and encryption already exist for HTTP –…[more]

    Reply ↓
  9. RSS Security

    Missed some of the earlier conversations, but I picked up Mark O’Neil’s excellent summary on RSS Security. My own view – people are seeking private RSS – which is not equal Secure RSS – RSS is an XML flavour, which…[more]

    Reply ↓
  17. Alessandro

    I believe that RSS should remain open and public standart. if you need any private solution – choose somethink else. RSS was initially created for public.

    Reply ↓
  19. Dui

    I know this article is rather old, but is this still a problem with RSS today? I just stumbled on this page. Honestly, I wasn’t aware that this was even an issue.

    Reply ↓
  20. Shaun Drutar

    So you talk about security from the perspective of the publisher. I would like to hear your thoughts on risks to the end user. Thus far RSS subscribers are exposed to similar risks as web browsers. The real exception here is the automated download of RSS and podcast type content. In corporate environments “most” RSS users are protected by the various layers of web content filtering already in place for HTTP traffic. Add anti-virus and other host based defenses, you are somewhat protected as a subscriber. If you account for zero-day exploits and attacks, the risk from RSS is very real…but still somewhat mitigated.

    Reply ↓
  21. Nick Harris

    @Shaun –

    Security on the subscriber side is also dependent on what program you’re using to consume RSS. The risks are similar to those of a browser, but with programs like FeedDemon, Inbox or NewsGator Desktop, they’re actually much less.

    Both FeedDemon and Desktop use and embedded copy IE, but with much more control over what IE will allow to run. In both programs, javascript is disabled which thwarts most common exploits. Since Inbox is an Outlook add-in, it also inherits Outlook’s security model as further protection.

    Nick Bradbury has a post (http://nick.typepad.com/blog/2006/08/feed_security_a.html) which goes into more detail about FeedDemon.

    On top of that, our enterprise solution uses a centeral server that does the actual retrieval of RSS items then distributes it out to users within the enterprise. As items are retrieved they are scrubbed of potential security issues before they are delivered to end users. It adds another layer of security on top of the things you mention.

    Reply ↓
  22. Madhu

    Hi
    I am looking out for ways to do authorization. I need to check if the user is eligible for viewing the particular contents depending on the mail id which i fetch from outlook. How do i do it ?

    Reply ↓

Leave a Reply