121792 - User can see content of password and hidden fields in page info, and this option cannot be turned off

Status: VERIFIED FIXED

(SeaMonkey :: Page Info, defect)

Description

[Alexander Hessentswey]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020124
BuildID:    2002012403

User can see content of password and hidden fields in page info - it's great!
But there should be ability (some users share computer and Mozilla with others)
to turn this option off or to require special password for this option.
Something like "Show value of the password fields in Page Info: freely/require
password [change password]/off".

If you will decide that this is not critical, I will agree with you.

I think, an option to see value of hidden and password fields is very useful, so
thank you!

Comment 1

[Daniel Brooks [:db48x]]

yes, this is a bug. some would say critical, some not. trivial to fix, unless
you really really think it's worth bothering with extra passwords and prefs and
stuff.

Comment 2

[Alexander Hessentswey]

May be, you could connect this option to the Master Password?

Comment 3

[Daniel Brooks [:db48x]]

could, technically. still lots and lots more work.

Comment 4

[Daniel Brooks [:db48x]]

oh, and fwiw, I don't consider the fact that you can see the values of hidden
fields bad, after all you can just do view-source and see the same information.

Comment 5

[Alexander Hessentswey]

Yes, you are right. But what about password fields... May be, if user sets
Master Password, he can expect that another user cannot get his stored
passwords... even via Page Info...

However, I think, it's not critical. So, if you think it's not critical too, we
will decide that all is correct.

Comment 6

[Daniel Brooks [:db48x]]

Attachment: simplest fix

this is pretty much the simplest possible fix. Personally I think it is
sufficient, simple because I don't think it's worth the trouble to ask the user
for a password in order to let him view page info.

Comment 7

[Peter Trudelle]

Agreed, asking passwords for this would be intolerable.

Comment 8

[Jesse Ruderman]

Fwiw, this change won't prevent me from using a bookmarklet to extract 
passwords from a web form.  (I offered to give my dad a bookmarklet to do 
exactly that when Gator, a password manager add-on for IE that he used, turned 
from freeware to spyware.)

I still think this page info bug should be fixed, since most users won't think 
of writing a bookmarklet to steal a password.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 66562 [details] [diff] [review]
simplest fix

>+        var val = (elem.type.match(/password/i)) ? theBundle.getString("formPassword") : elem.value;

Instead, do:

	  var val = (elem.type == "password") ?
theBundle.getString("formPassword") : elem.value;

the .type property is lowercased regardless as it is defined in HTML 4 (the DOM
spec explicitly references HTML 4 which uses lowercase).

See:
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-62883
744
http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/html.html#ID-62883744
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-type-INPUT

Comment 10

[Daniel Brooks [:db48x]]

Attachment: nifty

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 66653 [details] [diff] [review]
nifty

r=caillon

Comment 12

[Daniel Brooks [:db48x]]

jag, could you sr= this one too please?

Comment 13

[Alexander Hessentswey]

I'm sorry, but if you disable this option for all users with no way to enable
it, no user will be able to read HIS OWN password if he forgot it, but website
remembers.

Comment 14

[Adam Hauner]

Alexander Hessentswey: IMHO it's correct.

Comment 15

[Daniel Brooks [:db48x]]

You could make the same argument against the stars that show up in place of the
actuall characters in the original input fields. Besides, if the user (or anyone
else, for that matter) really really wants to know the password, there _are_
ways to get it. And I'm not talking about mucking about in the profile or
anything complicated like that.

Comment 16

[Alexander Hessentswey]

May be, the best variants are
1) only block viewing of the password field value with PageInfo (Master Password)
or
2) leave it as is

Comment 17

[jag (Peter Annema)]

Comment on attachment 66653 [details] [diff] [review]
nifty

Just tested that Mozilla actually does the right thing for <input
type="PASSWORD">.

sr=jag.

Comment 18

[timeless]

fix checked in

Comment 19

[Patty Mac]

Verified the patch.

Comment 20

[Enrico Scoda]

Strange behaviour:
- on Forms tab password is substituted by '*******'
- on Links tab password is visible (Form Submission link)

I don't know what is the correct behaviour but actually it is not coherent.

Comment 21

[Boris Zbarsky [:bzbarsky]]

It shouldn't be on the links tab.  Could you attach your HTML to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=121792&action=enter ?

Comment 22

[Enrico Scoda]

Attachment: part of bugzilla login form

Fill this simple form and open Page Info, then Links tab; the third row
contains the password

Enrico

Comment 23

[Matthias Versen [:Matti]]

Enrico Scoda: wfm with a 1 day old CVS (no password in the link tab)

Comment 24

[Daniel Wang]

*** Bug 182883 has been marked as a duplicate of this bug. ***

Comment 25

[Daniel Wang]

*** Bug 195023 has been marked as a duplicate of this bug. ***