Am 31.08.2011 01:10, schrieb Peter Saint-Andre:
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:
Hello,
[..]
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
xmlns='...muc#request>)
I assume this is about 'Registering with a Room'. There are two parts to
this:
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?
e.g.
---------------------
<message from='user3n...@home.test/pda'
id='yd53c486'
to='room1@chat.example'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/muc#request</value>
</field>
<field var='muc#role'
type='text-single'
label='Requested role'>
<value>participant</value>
</field>
<field var='muc#role'
type='hidden'
label='Requested role'>
<value>moderator</value>
</field>
</x>
</message>
---------------------
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.
Translate is a much better wording than forward.
The attack above might work if the service would forward the hidden
field to the owner/moderator, the owner doesn't see the hidden field,
the field got send back and then the service parses the hidden field and
sets the role as requested in the 2. (hidden) field. I don't know if
there is an implementation which behaves like this, but just forwarding
is imho the wrong thing.
Playing with labels could end bad too, e.g. what happens when the
service forwards a request which contains the following:
---------------------
<field var='muc#request_allow'
type='boolean'
label='Refuse to grant voice to this person?'>
<value>true</value>
</field>
---------------------
Regards,
Alexander
