Re: [OAUTH-WG] OAuth Digest, Vol 121, Issue 55

[Adam Cashion <[e-mail]>]

email

On Wed, Nov 21, 2018, 7:24 AM <[e-mail] wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Daniel Fett)
>    2. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Neil Madden)
>    3. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (Daniel Fett)
>    4. Re: OAuth Security Topics -- Recommend authorization code
>       instead of implicit (George Fletcher)
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Fett <[e-mail]>
> To: Neil Madden <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Wed, 21 Nov 2018 10:25:49 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>
> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
>
> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.
>
>
> I think we’re talking about different things. 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.
>
> Thanks for the clarification! I see that you highlight an important point
> there.
>
> The protection that would be required essentially boils down to something
> similar to a CSRF protection for the resource server.
>
> Luckily, CORS covers this: You can't set the Authorization header
> cross-origin unless the appropriate CORS headers are set. So while the
> third party origin would be able to send a request through the browser
> using the TLS context, it would not be able to attach the access token.
> (Unless, of course, that third party origin is whitelisted, or if the
> bearer token is sent in a different way, e.g., as a URL parameter.)
>
> As a side note, interestingly, this would leave an authorization code
> unprotected, if the sender authentication would be mTLS or token binding.
> PKCE on the other hand is fine.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Neil Madden <[e-mail]>
> To: Daniel Fett <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Wed, 21 Nov 2018 10:01:49 +0000
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> > On 21 Nov 2018, at 09:25, Daniel Fett <[e-mail]> wrote:
> >
> > Am 21.11.18 um 10:09 schrieb Neil Madden:
> >>> If a page from origin A includes a third-party script from origin B,
> that external script runs in origin A and has access to all cookies and the
> JavaScript context of the page.
> >>>
> >>> The SPA from origin A would be compromised. That is why we need things
> such as Subresource Integrity.
> >>>
> >> I think we’re talking about different things. 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.
> > Thanks for the clarification! I see that you highlight an important
> point there.
> >
> > The protection that would be required essentially boils down to
> something similar to a CSRF protection for the resource server.
> >
> > Luckily, CORS covers this: You can't set the Authorization header
> cross-origin unless the appropriate CORS headers are set. So while the
> third party origin would be able to send a request through the browser
> using the TLS context, it would not be able to attach the access token.
> (Unless, of course, that third party origin is whitelisted, or if the
> bearer token is sent in a different way, e.g., as a URL parameter.)
>
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an
> Authorization header and not just sent in a URL parameter or a CORS-safe
> form POST body (e.g. application/x-www-form-urlencoded). This should
> probably be its own security best practice recommendation, but I haven’t
> seen it anywhere. I think most REST APIs already do this following RFC
> 6750, but we should spell out that it has security benefits.
>
> Secondly, this means that we are relying on something other than
> (TLS-based) sender-constrained access tokens to prevent this, so we should
> clarify that in the document.
>
> >
> > As a side note, interestingly, this would leave an authorization code
> unprotected, if the sender authentication would be mTLS or token binding.
> PKCE on the other hand is fine.
>
> Right - that’s why I am glad to see the security topics draft recommending
> PKCE in all cases.
>
> Why is PKCE so effective? In my opinion, you can view PKCE as a one-time
> PoP scheme for the auth code - you prove possession of the secret to the AS
> by simply giving it the secret along with the auth code. You could do
> something similar with the implicit flow, but I won’t share that scheme
> here as I am happy for the implicit flow to die ;-)
>
> — Neil
>
>
>
>
> ---------- Forwarded message ----------
> From: Daniel Fett <[e-mail]>
> To: Neil Madden <[e-mail]>
> Cc: [e-mail]
> Bcc:
> Date: Wed, 21 Nov 2018 11:06:49 +0100
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> Am 21.11.18 um 11:01 schrieb Neil Madden:
>
> On 21 Nov 2018, at 09:25, Daniel Fett <[e-mail]> <[e-mail]> wrote:
>
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>
> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
>
> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.
>
>
> I think we’re talking about different things. 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.
>
> Thanks for the clarification! I see that you highlight an important point there.
>
> The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.
>
> Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)
>
>
> Right. But two points here:
>
> Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.
>
> Exactly what I thought. I will prepare a proposal for the security BCP.
>
> -Daniel
>
>
>
> ---------- Forwarded message ----------
> From: George Fletcher <[e-mail]>
> To: Torsten Lodderstedt <[e-mail]>, John Bradley <
> [e-mail]>
> Cc: Mike Jones <Michael.Jones=[e-mail]>, "
> [e-mail]" <[e-mail]>
> Bcc:
> Date: Wed, 21 Nov 2018 08:24:01 -0500
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
> An SPA has a backend because it has to be loaded from somewhere :)
>
> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
>
> We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
>
> Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.
>
>
> Am 20.11.2018 um 23:29 schrieb John Bradley <[e-mail]> <[e-mail]>:
>
> Post response works OK for server based clients.  I don't think POST works for single page applications.
>
> Basically that would be something more like postmessage between two JS apps.
>
> Postmessage also has security issues passing a access token and leaking.
>
> Perhaps someone more familiar with SPA can comment on POST.
>
> John B.
>
>
>
> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <[e-mail] wrote:
> Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.
>
> Thanks,
> George
>
> On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.
>
>
>
>                                                        -- Mike
>
>
>
> From: OAuth <[e-mail]> <[e-mail]> On Behalf Of John Bradley
> Sent: Tuesday, November 20, 2018 7:47 AM
> To: [e-mail]
> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>
>
>
> Yes the at_hash protects the client from accepting an injected AT.
>
> Unfortunately it doesn't do anything to protect against leakage in logs or redirects.
>
> So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.
>
> John B.
>
> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
>
> Hi Mike,
>
> I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.
>
> I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues:
>
> 1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
> 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach.
>
> kind regards,
> Torsten.
>
> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=[e-mail]> <Michael.Jones=[e-mail]>:
>
> This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>
> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>
>                                                                 Thank you,
>                                                                 -- Mike
>
> From: OAuth <[e-mail]> <[e-mail]> On Behalf Of Hannes Tschofenig
> Sent: Monday, November 19, 2018 2:34 AM
> To: oauth <[e-mail]> <[e-mail]>
> Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
>
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>