iOS Platform App Security checklist

#1. Objective
iOS platform app security risk-related general checklist to ensure the quality and efficiency of the iOS Client Security assessment.
#2. Data security
# #2.1 Transport Security
A review scenario for this type of vulnerability: The app sends or receives sensitive information, such as user passwords, user privacy information, or other sensitive operations over the network
* * Vulnerability Type Description: * * Because mobile devices are usually connected via WiFi, so they face in-the-middle attacks such as network eavesdropping, network hijacking, and so on sensitive information need to be encrypted transmission, and docking received important data also need to perform integrity check. If the application itself implements the encryption and integrity check mechanism, it is necessary to confirm whether the mechanism has security flaws, such as whether the algorithm is strong enough, whether there is a logical defect, the key management is secure, etc. The usual practice is to secure the network transmission through HTTPS, while the application client needs to strictly verify the legitimacy of server-side certificates, and HTTPS communication requires the service side has a CA-issued certificate, some product lines do not do this, the use of self-signed certificate of the way HTTPS request, Here you need to make sure that the checksum logic is not bypassed properly. The following provides a way to use a self-signed certificate for HTTPS requests and correctly verify the validity of the server domain name and certificate:
"' OBJC
static NSString *url = @ "https://tcpper.baidu.com/";
Nsurlrequest *request = [nsurlrequest requestwithurl:[nsurl urlwithstring:url];
Nsurlconnection conn =
[[[Nsurlconnection alloc] initwithrequest:request delegate:self] autorelease];
```
Wherein, delegate:self specifies the self object implements the Nsurlconnectiondelegate protocol, which contains the authentication certificate and hostname callback, the developer can choose to implement

"' OBJC
(void) connectionnsurlconnection *) connection Willsendrequestforauthenticationchallenge
Nsurlauthenticationchallenge *) Challenge
{
Nsurlprotectionspace *protectionspace = [Challenge Protectionspace]; Sectrustref Trust = [Protectionspace servertrust];
Seccertificateref *pservercert = sectrustgetleafcertificate (trust);
Nsurlcredential *credential = [nsurlcredential credentialfortrust:trust];
NSString *path = [[NSBundle mainbundle] pathforresource:@ "Rootcert" oftype:@ "der"];
NSData *data = [NSData Datawithcontentsoffile:path];
Seccertificateref Clientcert = Seccertificatecreatewithdata (NULL, Cfbridgingretain (data));
Cfdataref Clientcertdata;
Cfdataref Servercertdata;
Clientcertdata = Seccertificatecopydata (Clientcert);
Servercertdata = Seccertificatecopydata (Pservercert);
Success = Cfequal (Clientcertdata, servercertdata);
Cfrelease (Clientcertdata);
Cfrelease (Servercertdata);
if (success) {
if ([Challenge.protectionSpace.host
isequaltostring:@ "tcpper.baidu.com"])
{
[[Challenge Sender] Usecredential:credential
Forauthenticationchallenge:challenge];
Return
}
}
[[Challenge Sender]
Cancelauthenticationchallenge:challenge];
}
```
In the code above, we took the server and client certificates separately from challenge and locally, and compared the certificates to the same, then verified the host signed with the certificate, and confirmed that it was the same as the host we wanted to pass the validation.
* * Audit Point and Method: * * The Black box audit method through the network analysis tool fiddler and other analysis app to send the received packet, to observe whether there is plaintext transmission of sensitive information, and if there is encrypted transmission of sensitive information, the need for further analysis of encryption algorithm robustness and key management mechanisms, such as simple transmission via base64 encryption. If it is transmitted over HTTPS, see if it can be decrypted by fiddler, and if so, it can be a man-in-the-middle attack. White box audit method to check the HTTP transmission part of the code, the main concern is whether to verify the server-side certificate and verify that the correctness of the logic can be bypassed and so on. Model 1:[nsurlrequest Setallowsanyhttpscertificate:yes Forhost:[webserverurl host] without verifying the validity of the service-side certificate using the HTTPS protocol; Demonstration of the legality of service-side certificates not verified using the HTTPS protocol 2:[self.httpsrequest Setvalidatessecurecertificate:no]

# #2.2 Storage Security
* * Vulnerability Type DESCRIPTION: * * Data storage security refers to the security of the app's local data store, which mainly refers to the secure storage of the app's home directory files, and highly sensitive data that prohibits plaintext from being stored in the app client, such as user passwords, Bduss, Ptoken, Stoken, etc. Or after simple encryption is not allowed, such as Base64 encryption. The app's home directory file path is/private/var/mobile/application[guid]/, which focuses on the following folder contents:
1. Documents folder: Mainly the user archive files, you can use the Itoolsgui tool to view;
2. Library/preferences folder: Mainly preferences files, generally plist format, you can use Plist Editor Pro for Windowsgui tools to open;
3. Library/caches folder: The main preservation of the application of persistent data, the user application upgrade or after the application closed data save, generally in the sqlite3 format, you can use the SQLite Database Browsergui tool or sqlite3 command-line tools to view;
4. Library/cookies folder: A persistent cookie that primarily stores Safari browser and app apps, The generic file name is Cookies.binarycookies, and you can use the Python script tool provided by Securitylearn Binarycookiereader to read its contents, referring to the link:
[http://www.securitylearn.net/2012/10/27/cookies-binarycookies-reader/] (http://www.securitylearn.net/2012/10/27/cookies-binarycookies-reader/)
5. Library/webkit folder: The main save WebKit local storage file, not all apps exist this folder.
* * Audit Point and Method: * * The Black box audit method through the tools described above to check whether the files in the above folder is plaintext storage or Base64 encoding store app sensitive information or personal privacy content, such as user password.

# #2.3 Key Management
A review scenario for this type of vulnerability: The app encrypts the data, transmits it, but does not use a secure key management method that causes the key to leak and the data is decrypted
* * Vulnerability Type description: **app in the local data storage or network data transmission, for sensitive data needs to be encrypted, encryption algorithm is divided into symmetric encryption and asymmetric encryption, symmetric encryption algorithm commonly used AES, 3DES, asymmetric encryption algorithm is generally used RSA. At this point, if a secure key management scheme is not adopted, it is easy to cause a key leak. Common methods of unsafe Key management include: Write a symmetric key or private key to die in the configuration file or code, the entire app uses a unique symmetric key to encrypt the data decryption, if the attacker analyzes the key in reverse, you can decrypt the entire application of data, resulting in the disclosure of sensitive information , the symmetric key or private key is transmitted through the network plaintext, the attacker obtains the key through network eavesdropping, and can decrypt the encrypted data of subsequent transmissions, which leads to the disclosure of sensitive information. * * Audit Point and Method: * * The Black box audit method through the dynamic analysis tools such as Introspy to observe the runtime and decryption or create key information, observe the encryption and decryption algorithm used by the app and key, if the symmetric key has been fixed, it is likely to write dead in the configuration file or code, You can further search for code or configuration files and analyze key generation mechanisms. At the same time, combined with fiddler and other network analysis tools to analyze the transmitted data, to observe the existence of plaintext transmission key and so on.
#3 Information Disclosure
# #3.1 NSLog Information disclosure
Review scenario for this type of vulnerability: sensitive information is leaked in the log record
* * Vulnerability Type Description: * * in iOS development, RD often needs to output some running data in real-time to determine if the program is running correctly, generally using the nslog output, but the output data may expose the confidential data inside the app, so the release version needs to be completely screened out , or it will cause the disclosure of sensitive information. By masking out the nslog output, you can comment out all the nslog statements, but it's cumbersome and time-consuming, The better solution is to add a piece of code in the project's-prefix.pch file, defining that the NSLog is only output in debug mode, not output under release, and similar code:
"' OBJC
#ifndef _*optimize*
_#define NSLog (...) NSLog (_*va_args*_)
#else
#define NSLOG (...) {}
#endifRelease模式通常会定义_ *optimize*_,
The debug mode does not, the compiler through the macro to determine whether to compile output nslog information,
Or you can determine whether the compiler output nslog information by judging if the debug macro is already defined:
#ifdef debug#define NSLog (...) NSLog (_*va_args*_) #else # define NSLOG (...) {} #endif
```
* * Audit Point and Method: * * White box Audit method determines whether the compiler compiles output nslog log information by looking at whether the-prefix.pch file in the source code defines the above macro definition, and if there is no definition, see if there is an annotated NSLog statement in the code file by looking at the source code.

# #3.2 Background Snapshot
Review scenario for this type of vulnerability: The app has cached the current UI in the background
* * Vulnerability Type description: **ios's background task processing is unique, when the app enters the background, the system will automatically intercept the current app display UI in a cache to the Library/caches/snapshots directory, so that the app back to the foreground can quickly display the interface, Therefore, some ui,snapshot mechanisms that display sensitive information can cause information disclosure,
"' OBJC
If you want to block the iOS snapshot mechanism, you can use code similar to the following:
(void) Applicationdidenterbackground (SAD) uiapplication *) application
{
if (Apphaspasscodeon) {
Uiimageview *splashview = [[Uiimageview alloc]
Initwithframe:cgrectmake (0,0, 320, 480)];
Splashview.image = [UIImage imagenamed:@ "Default.png"];
[Window Addsubview:splashview];
[Splashview release];
}
}
```
* * Audit Point and Method: * * The Black box audit method through the Ifunbox and other tools to see whether the application's Library/caches/snapshots directory cache the application into the background of the UI, as well as the current cache of the existence of sensitive information disclosure and other issues.
#4. IPC Security
# #4.1 urlscheme
Review scenario for this type of vulnerability: interaction between different apps via urlscheme * * Vulnerability type description: **ios uses a sandbox mechanism to limit the behavior of the application, which can control the behavior of malware and mitigate the risk of a well-behaved app being breached. The app running in the sandbox passes through the kernel when it accesses the resource, and the app can access the requested resource only if it is checked. Apps in iOS are isolated from each other, and sometimes in order to achieve simple interactions between different apps that require the use of urlscheme, the use of urlscheme to some extent breaks the isolation between apps, and if handled improperly there is a risk of urlscheme hijacking and maliciously injecting data. The urlscheme of the app after the experiment was found to be a priority, so the post-install app can hijack data that is transmitted interactively between other apps by registering the appropriate urlschemes as follows:
Source APP:
! [] (https://thumbnail0.baidupcs.com/thumbnail/d0772d93e252a5bed5dd1dab2ff32549?fid= 1962957030-250528-81532063416250&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-uhx3%2f2eol6eqevyha1jb18bvv2k%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353378216595906670&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
Target APP:
! [] (https://thumbnail0.baidupcs.com/thumbnail/9cd563251f9b3ed16ee0e151b5c3c4a2?fid= 1962957030-250528-307917286063562&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-xvsdvqtj4y6on1x9dbgehxfwnbu%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353378216595906670&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
! [] (https://thumbnail0.baidupcs.com/thumbnail/2cda710c74933669ed230b9670ac7cfc?fid= 1962957030-250528-820419784013259&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-8iqxdkx%2bviufrovl%2f0y9tnppdpe%3d&expires=8h&chkbd=0&chkv =0&DP-LOGID=5353417911269716952&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
Hijacking results:
! [] (https://thumbnail0.baidupcs.com/thumbnail/be1ebb55a5874c56c301fe48d7be3a36?fid= 1962957030-250528-697658547206349&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-ky4gr87vmja5xaz40q3smzfmvta%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353417911269716952&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
At the same time, if the destination end of the urlscheme is not sufficient to verify the data input from the source, the destination can be logically processed based on the data submitted by the source, which may result in unexpected buffer overflow or logical defect due to injection of malicious data, as follows:
! [] (https://thumbnail0.baidupcs.com/thumbnail/c13cafe1de270162abd7ef86be2611db?fid= 1962957030-250528-720657742127005&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-insl4oox8pwo%2biu51lxeqssiw6w%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353417911269716952&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
Verify that the input of the urlscheme can be placed in the following appdelegate:
"' OBJC
– (BOOL) Application: (UIApplication *) application Handleopenurl: (nsurl *) URL {
Validate input from the Urlreturn YES;
}
```
* * Audit Point and Method: * * White Box audit method first through the Ifunbox tool and so on in the application home directory to view the Info.plist file, find the key to cfbundleurltypes this value, determine the application registration of all Urlscheme, as follows:
! [] (https://thumbnail0.baidupcs.com/thumbnail/97a8f545ba0dfc970470a1070368afcc?fid= 1962957030-250528-1015475913625221&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-jvvdyhtej%2fz1vnw84ss3cvzjvrg%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353417911269716952&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
It then audits the implementation logic of each urlscheme in the source code to see if the data can be maliciously injected or whether sensitive information is transmitted.
# #4.2 pasteboard
Review scenario for this type of vulnerability: Apps use the Clipboard to share data between applications or between applications
* * Vulnerability Type Description: * * In iOS, you can use the Clipboard to share data between applications and applications, and the Clipboard is divided into system-and application-level The system level is created using uipasteboardnamegeneral and Uipasteboardnamefind, and the data is not lost when the application is closed or uninstalled. The application level is created through Pasteboardwithname:create, which allows the data to remain on the Clipboard after the application is closed, but the data is lost after the application is unloaded. When the app enters the background or exits, if the Clipboard is not cleared and the app transmits sensitive information through the Clipboard, the risk of sensitive information disclosure is compromised; the app goes to the background to clear the Clipboard contents can be placed in appdelegate, if you use a custom clipboard, replace with a custom clipboard [ Uipasteboard Generalpasteboard].
"' OBJC
(void) Applicationdidenterbackground: (uiapplication *) application{
If your application supports background execution, this method is called instead of Applicationwillterminate:when the User quits.
[Uipasteboard generalpasteboard].items = nil;
}
```

* * Audit Point and method: * * Black box Audit method The importance of using Introspy dynamic analysis tool to observe whether the app uses pasteboard to transmit data and transmit data; the White-box audit method is to navigate to the specific pasteboard through the Pasteboard creation function described above. , and then trace the parsing code.

#5 UIWebView
Review scenario for this type of vulnerability: App uses UIWebView to show content from URLs * * Vulnerability type description: **uiwebview uses the WebKit kernel and supports JavaScript, There is currently no public API available to disable JavaScript in UIWebView, so if any input controlled by the user is used as the content of UIWebView, it can be manipulated to execute JavaScript code at run time in UIWebView, as follows:
! [] (https://thumbnail0.baidupcs.com/thumbnail/02de037d0287ab3383ac956656de0bfa?fid= 1962957030-250528-188911265477837&time=1471518000&rt=pr&sign= Fdtaer-dcb740ccc5511e5e8fedcff06b081203-sfkhywu2fzhjpx10xfodwxsff9e%3d&expires=8h&chkbd=0&chkv=0 &DP-LOGID=5353417911269716952&DP-CALLID=0&SIZE=C10000_U10000&QUALITY=90)
As long as the content of UIWebView depends on the input of the user, there may be security problems in the traditional web security, such as XSS, url jump, CSRF, etc., which belong to the extension of web security.

* * Audit points and methods: * * White box Audit method by locating the code to the specific UIWebView, to see whether the content of UIWebView depends on the user's input, the traditional web security risk detection method is the same as the web-based detection idea. The Black box audit method is for all user input points, submit the corresponding payload view or contrast program response can determine whether there is a corresponding security risk.

iOS Platform App Security checklist