This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27516 - exposing passwords is a bad idea
Summary: exposing passwords is a bad idea
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-04 15:28 UTC by Sam Ruby
Modified: 2015-06-15 16:29 UTC (History)
4 users (show)

See Also:

Attachments

Description Sam Ruby 2014-12-04 15:28:42 UTC 
This bug is opened on behalf of David Walp, based on http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0505.html

Original comment:

Yes, we, Microsoft, are of the opinion that exposing passwords is a bad idea.  Based on received feedback, customers agree and I suspect our customers are not unique on this opinion.
Comment 1 Anne 2014-12-04 15:41:25 UTC 
This is how e.g. XMLHttpRequest implements the user/password arguments. Has Microsoft dropped support for these in ftp URLs too now or are they still not telling the whole story when giving feedback?
Comment 2 Sam Ruby 2014-12-04 15:45:38 UTC 
A concrete example of an intentional difference from the proposed standard:

http://intertwingly.net/projects/pegurl/urltest-results/7357a04b5b

IE intentionally raises an exception of somebody attempts to fetch the href from an <a> element if that element contains a password.
Comment 3 Anne 2014-12-04 15:49:44 UTC 
Nothing is fetched in that test right? You mean invoking href's getter? I don't think that should ever throw.

I don't really see what attack that would protect against.
Comment 4 Sam Ruby 2014-12-04 18:21:21 UTC 
Ah, I should have avoided the word 'fetch' as it has other meanings in this context. :-)

Yes, I meant invoking the getter for href on an anchor (<a>) element.

Do you have an alternative to throwing an exception to suggest that meets the stated customer requirements?
Comment 5 Anne 2014-12-04 18:33:38 UTC 
Yeah, align with all the other UAs. I don't see the security problem. The password can also be retrieved through getAttribute().
Comment 6 Sam Ruby 2014-12-04 18:49:14 UTC 
document.querySelector('a').getAttribute('href') does indeed expose the password with IE11.
Comment 7 Anne 2014-12-04 19:26:12 UTC 
Apologies to Microsoft for comment 1, that was out of line.

The last time this was discussed in the context of XMLHttpRequest it turned out that username/password was not disabled for all URL schemes. And it wasn't clear what they were protecting against. That is why the URL specification aligned with the majority of implementations.

There's definitely something to say for not handling URLs that username/password set in Fetch, at least for certain type of fetches, but that's a separate discussion (recently held on blink-dev).
Comment 8 Sam Ruby 2015-01-02 10:22:51 UTC 
This syntax is deprecated per RFC 3986 and RFC 7230.  See:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13571.html

At a minimum, URLs that contain a non-blank password should be considered a conformance error.
Comment 9 Karl Dubost 2015-01-02 11:38:39 UTC 
Probably related, but maybe it deserved a proper bug at Moz.
https://bugzilla.mozilla.org/show_bug.cgi?id=479038
Comment 10 Sam Ruby 2015-04-04 02:49:25 UTC 
Related: https://support.microsoft.com/en-us/kb/834489
Comment 11 Anne 2015-06-15 15:21:27 UTC 
So yeah, if we want to match the RFCs we should make both username and password a conformance error. That seems very reasonable to me.