Subject: [OAUTH-WG] Binding Access Tokens is not enough!

From: Daniel Fett <[email-masked]>
Date: Thu, 22 Nov 2018 15:42:06 +0100

Hi all,

I would like to discuss a text proposal for the security BCP.

Background:

Yesterday, Neil pointed out the following problem with binding access
tokens using mTLS or token binding in SPAs:

"I am talking about scripts from places like ad servers that are usually
included via an iframe to enforce the SOP and sandbox them from other
scripts. If they get access to an access token - e.g. via
document.referrer or a redirect or some other leak, then they still act
within the same TLS context as the legitimate client."

The problem is that a browser's TLS stack will attach the proof of
possession no matter which origin started a request.

(This seems like a real downside of token binding - why does it not have
the "same site" option that cookies nowadays have?)

I prepared the following addition to the security BCP and would like to
hear your opinions:

"It is important to note that constraining the sender of a token to a
web browser (using a TLS-based method) does not constrain the origin of
the script that uses the token (lack of origin binding). In other words,
if access tokens are used in a browser (as in a single-page application,
SPA) and the access tokens are sender-constrained using a TLS-based
method, it must be ensured that origins other than the origin of the SPA
cannot misuse the TLS-based sender authentication.

The problem can be illustrated using an SPA on origin A that uses an
access token AT that is bound to the TLS connection between the browser
and the resource server R. If AT leaks to an attacker E, and there is,
for example, an iframe from E's origin loaded in the web browser, that
iframe can send a request to origin R using the access token AT. This
request will contain the proof-of-posession of the (mTLS or token
binding) key. The resource server R therefore cannot distinguish if a
request containing a valid access token originates from origin A or
origin E.

If the resource server only accepts the access token in an Authorization
header, then Cross-Origin Resource Sharing (CORS) will protect against
this attack by default. If the resource server accepts the access tokens
in other ways (e.g., as a URL parameter), or if the CORS policy of the
resource server permits requests by origin E, then the TLS-based token
binding only provides protection if the browser is offline."

The "summary" above this text reads as follows:

"If access tokens are sender-constrained to a web browser, the resource
server MUST ensure that the access token can only be used by the origin
to which the access token was issued (origin binding). One solution for
the resource server to accomplish this is to only accept the access
token in an Authorization header (as described in RFC 6750) and to
ensure that the active CORS policy prevents third parties from sending
Authorization headers. See <xref target="pop_tokens"/> for details."

What do you think?

-Daniel

---

From: Neil Madden <[email-masked]>
Date: Fri, 23 Nov 2018 13:54:00 +0000

Thanks for doing this Daniel, I think the proposed text is good.

— Neil

> On 22 Nov 2018, at 14:42, Daniel Fett <[email-masked]> wrote:
> 
> Hi all,
> 
> Yesterday, Neil pointed out the following problem with binding access tokens using mTLS or token binding in SPAs:
> 
> "I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client."
> 
> The problem is that a browser's TLS stack will attach the proof of possession no matter which origin started a request.
> 
> (This seems like a real downside of token binding - why does it not have the "same site" option that cookies nowadays have?)
> 
> I prepared the following addition to the security BCP and would like to hear your opinions:
> 
> "It is important to note that constraining the sender of a token to a web browser (using a TLS-based method) does not constrain the origin of the script that uses the token (lack of origin binding). In other words, if access tokens are used in a browser (as in a single-page application, SPA) and the access tokens are sender-constrained using a TLS-based method, it must be ensured that origins other than the origin of the SPA cannot misuse the TLS-based sender authentication.
> 
> The problem can be illustrated using an SPA on origin A that uses an access token AT that is bound to the TLS connection between the browser and the resource server R. If AT leaks to an attacker E, and there is, for example, an iframe from E's origin loaded in the web browser, that iframe can send a request to origin R using the access token AT. This request will contain the proof-of-posession of the (mTLS or token binding) key. The resource server R therefore cannot distinguish if a request containing a valid access token originates from origin A or origin E.
> 
> If the resource server only accepts the access token in an Authorization header, then Cross-Origin Resource Sharing (CORS) will protect against this attack by default. If the resource server accepts the access tokens in other ways (e.g., as a URL parameter), or if the CORS policy of the resource server permits requests by origin E, then the TLS-based token binding only provides protection if the browser is offline."
> 
> 
> "If access tokens are sender-constrained to a web browser, the resource server MUST ensure that the access token can only be used by the origin to which the access token was issued (origin binding). One solution for the resource server to accomplish this is to only accept the access token in an Authorization header (as described in RFC 6750) and to ensure that the active CORS policy prevents third parties from sending Authorization headers. See <xref target="pop_tokens"/> for details."
> 
> What do you think?
> 
> -Daniel
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 25 Nov 2018 19:46:25 +0100

Does this mean the RS effectively relies on the user agent to enforce the sender constraint (via CORS policy)?

> Am 23.11.2018 um 14:54 schrieb Neil Madden <[email-masked]>:
>

---

From: Daniel Fett <[email-masked]>
Date: Mon, 26 Nov 2018 09:46:59 +0100

Yes. Token Binding enforces that only the right browser can send the
token; in this browser, CORS enforces that only the correct origin can
send the token.

---

From: Neil Madden <[email-masked]>
Date: Mon, 26 Nov 2018 10:33:13 +0000

I would perhaps clarify this a little, as it’s not really CORS that is doing the work here, but rather the same-origin policy (SOP) — which is actually *relaxed* by CORS. 

It is the fact that there is a non-safe header (Authorization) on the request that triggers the SOP protections - and it would do so even in an old pre-CORS browser. Otherwise CORS wouldn’t even be involved as the request would be considered “safe”. For instance, if your (RS) API just requires an x-www-form-urlencoded POST body with the access token as one of the fields then I can always just create a form in a hidden iframe and submit it cross-origin with no problems, CORS or not. Adding the Authorization header prevents that - you can’t add a custom header to a form submission, and Ajax would not be allowed to make that request.

What CORS changes is that things that would previously be blocked outright now produce a CORS preflight to allow the destination origin to override the SOP and allow a request to go ahead anyway.

— Neil

> On 26 Nov 2018, at 08:46, Daniel Fett <[email-masked]> wrote:
> 
> Yes. Token Binding enforces that only the right browser can send the token; in this browser, CORS enforces that only the correct origin can send the token.
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 29 Nov 2018 01:22:56 +0000

In some cases, the resource server will need to support CORS in order to support SPA clients that are on different origins. In this case, the resource server must optimistically allow the CORS request to be made, then validate that the request origin is appropriate for the access token provided in the request. To my knowledge, I haven't seen "origin-constrained access tokens" raised as a requirement anywhere, but here we are.

-- 
Annabelle Richard Backman
AWS Identity

On 11/26/18, 2:34 AM, "OAuth on behalf of Neil Madden" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    — Neil

---

From: Neil Madden <[email-masked]>
Date: Thu, 29 Nov 2018 06:51:34 +0000

My intent wasn’t to suggest that tokens *must* be origin constrained, just to point out if you are using TLS-based sender constrained tokens then you may also want to consider that aspect. 

In some cases you may be comfortable that protections against in-browser token theft are adequate without any sender/origin constraint. Sometimes a plain old bearer token is fine. 

— Neil

> On 29 Nov 2018, at 01:22, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 30 Nov 2018 00:22:03 +0000

Sure. But given that TLS token binding is often put forth as a mitigation against token theft and replay, it's worth noting that on its own it does not address this risk when the replay is coming from the same browser, and the RS needs to support CORS.

On 11/28/18, 10:51 PM, "Neil Madden" <[email-masked]> wrote:

    
    — Neil