707597 - Bugzilla shouldn't allow using GET when authenticating in order to protect users from poorly-written client apps

Status: RESOLVED WONTFIX

(Bugzilla :: User Accounts, defect)

Description

[Dave Miller [:justdave]]

We discovered an unusually high number of regular logins from people who should know better in the bugzilla.mozilla.org webserver logs where the user's email address and password were logged with the URL because they logged in submitting their credentials as URL params using a GET.

In tracking this down, it turned out to be a popular third-party Bugzilla client which was doing this, unbeknownst to the end-users.  This isn't a huge criticality because in theory the people with access to those weblogs would have access to alter Bugzilla's code to log your passwords anyway if they really wanted them, but as with other things, it's better not to leave temptation, not the mention you never know where the logs might end up down the road.

With the upsurge in the use of mobile apps and integration with other applications in recent years, the likelihood of this type of thing happening without knowledge of the end user is really high.  For an end-user protection thing we should enforce this on the server side so that clients are forced to use POST if they submit authentication credentials with the transaction.

The best place to do this is probably within the CGI authentication method, as other methods (single sign-on apps that pass a single-use auth token with the redirect, for example) may have a legitimate and non-scary use for it.

Comment 1

[David Lawrence [:dkl]]

Just as a note in regard to BMO. I am currently working on moving the REST API to BMO as a native extension. When doing GET requests over REST to get bugs, etc., public or private, it is common to include the username/password in the GET request as URL params.
As part of the design of REST, retrieving data resources is almost always over GET and we need to allow users to get private information so URL params should still be allowed for auth. Other write operations, such as PUT/POST would be done as POST body parameters and would not be logged.

Comment 2

[Max Kanat-Alexander]

  Hmm. I definitely agree that clients should not generally use GET with authentication, if they have some other option. But I'm not convinced that the solution is to fully deny all people the use of GET auth simply because a few developers have misused it.

  Perhaps the best solution would be to provide something like an OAuth token that people could use in the URL for their GET requests. Retrieving the token would have to be a POST operation.

  I don't think this is a security issue that needs to stay confidential.

Comment 3

[Gervase Markham [:gerv]]

I agree that this isn't security issue.

As dkl comments, the REST API, and RESTfulness in general, require it to be possible to pass authentication credentials as a GET. RESTfulness uses the HTTP verb to mean something, and also tries to make it so that each operation is a single request (rather than having a "login" operation, and then a subsequent privileged operation). This means that, inevitably, there will be GETs with parameters for any web app which allows the reading of privileged data.

AFAICS, the only risk difference between GET and POST for password leakage is that the webserver log stores GET info, but not POST. However, I think all webmasters of webapps like Bugzilla should be treating their logs as confidential info anyway, because there are plenty of other things which can appear in URL parameters which are sensitive.

The Bugzilla API's own logs (but not the webserver's) are pre-processed to remove passwords.

Gerv

Comment 4

[Frédéric Buclin]

So if I understand comments correctly, this bug is wontfix?

Comment 5

[Gervase Markham [:gerv]]

Well, dkl, max and I think so, but given that justdave filed it, I think we should give him the opportunity to come back at us before we close it! :-)

Gerv

Comment 6

[:glob ✱]

i also vote for wontfix.  i filed bug 699449 about filtering passwords out of bmo's httpd access logs.

Comment 7

[David Lawrence [:dkl]]

wontfix++

Gerv, what method are you using to filter the logs? We should be looking into solutions for this as well for BMO and you may have an easy fix for us.

dkl

Comment 8

[David Lawrence [:dkl]]

(In reply to David Lawrence [:dkl] from comment #7) 
> Gerv, what method are you using to filter the logs? We should be looking
> into solutions for this as well for BMO and you may have an easy fix for us.

Sorry, please add any info to bug 699449.

dkl

Comment 9

[Gervase Markham [:gerv]]

Bug 699449: not authorized :-(

But I have a custom logging function, and I do the filtering in there using a simple regexp which checks the URL params for the ones I know contain passwords and replaces them with "XXXX". Very simple!

Gerv

Comment 10

[Max Kanat-Alexander]

I would say that this bug as per its original description and summary is WONTFIX.

However, we should give people a way to auth via GET that doesn't involve a permanent secret like a password--perhaps via an OAuth flow or something similar like that, where you get a token that you have to renew every so often (it becomes invalid after an hour or so, for example).

If there isn't a bug for that already, it should be filed, and this bug should be referenced as the reasoning. Or alternately, this bug should be converted to have a new objective. But given that so many comments on this bug now say "wontfix," I think that would be confusing to anybody coming along and reading it, and a new bug should be opened.

Comment 11

[Max Kanat-Alexander]

Also, then once we have that token-based flow for GET logins, we can deprecate using Bugzilla_password as a URL argument, and then eventually deny it, thus actually fixing this bug. But we have to give people a workable alternative first, for the situations where they really need that functionality.

Comment 12

[Dave Miller [:justdave]]

Sounds like a plan.

Comment 13

[Dave Miller [:justdave]]

er...