0.1.0-beta.15 leaks potentially private data

Christoph8434

I have just updated my Flarum installation from version 0.1.0-beta.13 to 0.1.0-beta.14 and then 0.1.0-beta.15.

I use Flarum to run a forum for a community where even usernames should remain private. Therefore, I set the View user list permission to Admins.

With 0.1.0-beta.13, when a non-admin user requested a URL such as https://forum.example.net/api/users/1234, Flarum sent a 404 response:

{"errors":[{"status":"404","code":"not_found"}]}

However, with 0.1.0-beta.15, even an unauthenticated client will receive a response with a payload:

{
  "data": {
    "type": "users",
    "id": "1234",
    "attributes": {
      "username": "foo_bar",
      …

Therefore, by simply enumerating the user IDs, anyone can get a complete list of usernames. It seems that this is not supposed to happen.

Regards
Christoph

luceos

Thanks for reporting, the team is on top of this.

Hiding to prevent immediate abuse.

Christoph8434

There seems to exist another privacy-related problem with 0.1.0-beta.15:

Using an URL such as https://forum.example.net/u/john_doe, an unauthenticated client can test if that username exists even if the View user list permission is set to Admins. Furthermore, the response reveals the user's avatar, group memberships and the date the user joined the forum.

clarkwinkelmann

Thanks for your reports.

The behavior indeed changed from beta 13 to beta 14. The change was made on purpose in flarum/core2305 The reasoning for the change can be consulted in flarum/core1680

However it seems like we did forget to describe it in the release post. That's an oversight, we should have made this more clear. It seems to be missing from the CHANGELOG file too, we will correct that.

Essentially "View user list" was never supposed to prevent user enumeration or user profile access. It controls the search endpoint, which allows filtering users by additional parameters, and sort them by some values.

Up to beta 13, this permission was used to partially prevent user profile access, but this caused issues and wasn't a good solution, since it never hid all of the information anyway.

So as of beta 14, it has been decided that this permission would only serve to protect the user search, and that other permissions might be introduced later for the other features.

As of beta 14 and 15, Flarum does not come with the ability to hide user profiles. This is intentional. We know that user ID and usernames can be enumerated, and we don't consider that a vulnerability.

Some solutions that could help with your situation:

The "View discussions" permission controls visibility of both all posts and all profiles. Allowing to make a fully private forum.

Then there solutions for partially public forums that could be made using the extension API:

If the usernames must not be visible to guests, an extension could replace them with blank/other values when viewed as guest
An extension could introduce a non-sequential ID system

If you can describe your situation in more details (what's public, what's private, how people should gain access), we might be able to make other suggestions as to how to proceed.

PS: While we talk about enumeration, in Flarum, just like in many other software, there are other endpoints which allow enumeration. The sign up form, when registrations are open, already leaks username and email existence. Likewise, the password reset feature exposes email existence.

Flarum can be hardened to protect against those leaks, but we feel this is best left to specialized extensions since on most forums the information will already be discoverable by legitimate means (username) or worsens the user experience (email).

Christoph8434

clarkwinkelmann Clark, thank you for this elaborate response.

The basic setup and requirements of my forum are as follows:

Sign up is closed. Users are added and removed according to the membership list of my organization using SQL scripts.
Usernames are typically in the form firstname_lastname and are therefore sensitive data.
Members should not be able to see the complete list of members. (Members will be able to see members that have participated in discussions, of course, but members should be able to "lurk", i.e. to read discussions without actively participating in them.)
Guests must not be able to see any user-related data or discussions.

This is a screenshot of the permission settings – as far as I can see, these settings are as restrictive as possible:

What concerns me the most is the fact that with 0.1.0-beta.15 even an unauthenticated client can easily enumerate all usernames. For the time being, I have added these rewrite rules to Flarum's .htaccess:

RewriteRule "^api/users" "-" [forbidden]
RewriteRule "^u/[a-z_]+$" "-" [forbidden]

Regards
Christoph

clarkwinkelmann

Christoph8434 until we introduce actual private profiles, I feel like the best option would be to set the name/firstname as the "display name" instead of username, and then restrict who can see that display name using permissions or custom code. And the username should be set to something random instead.

Unfortunately it seems our own Nickname extension doesn't come with permissions to control who can see nicknames. But a simple addition in extend.php could be made so users can only see their own nicknames. We can help you with the code for that.

ctml

Christoph8434 What concerns me the most is the fact that with 0.1.0-beta.15 even an unauthenticated client can easily enumerate all usernames.

For some that might even expose additional information about the user other than basic info. For instance, if you use social buttons all of the data is exposed from https://forum.example.net/api/users/1234. So unauthenticated clients could get access to emails, facebook, or anything else users chose to share on their profile. Though it doesn't seem like there is a way to restrict access to user profiles anyway, so that information would have always accessible to unauthenticated users.. but it is something I thought it would be nice to have a permission control for.

Christoph8434

clarkwinkelmann I have now installed the Nicknames extension and used mysqldump to migrate from usernames in the form firstname_lastname (and no nicknames) to random numeric strings (such as 84332) as usernames and Firstname Lastname as nicknames. This apparently went quite well, and the existing discussions are now rendered with nicknames instead of usernames.

I would now like to fiddle with the extend.php file. Any pointers to which functions or settings I should use there?

clarkwinkelmann

ctml I understand the concern. And I think we should introduce a permission that will control who can see the users in the future. Such a permission should/would also apply to relationships like discussion.user and post.user as to effectively hide the data. But this likely won't be before Flarum stable.

What extensions can do (and many do) is offer additional permissions for their own features. For example the social buttons extension should offer a permission controlling who can see this information, so that it can be restricted to logged in users. I believe the bio extension and many other already offer such settings.

Effectively that would leave only the user ID and username enumerable/discoverable, everything else can be locked down with permissions in the individual extensions.

Christoph8434

This is my totally uninformed attempt to block resources such as https://forum.example.net/api/users/1234 or
https://forum.example.net/u/john_doe for unauthenticated clients:

<?php

/*
 * This file is part of Flarum.
 *
 * For detailed copyright and license information, please view the
 * LICENSE file that was distributed with this source code.
 */

use Flarum\Extend;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;

class Middleware implements MiddlewareInterface
{
    private function isSensitive(ServerRequestInterface $request): bool
    {
        $path = $request->getUri()->getPath();
        return str_starts_with($path, '/u/') || str_starts_with($path, '/users');
    }

    private function isAuthenticated(ServerRequestInterface $request): bool
    {
        return boolval($request->getAttribute('actor')->username);
    }

    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $response = $handler->handle($request);
        if($this->isSensitive($request) && ! $this->isAuthenticated($request))
        {
            return (new Laminas\Diactoros\Response\HtmlResponse('<h1>Forbidden</h1>'))->withStatus(403);
        }
        return $response;
    }
}

return [
    (new Extend\Middleware('forum'))
        ->add(Middleware::class),
    (new Extend\Middleware('api'))
        ->add(Middleware::class),
];

Just put these lines in the extend.php file in Flarum's root directory. As you have probably guessed, I am not a PHP programmer. 🙂

streaps

Do I understand it correctly that the problem still persists and it's not possible (out of the box with permissions) to hide user profiles for guests and web crawlers?

clarkwinkelmann

streaps Flarum currently doesn't support having public discussions with private profiles, that's correct. It's much more than disabling the profile page, because the user information can be retrieved in many different ways through relationships in the REST API.

However if the whole forum is private, you can set "View forum" permission to registered users and this will hide both discussions and users.

Most extensions that add information to a user profile have custom access control for that data. So while you cannot hide the profile page, you can usually strip it down of all extension-provided data.

If you're afraid of usernames reveling sensitive information, there exist multiple extensions that allow disabling/hiding usernames and switching to ID / Display name. But as said in my post above since the username is constrained to be unique, there will always be endpoints that can be used to leak their existence.

luceos

User profiles to guests also have far less data/information than for members and admins. Properties get added based on permissions (and need).

streaps

I'm talking about the user profile which does not only show the username, but registration date, last time online, all posts and mentions.

clarkwinkelmann

streaps those are indeed always public in Flarum core, but an extension could easily change that.

Users can hide whether they are online in their preferences.