5

My iOS app has a lock screen which, when enabled, covers the whole of UIScreen. However, outside of the UIScreen bounds, I have panes with sensitive information that are no covered by the lock screen. (Those panes can be swiped in and out when the screen is unlocked.)

How safe is it to have information outside of the UIScreen bounds? Can an attacker use some sort of external display, or a debugger, or some other mechanism to "reveal" what is outside of the UIScreen screen?

[The lock screen is a WKWebView which by default has a "magnifying glass" function. I discovered that, when triggered at the edges of the UIScreen, the magnifying glass shows a few pixels of what is behind the UIScreen edge. I have since disabled the magnifying glass with this answer.]

Community
  • 1
  • 1
Randomblue
  • 112,777
  • 145
  • 353
  • 547
  • 1
    Instead of worrying about if someone can get to information that is off screen a better solution would be to load the sensitive information on demand. Now how that can be done depends completely on your implementation. – zambrey Apr 24 '15 at 04:16
  • Hey Randomblue, you should accept an answer if you are satisfied. If not, feel free to follow up with any questions. – JAL Jan 21 '16 at 18:17

2 Answers2

9

"Hiding" views offscreen is not secure at all. Anyone with a Jailbroken device can hook into your app at runtime using MobileSubstrate and call [[[UIApplication sharedApplication] keyWindow] recursiveDescription] to dump the view hierarchy. There are also tools such as Reveal and Spark Inspector that provide an interface similar to Xcode's view debugger to view any views currently in the app's UIWindow.

As zambrey suggested, it would be best to initialize any views with sensitive information as-needed and remove them when they are dismissed and no longer needed by the user, rather than keeping them out of view but still in the window hierarchy. The benefits of this aren't just safety, but having fewer views in memory will improve your app's performance and reduce its memory footprint.

If you are concerned about security, you may want to check for a jailbroken device at runtime and restrict some features for those devices.

JAL
  • 41,701
  • 23
  • 172
  • 300
  • 1
    One of the reasons that many banks do not allow their apps to run on jailbroken/rooted devices is because of exactly this. Even on non-jailbroken devices, the app is immediately closed upon any type of exit. – AStopher Nov 18 '15 at 13:36
  • "Anyone with a Jailbroken device" -> what about a non-jailbroken device? I'm mostly interested in that scenario. – Randomblue Jan 23 '16 at 20:27
  • @Randomblue well, anyone without a jailbroken device would probably not be able to see off-screen information, unless they had a Accessibility feature that somehow was able to augment the views in your app, or had a device with a screen size you didn't account for in your view hiding logic, causing your views to appear on-screen rather than off-screen. – JAL Jan 26 '16 at 18:26
5

Technically anything that is in memory could be exposed on a jailbroken device. Hiding the sensitive views outside what is currently being displayed is not a security measure. Once the device is jailbroken, the views and the content of those views will be exposed. Even if you have a password textfield set as 'secureTextEntry' and even if you hide it, the contents could be read with a debugger attached to the app as long as the textfield is not deallocated. And even when the textfield is deallocated, the memory could be dumped and if that memory has not been overridden yet you could potentially find the contents of that view.

Now, if you are not worried about the Jailbroken scenario, and you only want to find other options where somebody with a non jailbroken device could explore the views, you should probably check the Accessibility features included in iOS. VoiceOver will be able to read out loud text that is hidden if the accessibility in that view is not properly disabled. Removing views from accessibility tools is sometimes tricky because a change on the parent could affect all subviews (read the UIAccessibility documentation)

Setting accessibilityElementsHidden to YES in the parent view or isAccessibilityElement to NO in the view, should work.

pablobart
  • 2,641
  • 1
  • 24
  • 22