Subject: [OAUTH-WG] embedded UA detection

From: Giada Sciarretta <[email-masked]>
Date: Fri, 11 Oct 2019 16:44:45 +0200

Hello,

We are working on a project that involves mobile native applications.

The OAuth for native apps (RFC8252) spec "requires that native apps MUST
NOT use embedded user-agents  to perform authorization requests and allows
that authorization endpoints MAY take steps to detect and block
authorization requests  in embedded user-agents".

We would like to integrate in our AS the state-of-the-art techniques for
detecting and blocking authorization requests in embedded user-agents. We
are aware of the following techniques (link
<https://stackoverflow.com/questions/31848320/detect-android-webview>):

   - doing a string checking on the User agent string value. In the
   chromium based-WebView
      - in the older versions it adds the “Version/X.X” string into the UA
      field. For example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us;
Nexus One
      Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile
      Safari/533.1
      - in the newer version it will add, “;wv”. For example: Mozilla/5.0
      (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv)
AppleWebKit/537.36 (KHTML,
      like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
   - checking the presence of X-Requested-With HTTP header, the value of
   this header will be the application's name that is running the webview.

but we know that these detection methods can be bypassed by an attacker. Do
you have any suggestions in this regard?

Thank you in advance for your response.

Kind regards,

Giada Sciarretta

-- 
--
Le informazioni contenute nella presente comunicazione sono di natura 
privata e come tali sono da considerarsi riservate ed indirizzate 
esclusivamente ai destinatari indicati e per le finalità strettamente 
legate al relativo contenuto. Se avete ricevuto questo messaggio per 
errore, vi preghiamo di eliminarlo e di inviare una comunicazione 
all’indirizzo e-mail del mittente.

--
The information transmitted is 
intended only for the person or entity to which it is addressed and may 
contain confidential and/or privileged material. If you received this in 
error, please contact the sender and delete the material.

---

From: Joseph Heenan <[email-masked]>
Date: Thu, 24 Oct 2019 11:00:59 +0100

Hi Giada,

All methods can be bypassed by an attacker that has control of the app in question, it’s just a matter of effort. I believe many AS’s use client side javascript to provide a harder to bypass implementation.

Your aim here is probably mainly to prevent naive developers “accidentally” (or with good but misplaced intentions) using an embedded user agent.

In general the real state of the art would be for the party that owns the AS to have an associated first-party native mobile app, as that improves the user experience and greatly reduces the associated risks. I wrote about the pattern for doing this here:

https://josephheenan.blogspot.com/2019/08/implementing-app-to-app-authorisation.html

That said all the choices and risks here are very complex and interact with each other - from the information given I definitely can’t say whether app2app is a good approach in your use case.

Cheers

Joseph

> On 11 Oct 2019, at 15:44, Giada Sciarretta <[email-masked]> wrote:
> 
> Hello,
>  
> The OAuth for native apps (RFC8252) spec "requires that native apps MUST NOT use embedded user-agents  to perform authorization requests and allows that authorization endpoints MAY take steps to detect and block authorization requests  in embedded user-agents".
>  
> We would like to integrate in our AS the state-of-the-art techniques for detecting and blocking authorization requests in embedded user-agents. We are aware of the following techniques (link <https://stackoverflow.com/questions/31848320/detect-android-webview>):
> doing a string checking on the User agent string value. In the chromium based-WebView
> in the older versions it adds the “Version/X.X” string into the UA field. For example: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
> in the newer version it will add, “;wv”. For example: Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5 Build/LMY48B; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/43.0.2357.65 Mobile Safari/537.36
> checking the presence of X-Requested-With HTTP header, the value of this header will be the application's name that is running the webview.
>  
> but we know that these detection methods can be bypassed by an attacker. Do you have any suggestions in this regard?
>  
> Le informazioni contenute nella presente comunicazione sono di natura privata e come tali sono da considerarsi riservate ed indirizzate esclusivamente ai destinatari indicati e per le finalità strettamente legate al relativo contenuto. Se avete ricevuto questo messaggio per errore, vi preghiamo di eliminarlo e di inviare una comunicazione all’indirizzo e-mail del mittente.
> --
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth