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.
Maybe I just take that 'forward' to literal, but I don't like it.
Regards,
Alexander
