772809 - Forgot Password form lacks CSRF protection

Status: RESOLVED DUPLICATE of bug 706271

(Bugzilla :: User Accounts, defect)

Description

[chetan1]

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.

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[chetan1]

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.

Comment 3

[Gervase Markham [:gerv]]

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

Comment 4

[chetan1]

Some related links:

http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests
http://news.softpedia.com/news/Gmail-Login-Gets-CSRF-Protection-123407.shtml
http://seclab.stanford.edu/websec/csrf/csrf.pdf

Comment 5

[chetan1]

"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).

Comment 6

[chetan1]

"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.

Comment 7

[Reed Loden [:reed]]

The login form issue is already filed as bug 713926. Changing this to only be for the forgotten password form.

Comment 10

[Frédéric Buclin]

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.

Comment 11

[Frédéric Buclin]

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.