Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

Low Risk Mobile Vulnerabilities Can Lead to High Risk Exposure pt. 2

jhaddix ‎11-12-2013 01:59 PM - edited ‎09-25-2015 10:28 AM

Cache, Cache, Cache!


When you run any application there are certain things developers do to provide you with that seamless feel you are accustomed to. One of these things is caching. The idea behind caching is to preload or store some sort of information instead of having to retrieve it again from a far off place every time you need it.


Two examples we see often are iOS screen caching and NSURL caching.


iOS screen caching goes something like this;


You are inside an application on a screen with personal or valuable data...




Then, in the middle of using your app, you have to hit the “home” button for something (or you get call). After you finish your call you want to go back and complete recovering your password. Well, in order to facilitate the fancy animation to bring back up your mobile app, iOS took a screen shot of where you were before!

This screenshot is stored on the phone in:


  • /var/mobile/Applications/{YourAppUID}/Library/Caches/Snapshots/{YourAppBundleID}/UIApplicationAutomaticSnapshotDefault-Portrait@2x.png

If your phone gets lost or stolen, normally, so does your data =(


We have run into several sensitive implementations of screen caching: 

  • Ticket QR codes (airline, train, transit, and concert)
  • Banking info (account numbers, etc)
  • Sensitive “scanned” Documents viewed in app
  • Etc.



NSURL caching is the same caching idea except with your applications network traffic.


If not configured right, NSURL (or other network communication methods) with keep a cache of all POST data responses in a SQL file called Cache.db


This file is given least amount of data encryption by the OS and stored inside:


  • /var/mobile/Applications/{YourAppUID}/Library/Caches/{YourAppBundleID}/Cache.db

 Why is this an issue? In the POST response data can be unique account information, session tokens, and private message data, you name it… all kinds of juicy info can be in there.





We recognize that you might not even know these methods do this by default. Both these vulns, along with many other caching vulns we find, are part of a category of unintended data leakage in the OWASP Mobile Top Ten called “Side Channel Data Leakage”


We recommend:


  1.  When sending an application to the background you can overlay an image so that the screenshot taken is just that image, instead of juicy info. Here we’ve written just to splash the logo of our app:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {

UIImageView *myLogo = [[UIImageView alloc] initWithImage:@"logo.png"];

self.backgroundImage = myLogo;

[self.window addSubview:myLogo];



2.   To prevent particular requests from being cached, implement the connection:willCacheResponse: method on the   delegate and return nil for those requests.


 (NSCachedURLResponse *)connection:(NSURLConnection * connection willCacheResponse:(NSCachedURLResponse *)cachedResponse


    // implement handling for different requests here

    return nil;



 3.    Always have your applications assessed before a major release.

0 Kudos
About the Author


27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all