Last Comment Bug 15980 - Password shown in the Location-bar and in html
: Password shown in the Location-bar and in html
Status: RESOLVED FIXED
security
:
Product: Bugzilla
Classification: Server Software
Component: Bugzilla-General (show other bugs)
: unspecified
: All All
: -- major with 4 votes (vote)
: Bugzilla 2.14
Assigned To: Dave Miller [:justdave] (justdave@bugzilla.org)
: default-qa
Mentors:
: 34025 49587 56375 191959 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-10 02:58 PDT by christian.mattar
Modified: 2012-12-18 20:46 PST (History)
11 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch (1.05 KB, patch)
2001-06-06 18:38 PDT, Dave Miller [:justdave] (justdave@bugzilla.org)
no flags Details | Diff | Splinter Review
Patch v2, fixed incorrect statement about bookmarking in the comment (1.34 KB, patch)
2001-06-06 19:00 PDT, Dave Miller [:justdave] (justdave@bugzilla.org)
no flags Details | Diff | Splinter Review
Patch v3 - includes fix to HTML on mid-air collission page (2.51 KB, patch)
2001-06-06 19:09 PDT, Dave Miller [:justdave] (justdave@bugzilla.org)
no flags Details | Diff | Splinter Review

Description christian.mattar 1999-10-10 02:58:23 PDT
If you enter bugzilla the first time and enter your account information, it is
displayed in the location-bar during the rest of the bugzilla-session.
While my Bugzilla-account isn't exactly critical, i use my standard-password
here, so people standing next to me could easily see the password and use it for
various of my accounts.
Comment 1 Terry Weissman 2000-04-13 07:28:26 PDT
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Comment 2 Doron Rosenberg (IBM) 2000-04-25 04:03:49 PDT
how about using md5 for the password?
Comment 3 Jesse Ruderman 2000-05-10 16:23:30 PDT
suggested solution: use POST instead of GET for forms involving the bugzilla 
password.

i also noticed this happens right after i logged in to post a bug, by the way.
Comment 4 Jesse Ruderman 2000-08-19 14:24:09 PDT
*** Bug 49587 has been marked as a duplicate of this bug. ***
Comment 5 LeftTwin 2000-10-24 11:28:24 PDT
I would like to vote AGAINST using an MD5 hash as a way to obscure the password 
in the URL. An MD5 hash is only effective if the application (internally) has 
access to the real password to create a hash to compare against (eg. by getting 
it from the MySQL database). However, LDAP users would then be toast as many 
LDAP servers do not allow the application to query the real password; you 
provide it with a username and password, and it tells you whether it is 
correct. An MD5 scheme would not work for LDAP users.

Jesse's suggestion to use POST seems to be a much better solution.
Comment 6 uamjet602 2000-12-01 04:59:27 PST
Changing the operation to post is trivial, and prevents the password from
appearing in the location bar and the web server log.

To change it:

In CGI.pl, remove lines 845-847 ( the 3 lines after 'my method = "POST"' )
Comment 7 timeless 2000-12-01 07:52:27 PST
I casually object. I like being able to bookmark the login page including 
password.  Until we get correct authentication and memory please do not apply 
this change.
Comment 8 Hugh Kennedy 2001-01-04 07:52:23 PST
*** Bug 56375 has been marked as a duplicate of this bug. ***
Comment 9 Matthew Tuck [:CodeMachine] 2001-01-13 07:06:24 PST
Dupe bug #56375 has a variety of suggestions - basically we could support POST
and GET, POST as the default and later drop GET when feasible.
Comment 10 Stephan Niemz 2001-02-26 13:16:05 PST
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
Comment 11 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-02-27 19:40:08 PST
*** Bug 34025 has been marked as a duplicate of this bug. ***
Comment 12 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-02-27 20:23:16 PST
Moving to real milestones...
Comment 13 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-02-27 20:40:38 PST
can you point out to me where it's in the HTML?  I haven't ever seen it in the 
html anywhere...
Comment 14 Jesse Ruderman 2001-02-27 21:02:52 PST
It shows up in the html for the mid-air collision page, for one...
Comment 15 dannyman 2001-03-09 11:37:51 PST
Well, from hacking on Bugzilla, it appears that once the user has been
authenticated and issued a cookie, Bugzilla should never again need their
password.  That it then gets pasted in to GET URLs I figger to be an accident
from maybe just taking all existing form values and sticking them in there.

I'll go poke at this a little and see if this may just be a simple patch against
Bugzilla 2.x.

-danny
Comment 16 Hixie (not reading bugmail) 2001-03-14 14:53:01 PST
Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)
Comment 17 Stephan Niemz 2001-03-15 03:07:48 PST
Maybe I'm missing something here, but this is definitely a bug in Bugzilla 2.x
and should be fixed there. Why this component change?
Comment 18 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-03-30 03:54:31 PST
I agree with faniz.  This is a security issue and shouldn't wait.
Comment 19 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-03-30 04:12:35 PST
My thoughts on this:  (sorry timeless)  As a security administrator for my local 
network, I strongly *dislike* the ability to bookmark an authenticated login.  
Maybe this isn't a big issue if your computer is secure, but that would mean that 
anyone else could walk up to your computer and pretend to be you. :-)

The one thing that I don't like about this is that it is a cool thing to be able 
to bookmark various other URLs in Bugzilla, which you can't do if a POST is used.  
I'm thinking to perhaps add a "redirect.cgi" which will process a POSTed login, 
then redirect to the original URL via GET (so the parameters are visible) except 
that the bugzilla_login and bugzilla_password items are removed from the query. 
This will break Bugzilla for anyone who has cookies turned off though.  A 
possible way around that is, if the original query was generated by a GET, add a 
checkbox to the login screen for "keep my query visible in the address bar", 
which would default to checked if there are any Bugzilla cookies present at all 
(previous query lists, prefered sort order, whatever, just so we know cookies are 
turned on).  People without cookies would have to leave that unchecked, then it 
would use POST to finish the query and they wouldn't be able to bookmark it, but 
that's a tradeoff for not using cookies.
Comment 20 Jesse Ruderman 2001-04-03 13:45:44 PDT
timeless: you should still be able to bookmark the url with the password using 
this bookmarklet: 
http://www.squarefree.com/bookmarklets/powersurfing.html#frmget
Comment 21 dannyman 2001-04-10 12:44:49 PDT
Go to CGI.pl and edit the "confirm_login" subroutine.Go to:my $method = "POST";This is line 882 in our locally-hacked version.Comment out the next three lines:#        if (defined $ENV{"REQUEST_METHOD"} && length($::buffer) > 1) {#            $method = $ENV{"REQUEST_METHOD"};#        }The default is POST.  The lines I comment out here only disable the parent CGI's inclination to override POST, but you never want GET if the transaction involves passwords.If my understanding is correct, this ONLY applies to the case where you are logging in.  If you want to bookmark a GET CGI, then log in first, and THEN run your query.Things seem to work right here, except my Konquerer web browser may have some bugs wrt deleting cookies.  Can others try this fix, and if it passes muster, it can be committed to 2.x.
Comment 22 dannyman 2001-04-12 20:21:43 PDT
I am sorry that I was not aware that Bugme eats white space formatting 
submitted in the comments field.  But, anyway, has anyone played with my 
proposed fix? :)
Comment 23 Matthew Tuck [:CodeMachine] 2001-04-13 03:55:29 PDT
2.12 is out any day now, so we will get to this shortly.
Comment 24 Eric Hanson 2001-04-16 08:18:02 PDT
It seems that timeless shouldn't need to have a bookmark with his password since
the cookie will keep him logged in?  Since we now have saved searches and such
it seems that there is little reason to use GET.  As long as a get url will
still pull up the right page (so we can reference bugs by URLS on the newsgroup
and such) it should be ok.  
Suggestion, each bug has a line somewhere, 'url to referene: bugzilla_url_here' 
so that people can copy the URL into email and such.
Comment 25 timeless 2001-04-16 09:38:56 PDT
timeless (that's me) has two bugzilla accounts. And also occasionally lives 
behind a rotating transparent proxy.

Between these to facts, i can't rely on or even use the cookie, because it 
either (a) invalidates or (b) gives me the wrong user state.

Do i actually use something like this? yes ie keeps very few history states 
because i don't use it, but among them are urls to login as me or my alter 
state.

[and now I will sotp refering to myself in the third person]
Comment 26 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-04-21 23:46:55 PDT
BTW, there's no reason to make putting the login and password in the URL query 
field stop working.  We just won't use it from the login screen.  If the user 
then wants to take a query URL and insert the parms for the login_name and 
password into it, reload, then bookmark it, that would work just fine, I'd think.
Comment 27 Myk Melez [:myk] [@mykmelez] 2001-05-01 18:45:58 PDT
>BTW, there's no reason to make putting the login and password in the URL query 
>field stop working.

I wouldn't say there was no reason.  There are two security issues here: the
security of the user and the security of the system.  Fixing this bug in a way
that allows users to continue to use URLs containing their usernames and
passwords resolves the first issue (because by intentionally altering URLs users
are accepting potential compromises), but it doesn't resolve the second issue,
since it leaves the system vulnerable to those compromises.

Given that in this case very few users are likely to hack their URLs, it
probably isn't a big deal, but Matty's suggestion of dropping GET support after
an interim period of supporting both methods seems like the best approach.

Comment 28 timeless 2001-05-01 18:59:21 PDT
I'll continue to object to dropping support for get.

out of curiousity, do https urls get sent in the clear?
Comment 29 Matthew Barnson 2001-06-06 17:12:44 PDT
SSL encrypts all data beyond the key used to encrypt the message.  The public 
key itself is sent in the clear (it has to be ), but the data portion of the 
packet is completely encrypted.  So advising people to run Bugzilla in SSL 
would be sufficient to prevent man-in-the-middle attacks.  However, without 
SSL even putting the password in a POST is vulnerable.

The real issue here is the "co-worker looking over the shoulder" fear.
Comment 30 dannyman 2001-06-06 17:45:08 PDT
Uhhhh, no.URLs are frequently stored in browser-side caches.  POST form data is less likely to get such royal treatment.  Storing passwords on the filesystem, particularly within the context of a web browser, is a bad idea - there are then plenty of chances for another to read the password from the file, from permissive file permissions on a multi-user machine, to memory buffer overflow explouts.All the SSL in the world isn't going to save you from bad security practice.Any way, the fix I proposed earlier on this bug addresses this problem to my satisfaction in my environment, so I'll remove myself from the CC list now. :)
Comment 31 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-06-06 18:38:10 PDT
Created attachment 37459 [details] [diff] [review]
Patch
Comment 32 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-06-06 18:41:01 PDT
The patch I just attached simply comments out the check to see what request 
method the calling page was using, thus the default of POST is always used.
If you need to bookmark something and have cookies off, bookmark it from the 
screen asking you to log in.  It should still get you there after logging in.
Comment 33 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-06-06 19:00:31 PDT
Created attachment 37461 [details] [diff] [review]
Patch v2, fixed incorrect statement about bookmarking in the comment
Comment 34 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-06-06 19:09:43 PDT
Created attachment 37462 [details] [diff] [review]
Patch v3 - includes fix to HTML on mid-air collission page
Comment 35 Jacob Steenhagen 2001-06-07 07:23:12 PDT
v3 looks good (I can't verify that the username and password doesn't show up in
the HTML becase my IE install doesn't seem to want to View Source at all and
Mozilla seems to re-request the page rather than show my the source as it
appears in the active window, but The code for not printing it looks good).
r=jake
Comment 36 Jacob Steenhagen 2001-06-07 12:40:27 PDT
-> Dave
Comment 37 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-06-07 13:29:01 PDT
checked in.
Comment 38 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-09-02 23:43:32 PDT
Moving to Bugzilla product
Comment 39 Dave Miller [:justdave] (justdave@bugzilla.org) 2003-02-06 10:11:39 PST
*** Bug 191959 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.