Difference between revisions of "Native App Security"

From MgmtWiki
Jump to: navigation, search
(=App Vetting Process)
(Solutions)
Line 24: Line 24:
 
* Joint use [[Native App]]s are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
 
* Joint use [[Native App]]s are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
 
* [https://www.owasp.org/index.php/SameSite Same Site] was designed to help, but [https://outlook.live.com/mail/inbox/id/AQQkADAwATExAGMzNy1iY2JmLWIwYmYtMDACLTAwCgAQAHD5YNrixl9FqyVrfekhw50%3D as of (2018-09-21) is not consistently applied]. In 2020 a process of tightening the same site requirements was under way at blink.
 
* [https://www.owasp.org/index.php/SameSite Same Site] was designed to help, but [https://outlook.live.com/mail/inbox/id/AQQkADAwATExAGMzNy1iY2JmLWIwYmYtMDACLTAwCgAQAHD5YNrixl9FqyVrfekhw50%3D as of (2018-09-21) is not consistently applied]. In 2020 a process of tightening the same site requirements was under way at blink.
* RFC 8258 ''OAuth 2.0 for Native Apps'' is a best practice document that requires tall requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. It includes details for each of the major platforms, iOS, Android and Windows. In particular it mentions the app's security identifier for Windows, but all os's give the apps some sort of identifier that survives update and should be the primary source of app identity as the os app store will assure uniqueness.
+
* RFC 8258 ''OAuth 2.0 for Native Apps'' is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. It includes details for each of the major platforms, iOS, Android and Windows. In particular it mentions the app's security identifier for Windows, but all os's give the apps some sort of identifier that survives update and should be the primary source of app identity as the os app store will assure uniqueness.
  
 
===App Vetting Process===
 
===App Vetting Process===
 
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-163r1.pdf NIST Special Publication 800-163 Revision 1 Vetting the Security of Mobile Applications] 2019-04 describes a process to ensure that mobile applications conform to an organizations's security requirements and are reasonably free from vulnerabilities.
 
* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-163r1.pdf NIST Special Publication 800-163 Revision 1 Vetting the Security of Mobile Applications] 2019-04 describes a process to ensure that mobile applications conform to an organizations's security requirements and are reasonably free from vulnerabilities.
 
* Native Apps have been shown to be vulnerable by the public announcement of many breaches; see the discussion of [https://wiki.idesg.org/wiki/index.php/Patient_Choice Patient Choice].
 
* Native Apps have been shown to be vulnerable by the public announcement of many breaches; see the discussion of [https://wiki.idesg.org/wiki/index.php/Patient_Choice Patient Choice].
 +
* The [https://www.firstnet.com/apps.html FirstNet process of app vetting] is already well tested.
  
 
===NIST NCCoE Support===
 
===NIST NCCoE Support===

Revision as of 12:16, 21 February 2020

Full Title and Meme

An app or application that is installed by the user to their device, as distinct from a Web App that runs in the browser context only. Apps implemented using web-based technology but distributed as a native app, so-called "hybrid apps", are considered equivalent to native apps by RFC 8252.

Context

  • The day when a personal computer was for running applications for the user is long gone, never to return.
  • Today a personal computer depends on cloud based service for nearly all of its functionality.
  • Some of those sites are willing to use a trusted User Agent, typically a web browser from a well-known and trusted vendor for rendering its content.
  • The first of the Laws of Security tell us that when an attacker gets to run their code on your computer, it is no longer just your computer any longer.
  • But now many Web Sites encourage to run their applications on the user device to improve their control of the User Experience.
  • When these apps exchange user data with other locations, they are considered by OAuth 2.0 to be operating a clients of the user.
  • But the security of these apps is questionable, a IETF standard OAuth 2.0 for Native Apps seeks to address some of the issues.
  • For the case where the user is not forced to allow an application to run on their personal device, see the page Web Site Security.

Problems

  • One of the worst case scenarios for Native App security is that of payments made directly from a user's bank account without the user selected user agent (browser) assuring that the user consents to the payment.
  • In Open Banking it is proposed that a payment initiator and a bank can both have Native Apps running where the payment initiator app asks the banking app on the same device for permission to remove money from the user's account.
  • The article Watch Out for a Clever Touch ID Scam Hitting the App Store shows how unscrupulous apps can fool the user in to granting access to their bank accounts.
  • A Web View is a display of information from a Web Site. There is no trustworthy indication that the Native App has correctly displayed the information that it obtained from the Web Site.

Solutions

  • The Native App exposes its name and the web site that backs it in a manner that allows the user to make a meaningful trust decision.
    • Android play store requires[1] any app that uses a brand name service to be securely bound to a URL that properly exposes that brand.
    • Apple has not released any plans to improve app naming security as of 2018-09-21.
  • Joint use Native Apps are provide to some industries for all to use. It makes the trust decision by the user much more difficult.
  • Same Site was designed to help, but as of (2018-09-21) is not consistently applied. In 2020 a process of tightening the same site requirements was under way at blink.
  • RFC 8258 OAuth 2.0 for Native Apps is a best practice document that requires all requests from native apps should only be made through external user-agents. This document assumes that those are browsers supplied by the o/s vendor or otherwise vetted as secure for the user. It includes details for each of the major platforms, iOS, Android and Windows. In particular it mentions the app's security identifier for Windows, but all os's give the apps some sort of identifier that survives update and should be the primary source of app identity as the os app store will assure uniqueness.

App Vetting Process

NIST NCCoE Support

Android Support

Apple iPhone Support

Windows Support

  • Windows (UWP) settings are on all Windows 10 computer, but do not seem to be shown anywhere on the web. Just navigate start -> settings -> privacy -> app settings.
  • Rules for apps installed on Windows devices are of two types (UWP and traditional), but it is not clear how the user could possibly distinguish, so the concept has not been helpful.

References

  1. 1.0 1.1 Handling Android App Links. https://developer.android.com/training/app-links/

Other References