Only need app-id to create users? Security risk?

[j2c-arnuth]

Am I getting this right?

Assuming:

• an app has "Email Password Auth", and "Send a confirmation email" turned on
• an attacker gets the APP-ID, which is: displayed on Realm UI, part of the HTTPS end points and included in the real_config file.

then the attacker could:

  const app = Realm.getApp('APP-ID');
  app.emailPasswordAuth.registerUser({
        email: 'tt0673523@gmail.com',
        password: '123123123',
    });

Registering the user and obtaining token and tokenId in the registered email.

then:

  const app = Realm.getApp('APP-ID');
  app.emailPasswordAuth. confirmUser({
        token: TOKEN',
        id: TOKEN-ID',
    });

Meaning that an attacker only needs the APP-ID to freely create app users.

[kraenhansen]

@j-medinformatics please clarify how you view this as a potential security risk? If you want to do additional checks (such as the email has to be on a certain domain name etc.) you can use a confirmation function instead of a simple confirmation email. If you want even more control over who can create users in your app, you can alternatively use a third party service in combination with the JWT / custom token authentication provider.

[j2c-arnuth]

Hi @kraenhansen,

The issue I see is not about the level of control different configurations offer. The problem is that a valid configuration (email and password auth + email confirmation) could be used to illegally create application users. This is the scenario I see:

• Email and password auth is turned on
• Confirmation is managed using a callback route included in the confirmation email
• Back API is exposed to the Front using HTTPS end points (which includes the app-id, according to the docs "https://data.mongodb-api.com/app/<App ID>/endpoint")

Following the documentation, this seems like a valid scenario (no warning about it in the docs). However, in this scenario, an attacker could get the App-id using a browser to check network requests between backend and frontend. And, with the app-id they could bypass the confirmation logic (as shown in my initial comment).

I think this could be prevented if the SDKs would require an API-KEY to get an instance of Realm.APP. Sort of how Realm-CLI works.

[kraenhansen]

To clarify: The app id is not to be considered confidential information.

The confirmation via email built into the platform is only ment to verify that the user can receive emails on the email address they provide. The TOKEN from your example is generated per confirmation request and is therefore bound to the specific user and email. I.e. if the user can't receive an email with the token, they cannot confirm their user.

a valid configuration (email and password auth + email confirmation) could be used to illegally create application users

The app id, email password auth + built-in confirmation via email enabled and an ability to read emails from the users created, is all a person of ill intent need to create users. If your app needs to restrict that further, you'd need to enable a more advanced auth provider.

I think this could be prevented if the SDKs would require an API-KEY to get an instance of Realm.APP.

In the end, this would either need to be exposed to end-users if called from a browser or some endpoint (a server or a cloud function) would know this secret and provide it for legitimate users. I don't see how that would make creation of users for malicious intent any less likely.

[kraenhansen]

If you're still concerned, please feel free to reach out to our security team via security@mongodb.com.

[j2c-arnuth]

Thanks @kraenhansen,

I think it is my bad. I typically work on applications where the user is not expected to self-register. And, after reading your response, it seems that is the main use case atlas auth services is focused on. That is not to say, that other cases where more control is required are not covered, as your answer explains.

[kraenhansen]

I'll go ahead and close this, as per your last comment.