[Standards] request for reviews: XEP-0045 v1.25rc5

Ralph Meijer ralphm at ik.nu
Tue Sep 6 09:09:19 UTC 2011

On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote:
> [..]
> I don't see any reason why the user should send a form to the server.
> If using a form is wanted, the correct way would be that the user 
> requests a form for the request from the server, and sends back the 
> result, which is then processed by the server (resulting in a form for 
> the moderator).
> The described way where the user generates a form only makes sense, if 
> that form is forwarded to the moderator. But that would result in the 
> possible problems I've described (e.g. hidden fields and wrong labels).

I don't see how requesting a form from the service first somehow makes
this better. An attacker could simply ignore that form and submit its
own bad one.

A service implementation simply needs to always check foreign inputs
against its internal definitions of allowed fields with their types and
ignore the rest. Whether you are using plain XML or our Data Forms does
not really matter.

Given solid library support, handling forms correctly is quite easy. In
Wokkel I first parse incoming forms into an internal representation, and
as a second step I can type-check the values against a set of field
definitions for that form type. This will interpret the incoming form
according to those definitions, *not* against whatever the peer happens
to pass along (i.e. type attributes that do not match the type in the
field definition will raise an error).

Let's look at your example:

<message from='user3none at home.test/pda'
          to='room1 at chat.example'>
   <x xmlns='jabber:x:data' type='submit'>
     <field var='FORM_TYPE'>
     <field var='muc#role'
            label='Requested role'>
     <field var='muc#role'
            label='Requested role'>

In Wokkel, the form would be rejected in the first step because it has
more than one 'muc#role' field. If the submitted form would only have
the second field, with type hidden, it would be rejected in the second
step because the field type didn't match.

For plain XML you would need to do similar things. Your example:

<message from='user2 at example.com/box'
          to='room2 at chat.example.com'>
   <x xmlns='http://jabber.org/protocol/muc#request' type='submit'>
     <item affiliation='member' nick='someone'/>

Several possible attacks for libraries that aren't too careful checking
their inputs:

1) There could be more than one item element:

   <x xmlns='http://jabber.org/protocol/muc#request' type='submit'>
     <item role='participant' nick='someone'/>
     <item role='moderator' nick='someone'/>

2) The namespace of the second <item/> element could be different from
its parent. Example:

   <x xmlns='http://jabber.org/protocol/muc#request' type='submit'>
     <item role='participant' nick='someone'/>
     <item xmlns='http://www.jabber.org/protocol/muc#request'
           role='moderator' nick='someone'/>

3) The namespace of the attributes could be different, or their could be
one in the empty namespace and one in another:

   <x xmlns='http://jabber.org/protocol/muc#request' type='submit'>
     <item xmlns:muc='http://jabber.org/protocol/muc#request'

In short, I don't think that passing along the form as-is, is much of an
issue. The client receiving the request can do several checks (like
duplicate fields) and when the form comes back, the MUC service needs to
check its inputs anyway. Also, this particular example tries to obtain
the moderator role (even though your XML examples use 'affiliation'). A
service should not honour requests other than 'participant', because
requesting voice is just that.

That said, having the service vetting the form before passing it along
wouldn't hurt, of course. A slight rewording of the text could achieve
that. I just don't see enough reason to change the actual protocol at
this stage of development of this specification.


More information about the Standards mailing list