Copy of an email I sent to http://tech.groups.yahoo.com/group/rss-cloud/messages:
I’ve been looking into the security of rssCloud over the last few days and a number of serious issues have come up. The ones of immediate importance have been reported and fixed, but I’d like to suggest some protocol changes to prevent rssCloud servers from DoS’ing sites or ending up DoS’ing each other.
Here are my implementor guidelines, based on the research over the last few days. These guidelines should mitigate all of the problems I’ve found so far without requiring rssCloud subscribers to make major changes to their code:
- An rssCloud implementation MUST validate that the Content-Type of the POST is “application/x-www-form-urlencoded”.
- All rssCloud parameters MUST be read from the body of the HTTP POST (ie: $_POST in PHP or equivalent in other languages). Parameters in the querystring must be ignored.
- The path parameter for the callback path MUST begin with a /.
- The port parameter, if specified, must be converted to an integer value before constructing the callback URL with it. Any trailing non-digit characters must cause the hub to return a 5xx error.
- The subscription callback and all subscription pings MUST include a “challenge” parameter (inspired by PubSubHubbub). The subscriber MUST respond with a response that contains the contents of that challenge parameter as the body of the response. No additional information may appear in the body.
I haven’t taken a look at the SOAP/XML-RPC parts of the protocol yet, but the extra framing should help make them more secure. Someone more familiar with those technologies should run those through their paces.
Feel free to contact me with any rssCloud hub implementation you might have and I’ll run my battery of tests against it.
[...] to share example code or which shared host(s) are vulnerable. Thankfully the fix is easy: follow my security recommendations to close the [...]
[...] has a serious vulnerability that needs to be addressed in the protocol. I’ve linked some security recommendations here that rssCloud hubs should implement as soon as [...]
Could you explain all that again? What is the motivation for each of the five requirements?
Regarding the DoS, would the following be another possible solution:
If a subscriber gets a ping for something it doesn’t expect, it returns an HTTP 403 “Forbidden”. RssCloud hubs receiving 403 responses to a ping, in accordance with the HTTP protocol, understand they are not to send the ping for that feed again.
This means no validation step would ever be necessary– every ping action has the capability to discover its desirability by looking at the HTTP response.
Sure, an attacker could attempt to sign you up for a million feeds, but it would take a million requests from the attacker to the cloud, and you’d reject each ping the first time it happens, buying the attacker nothing.
(multiple subscription URLs with a single call, as Dave added to the spec, might have to be disallowed–for this and other reasons.)
Mason,
Each of those items came from a specific issue I found on either Dave’s server or the WP rssCloud plugin. 1-2 are prevent reusing POSTs from other systems to force an unwanted subscription. 3-4 are to prevent URL construction attacks (ie: WP rssCloud used to let you sign up with a path of @otherserver.com). 5 is to prevent signing up arbitrary endpoints that can be exploited to DoS a service (ie: search endpoints).
The big problem is that you can sign up something that isn’t actually a subscriber- ie: the search interface of some random web forum. I mentioned this elsewhere, but rssCloud verifies the “ability of the endpoint to accept POST” rather than the “intent of the endpoint to accept rssCloud subscription pings”.