Chrome sends empty HTTP Negotiate token after 401 response with OK authentication
Reported by
r...@qoxp.net,
May 6 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 Steps to reproduce the problem: 1. client: GET with no Authorization header 2. server: 401 with WWW-Authenticate: Negotiate 3. client: GET with Authorization: Negotiate + initial SPNEGO/Kerberos token 4. server: 401 with SPNEGO response indicating authentication succeeded 5. client: GET with empty token: "Authorization: Negotiate \r\n" In this situation, Kerberos authentication is successful; the server is simply configured to deny the page to this particular authenticated user (it might provide the page to someone else). This odd behavior causes trouble because: a) Some servers can't handle it and crash (though that's clearly a bug in the server). b) The user only sees the result of the last GET attempt, which indicates that authentication failed. But that's misleading; the user should have gotten the response in step 4, the content of which in our use case tells the user they were authenticated but not allowed to view the page. This happens correctly with Firefox, for example, which does not do the buggy/malformed step 5. What is the expected behavior? Instead of sending an empty Negotiate token, Chrome should try the next available authentication method (or just stop if there are none). What went wrong? Chrome sent an empty, malformed Negotiate token. I am attaching a pcap file showing the exchange. Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: RHEL 7.3 Flash Version:
,
May 6 2017
I selected "Security" as the bug area since it seemed the most fitting of all the listed options, but I'm not sure that's right; feel free to recategorize as appropriate. It's a security-related bug, certainly, but with no obvious exploit or corresponding vulnerability.
,
May 8 2017
Thanks for the report. As this doesn't result in a vulnerability, derestricting for visibility and hopefully faster resolution.
,
May 8 2017
I'm not too familiar with the auth code. But if the server isn't suggesting the user should be prompted with another set of credentials, shouldn't it be returning 403, and not 401? Per spec: 3.1. 401 Unauthorized The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource. If the WWW-Authenticate doesn't include yet another challenge it expects the client to reply to, it seems to me like that's violating spec. Admittedly, we should probably hang up in confusion at that point, and display a network error page at that point, instead of sending another ge, if I'm understanding what's going on.
,
May 10 2017
,
Apr 25 2018
Per comment #4, think this isn't a Chrome issue.
,
Apr 25 2018
Sorry, I don't understand. How do the comments in #4 suggest that this "isn't a Chrome issue?" Your browser sends a malformed Authorization header: "Authorization: Negotiate" should be followed by a GSSAPI token, and instead there's nothing. There's nothing to send, because there is no next token: the GSSAPI security context is established. It shouldn't do this, and it causes the problems I listed initially. Other browsers don't do this, and don't have those problems. Why should this not be fixed?
,
Apr 25 2018
The server is sending a 401 (another auth challenge) to indicate auth succeeded. If it wants to indicate access to a page is denied, it should be returning a 403, per comment #4. While Chrome perhaps should do something better in the case of a broken server, the server is clearly violating spec, if it isn't sending an auth challenge: 3.1. 401 Unauthorized The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by r...@qoxp.net
, May 6 2017