Subject: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

From: Neil Madden <[email-masked]>
Date: Mon, 15 Mar 2021 10:00:53 +0000

I want to come back to this topic as a new thread.

As I understand things, the difference on Android is that any app can claim to be a generic web browser and so claim to handle all URIs. Whereas on iOS only specifically vetted apps can claim to be web browsers. Is that correct?

If so, this does seem like a quite large hole in security of OAuth on Android. Should we be considering a new draft recommending alternative measures (such as attestation) on Android? Presumably the same issue is also true on most desktop OS?

— Neil

> On 23 Feb 2021, at 15:20, George Fletcher <[email-masked]> wrote:
> 
> Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that you want to ensure is "your" app then the most secure way is to look at "app attestation". This is however, way off topic for this thread :)
> 
> On 2/14/21 9:28 AM, Neil Madden wrote:
>> Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. 
>> 
>> There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. 
>> 
>> — Neil
>> 
>>> On 14 Feb 2021, at 13:48, Stoycho Sleptsov <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> 
>>> I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS",
>>> with the objective to verify if they are valid.
>>> 
>>> I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example).
>>> If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication.
>>> 
>>> Or is it considered a bad practice to do that?
>>> 
>>> Regards,
>>> Stoycho.
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Om <[email-masked]>
Date: Wed, 17 Mar 2021 10:47:03 +0530

If I read this correctly,
https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1
draft already addresses this under best practices.

On Mon, Mar 15, 2021 at 3:31 PM Neil Madden <[email-masked]>
wrote:

> As I understand things, the difference on Android is that any app can
> claim to be a generic web browser and so claim to handle all URIs. Whereas
> on iOS only specifically vetted apps can claim to be web browsers. Is that
> correct?
>
> If so, this does seem like a quite large hole in security of OAuth on
> Android. Should we be considering a new draft recommending alternative
> measures (such as attestation) on Android? Presumably the same issue is
> also true on most desktop OS?
>
> — Neil
>
> Unfortunately, in the mobile app world this isn't sufficient. On iOS using
> Universal Links will bind the https redirect_url to your app in a secure
> way but it doesn't work the same way on Android with App Links. There is
> still a problem with "mobile app impersonation". If you have an app that
> you want to ensure is "your" app then the most secure way is to look at
> "app attestation". This is however, way off topic for this thread :)
>
> On 14 Feb 2021, at 13:48, Stoycho Sleptsov <[email-masked]> <[email-masked]> wrote:
>
> 
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
- Regards,
Omkar Khair

---

From: Neil Madden <[email-masked]>
Date: Wed, 17 Mar 2021 07:55:38 +0000

No, it doesn’t mention this attack. The issue is that if the redirect_uri is not strongly bound to a legitimate client then a malicious app on the user’s device can initiate an OAuth flow and impersonate the legitimate client and then intercept the response by claiming to handle the redirect_uri. 

We thought this was solved by using claimed https redirect_uris (Universal Links on iOS, AppLinks on Android), as these require the webserver to publish a document explicitly granting permission for a particular app to claim part of its https address space. But it turns out that Android has a hole in this because it allows any app to claim to be a web browser and so handle all URIs. 

(I thought this attack was discussed in the security topics bcp, but I can’t see it). 

The 2.1 draft currently requires (MUST) ASes to support private-use URL schemes, which makes this problem much worse. IMO private-use URL schemes are un-securable and shouldn’t be encouraged let alone mandated. 

— Neil

> On 17 Mar 2021, at 05:17, Om <[email-masked]> wrote:
> 
> If I read this correctly, https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1 draft already addresses this under best practices.
> 
>>> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden <[email-masked]> wrote:

---

From: "SOMMER, DOMINIK" <[email-masked]>
Date: Wed, 17 Mar 2021 08:04:13 +0000

I’d throw in PKCE as a means of assuring that the client who made the user follow the auth flow in the first place, is apparently the only one able to “redeem” the auth code returned to the redirect_uri.

Von: OAuth <[email-masked]> Im Auftrag von Om
Gesendet: Mittwoch, 17. März 2021 06:17
An: Neil Madden <[email-masked]>
Cc: Vittorio Bertocci <vittorio.bertocci=[email-masked]>; oauth <[email-masked]>; Warren Parad <wparad=[email-masked]>
Betreff: Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]

On Mon, Mar 15, 2021 at 3:31 PM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
I want to come back to this topic as a new thread.

— Neil

On 23 Feb 2021, at 15:20, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

— Neil

On 14 Feb 2021, at 13:48, Stoycho Sleptsov <[email-masked]><mailto:[email-masked]> wrote:

Regards,

Stoycho.

Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 116409
Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt

OAuth mailing list

[email-masked]<mailto:[email-masked]>

ForgeRock values your Privacy<https://www.forgerock.com/your-privacy>_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
- Regards,
Omkar Khair

---

From: Neil Madden <[email-masked]>
Date: Wed, 17 Mar 2021 08:14:49 +0000

Right, but PKCE doesn’t stop an attack when the malicious app initiates the authorization flow. 

> On 17 Mar 2021, at 08:04, SOMMER, DOMINIK <[email-masked]> wrote:
> 
> 
> On 14 Feb 2021, at 13:48, Stoycho Sleptsov <[email-masked]> wrote:
>  
> 
> ForgeRock values your Privacy_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Warren Parad <[email-masked]>
Date: Wed, 17 Mar 2021 11:48:12 +0100

Would it be fair to characterize this attack vector as a mix-up attack
where the malicious app is essentially an Attacker AS?

In the Desktop OS category, responding with the *issuer* in the
authorization response (
https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00) returned to
the user's browser via the one that presumably user started the flow with.
But on Android apps can directly decide intercept the authorization
response thus invalidating the protection mechanism instituted by the draft?

I do agree that hypothetically there could be a malicious program installed
in the Desktop OS environment that could perpetrate this attack. However,
without thinking too much about it, I'm biased to believe existing TLS and
browser security mechanisms are sufficient with the addition of the
*issuer *included in the response.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Wed, Mar 17, 2021 at 9:15 AM Neil Madden <[email-masked]>
wrote:

> I’d throw in PKCE as a means of assuring that the client who made the user
> follow the auth flow in the first place, is apparently the only one able to
> “redeem” the auth code returned to the redirect_uri.
>
>
>
>
>
> *Von:* OAuth <[email-masked]> *Im Auftrag von *Om
> *Gesendet:* Mittwoch, 17. März 2021 06:17
> *An:* Neil Madden <[email-masked]>
> *Cc:* Vittorio Bertocci <vittorio.bertocci=[email-masked]>;
> oauth <[email-masked]>; Warren Parad <wparad=[email-masked]>
> *Betreff:* Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token
> Mediating and session Information Backend For Frontend (TMI BFF)]
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH,
> Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt
> am Main HRB 116409

---

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Wed, 17 Mar 2021 14:20:23 +0100

I don't think this attack fits into the mix-up attack class.

According to the security BCP (section 4.4) mix-up attacks are defined as:

> The goal of the attack is to obtain an authorization code or an access 
> token for an uncompromised authorization server. This is achieved by 
> *tricking the client into sending those credentials to the compromised 
> authorization server* (the attacker) instead of using them at the 
> respective endpoint of the uncompromised authorization/resource server.

While the goal of both attacks might be similar, in the scenario we are 
talking about here there is no honest client who sends credentials to 
the attacker.

On 17.03.2021 11:48, Warren Parad wrote:
> authorization response 
> (https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00 
> <https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00>) 
> returned to the user's browser via the one that presumably user 
> started the flow with. But on Android apps can directly decide 
> intercept the authorization response thus invalidating the protection 
> mechanism instituted by the draft?
>
> I do agree that hypothetically there could be a malicious program 
> installed in the Desktop OS environment that could perpetrate this 
> attack. However, without thinking too much about it, I'm biased to 
> believe existing TLS and browser security mechanisms are sufficient 
> with the addition of the *issuer *included in the response.
>
> 	
>
> Warren Parad
>
> Founder, CTO
>
> On Wed, Mar 17, 2021 at 9:15 AM Neil Madden <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     On 17 Mar 2021, at 08:04, SOMMER, DOMINIK
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     
>>
>>     I’d throw in PKCE as a means of assuring that the client who made
>>     the user follow the auth flow in the first place, is apparently
>>     the only one able to “redeem” the auth code returned to the
>>     redirect_uri.
>>
>>     *Von:*OAuth <[email-masked]
>>     <mailto:[email-masked]>> *Im Auftrag von *Om
>>     *An:* Neil Madden <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc:* Vittorio Bertocci
>>     <vittorio.bertocci=[email-masked]
>>     <mailto:[email-masked]>>; oauth <[email-masked]
>>     <mailto:[email-masked]>>; Warren Parad
>>     <wparad=[email-masked]
>>     <mailto:[email-masked]>>
>>     *Betreff:* Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re:
>>     Token Mediating and session Information Backend For Frontend (TMI
>>     BFF)]
>>
>>     https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10
>>     <https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10>
>>     the 2.1 draft already addresses this under best practices.
>>
>>     On Mon, Mar 15, 2021 at 3:31 PM Neil Madden
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         As I understand things, the difference on Android is that any
>>         app can claim to be a generic web browser and so claim to
>>         handle all URIs. Whereas on iOS only specifically vetted apps
>>         can claim to be web browsers. Is that correct?
>>
>>         If so, this does seem like a quite large hole in security of
>>         OAuth on Android. Should we be considering a new draft
>>         recommending alternative measures (such as attestation) on
>>         Android? Presumably the same issue is also true on most
>>         desktop OS?
>>
>>         — Neil
>>
>>
>>
>>             On 23 Feb 2021, at 15:20, George Fletcher
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             Unfortunately, in the mobile app world this isn't
>>             sufficient. On iOS using Universal Links will bind the
>>             https redirect_url to your app in a secure way but it
>>             doesn't work the same way on Android with App Links.
>>             There is still a problem with "mobile app impersonation".
>>             If you have an app that you want to ensure is "your" app
>>             then the most secure way is to look at "app attestation".
>>             This is however, way off topic for this thread :)
>>
>>                     On 14 Feb 2021, at 13:48, Stoycho Sleptsov<[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>                       
>>
>>                     
>>
>>     Sitz der Gesellschaft / Corporate Headquarters: Miles & More
>>     GmbH, Frankfurt am Main, Registereintragung / Registration:
>>     Amtsgericht Frankfurt am Main HRB 116409
>>         ForgeRock values your Privacy
>>         <https://www.forgerock.com/your-privacy>_______________________________________________
>>         OAuth mailing list
>>         <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>     -- 
>>
>>     - Regards,
>>     Omkar Khair
>>
>>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>     ForgeRock values your Privacy
>     <https://www.forgerock.com/your-privacy>_______________________________________________
>     OAuth mailing list
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Is your OAuth or OpenID Connect client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 17 Mar 2021 06:53:22 -0700

This is an impersonation attack. As far as I know there isn't any good
solution for it. The good news is the preconditions for actually pulling
off the attack make it unlikely to be a problem in practice.

I would like to see a proper solution though, however that's going to
require some sort of cooperation from the mobile OS vendors to provide the
necessary hooks to properly authenticate apps in some way.

Aaron

On Wed, Mar 17, 2021 at 6:20 AM Karsten Meyer zu Selhausen <
[email-masked]> wrote:

> token for an uncompromised authorization server. This is achieved by *tricking
> the client into sending those credentials to the compromised authorization
> server* (the attacker) instead of using them at the respective endpoint
> of the uncompromised authorization/resource server.
>
>
> talking about here there is no honest client who sends credentials to the
> attacker.
>
> https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00) returned
> to the user's browser via the one that presumably user started the flow
> with. But on Android apps can directly decide intercept the authorization
> installed in the Desktop OS environment that could perpetrate this attack.
> However, without thinking too much about it, I'm biased to believe existing
> TLS and browser security mechanisms are sufficient with the addition of the
>> I’d throw in PKCE as a means of assuring that the client who made the
>> user follow the auth flow in the first place, is apparently the only one
>> able to “redeem” the auth code returned to the redirect_uri.
>>
>>
>>
>>
>>
>> Unfortunately, in the mobile app world this isn't sufficient. On iOS
>> using Universal Links will bind the https redirect_url to your app in a
>> secure way but it doesn't work the same way on Android with App Links.
>> There is still a problem with "mobile app impersonation". If you have an
>> app that you want to ensure is "your" app then the most secure way is to
>> look at "app attestation". This is however, way off topic for this thread :)
>>
> Is your OAuth or OpenID Connect client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>
> Hackmanit GmbHUniversitätsstraße 60 <https://www.google.com/maps/search/Universit%C3%A4tsstra%C3%9Fe+60?entry=gmail&source=g> (Exzenterhaus)
> 44789 Bochum
>
-- 
---
Aaron Parecki
https://aaronparecki.com