Security-focused post about PubSubHubbub

[Brett Slatkin]

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

[Pádraic Brady]

He posted the link to the rsscloud list so I suggested he also post it here - I have no idea why he hasn't. Unfortunately his blog doesn't accept comments either. I've asked to re-post here - it's silly throwing out an article like this without checking his assessment with the list.

While his points appear valid from their brief descriptions, a lot of it is a litany of faults only possible by ignoring common sense and are met by many web applications out there without issue. I mean who designs web apps to download GBs from a blind URL? It breaks the first rule of web app security - never trust your users ;).

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

---

From: Brett Slatkin <bsla...@gmail.com>
To: pubsubhubbub <pubsub...@googlegroups.com>
Sent: Sun, November 22, 2009 12:14:30 AM
Subject: [pubsubhubbub] Security-focused post about PubSubHubbub

[Ravi Pinjala]

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

[Pádraic Brady]

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

[Joseph Scott]

Wouldn't simply including a hub challenge style verification for sent
updates address this? Redirecting DNS to a targeted URL, like
http://google.com/, is likely to return an HTTP status code of 2xx
simply because it won't specifically be looking for PSHB updates. But
it's very unlikely to look for and return a valid hub challenge string
when receiving that update. Once that fails a few times the
subscription would get dropped.

That's far from perfect, but it's a step better than allowing hubs to
be a blind relay.

On Sun, Nov 22, 2009 at 12:41 AM, Pádraic Brady <padrai...@yahoo.com> wrote:
> 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.

--
Joseph Scott
jos...@josephscott.org
http://josephscott.org/

[James Holderness]

Joseph Scott wrote:
> Wouldn't simply including a hub challenge style verification for sent
> updates address this?

It would help but, as you say, it's far from perfect.

IMO, what you should be using is an HTTP continue expectation.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3

Regards
James

[Brett Slatkin]

Hey James,

Thanks for following up in this forum. The HTTP continue is an
interesting suggestion. I'm still putting together a reply to your
original post (and Joseph Scott's) so hopefully I'll have more for us
to discuss shortly.

-Brett