296644 - Sanitize doesn't clear per-session passwords

Status: RESOLVED INCOMPLETE

(Firefox :: Settings UI, defect)

Description

[Nikolas 'Atrus' Coukouma]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050515 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macitosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050530 Firefox/1.0+

Using Sanitize doesn't clear passwords that were prompted with
SAVE_PASSWORD_FOR_SESSION

Reproducible: Always

Steps to Reproduce:
1. Go to some URL that requires authentication. The URL for this bug is one with
user "testing" and password "123"
http://dent.student.umd.edu/~atrus/auth_test/
2. Select Tools>Sanitize Firefox/DeerPark
3. Visit the URL again

Actual Results:  
Accessed the resource without entering the password

Expected Results:  
Prompted the user for a password

Comment 1

[Nikolas 'Atrus' Coukouma]

Digging deeper ... It appears that this is cached at the HTTPChannel level. The
password manager is only used for filling in the prompts, when they appear.
There's an nsHttpAuthCache object used by HTTP channels and simple username and
password members for FTP connection threads. If that is correct then it will be
difficult to hunt them all down and reset them, yes?

Comment 2

[Nikolas 'Atrus' Coukouma]

Attachment: Patch to sanitize.js

This is a small patch that uses nsIHttpAuthManager.clearAll to clear the cached
auth info. It's tied to "clear passwords" because it's unlikely that a user
would want to differentiate between cached http auth and passwords stored via
the password manager.

Comment 3

[Mike Connor [:mconnor]]

Comment on attachment 187327 [details] [diff] [review]
Patch to sanitize.js

Ok, this is a good start, but we need a second avenue to clear session data as
well, without having to clear passwords, but I think that's covered under the
SSL session bug.

Comment 4

[Mike Connor [:mconnor]]

Comment on attachment 187327 [details] [diff] [review]
Patch to sanitize.js

this doesn't do enough, actually, since SSL sessions will still be intact.

Comment 5

[Nikolas 'Atrus' Coukouma]

To clear cached shared secrets ...
Hrm, if I understand things correctly, we need to call SSL_ClearSessionCache, or
replace the cache.
nsCRLManager::ImportCrl
nsCRLManager::DeleteCrl
nsNSSComponent::ShutdownNSS

Shutting down NSS and bringing it back up looks like the best way to go about
this. We can trigger this by broadcasting a profile change (perhaps change
profile from and to the same one?)[1]

There's also the issue of ssl/tls certs. nsICertTree seems to cover that.[2]

FTP saves passwords internally, so I'm not sure how to handle that.

[1]
http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSComponent.cpp#1767
[2]
http://lxr.mozilla.org/seamonkey/source/security/manager/pki/resources/content/certManager.js#76

Comment 6

[Nikolas 'Atrus' Coukouma]

I found bug 296644 since the partial fix is included in recent 1.5 releases. That's (partially) resolved, so I think comment 4 is addressed. The "Authenticated Sessions" label seems to be a better fit than my current patch's passwords.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jhirsch, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Closing this long-abandoned bug