Version 7.0.0 (September 2024)
- 28 Oct 2024
- 8 Minutes à lire
- SombreLumière
Version 7.0.0 (September 2024)
- Mis à jour le 28 Oct 2024
- 8 Minutes à lire
- SombreLumière
The content is currently unavailable in French. You are viewing the default English version.
Résumé de l’article
Avez-vous trouvé ce résumé utile ?
Merci pour vos commentaires
Introduction
Welcome to Mobile Application Shielding 7.0.0!
The OneSpan Customer Portal only accepts connections via TLS 1.2 or later. Earlier versions are no longer supported because all versions of the TLS protocol prior to 1.2 have been deprecated.
This is a release of Mobile Application Shielding, which contains enhancements and other product updates. For more information about new features and fixed defects, refer to the respective chapters in this document.
For information about configuring and using Mobile Application Shielding, see Mobile Application Shielding Integration Guide.
On the OneSpan Customer Portal, the last 12 versions of Mobile Application Shielding are available for download. To maintain protection against the latest mobile threats, ensure to update Mobile Application Shielding to the latest version!
Supported platform versions
App Shielding version 7.0.0 was successfully tested with Android 15.
Android 5.0 (API level 21) – Android 15.
Shielding Tool:
Windows 10: 64-bit Java 17
Mac OSX (10.9+)
Ubuntu Linux 20.04 LTS or 22.04 LTS
The App Shielding Gradle plugin version 2.0 and later is supported.
The App Shielding Gradle plugin 2.0 supports Android App Bundles and newer Android build versions.
The plugin and documentation can be downloaded from:
Android platform updates
Added support for Android 15 (API 35)
The Android minimum supported version is 5.0 (API level 21). This version of App Shielding supports Android 15.
If you want your protected app to run on Android 15, you must upgrade to App Shielding 6.6.0 or later.
Beginning with Android15, Android supports devices that are configured to use a page size of 16 KB (i.e., 16 KB devices). App Shielding has been updated to work on these 16 KB devices. However, if your app uses any native libraries, you must ensure that these libraries are ready for 16 KB page sizes. For more information, refer to the Android Developer documentation.
As of March 1, 2024, App Shielding for Android version 4.3.11.78273 and earlier are no longer supported. For more information, refer to the OneSpan Customer Portal at https://cp.onespan.com/.
Deprecations
Platform minimum supported versions
Android 4.4 (API levels 19 and 20) are no longer supported by App Shielding. The new minimum supported version is Android Lollipop 5.0 (API level 21).
Android Native Development Kit (NDK)
Google has announced that Android Native Development Kit (NDK) (r26) will no longer support KitKat (API levels 19 and 20). The minimum version supported by the NDK for r26 will be Lollipop (API level 21).
App Shielding switches to NDK r26 after its release as LTS version.
Deprecated API: ShieldSDK-secure-edit-text
The ShieldSDK-secure-edit-text API is no longer maintained and is considered obsolete. It has been removed from the current release.
Deprecated configuration option removed: Allow work profile and device vendor virtual spaces
The Allow work profile and device vendor virtual spaces configuration option is now deprecated and has been removed. It has been replaced with the Check Private Space option.
For more information, refer to Mobile Application Shielding Android Integration Guide.pdf included in the product package, or online at Configuration of App Shielding for Android apps .
New features and other updates
Support for Android 15
App Shielding now supports Android 15 (API level 35).
Support byte code for applications with a minSdk of 26 or newer
An Android application that is compiled for a minSdk version of API Level 26 (Android 8.0) or later might contain byte code that was introduced in DEX file versions 038 and 039. The Shielding Tool can now decode and encode such byte code.
Support large APK files
App Shielding now supports .apk files that are larger than 2 GB.
Private Space and Work Profile
Android devices can be set up to have a Work Profile (i.e., a managed profile) like Google Workspace, Samsung Secure Folder, Xiaomi Dual Apps, Microsoft Workspace etc., where the available functionality is controlled by an IT administrator. Previously, App Shielding first checked if the app was running in a virtual space before checking for a Work Profile. The Work Profile has now been separated into its own check and configuration.
Android 15 also introduced a Private Space that allows a user to create their own similarly controlled environments.
For more information, see the Android Developer documentation on managed profiles and Private Space.
With a single configuration option, App Shielding can now be configured to detect if the protected application is running in either a Private Space or a Work Profile. The default configuration is to enable the detection but not to exit when the application is running inside a Private Space or Work Profile.
The sample provided with App Shielding for Android has been updated and includes this new configuration option.
If your application registers an ExtendedObserver implementation of App Shielding, and the detection is enabled (Check Private Space) and Exit on Private Space is disabled, the ExtendedObserver implementation will receive a handleCallback() call with a new CallbackType of PRIVATE_SPACE. The provided PrivateSpaceData contains information about whether App Shielding detects that the application is launched in a Private Space or Work Profile. The data does not specify which one.
An app that is launched in a Private Space or Work Profile cannot query details about the keyboard and/or screen reader in use on the device. Thus, App Shielding does not trust any keyboard or screen reader when running in these environments. If Block untrusted screenreaders is enabled (which it is by default), and the app is running in a Private Space or Work Profile, all text-to-speech access to the app is blocked.
Tapjacking
Tapjacking is an attack vector where a user is tricked into selecting a security-relevant control from an overlay that obscured the intended button. For more information, refer to the Android Developer documentation.
App Shielding can now be configured to check for tapjacking and to block any input to the application when a non-system overlay is detected on the screen. For Android 12 and later, this also blocks and removes non-system overlays when the protected app is running. The default is to disable this check and not block these inputs.
The sample provided with App Shielding for Android has been updated and includes this new configuration option.
If your application uses a legitimate overlay window, we recommend keeping this configuration option disabled and implement the event blocking yourself to allow for exceptions.
If your application registers an ExtendedObserver implementation of App Shielding, and the detection is enabled (Check Tapjacking), the ExtendedObserver implementation will receive a handleCallback() call with a new CallbackType of TAPJACKING. The provided TapjackingData contains information regarding the detection of a tapjacking input.
Firebase crashlytics support for Android 7.0 or later
A protected app now supports Firebase crashlytics native crash reports for Android version 7.0 or later. If your application is expected to run on an older Android version, contact OneSpan Support.
Fixes and other changes
Avoid false positives on emulated input checks for some Xiaomi devices
Avoid false positives on emulated input checks for some Xiaomi devices and block emulated input events by enabling the Block emulated input configuration option. The default is, however, to not block these inputs.
Fix blocking and unblocking when an untrusted screen reader is activated or disabled
Description: If App Shielding was configured to block untrusted screen readers (which it is by default), and all untrusted Accessibility Services were disabled while the protected application was running, then any enabled Accessibility Service was still blocked for the application even though it was trusted.
Status: This issue has been fixed. Now, the enabled and trusted Accessibility Service is no longer blocked. For more information, refer to the descriptions of the Check Trusted Screenreaders and Block untrusted screenreaders configuration options for more details.
Known limitations
The limitations described here have not yet been solved for the current Mobile Application Shielding version. Possible workarounds are described where available.
Bypassing App Shielding protection in Cordova-based applications
Description: Because of the nature of pure Javascript frameworks such as Cordova, the effectiveness of the push and pull bindings of App Shielding is affected. As a result, it might be possible to extract all Javascript files from a shielded application and build a new Cordova-based application with the extracted Javascript files. That new application will behave identical to the original one but has two major differences:
It is not longer protected with App Shielding.
It is signed with a different developer certificate.
Because this new application is signed with a different developer certificate, it is recognized by the stores or every device as a completely different and new application in comparison to the original shielded application. It cannot be avoided that a new application like this is built that looks and behaves similar to the original application.
OneSpan risk assessment: Threat actors will need to make heavy use of targeted phishing attacks to convince users of the original application to install the rogue version. For attackers, however, it is much easier to use existing malware frameworks that mimic hundreds of login screens in one single piece of malware. In addition, the existence of any rogue versions of the application does not affect the security features of the original shielded application. Everyone who is using the genuine, shielded application is protected with all the features of App Shielding, including all security measures of the original application. Therefore, we consider this issue to be of low risk.
NFC payment failure in shielded apps with Thales Gemalto SDK
Description: When using the shielded version of the app, NFC payments fail. This is caused by a compatibility issue with the Thales Gemalto TSH Pay SDK which also provides debugger detection. The SDK incorrectly flags the App Shielding debugger detection as a native debugger.
Solution: Allowlisting. For implementations integrating both the Thales Gemalto SDK and App Shielding, debuggers coming from the SDK's own debugging processes and sub-processes should be added to an allowlist within theThales Gemalto SDK.
It is essential to not only add the processes to the allowlist but also their sub-processes. Otherwise, the SDK will still handle App Shielding as a native debugger!
Magisk and root hider tools on new Android versions
Root hider tools such as Magisk Hide are designed to hide the fact that the device is compromised (rooted). Android has been increasingly restricted in what can be inspected and observed of the system from inside an app. This means that a rooted system with a root hider tool can be hard to detect due to missing privileges.
On Android 8+, App Shielding may not able to reliably detect a rooted device with Magisk Hide depending on the version of these tools.
Android App Bundles
The OneSpan Customer Portal support for Android App Bundles does not yet include instant-enabled app bundles.
Cet article vous a-t-il été utile ?