Security Issue: User Impersonation

Not sure where to post this, and frankly not sure if it should be in a public forum, but I realized an issue today.

Issue: Because users do not have to verify their emails (nor is there an option to), then any user can enter another user’s email (or domain!) and get access to that entire user’s records.

Many people have conditional filters to limit records to a particular logged-in user’s domain or email address. Not sure if this is a known issue or what (tried searching), but as a security company creating a portal for clients it would be disastrous if clients had access to other client’s data and reports.

Fix: Enable email verification for all email signups by default. Allow users to remove (but give a warning). As a workaround I can force Google auth only, or utilize Auth0 or something (more work).

Would love to hear the team’s thoughts.

Hi Ayman,

The scenario you raise is interesting. Certainly having email verification in all cases would be ideal.

However, in order for this scenario to constitute a risk, it would imply that a user with that email previously exists in the database, so that it can have associated records, otherwise, it would be a new user without any record in the database, which implies that there is no risk.

Of course, if a new user comes and tries to register with his email (that was used by someone else), Softr will tell him that a “User by given email already exists.”, so he will not be able to use his own email to register.

Even if a user wants to change his email with another email of an already registered user, to try to “usurp” his identity, it would not be possible.

You can do the following test:

1) The user base is synchronized with Airtable. ( :raised_hand: Note that the synchronization with Airtable is only from Softr to Airtable and not vice versa).
2) There are two users in the base:
User A with email: a@a.com
User B with email: b@b.com
3) User A enters a page that has a form where he/she can view and update his/her profile data, including email.
4) User A enters and tries to update his email to: b@b.com

Result: the user A’s email is not updated, it is still a@a.com

If I am not mistaken, it is not possible to have users with the same email, since it is the primary key that univocally identifies the user, therefore, the usurpation of identity could not happen.

Please let me know if there is something I have not understood in your approach.

Hi @ohtejera,

So the problem is where someone is allowing any user from the the domainacme.com” for example to access Acme’s records, based on the domain criteria.

However, a subversive user can easily register for an account with “attacker@acme.com” and is automatically granted access to Acme’s records, without any verification at all. Of course knowledge of the registered domain is required, but that can be pulled from the list of clients on a website, forum, or any other public messaging.

Does that help illustrate the risk a little more clearly?

Now I see more clearly the scenario you raise.

Perhaps one option was to use the Signin with Code block., but I understand that it is not useful, since it is the Signup process that would have to be validated initially (email verification).

Just to clarify the force-Google-auth scenario: you can force Google auth by building an app that uses only the “Google Sign in” and none of the sign-in blocks that offer sign in with username and password.

However, the only way to prevent signing up with username and password is to use custom code to hack the fields out of the Sign Up block.

This is particularly pernicious, because it opens a social engineering hole: if the user can sign up with an unverified email, then even if they cannot log in, they can email the admin, spoofing the From: address of the email, and request a magic link, and then it’s game over unless the admin is really careful. If the attacker is really good they won’t even ask for the magic link, they’ll just keep saying they can’t get Google Signin to work until the admin thinks of the magic link feature and sends the link unprompted.

Hey folks, thanks for bringing this up and we should certainly prioritise email verification. I think @ayman point is specifically valid if one has open registration to a platform and does gating based on the domain only. I will talk to a team to enable email verification.

I think signup blocks that have email in them could have option to enable email verification in them where immediately the next step step is to verify email… wdyt ?

2 Likes

Yes that could work, I also think there should be a new user group or subgroup, next to logged-in users;
Verified-users, then we can save time planning logic for content for non-verified users and put a little pressure on them to make them check their emails to verify and gain full access to content.

IMHO there are three phases:

  1. The most urgent thing is to close the existing hole in Google auth integration by creating an option in the Sign Up block to permit only the “Sign Up With Google” flow.
  2. The next most urgent thing is to allow the sign-up flow to pause for email verification and only allow the user to log in after that is complete.
  3. Finally, I think it’s important (but not urgent) to support the use case where an unverified user can still log in but is restricted (e.g., with group-based permissions) from some areas of the app.

You could probably convince me that 3 was more urgent than 2, but I suspect 2 is a lot easier to implement than 3.

1 Like

@ayman As a short-term solution, will the standalone Google Sign-in block we have work? (@dcoletta is this what you mean be phase 1?

The standalone Google sign-in block is part of phase 1 (in my humble description) but phase 1 doesn’t work yet because, short of custom code there is not yet any way to prevent native sign-up.

I think how @dcoletta broke it down is a great approach. Softr already has an only Google sign-in block already, so I believe #1 is solved.

#2 is the way to fix this. It would be essential to have this as an option as we don’t want to reduce usability for less critical apps (I’m reading PLG now and saw a metric regarding email verification reducing usability). This is where #3 would be handy. I’ve seen apps allow you to login but with limited access until you verify.

If you remove the signup page, users have to sign in with a validated email, right? So wouldn’t that solve it?

But yes, I agree, having a better built-in way to do this is better.

At the risk of beating a dead horse, #1 is not solved today without custom code that blocks native sign-ups in the sign-up block. (Or as @alex37 suggests, don’t offer a sign-up block at all, and create accounts via the API or the studio.)

Hey @dcoletta, I’m referring to this block here, which I’ve used before. Maybe I’m missing something? (Poor horse! :sweat_smile:)

image

That block prevents native sign-in and only allows Google Sign-in. That’s half the solution. The problem is there’s another half that is needed, which is a block that prevents native sign-up and only allows Google Sign-up. That does not exist.