# iOS App Extensions
**Content copied form** [**https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#app-extensions**](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#app-extensions)
App extensions let apps offer custom functionality and content to users while they’re interacting with other apps or the system. Some notable ones are:
* **Custom Keyboard**: replaces the iOS system keyboard with a custom keyboard for use in all apps.
* **Share**: post to a sharing website or share content with others.
* **Today**: also called **widgets**, they offer content or perform quick tasks in the Today view of Notification Center.
For example, the user selects text in the _host app_, clicks on the "Share" button and selects one "app" or action from the list. This triggers the _app extension_ of the _containing app_. The app extension displays its view within the context of the host app and uses the items provided by the host app, the selected text in this case, to perform a specific task (post it on a social network, for example). See this picture from the [Apple App Extension Programming Guide](https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionOverview.html#//apple\_ref/doc/uid/TP40014214-CH2-SW13) which pretty good summarizes this:
### **Security Considerations**
From the security point of view it is important to note that:
* An **app extension does never communicate directly with its containing app** (typically, it isn’t even running while the contained app extension is running).
* An **app extension** and the **host app** **communicate** via **inter-process** communication.
* An **app extension’s** containing app and the **host app don’t communicate** at all.
* A **Today** **widget** (and no other app extension type) can ask the system to open its containing app by calling the `openURL:completionHandler:` method of the `NSExtensionContext` class.
* Any **app extension** and its **containing app** can **access shared data in a privately** defined shared container.
* App extensions **cannot access some APIs**, for example, HealthKit.
* They **cannot receive data using AirDrop** but do can send data.
* **No long-running background tasks** are allowed but uploads or downloads can be initiated.
* App extensions **cannot access the camera or microphone on an iOS device** (except for iMessage app extensions).
### Static analysis
#### **Verifying if the App Contains App Extensions**
If you have the original source code you can search for all occurrences of `NSExtensionPointIdentifier` with Xcode (cmd+shift+f) or take a look into "Build Phases / Embed App extensions":
.png>)
There you can find the names of all embedded app extensions followed by `.appex`, now you can navigate to the individual app extensions in the project.
If not having the original source code:
Grep for `NSExtensionPointIdentifier` among all files inside the app bundle (IPA or installed app):
```bash
$ grep -nr NSExtensionPointIdentifier Payload/Telegram\ X.app/
Binary file Payload/Telegram X.app//PlugIns/SiriIntents.appex/Info.plist matches
Binary file Payload/Telegram X.app//PlugIns/Share.appex/Info.plist matches
Binary file Payload/Telegram X.app//PlugIns/NotificationContent.appex/Info.plist matches
Binary file Payload/Telegram X.app//PlugIns/Widget.appex/Info.plist matches
Binary file Payload/Telegram X.app//Watch/Watch.app/PlugIns/Watch Extension.appex/Info.plist matches
```
You can also access per SSH, find the app bundle and list all inside PlugIns (they are placed there by default) or do it with objection:
```bash
ph.telegra.Telegraph on (iPhone: 11.1.2) [usb] # cd PlugIns
/var/containers/Bundle/Application/15E6A58F-1CA7-44A4-A9E0-6CA85B65FA35/
Telegram X.app/PlugIns
ph.telegra.Telegraph on (iPhone: 11.1.2) [usb] # ls
NSFileType Perms NSFileProtection Read Write Name
------------ ------- ------------------ ------ ------- -------------------------
Directory 493 None True False NotificationContent.appex
Directory 493 None True False Widget.appex
Directory 493 None True False Share.appex
Directory 493 None True False SiriIntents.appex
```
We can see now the same four app extensions that we saw in Xcode before.
#### **Determining the Supported Data Types**
This is important for data being shared with host apps (e.g. via Share or Action Extensions). When the user selects some data type in a host app and it matches the data types define here, the host app will offer the extension. It is worth noticing the difference between this and data sharing via `UIActivity` where we had to define the document types, also using UTIs. An app does not need to have an extension for that. It is possible to share data using only `UIActivity`.
Inspect the app extension's `Info.plist` file and search for `NSExtensionActivationRule`. That key specifies the data being supported as well as e.g. maximum of items supported. For example:
```markup
NSExtensionAttributes
NSExtensionActivationRule
NSExtensionActivationSupportsImageWithMaxCount
10
NSExtensionActivationSupportsMovieWithMaxCount
1
NSExtensionActivationSupportsWebURLWithMaxCount
1
```
Only the data types present here and not having `0` as `MaxCount` will be supported. However, more complex filtering is possible by using a so-called predicate string that will evaluate the UTIs given. Please refer to the [Apple App Extension Programming Guide](https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple\_ref/doc/uid/TP40014214-CH21-SW8) for more detailed information about this.
**Checking Data Sharing with the Containing App**
Remember that app extensions and their containing apps do not have direct access to each other’s containers. However, data sharing can be enabled. This is done via ["App Groups"](https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple\_ref/doc/uid/TP40011195-CH4-SW19) and the [`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) API. See this figure from [Apple App Extension Programming Guide](https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple\_ref/doc/uid/TP40014214-CH21-SW11):
As also mentioned in the guide, the app must set up a shared container if the app extension uses the `NSURLSession` class to perform a background upload or download, so that both the extension and its containing app can access the transferred data.
**Verifying if the App Restricts the Use of App Extensions**
It is possible to reject a specific type of app extension by using the following method:
* [`application:shouldAllowExtensionPointIdentifier:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623122-application?language=objc)
However, it is currently only possible for "custom keyboard" app extensions (and should be verified when testing apps handling sensitive data via the keyboard like e.g. banking apps).
### Dynamic Analysis
For the dynamic analysis we can do the following to gain knowledge without having the source code:
* Inspecting the items being shared
* Identifying the app extensions involved
**Inspecting the Items Being Shared**
For this we should hook `NSExtensionContext - inputItems` in the data originating app.
Following the previous example of Telegram we will now use the "Share" button on a text file (that was received from a chat) to create a note in the Notes app with it:
.png>)
If we run a trace, we'd see the following output:
```bash
(0x1c06bb420) NSExtensionContext - inputItems
0x18284355c Foundation!-[NSExtension _itemProviderForPayload:extensionContext:]
0x1828447a4 Foundation!-[NSExtension _loadItemForPayload:contextIdentifier:completionHandler:]
0x182973224 Foundation!__NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT_S3__
0x182971968 Foundation!-[NSXPCConnection _decodeAndInvokeMessageWithEvent:flags:]
0x182748830 Foundation!message_handler
0x181ac27d0 libxpc.dylib!_xpc_connection_call_event_handler
0x181ac0168 libxpc.dylib!_xpc_connection_mach_event
...
RET: (
" - userInfo:
{
NSExtensionItemAttachmentsKey = (
" {types = (\n \"public.plain-text\",\n \"public.file-url\"\n)}"
);
}"
)
```
Here we can observe that:
* This occurred under-the-hood via XPC, concretely it is implemented via a `NSXPCConnection` that uses the `libxpc.dylib` Framework.
* The UTIs included in the `NSItemProvider` are `public.plain-text` and `public.file-url`, the latter being included in `NSExtensionActivationRule` from the [`Info.plist` of the "Share Extension" of Telegram](https://github.com/TelegramMessenger/Telegram-iOS/blob/master/Telegram/Share/Info.plist).
**Identifying the App Extensions Involved**
You can also find out which app extension is taking care of your the requests and responses by hooking `NSExtension - _plugIn`:
We run the same example again:
```bash
(0x1c0370200) NSExtension - _plugIn
RET:
(0x1c0372300) -[NSExtension _plugIn]
RET:
```
As you can see there are two app extensions involved:
* `Share.appex` is sending the text file (`public.plain-text` and `public.file-url`).
* `com.apple.mobilenotes.SharingExtension.appex` which is receiving and will process the text file.
If you want to learn more about what's happening under-the-hood in terms of XPC, we recommend to take a look at the internal calls from "libxpc.dylib". For example you can use [`frida-trace`](https://www.frida.re/docs/frida-trace/) and then dig deeper into the methods that you find more interesting by extending the automatically generated stubs.
###