Write-only permissions on STOMP queues

[jmico]

When a STOMP plugin (or WebStomp) is open to the internet you can't completely trust on login credentials:

• Untrusted remote users should not be able to write on resources which other users read. A /topic open to the internet should be read-only, otherwise a malicious actor can inject malformed or false data to another users.

• Untrusted remote users should not be able to read on resources which other users write. A /queue open to the internet should be write-only, otherwise a malicious actor can disrupt a service consuming from the queue, as data sent to it will never reach its intended destination. It also allow to easily obtain data submitted by other users, which could be a security problem.

Currently /topic can be properly made read-only with set_topic_permissions. Temporary queues /temp-queue are secure, as only the connection that creates them can read from it.

The problem is that currently there is no mechanism to forbid certain STOMP users from consuming from /queue, as set_permissions is not fine grained enough.

A broad restriction forbidding SUBSCRIBE to any queue will be enough. It could even be hardcoded to guest user.

[michaelklishin]

The scenario where you open up a broker for public writes is hardly a common one. /amq/queue gives you the most flexibility. We don't have plans to change the permission system. Unfortunately no system would work equally well for all four protocols we support.

[michaelklishin]

Yeah and we most certainly don't want to introduce any changes that would be hardcoded to a specific user or cover a very specific use case such as "an overlay that prevents all consumption". The permission system actually is flexible enough but STOMP has so many ways of doing things using different destinations that there always will be a blind spot of some kind.

/queue/{name} destinations use the same naming scheme which is user-independent, and it makes it harder to separate permissions for STOMP users but it is not the case for other protocols and even STOMP destinations.

[jmico]

Thanks for your reply :)