0

From personal experience many mobile apps that I've tested don't actively detect and discourage (with a warning) or even block the app from running on/in:

While this is great for security testing purposes, one could imagine that in general you'd want to prevent your app from running on such devices in the first place as it could pose additional risks to the data that is handled in the app. For devices that run outdated operating systems (OS) that don't receive security updates any longer, I'd apply the "assume breach" principle from the zero trust security model.

I could imagine that preferably hardware-backed attestation would be ideal for "root detection"1 and for preventing apps from running on rooted/jailbroken devices. For "emulation detection" the same or a similar emulation detection approach to Flutter can be used, although that doesn't seem very robust to me. For no longer supported outdated operating systems2 one could simple pull it from the Play and App store for certain mobile OS versions for new installations. Additionally and in a backwards compatible way (when introduced early enough) an active check could be introduced that puts an end date on the use of certain OS versions, or more foolproof call an API to be able to 'discontinue' (and perhaps wipe app data) on older versions of the app without the need for updating them first.

Should mobile app developers take active action against the three mentioned cases and should security auditors, penetration testers perhaps inform mobile app developers about the lack of such measures? Are there any known industry standards that require or advice such measures to be in place in mobile apps?

1: For example such as the RootBeer library for Android.
2: Which is also reported as an issue under the 'Manifest Analysis' section by Static Analysers like MobSF as: "App can be installed on a vulnerable Android version. This application can be installed on an older version of android that has multiple vulnerabilities. Support an Android version => 10, API 29 to receive reasonable security updates."

Improve this question
12
  • 4
    Not all data are equally valuable and thus security requirements to protect these data differ. Make an analysis to decide if there are relevant threats regarding your app and the data it stores on less secure devices. Then decide if the risks are acceptable for you as app developer or if they can be somehow mitigated and if they are acceptable for the user of the device.
    – Steffen Ullrich
    Commented Sep 18 at 15:55
  • 4
    having been on the receiving end of this kind of warning, while there are certainly security benefits, this ends up feeling extremely hostile. my device is my device, goddammit, and I will run what I please. a warning is totally fine, blocking is not.
    – strugee
    Commented Sep 18 at 16:02
  • 5
    be careful too that you don't set up incentives to make security worse. I unlocked my bootloader and installed LineageOS (which generates a bootloader-is-unlocked security warning on each boot) with no intention to root. but I was forced to root to circumvent apps that refused to run based on the unlocked bootloader.
    – strugee
    Commented Sep 18 at 16:05
  • 2
    Banking apps and e-identity apps I've used have implemented OS version requirements, and they limit the supported OSes to ios/ipados, android, windows, ubuntu/debian and macos. They motivate it by saying that it's their responsibility to ensure their apps can be trusted and that the apps don't provide a better option than traditional means of committing fraud. I think it's reasonable that they say they can't guarantee security on all possible OSes there are and are limiting it to the most common ones. And I think all of them have a website you can use instead if there is no supported app.
    – n-l-i
    Commented Sep 19 at 1:33
  • 1
    @gnasher729 ... so ... you were paid to be responsible for the user. You see how that's not the same context at all, right? The app creator is not responsible, the responsible party enlisted your help,,,
    – schroeder ♦
    Commented Sep 21 at 20:08

2 Answers 2

Reset to default
2

No, such a requirement would make security worse, not better. Consider that GrapheneOS is widely accepted to be more secure than stock Android, but what you propose would disallow it.

Improve this answer
2
  • I didn't think of this, it's a valid argument indeed but only against disallowing rooting. That still leaves the questions for disallowing end of life OS and emulators.
    – Bob Ortiz
    Commented Sep 18 at 17:12
  • s/would/could potentialy/g ... other than that +1
    – CaffeineAddiction
    Commented Sep 26 at 5:36
1

The exclusion of emulated environments would reduce security, not increase it. As a user I might run a specific app in an emulatated environment on purpose specifically because I don't trust the app. So for security reasons I decided to not give the app full access to my device but rather run it inside a closed environment.

You are suggesting to prevent that for security reasons. Whos security are you trying to protect here? To me this looks like the app maker decides that their security is more important than my user security. Sounds like a bad idea to me.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .