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

["Richard Backman, Annabelle" <[e-mail]>]

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.

-- 
Annabelle Richard Backman
AWS Identity
 

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

    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 <[e-mail]> wrote:
    > 
    > 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" <[e-mail] on behalf of [e-mail]> wrote:
    > 
    >    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 <[e-mail]> 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.
    >> 
    >>> Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt:
    >>> 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 <[e-mail]>
    >>>> :
    >>>> 
    >>>> Thanks for doing this Daniel, I think the proposed text is good.
    >>>> 
    >>>> — Neil
    >>>> 
    >>>> 
    >>>>> On 22 Nov 2018, at 14:42, Daniel Fett <[e-mail]>
    >>>>> wrote:
    >>>>> 
    >>>>> 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
    >>>>> 
    >>>>> _______________________________________________
    >>>>> OAuth mailing list
    >>>>> 
    >>>>> [e-mail]
    >>>>> https://www.ietf.org/mailman/listinfo/oauth
    >>>> _______________________________________________
    >>>> OAuth mailing list
    >>>> 
    >>>> [e-mail]
    >>>> https://www.ietf.org/mailman/listinfo/oauth
    >> 
    >> 
    > 
    >    _______________________________________________
    >    OAuth mailing list
    >    [e-mail]
    >    https://www.ietf.org/mailman/listinfo/oauth
    > 
    >