× Joomla Facebook Connect support forum

Topic-icon Security issue with signup

11 years 4 months ago #29136 by chramb1
When a new user signs in with Facebook for the first time, they are taken to the loginregister view which allows them to either associate their FB identity with an existing account or create a new one.

The problem here is that in creating a new account, the fbusername, email and generated password are stored in the loginregister form as hidden variables. This would allow anyone to modify the value of these variables before submitting the form. That form is then submitted to the loginregister controller function createNewUser(). A clone of getUser() is acquired (presumably a clone of the guest account) and then these values are bound to the clone.

We now have a JUser object with any username, email and password a bad actor wants to submit, mapped to the facebook account they used.

These variables should never be exposed to a user to modify.
The topic has been locked.
Support Specialist
11 years 4 months ago #29137 by alzander
Replied by alzander on topic Security issue with signup
Christopher,
That's correct behavior. You can set those values in JFBConnect to be editable, if you want, it's a simple setting. In that case, they are directly exposed to the user to modify before submitting the form so that they can choose their own username, password and email address. That's the administrator's option if they want the user to be able to change those settings during the registration process.

As for the FB user id that is used for the association, that is *not* taken from the form as that would be a security issue if the user could associate their account to any Facebook user. We fetch the FB User ID during the registration process securely from Facebook's cookie that they set for us.

Finally, after the JUser object is bound to the data passed in during registration, we attempt to do a save which will check if the username and email are already taken by another user. If so, the registration will not process and the user will be sent back to the Login/Register page to try again.

Please feel free to test and let us know if you are still unsure about something. We take security very seriously, and have gone over our registration process many times to make sure it's secure. I'm by no means guaranteeing anything, but I don't think this is an issue.

Thanks,
Alex
The topic has been locked.
11 years 4 months ago #29139 by chramb1
Replied by chramb1 on topic Security issue with signup
Okay, sure enough, after using TamperData to change the email address to one already on the site, submitting the form gets the following error:

Unable to save user. Please ensure your username is not taken and that your passwords match.

So that'll prevent a user from using an existing email.

The only problem I have is this: in allowing users to sign up with Facebook, I rely on Facebook to provide the email address of the user as already validated and good. Having a validated email for our users is critical. Now, yes, I could require activation email, but the beauty of FBConnect is that FB has done this for you and you can log the user in and they can get going right away. This reduces the bounce rate by impressive amounts.

But now, even if I've turned off the ability for a user to edit their email, they can still tamper with the form and put in a non-validated email address.

So this is reduced from being a potential security threat to being something that bypasses site requirements and the flow of authenticated data from FB.

Is there any way to refactor the code to say, "If the ability to edit the fields is off, do not use hidden variables to pass them, but store them in the session object so they cannot be tampered-with?"
The topic has been locked.
Support Specialist
11 years 4 months ago #29153 by alzander
Replied by alzander on topic Security issue with signup
It's definitely not a security issue, like you mention. I can see where it could be a problem to get around activation. However, the user has already been activated by Facebook, so you know they (likely) aren't a 'bad' user. Additionally, if they edit their profile in Joomla, they have the ability to edit their own email address directly after registration, so that's easily changed at any point anyways.

As to your final question:

If the ability to edit the fields is off, do not use hidden variables to pass them, but store them in the session object so they cannot be tampered-with?

That should be very easy to do for the email field. We wouldn't do it for the password field, as there's no issue with tampering with that field. Let me look into the change that would be required, and also let me know if you still want this, given the above about changing a user's email later on anyways. Shouldn't be difficult, but may take a day or so to come up with the best solution.

Thanks,
Alex
The topic has been locked.
11 years 4 months ago #29170 by chramb1
Replied by chramb1 on topic Security issue with signup
No, the more I think about it, the more I think that this is something outside of the scope of your code. If I want to enforce email sync, I should do that in my plugin and also capture any changes with a callback to keep things synchronized. It's unique enough that it shouldn't have to be part of your core code.
The topic has been locked.
Support Specialist
11 years 4 months ago #29177 by alzander
Replied by alzander on topic Security issue with signup
We agree that it's a little beyond what we want to implement. I'll agree that the ability to fiddle with the email address isn't ideal, it's honestly not something we see being abused since it's not obvious and not something that can be repeated unless the 'bad' person has many Facebook accounts.

Either way, glad we could talk you through it, and happy you understand the uniqueness aspect. We really try hard not to add features unless a wide audience would use it. We have enough options already and try hard to decrease even those instead of increase them.. it makes everything easier.

Best of luck,
Alex
The topic has been locked.