0
votes

is it possible to create new users (In-band registration) using anonymous user using Strophe.js like in the example here: http://groups.google.com/group/strophe/browse_thread/thread/a0e15ae226b91a3a?fwc=1 . I managed to register new users with an existing account only (as a normal "not admin" user). Is that a openfire security issue? I connected anonymously using:

 connection.connect("server.local", null, onConnect);

The server returns:

 <iq xmlns="" type="error" id="reg2" to="[email protected]/7711fc7f">
    <query xmlns="jabber:iq:register">
        <username>user</username>
        <password>abc</password>
    </query>
    <error code="400" type="modify">
        <bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    </error>
</iq>

If I connect with a registered user it works fine and I can create other users. Would it be unsecure to allow registration from a dedicated user account say [email protected] (with no admin rights) ?

1

1 Answers

2
votes

I managed to register new users with an existing account only (as a normal "not admin" user). Is that a openfire security issue?

This depends on your point of view - if that's what you want, no it isn't a security issue. If you want to restrict account creation to admins in your deployment, yes it is. Openfire should have configuration parameters to control who can create accounts (though in some versions these controls simply don't work - that was a security issue!).

There are known scripts around that actively discover and register accounts on servers with open registration. Some people (especially large targets like jabber.org) choose to disable in-band registration entirely, while others simply place per-IP rate-limiting restrictions on it. There is also a specification (XEP-0158) for CAPTCHAs to be sent to clients for in-band registration, but support for this is far from universal yet.

The server returns:

The error stanza you gave has xmlns="", which is suspicious to my eyes. It should be "jabber:client", but it seems Openfire understood it anyway.

You could also try setting the 'to' address of the request to the host that you are trying to register on (e.g. to='example.com' when registering '[email protected]'). If you are already setting 'to' then try without it. I have seen different interpretations of the specifications around this point.