Tuesday, August 14, 2012 At 4:00AM
The iOS Document Interaction APIs provide applications with the ability to have another application installed on the device handle a file. The most common scenario of this behavior is the Mail application. The Mail application receives emails which may contain document files like PDFs as attachments. Although the Mail application does have PDF preview functionality, there may be a separate PDF viewing or editing application installed on the device. The Mail application therefore opts to leverage the Document Interaction API in order to provide users with the ability to open the attached PDF file using any application on the device registered to handle PDF file types.
iOS applications can register to handle file types by setting the supported UTI types within the “CFBundleDocumentTypes” section of their Info.plist file. The application would also need to implement the “application:didFinishLaunchingWithOptions:” application delegate method to handling incoming files. When applications leverage the Documentation Interaction APIs to View or Open a file with another application, iOS will already know which applications have registered to handle the data type. The UI displays a listing of installed applications which can handle the file type.
At this point, people familiar with iOS may be wondering how this“Open In” functionality works due to the security restrictions of the iOS application sandbox. The sandbox prevents one application from accessing any data stored within another application’s container. When a user chooses an application listed in the “Open In” prompt, a copy of the file is made to the other application’s container.
This is where it starts to get interesting. The copy of the file is written to the receiving application’s Documents/Inbox folder. This file is not stored using data protection and will persist on the device even after the application is closed or the device is rebooted.
This becomes an issue when dealing with sensitive files in “secure container” applications. Secure containers are applications which implement their own form of data protection in order to supplement the data protection feature provided by iOS. In many cases these custom secure containers are created due to not having the ability to enforce device pass-codes on unmanaged devices. One scenario we encountered was a secure container application that wanted to incorporate “Open In” functionality for sending files to the Good For Enterprise (GFE) application. The GFE application would then provide users with the ability to email the received documents using their corporate email. Since GFE is also a secure container application, the organization assumed the file would remain encrypted on the device. Due to the discussed plaintext caching of the file, it becomes the receiving application’s responsibility to perform proper clean up of any files it has received. Unfortunately, GFE was not performing the necessary cleanup and the file remained stored in plaintext.
The main take away from the blog post should be to be very cautious when performing any form of inter-process communication with sensitive documents in your iOS application. iOS contains many subtle caching issues which could cause data expected to be stored encrypted to be unintentionally cached elsewhere in plaintext.
Author: Ron Gutierrez
©Aon plc 2023