iOS移动应用程序安全性-第一部分:iOS移动开发人员的最佳实践。

根据OWASP Top 10,每个ios开发人员都必须注意代码安全性,数据存储安全性,数据通信安全性等。 由于iOS移动应用程序不像其他移动平台(如Android)和任何混合移动开发(在其清单,清单,JavaScript注入等第一阶段非常开放)那样脆弱,因此iOS仍然存在其自身的问题。 确保正确地保护代码,逻辑,数据及其通信是每个组织/开发人员的责任,以防止任何入侵者篡改和理解代码。

为谨慎起见,在开发人员端,以下是初步威胁的一些清单,每个ios开发人员都应注意这些清单。 那些是:

1.屏幕录制和屏幕捕获

风险:
1.攻击者可以记录登录名/任何敏感屏幕,并捕获输入的用户名和密码。
2.在像应用程序一样的视频流中,任何付费视频内容都可以流式传输和记录。
这些风险将导致银行应用程序中的重大泄漏,如果执行屏幕截图或屏幕记录,则安全交易细节将受到损害。

OWASP:不安全身份验证

固定:
观察userDidTakeScreenshotNotification并使用UIScreen.isCaptured()限制用户继续进行操作。

示例代码:

NotificationCenter.default.addObserver(forName:.UIApplicationUserDidTakeScreenshot,object:nil,queue:OperationQueue.main){
打印(“截屏!!)}

要检查是否在ios 11及更高版本上正在发生屏幕录像:

  -(BOOL)isRecording { 
 对于(UIScreen.screens中的UIScreen *屏幕){ 
 如果([屏幕responseToSelector:@selector(isCaptured)]){ 
  // iOS 11+具有isCaptured方法。 
 如果([screen performSelector:@selector(isCaptured)]){ 
 返回是;  //屏幕捕获处于活动状态 
  }否则,如果(screen.mirroredScreen){ 
 返回是;  //镜像处于活动状态 
  } 
  }其他{ 
  // 11.0以下的iOS版本 
 如果(screen.mirroredScreen) 
 返回是; 
  } 
  } 
 返回否; 
  } 

2. KeyChain数据保护

风险:
使用易受攻击的访问性选项添加到KeyChain的钥匙串项可能会暴露于JailBroken设备上的其他应用程序或具有物理访问权的攻击者。 通常,开发人员可以选择以下操作:
kSecAttrAccessibleWhenUnlocked,
kSecAttrAccessibleAfterFirstUnlock,
kSecAttrAccessibleAlways,
kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
kSecAttrAccessibleAlwaysThisDeviceOnly。
选择最简单或更容易受到攻击的选项,例如“ kSecAttrAccessibleWhenUnlocked”,可能会导致潜在的安全风险。

OWASP:不安全的数据存储

固定:
“ kSecAttrAccessibleAfterFirstUnlock”或“ kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly”模式仅应在应用程序执行需要KeyChain项的后台处理时使用。

3.文件数据保护

风险:
当要保存新文件时,开发人员可以从以下选项中进行选择,以更好地利用数据保护:

全面保护(NSFileProtectionComplete)
除非打开,否则受保护(NSFileProtectionCompleteUnlessOpen)
在首次用户身份验证之前受保护(NSFileProtectionCompleteUntilFirstUserAuthentication)
无保护(NSFileProtectionNone)
选择最简单或更容易受到攻击的选项(如“ NSFileProtectionNone”)可能会导致潜在的安全风险。

OWASP:不安全的数据存储。

修复:建议使用“ NSFileProtectionCompleteUnlessOpen”和“ NSFileProtectionCompleteUntilFirstUserAuthentication”对所有文件进行数据保护。

例:

首次写入时加密文件

do { 
try data.write(to: fileURL, options: .completeFileProtection)
}
catch {
// Handle errors.
}

加密磁盘上的现有文件

 do { 
try (fileURL as NSURL).setResourceValue(
URLFileProtection.complete,
forKey: .fileProtectionKey)
}
catch {
// Handle errors.
}

4.弱越狱检测:

风险:
在JailBroken设备上,应用程序的逻辑和行为可能会受到损害,并使应用程序容易受到攻击。 话虽如此,任何黑客都可以通过一些努力绕过那些基本检查。 重要的是要知道这一点,而不要完全依赖越狱检测方法。

OWASP:多余的功能

固定:
以下测试将检查已知的,易于绕过的内容,并检查并通知开发人员他正在使用它们:

1.越狱设备上安装了许多独特的文件和应用程序。 在文件系统中检查这些文件可以帮助确定设备是否已越狱。 此测试检查开发人员是否正在寻找这些文件。
2.检查应用程序是否遵循沙盒规则,可以帮助用户识别应用程序是否已越狱。 检查的好方法是查看是否可以在应用程序捆绑包之外的某个位置修改文件。 此测试寻找开发人员进行的此类检查。
3.如果从您的应用程序调用Cydia的URL方案(Cydia://)成功,则可以确保设备已越狱。 此测试检查开发人员是否执行此检查。

除此之外,建议检查所有可能的方法以真正找到设备是否受到威胁。

例:

  func isDeviceJailBroken()-> Bool { 
  var jailbroken = false 
 如果TARGET_IPHONE_SIMULATOR == 1 { 
返回假
}
/ ****检查常见符号链接的存在。**** /
self.checkJBSymlinks()
/ ****检查越狱设备通用的文件是否存在。 **** /
self.checkJBOnlyAvailableFiles()
/ *****检查系统目录中的读/写权限(违反沙箱)***** /
self.checkReadWritePermissionsJBDevice()
返回越狱
}
 私人功能checkReadWritePermissionsJBDevice(){ 

var isError = false
让stringToBeWritten =“您的字符串”
let filePath = String(格式:“ / p%@%@%@%@%@%@”,“ ri”,“ va”,“ te / j”,“。te”,“ st”)

做{
尝试stringToBeWritten.write(toFile:filePath,原子地:true,编码:String.Encoding.utf8)
}
赶上{
isError = true
}

如果!isError {
让fileManager = FileManager.default
做{
尝试fileManager.removeItem(atPath:filePath)
}抓{}

}
}

5.显示/隐藏密码字段

风险:
在记录登录屏幕和其他敏感信息屏幕时,将显示应用程序密码。

OWASP:不安全身份验证

固定:

当您确定正在录制屏幕时,请在密码文本字段(或任何敏感文本字段)上使用“掩码”,并保护数据安全。
录制应用程序时隐藏/关闭键盘。

例:

  / ****当屏幕录制为真(或)时,我们还可以检查应用是否最小化/背景。  **** / 
  if(isRecording){ 
let maskView = UIView(frame: CGRect(x: 64, y: 0, width: 128, height: 128))
maskView.backgroundColor = .blue
maskView.layer.cornerRadius = 64
yourView.mask = maskView
  } 

6.隐私资源访问

风险:
该应用程序访问私有设备和/或用户资源(例如联系人,位置,蓝牙设备ID,摄像头和麦克风)。 在不安全使用此数据的情况下,这可能会导致数据泄漏(例如,通过HTTP以纯文本格式发送数据)。 开发人员应确保对这些资源的访问遵循安全策略(例如,在将数据发送到服务器之前对其进行加密)。 您还应确保没有正在使用的第三方库不安全地访问资源。

OWASP:不安全的数据存储

修复:验证对私有资源的所有访问并强制遵守安全策略。

例:
同时使用广告标识符,ABAddressBookRef等。

7.缺少证书固定

风险:
如果攻击者可以例如通过使用在设备上安装错误的证书颁发机构(CA)的已知技术为目标域生成有效证书,则攻击者可以模仿目标并解密流量,即“ Man-in”。 -中间攻击”。 这可能导致敏感数据泄漏,其他漏洞的利用。

OWASP:通信不安全

固定:
委托必须实现URLSession:task:didReceiveChallenge:completionHandler:
并通过证书身份验证处理所有连接。

  func urlSession(_会话:URLSession,didReceive挑战:URLAuthenticationChallenge,completeHandler:@转义(URLSession.AuthChallengeDisposition,URLCredential?)->无效){ 
 如果(challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust){ 
 如果让serverTrust = Challenge.protectionSpace.serverTrust { 
  var secresult = SecTrustResultType.invalid 
 让状态= SecTrustEvaluate(serverTrust,&secresult) 
  if(errSecSuccess == status){ 
 如果让serverCertificate = SecTrustGetCertificateAtIndex(serverTrust,0){ 
 让serverCertificateData = SecCertificateCopyData(serverCertificate) 
 让数据= CFDataGetBytePtr(serverCertificateData); 
 让大小= CFDataGetLength(serverCertificateData); 
 让cert1 = NSData(字节:数据,长度:大小) 
  let file_der = Bundle.main.path(forResource:“证书名称”,ofType:“ cer”) 
 如果让file = file_der { 
 如果让cert2 = NSData(contentsOfFile:file){ 
 如果cert1.isEqual(以cert2作为数据){ 
  completeHandler(URLSession.AuthChallengeDisposition.useCredential,URLCredential(trust:serverTrust)) 
 返回 
  }}}}}}} 
  //固定失败 
  completeHandler(URLSession.AuthChallengeDisposition.cancelAuthenticationChallenge,nil) 
  } 

8.启用调试日志

风险:
通过应用程序进行的不必要的调试日志可能会打印敏感信息和方法完成。 这在发行版本中风险更大。

OWASP:多余的功能

修复:使用#ifDef DEBUG或仅在调试版本上启用debug = 1。 严格避免使用NSLog。

 #ifdef DEBUG 
NSLog(@"Your log statement");
#endif

9. SSL证书到期

风险:
通常,每个证书的有效期约为一年,之后需要进行续订,如果续签未在正确的时间完成,则该应用将停止工作。

OWASP:通信不安全

固定:
在到期日之前提前更新证书,并更新IPA以使任何应用程序无缝运行。

示例:在每次启动时检查证书的到期时间,并在到期前的新几天内进行私密/请求。

10. HTTP请求的用法

风险:
该应用程序使用不安全的通信通道(HTTP)。 因此,路径上(即与受害者位于同一网络上)的攻击者可以向攻击者控制的服务器注入301 HTTP重定向响应。 中间人(MiTM)攻击。

OWASP:通信不安全

解决:
使用HTTPS代替HTTP,或强化缓存策略。

11.谨慎使用第三方图书馆

风险:
有时,第三方库可能会向您的代码注入有害代码。

OWASP:多余的功能

固定:
使用之前,请通过GitHub链接,许可证和代码检查任何第三方库。

12. iOS-代码混淆

风险:
最后但并非最不重要的一点是,任何人都可以反向工程并检查iOS应用程序中的类和方法,并尝试为该方法/通知观察者动态注入代码。 建议对代码进行混淆处理,以免直接运行应用程序逻辑。

OWASP:多余的功能

固定:
使用功能强大的代码混淆处理库第三方工具,这些工具可提供某种程度的混淆和完整性保护,其中包括:
阿尔山
Metaforic,
ry。
这些库使反向混淆变得困难。

这些是主要的12个安全威胁,每个开发人员都可以确保从头开始采取一定程度的措施。 这也可以像是开发人员的清单。 但是,尽管代码受到了保护,但几乎没有什么可用的工具可以绕过越狱,反向混淆和注入动态库并了解钥匙串和存储项。

我们将在下一个即将发布的博客中讨论测试人员广泛用于渗透测试的工具以及其他人用来理解您的代码的注入。 最初发布于https://blog.imaginea.com

..未完待续。

Interesting Posts