Security in openfire web interface - csrf

Openfire Openfire Dev
1

Hello everybody.

I would like to fix some security issues in the web interface.

I started by submitting a pull request that is supposed to fix xss injection vectors.

Now I would like to add some sort of csrf (cross site request forgery) protection.

What I would do is to add a token to the session once the user is authenticated.

And then check on every request that is changing data somehow if the token was sent as part of the ‘form-data’.

This would break API usage; in case there is any.

To address the API users, I would do the following:

Check if either the right token is set, or if a special header is sent that a normal web-browser could not generate on an attackers behalf.

Any comments? Does my plan make sense to you? Am I overlooking something?

While reading some code, I found other issues that might need a closer look. But first I would like to go for the low hanging fruit.

Anybody interested in teaming up?

Thanks for your time,

Best regards,

Sven

2

Hi Sven -

Thanks for your efforts on this. I think your approach will work fine, and would be a welcome improvement to the Openfire product. I would be happy to review and/or assist as needed. Feel free to continue working on it and submit pull request(s) as appropriate.

As for “API” usage of (or programmatic access to) the Openfire admin console, it seems to me that this ought to be discouraged anyway. Openfire is already highly configurable and has provided a plugin API for proper integration and component development. In fact, if you decide to implement an access control header to allow this, I would also request that we also provide a separate configuration property to enable this capability (effectively disabling console-based integration by default).

I have a few other suggestions as well:

  • I would recommend that we disallow and/or remove any existing GET operations for admin console commands, to help prevent leakage of the CSRF session token by avoiding vulnerable query-string parameters.
  • By extension, this approach will only be secure if the admin console is accessed via SSL (port 9091). An appropriate warning message on the non-secure login page could be helpful in this regard.
  • The CSRF session token name should be configurable via system properties, with a sensible default value.
  • If implemented, the CSRF access control header name should be configurable via system properties, again with a sensible default value.

In any case, welcome to the Openfire community. Look forward to working with you.

Tom