[rabbitmq-discuss] Forcing headers on incoming commands
rob at rabbitmq.com
Thu Jan 6 10:21:43 GMT 2011
On Mon, 27 Dec 2010 21:26:04 -0500, Mike Keen <mkeen.atl at gmail.com> wrote:
> I'm part of a small group working on a realtime social game powered by
> RabbitMQ/STOMP and run on Flash clients in the browser.
> We've run into some security concerns related to exposing our STOMP port
> the public. Specifically, we've noticed that without the "exclusive:
> header in an initial subscription (even to an anonymous queue), and the
> socket is dropped before the client sends a clean disconnect, the queues
> remain open for a pretty long time (at least a few minutes). This has
> to the concern that an attacker might be able to create any number of
> that could hang around and waste memory, or even lead to memory being
A few things have changed in the STOMP adapter that make this a bit
Most importantly, custom headers such as 'exclusive' are no longer
supported. Instead, we now support destination types with set semantics.
The support destinations are /queue/<name>, /topic/<name> and
/exchange/<name>/<routing_key>. The /queue and /topic types are designed to
work as closely to the corresponding types in ActiveMQ as possible.
For /queue, created queues are now durable and are not exclusive. This
means that it is a separate administration task to clean up queues. This is
designed to match ActiveMQ.
For /topic, a queue is created per SUBSCRIPTION, but only lasts for the
duration of that subscription. That means that after all subscribers to a
topic destination disconnect, no queues exist for that topic.
I recently updated the README for this. The changes are still going
through QA, but the relevant revision can be found here:
> Two questions considering the above:
> 1) Is it possible to set, through the config file, to force
> = true on every new queue creation on the server?
This isn't possible at the moment. I don't think we have any plans to
introduce such a feature.
> 2) Is this a legitimate security concern? Or would a massive number of
> queues (all bound to a topic exchange) not be enough to cause
Well, importantly, you can only create queues if you are an authenticated
user, so the attacker would need to get past that hurdle first. I have a
task to add SSL support for STOMP which will make sending credentials in
the CONNECT header a lot safer :)
Also, if you're using /topic destinations (probably the easiest way in
the new adapter to access topic semantics), then you would have to have a
large number of active subscriptions in order to have a large number of
queues. RabbitMQ handles large numbers of queues nicely, so for this to be
a major problem, you'd need to a large number of subscriptions created on a
topic that has a large publish volume. The subscriptions would have to be
in ack:client mode and would need to *not* ack the messsages. Even then,
new support in RabbitMQ 2.2.0 for handling large ack volumes means that you
a really only limited by disk space when it comes to the ack backlog.
One possible issue is that storing transaction state for STOMP transaction
takes up a non-trivial amount of RAM, so creating massive transactions and
not committing them could lead to out of memory. For this reason, I can
imagine a configuration option that allows for transaction support to be
I hope this helps.
> Thanks in advance for your help.
More information about the rabbitmq-discuss