Closed Bug 15980 Opened 25 years ago Closed 23 years ago

Password shown in the Location-bar and in html

Categories

(Bugzilla :: Bugzilla-General, defect)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.14

People

(Reporter: christian.mattar, Assigned: justdave)

References

Details

(Whiteboard: security)

Attachments

(3 files)

Patch
1.05 KB, patch
Details | Diff | Splinter Review
Patch v2, fixed incorrect statement about bookmarking in the comment
1.34 KB, patch
Details | Diff | Splinter Review
Patch v3 - includes fix to HTML on mid-air collission page
2.51 KB, patch
Details | Diff | Splinter Review 
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.
Status: NEW → ASSIGNED
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 .)
Assignee: terry → tara
Status: ASSIGNED → NEW
how about using md5 for the password?

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.
*** Bug 49587 has been marked as a duplicate of this bug. ***
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.

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

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.
*** Bug 56375 has been marked as a duplicate of this bug. ***
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.
Whiteboard: 3.0
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
*** Bug 34025 has been marked as a duplicate of this bug. ***
Moving to real milestones...
Whiteboard: 3.0
Target Milestone: --- → Bugzilla 3.0
Summary: Password shown in the Location-bar → Password shown in the Location-bar and in html
Whiteboard: security
can you point out to me where it's in the HTML?  I haven't ever seen it in the 
html anywhere...

It shows up in the html for the mid-air collision page, for one...
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
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.)
Assignee: tara → ian
Component: Bugzilla → Bugzilla 3
Priority: P3 → --
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?
I agree with faniz.  This is a security issue and shouldn't wait.
Assignee: ian → tara
Component: Bugzilla 3 → Bugzilla
Target Milestone: Bugzilla 3.0 → Bugzilla 2.14
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.

timeless: you should still be able to bookmark the url with the password using 
this bookmarklet: 
http://www.squarefree.com/bookmarklets/powersurfing.html#frmget
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.
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? :)

2.12 is out any day now, so we will get to this shortly.
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.
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]
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.

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


I'll continue to object to dropping support for get.

out of curiousity, do https urls get sent in the clear?
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.

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. :)
Attached patch Patch — — Splinter Review 

    
    

    
  
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.

Keywords: patch, 
          
            review

    
    

    
  
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

    
    

    
  
-> Dave
Assignee: tara → justdave

    
    

    
  
checked in.

Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified

    
    

    
  
*** Bug 191959 has been marked as a duplicate of this bug. ***
QA Contact: matty_is_a_geek → default-qa

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: