Subject: [webfinger] Outstanding WF Security Concerns

From: James M Snell <[email-masked]>
Date: Tue, 4 Dec 2012 13:48:24 -0800

In the current draft -07 spec there are a handful of fairly important
security issues that have yet to be dealt with. I summarized these in a
separate note to Paul and the other authors while waiting for this new list
to be set up and wanted to call them out here for discussion as well.

1. Potential Mixed-session hijack vulnerability

   When accessing an authenticated WebFinger service via HTTPS,
   there is a potential session-hijacking vulnerability if the
   returned JRD contains non-HTTPS URLs to the same domain as
   the WebFinger server and session cookies are not properly
   secured. As a best practice, if the JRD is served over a
   HTTPS connection, any links to the same domain contained
   within the JRD SHOULD also use HTTPS and server implementations
   need to make sure that all session cookies are properly
   secured against hijacking. (This issue is no different than
   your typical mixed-session vulnerability)

2. 3xx Redirects to insecure targets

   WebFinger explicitly allows a WebFinger server to redirect
   requests to a separate third party service provider. It
   does not, however, require the use of HTTPS with the redirected
   target.

   For example, imagine sending a GET request to:

     https://example.org/.well-known/webfinger?r...

   And getting back...

     HTTP/1.1 302 Found
     Location: http://example.net/wf?r=...

   The redirected request will no longer be protected, negating
   the point of using HTTPS in the first request and putting the
   client at risk.

   Redirects returned by the server for requests issued over HTTPS
   ought to be required to point to HTTPS secured URLs... e.g.

     HTTP/1.1 302 Found
     Location: https://example.net/wf?r=...

3. Also with regards to third party redirects, how is the client
   able to determine that the redirection was appropriately
   authorized by the original WF provider? If the server (or
   vulnerable intermediary) has been compromised, a client can be
   tricked into redirecting to a malicious server providing false
   information. If, for instance, a fake Identity Provider URL is
   provided, the client may not be capable of detecting the intrusion.
   Use of HTTPS will not prevent such attacks. One reliable
   solution is to require the use of cryptographic integrity checks on
   the JRD resource. That is, if Server A redirects to Server B, then
   the JRD provided by Server B needs to be signed by a key trusted by
   both Server A and the client. However it is done, the client needs
   to be able to determine that Server B is authorized by Server A
   to provide WebFinger data on it's behalf... a redirect served over
   HTTPS does not, by itself, provide sufficient assurance.

4. When a client sends an unauthorized WebFinger request for a
   resource, a 404 Not Found response needs to be returned to make
   such responses indistinguishable from requests for resources the
   service has no information about.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 12 Dec 2012 10:04:20 -0800

I had sent this before but I believe it went out before many people had
moved over to the new list. Item #1 has already been discussed but still
needs to be addressed in the draft. The other issues, as far as I can tell,
have not yet been dealt with.

---------- Forwarded message ----------
From: James M Snell <[email-masked]>
Date: Tue, Dec 4, 2012 at 1:48 PM
Subject: Outstanding WF Security Concerns
To: [email-masked]

   And getting back...

     HTTP/1.1 302 Found

     HTTP/1.1 302 Found

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 02:45:45 -0500

James,

1. “Potential Mixed-session hijack vulnerability” – WebFinger does not define a “session”.  The client requests a document and get a reply.  That’s it. We must allow non-HTTPS URIs in the document, because lots of people store lots of things in places that do not need to be secure.  Security requirements related to these other resources is really outside the scope of WF.  WF just tells a client where the information can be found.

2. “3xx Redirects to insecure targets” -  I think the language in the new proposal will address this.

3. This can occur with any protocol and there’s not a thing we can do.  A query might go to the right server and even the server itself is compromised and serving up bogus information.  The best we can do is recommend HTTPS and even then there are no guarantees.  We could disallow redirects, but that seems harsh.  I would personally like to use a redirect from HTTP to HTTPS, just as a means of forcing queries to use HTTPS. 

4. What is an “an unauthorized WebFinger request”?  If a query is sent to a server for resource/subject for which the server knows nothing about, it returns a 404.  If a client is truly not authorized, as in a client must provide credentials to even query the WF server, then a 401 (or 403) would be sent.  This would be standard HTTP behavior, not WF-specific behavior.  Is that what you’re getting at?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Wednesday, December 12, 2012 1:04 PM
To: [email-masked]
Subject: [webfinger] Fwd: Outstanding WF Security Concerns

I had sent this before but I believe it went out before many people had moved over to the new list. Item #1 has already been discussed but still needs to be addressed in the draft. The other issues, as far as I can tell, have not yet been dealt with.

---------- Forwarded message ----------
From: James M Snell <[email-masked]>
Date: Tue, Dec 4, 2012 at 1:48 PM
Subject: Outstanding WF Security Concerns
To: [email-masked]

In the current draft -07 spec there are a handful of fairly important security issues that have yet to be dealt with. I summarized these in a separate note to Paul and the other authors while waiting for this new list to be set up and wanted to call them out here for discussion as well. 

   target. 

   And getting back...

     HTTP/1.1 302 Found

   client at risk. 

     HTTP/1.1 302 Found

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:10:10 -0800

On Wed, Dec 12, 2012 at 11:45 PM, Paul E. Jones <[email-masked]>wrote:

> James,****
>
> ** **
>
> 1. “Potential Mixed-session hijack vulnerability” – WebFinger does not
> define a “session”.  The client requests a document and get a reply.
> That’s it. We must allow non-HTTPS URIs in the document, because lots of
> people store lots of things in places that do not need to be secure.
>  Security requirements related to these other resources is really outside
> the scope of WF.  WF just tells a client where the information can be found.
> ****
>
> **
>

Suggested text for the Security Considerations:

---START TEXT---
  While this specification does not define any notion of a persistent
"session" and does not directly require the use of client or server
authentication, it is expected that the WebFinger protocol will be used
within applications that do require persistent authentication and access to
secure resources. In such cases, WebFinger implementations that use
non-secured HTTP cookies as a means of exchanging authenticated session
identifiers are vulnerable to a variety of session hijacking and cross-site
scripting attacks. Such attacks are not specific to the WebFinger protocol
and are considered beyond the scope of this specification. That said,
however, the threat can be mitigated by properly securing cookies as
defined in [RFC6265] Sections 5.2.5 and 5.2.6.
---END TEXT---

Note that this vulnerability only exists under the following conditions:

 1. Access to the WebFinger document requires authentication or results in
the creation of a "session" on the server.
 2. Cookies are used to return the session identifier to the client
 3. The Cookies are not properly secured with HttpOnly/Secure flags
 4. The WebFinger document contains insecure links to the *same domain* as
the WebFinger servic. Insecure links to other domains contained within the
document are not affected.

Obviously, this is not a risk that is specific to WebFinger, but it needs
to be acknowledged as something that was considered and explicitly ruled
out of scope per BCP 72, Section 5. (http://tools.ietf.org/html/bcp72)

>  **
>
> 2. “3xx Redirects to insecure targets” -  I think the language in the new
> proposal will address this.****
>
> **
>

Based on what I've been able to follow so far, I think you're right. Good
to see this one being addressed.

>  **
>
> 3. This can occur with any protocol and there’s not a thing we can do.  A
> query might go to the right server and even the server itself is
> compromised and serving up bogus information.  The best we can do is
> recommend HTTPS and even then there are no guarantees.  We could disallow
> redirects, but that seems harsh.  I would personally like to use a redirect
> from HTTP to HTTPS, just as a means of forcing queries to use HTTPS. ****
>
> **
>

There is something we can do... Per BCP72 Section 5 it needs to be
mentioned as a potential vulnerability so implementers are properly
aware... The current final paragraph in the Security Considerations gets us
most of the way there but something also needs to be said about the risks
involved in entrusting non-verified third parties to provide WebFinger
data. Also, it must be indicated that dealing with such issues is
explicitly out of the scope of the WebFinger specification.

> **
>
> 4. What is an “an unauthorized WebFinger request”?  If a query is sent to
> a server for resource/subject for which the server knows nothing about, it
> returns a 404.  If a client is truly not authorized, as in a client must
> provide credentials to even query the WF server, then a 401 (or 403) would
> be sent.  This would be standard HTTP behavior, not WF-specific behavior.
> Is that what you’re getting at?****
>
> **
>

What I'm saying is that a particular user might not be authorized to use a
particular WebFinger server. For such users, I do not want them being able
to find out ANY information about any of that servers resources. For
instance, suppose we have a spammer who wishes to target a particular
organization. His first step is to generate a database of potential target
email addresses. The second step is to weed out all of the accounts that
are invalid. If the WebFinger server returns a 404 for all invalid
accounts; but a 401 for valid accounts that require authentication, the
attacker will have learned some very important information about the target
organization, making their job significantly easier in the end. In order to
keep from making the attackers job any easier, a WebFinger server that
requires authentication ought to return 404 for ALL non-authenticated
requests, even if the target resource is known to the server (see BCP72
4.6.3.1, "Make your attacker do more work than you do").

Again, yes, this is not a problem that is specific to WebFinger, but given
the core use cases that WebFinger is intended to address it needs to be
discussed.

- James

> **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *James M Snell
> *Sent:* Wednesday, December 12, 2012 1:04 PM
> *To:* [email-masked]
> *Subject:* [webfinger] Fwd: Outstanding WF Security Concerns****
>
> ** **
>
> have not yet been dealt with.****
>
> From: *James M Snell* <[email-masked]>
> to be set up and wanted to call them out here for discussion as well. ****
>
> ** **
>
> 1. Potential Mixed-session hijack vulnerability****
>
> ** **
>
>    When accessing an authenticated WebFinger service via HTTPS,****
>
>    there is a potential session-hijacking vulnerability if the ****
>
>    returned JRD contains non-HTTPS URLs to the same domain as ****
>
>    the WebFinger server and session cookies are not properly ****
>
>    secured. As a best practice, if the JRD is served over a ****
>
>    HTTPS connection, any links to the same domain contained ****
>
>    within the JRD SHOULD also use HTTPS and server implementations****
>
>    need to make sure that all session cookies are properly ****
>
>    secured against hijacking. (This issue is no different than ****
>
>    your typical mixed-session vulnerability)****
>
> ** **
>
> 2. 3xx Redirects to insecure targets****
>
> ** **
>
>    WebFinger explicitly allows a WebFinger server to redirect ****
>
>    requests to a separate third party service provider. It ****
>
>    does not, however, require the use of HTTPS with the redirected****
>
>    target. ****
>
> ** **
>
>    For example, imagine sending a GET request to:****
>
> ** **
>
>      https://example.org/.well-known/webfinger?r...****
>
> ** **
>
>    And getting back...****
>
> ** **
>
>      HTTP/1.1 302 Found****
>
>      Location: http://example.net/wf?r=...****
>
> ** **
>
>    The redirected request will no longer be protected, negating ****
>
>    the point of using HTTPS in the first request and putting the****
>
>    client at risk. ****
>
> ** **
>
>    Redirects returned by the server for requests issued over HTTPS****
>
>    ought to be required to point to HTTPS secured URLs... e.g.****
>
> ** **
>
>      HTTP/1.1 302 Found****
>
>      Location: https://example.net/wf?r=...****
>
> ** **
>
> 3. Also with regards to third party redirects, how is the client ****
>
>    able to determine that the redirection was appropriately ****
>
>    authorized by the original WF provider? If the server (or ****
>
>    vulnerable intermediary) has been compromised, a client can be ****
>
>    tricked into redirecting to a malicious server providing false ****
>
>    information. If, for instance, a fake Identity Provider URL is ****
>
>    provided, the client may not be capable of detecting the intrusion. ***
> *
>
>    Use of HTTPS will not prevent such attacks. One reliable ****
>
>    solution is to require the use of cryptographic integrity checks on ***
> *
>
>    the JRD resource. That is, if Server A redirects to Server B, then ****
>
>    the JRD provided by Server B needs to be signed by a key trusted by ***
> *
>
>    both Server A and the client. However it is done, the client needs****
>
>    to be able to determine that Server B is authorized by Server A****
>
>    to provide WebFinger data on it's behalf... a redirect served over****
>
>    HTTPS does not, by itself, provide sufficient assurance.****
>
> ** **
>
> 4. When a client sends an unauthorized WebFinger request for a ****
>
>    resource, a 404 Not Found response needs to be returned to make****
>
>    such responses indistinguishable from requests for resources the****
>
>    service has no information about.****
>
> ** **
>
> - James****
>
> ** **
>