[Standards] request for reviews: XEP-0045 v1.25rc5
stpeter at stpeter.im
Tue Aug 30 23:10:02 UTC 2011
On 8/23/11 6:34 AM, Alexander Holler wrote:
> Am 23.08.2011 11:23, schrieb Ralph Meijer:
>> On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote:
>>> And in my list before, I've forgotten to mention the problem that for
>>> requests a form is send by the user to room, which the room then
>>> forwards to moderators, and the moderators will see the form with the
>>> room as sender.
>>> I see it as a problem if the MUC-service really forwards such a request
>>> without checking every content. And if the service has to check
>>> everything of the form, there is no reason why a form must be send by
>>> the user, the service could build the form too and something more simple
>>> could be used for requests (e.g. something like<x
>> I assume this is about 'Registering with a Room'. There are two parts to
> I meant the wording e.g. in 8.6:
> "As noted in the Requesting Voice section of this document, when a
> service receives a request for voice from an occupant it SHOULD forward
> that request to the room moderator(s)."
> That 'forward' is what makes me nervous.
>> You appear to want to check the values sent to the room admin/owner, but
>> why? What attack vector do you believe needs to be addressed?
> One of the first things I first thought about is what happens with
> fields of type 'hidden' in the request. I haven't checked any
> implementation, but I could imagine implementations which really would
> just forward such fields which then might end in the approval form send
> to and back from the moderator. Playing with UTF-stuff in (forwarded)
> labels could allow some funny things too.
OK, but what is the attack?
Are you concerned about an attack against the room admins or an attack
against the MUC service?
The room will translate the user's request into the kind of form shown
at http://xmpp.org/extensions/xep-0045.html#voiceapprove and the admin
will click a few buttons (e.g., approve or deny) before returning that
form to the service. So there's no real attack here against the room
admin, or on the room as far as I can see. But I think it would be
better to say that the request is translated by the service into the
kind of form shown in Section 8.6.
More information about the Standards