1

Consider the following hypothetical scenario:

  1. I create the PhotoApp - native Android application that is used by users to manage their private photos.
  2. I create the PhotoService - Web API that is accessed by the native PhotoApp, providing the access and storage of the photos.
  3. Both applications are registered in the Azure AD and the PhotoApp is given the permission to access the PhotoService.
  4. PhotoApp uses Azure AD middleware web flow to provide a login to the application and access to the PhotoService.
  5. PhotoApp is launched and available to users.
  6. Malicious party downloads PhotoApp and extracts the TenantID, ClientID and rest of the authentication stuff from the app package.
  7. Malicious party creates rogue application BanditApp which uses same authentication configuration (TenantID, ClientID, ...) as the original PhotoApp.
  8. BanditApp is launched and available to users.
  9. The Azure AD is unable to distinguish between original PhotoApp and BanditApp.
  10. User logs into the BanditApp.
  11. The BanditApp steals photos from the user.
  12. The Azure AD and PhotoService are now involved in illegal activities.

Is this viable scenario?

How to protect this from happening?

Dusan
  • 111
  • 4
  • 1
    That's usually why you authenticate users and not applications, even more when the application is open to scrutinizing, but anyway: don't store enough credentials in an application so that's the only barrier toward datas. – Tensibai Aug 27 '18 at 12:28
  • Thank you for the comment. In order to use Azure AD identity provider (IP), the app must have required auth configuration parameters, those cannot be left out from there. Now, the web API is accessed via the JWT that contains user principal (generated by the IP) and not via application principal (which would be possible only by embedding the shared secret in the app and thus exposing it, which is not, certainly, the way to go). So, in my scenario, the user is authenticated in the web API. The problem is in the design - Azure AD trusts BanditApp out of the box. – Dusan Aug 28 '18 at 11:37
  • Think that real question is: How to make Azure AD IP trust only my genuine app and not every other app which says I am that app? – Dusan Aug 28 '18 at 11:39
  • Then I think it's a duplicate of [Secure Software: How to ensure caller is authentic?](https://security.stackexchange.com/questions/104107/secure-software-how-to-ensure-caller-is-authentic?rq=1) – Tensibai Aug 28 '18 at 12:07
  • More or less, it boils down to "you can't really prevent this", one way to mitigate the risk is to roll updates periodically with new keys. Once your known park is updated (or after few days to let a maximum of people update) invalidate the old keys, as such the banditapp would have to be updated also with new keys and the users fooled by banditapp should be visible by failure to authenticate in logs. – Tensibai Aug 28 '18 at 12:14

0 Answers0