I just reset my bugs.gentoo.org password and after submitting a new password and logging in, I noticed the current page's URL was: <https://bugs.gentoo.org/token.cgi?t=rD1epTwL74&a=chgpw&password=*****&matchpassword=*****&GoAheadAndLogIn=1> where "*****" is my password in cleartext. I realize the connection is over SSL, but isn't this a bug? I apologize if this has been brought up before, I didn't find anything in a search. Reproducible: Didn't try Steps to Reproduce: 1. Follow link in reset-password email. 2. Enter new password. 3. Click "Login" link at bottom of page.
That password turning up there is extremely concerning. The token.cgi page should be doing a POST, not a GET. Looking in the logs, I can see it does a POST the first time, but then there seems to be a redirect afterwards. mkanat/upstream: potential "minor" sec vuln, in that this is disclosed in the URLs and so ends up in a lot of logs. Mansour: can you tell me which of the following was actually manually initiated by you, and which was redirects? (I'm pretty sure the first two, but I don't know after that). __IP__ - - [10/Mar/2010:20:40:27 +0000] "GET /token.cgi?t=__TOKEN__&a=cfmpw HTTP/1.1" 200 1634 "-" "__UA__" __IP__ - - [10/Mar/2010:20:40:44 +0000] "POST /token.cgi HTTP/1.1" 200 1506 "-" "__UA__" __IP__ - - [10/Mar/2010:20:40:49 +0000] "GET /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1 HTTP/1.1" 200 1976 "-" "__UA__" __IP__ - - [10/Mar/2010:20:41:00 +0000] "POST /token.cgi HTTP/1.1" 200 2004 "-" "__UA__" __IP__ - - [10/Mar/2010:20:41:30 +0000] "GET /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1&GoAheadAndLogIn=1 HTTP/1.1" 200 2004 "-" "__UA__" __IP__ - - [10/Mar/2010:20:42:40 +0000] "GET /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1&GoAheadAndLogIn=1 HTTP/1.1" 200 2004 "-" "__UA__"
(In reply to comment #1) > Mansour: can you tell me which of the following was actually manually initiated > by you, and which was redirects? (I'm pretty sure the first two, but I don't > know after that). > > __IP__ - - [10/Mar/2010:20:40:27 +0000] "GET /token.cgi?t=__TOKEN__&a=cfmpw > HTTP/1.1" 200 1634 "-" "__UA__" > __IP__ - - [10/Mar/2010:20:40:44 +0000] "POST /token.cgi HTTP/1.1" 200 1506 "-" > "__UA__" > __IP__ - - [10/Mar/2010:20:40:49 +0000] "GET > /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1 > HTTP/1.1" 200 1976 "-" "__UA__" > __IP__ - - [10/Mar/2010:20:41:00 +0000] "POST /token.cgi HTTP/1.1" 200 2004 "-" > "__UA__" > __IP__ - - [10/Mar/2010:20:41:30 +0000] "GET > /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1&GoAheadAndLogIn=1 > HTTP/1.1" 200 2004 "-" "__UA__" > __IP__ - - [10/Mar/2010:20:42:40 +0000] "GET > /token.cgi?t=__TOKEN__&a=chgpw&password=__PASSWORD__&matchpassword=__PASSWORD__&GoAheadAndLogIn=1&GoAheadAndLogIn=1 > HTTP/1.1" 200 2004 "-" "__UA__" > After the password reset, I'm assuming I was automatically logged in, because I remember seeing an invalid token error after clicking "Login" (after the second time -- hadn't read the error at first). But there was still a "Login" link at the bottom right, as opposed to "Log out" as there is now. Maybe a browser caching issue? So then I refreshed the page, and I'm guessing that's when the form data was re-submitted as a GET. Actually, this may all be Firefox's fault... Those GET lines were probably me hitting Login again and again. I think that explains the "&GoAheadAndLogIn=1&GoAheadAndLogIn=1". (At that point I gave up and went straight to bugs.gentoo.org, only to see that I was already logged in.) Maybe I missed a redirect page somewhere (browser blocks those)?
I doubt this is still an issue in Bugzilla 3 or 4. Now that you upgraded to 4.0, you should check if that's still a problem. But I don't think so.
(In reply to comment #3) > I doubt this is still an issue in Bugzilla 3 or 4. Now that you upgraded to > 4.0, you should check if that's still a problem. But I don't think so. Yup, it has been fixed in 3.x already. I just tested it again, still fixed :)
