User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 Steps to reproduce: The login form and the forgot password form on bugzilla do not have any CSRF protection tokens. I made HTML forms which posts the required parameters to these forms. These forms can be accessed here: Login CSRF : www.jobsify.in/thesis/check/bugzilla1.html Forgot Password CSRF : www.jobsify.in/thesis/check/bugzilla2.html Actual results: I can make a user login as a bad user. All actions henceforth done by the user will be made through the bad user account. This can have severe security implications. Also, I can make a user request a reset password token for a particular account. Expected results: These forms should have CSRF protection tokens. On making CSRF requests they should display an error like on the other forms on bugzilla site.
How is this a security problem? If I wanted to send a password reset email for your account, I could just go to this URL: https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=1#forgot and send one. No CSRF is necessary. Yes, you can cause someone else to be logged in - but you can't take any actions as them, as you don't have access to their login credentials or cookie. Do you have a demonstration of an actual explot? It's not meaningful to protect a login form from CSRF, because you can't tie the CSRF token to a particular person, because they aren't logged in! So an attacker can just request a token by loading the page themselves, then include it in their request. Gerv
Consider the situation when these forms are hidden inside IFrames on my blog (can be anything). Now, if you were to visit my blog, it will log you in as me. All your actions henceforth on Bugzilla will be through my account which would obviously be visible to me.
Ah. Hmm. It certainly shouldn't be possible to smoothly log in as person A when you are already logged in as person B. Are you saying that it is? If I was logged out of Bugzilla, then yes, you could log me in as you - at the cost of revealing your password to anyone who did View Source on the attack page. And if the account was set up with the same name and a similar email address as me, I might not notice in the UI. I might notice not getting the bugmail, but that might be a little while. I might notice the lack of saved searches etc., or the lack of my customizations. I guess we could avoid this using a CSRF token which was tied to an IP address or range... Gerv
"It certainly shouldn't be possible to smoothly log in as person A when you are already logged in as person B. Are you saying that it is?" Yes, it logs me out from my own account and logs me in with the bad account automatically (CSRF one).
"If I wanted to send a password reset email for your account, I could just go to this URL" You can obviously, but if I were to put it inside a invisible iFrame on a popular site on the internet or even on the intranet, I can possibly spam your account with hundreds of password reset emails. And normal protections like ip/cookie restrictions won't work here.
The login form issue is already filed as bug 713926. Changing this to only be for the forgotten password form.
Summary: Forgot Password Form CSRF & Login CSRF in Bugzilla → Forgot Password form lacks CSRF protection
And the password part has already been filed as bug 706271. Note that you cannot use Bugzilla from an iframe. That's not possible since Bugzilla 4.0, see bug 475894.
Assignee: general → user-accounts
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Component: Bugzilla-General → User Accounts
Resolution: --- → DUPLICATE
Duplicate of bug: 706271
Bug 706271 has been fixed, so removing the sec flag. The 2nd issue described in this bug is not a security issue, as being logged in with the attacker credentials is of no harm as the attacker probably has less privileges than the victim.
You need to log in before you can comment on or make changes to this bug.