Subscribers track their subs too so it's simple to refuse non-matching updates quickly with a 404. But that's playing softball - the entire attack relies on the Subscriber's server being misconfigured or vulnerable to start with. So this is largely FUD - the same risk applies to all pubsub models relying on DNS. The protocol can't address unrelated security issues.
Paddy Sent from my iPhone On 22 Nov 2009, at 06:57, Ravi Pinjala <[email protected]> wrote: A few of the scenarios he lists are worrying, especially the one where a malicious user generates a large number of subs using unique query strings, and then redirects their DNS to some victim. How would something like this be mitigated? On some level, it's difficult to distinguish between somebody legitimately sub'ing to a large number of feeds, and somebody doing the same with the intent to point them at somebody else later on. I forget - is there any way for a subscriber to actively refuse an update, and indicate to the hub that the subscription is invalid? Something like that might help sub'ers mitigate some of these attacks. --Ravi Brett Slatkin wrote: James Holderness has written some critique of PubSubHubbub security: http://www.xn--8ws00zhy3a.com/blog/2009/11/pubsubhubbub-security-concerns It'd be nice if he had posted to this forum or provided another forum of his own for a response, but either way I plan to write something to go over all of his concerns. In the meantime, I'm happy to say that I think every issue he points out has already been or can easily be mitigated in the hubs that are out there, the biggest help being automatic subscription refreshing (http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#autorefresh) which can narrow the window of any attack significantly. In my view, his concerns further validate the idea that delegating to hubs is the correct model for real-time feeds, since it's very difficult to get all of the security and DoS details of an implementation correct for every publisher out there. -Brett
