如何使ios应用程序安全

确保iOS应用安全的指南 (Guide for Making iOS App Secure)

This is mobile era and pretty much everything these days can happen from our smart phone. Thanks to millions of apps out there which help us in accomplishing anything we want. Whether it is maintaining your schedule (calendar) to managing financial information on the go, all things can be done by mobile apps running on our smart phones. Since these apps have access to so much of confidential information, as developer when we make an app we need to follow highest security standards so that information is not accessed by someone who is not entitled for it.

Ť他是移动时代，几乎所有这些日子可以从我们的智能手机出现。 感谢数以百万计的应用程序，它们可以帮助我们完成所需的任何事情。 无论是维护您在旅途中管理财务信息的时间表(日历)，所有事情都可以通过运行在我们智能手机上的移动应用来完成。 由于这些应用程序可以访问大量机密信息，因此作为开发人员，在我们开发应用程序时，我们需要遵循最高的安全标准，以使没有资格获得此信息的人无法访问这些信息。

When it comes to iOS devices there are more than billion active devices that use iOS apps on daily basis. Here I am compiling the different security practices that an iOS developer should always keep in mind while developing apps.

对于iOS设备，每天有超过十亿的活动设备在使用iOS应用程序。 在这里，我正在编译iOS开发人员在开发应用程序时应牢记的各种安全实践。

1.在移动应用中启用ATS (1. Enable ATS in mobile apps)

With launch of iOS 9 and ELCapitan Apple launch ATS (Apple Transport Security) which forces apps to only connect to secure network. This means any connection that application makes to outside world must use HTTPS protocol and TLS1.2.

随着iOS 9和ELCapitan的发布，苹果公司发布了ATS(苹果传输安全性)，该应用程序强制应用程序仅连接到安全网络。 这意味着应用程序与外界的任何连接都必须使用HTTPS协议和TLS1.2。

In other words, ATS forces app to only make secure connection, and not use HTTP. There is an option to explicitly mention exception if need be by making explicit entry in plist.

换句话说，ATS强制应用程序仅建立安全连接，而不使用HTTP。 如果需要，可以通过在plist中进行显式输入来明确提及异常。

2. SSL证书固定 (2. SSL Cert Pinning)

This technique is very effective to deal with MITM(Man in the Middle) attack. SSL works on the basis of “chain of trust”. When app/client connects to a server, the client checks if received server’s SSL certificate is trusted by any SSL Certificate Authority.

此技术对于应对MITM(中间人)攻击非常有效。 SSL在“信任链”的基础上工作。 当应用程序/客户端连接到服务器时，客户端会检查接收到的服务器的SSL证书是否受任何SSL证书颁发机构的信任。

This makes sure app only communicates to designated server. App/Client bundles the SSL certificate of the designated server, so that it can match the SSL cert received while connecting to server and local cert. Details of this requires an article by itself. Stay tuned, I will be writing article on the details.

这样可以确保应用仅与指定服务器通信。 App / Client捆绑了指定服务器的SSL证书，因此它可以与连接到服务器和本地证书时收到的SSL证书匹配。 详细信息仅需一篇文章。 请继续关注，我将在细节上写文章。

3.将信息存储在KeyChain中，而不是NSUserDefaults中 (3. Storing info in KeyChain rather than NSUserDefaults)

NSUserDefaults provides us a way to save small bits of information that needs to be persisted between app launches and device restarts. All the info saved as part of UserDefaults is saved as plain text in plist which is not encrypted and can be read by anyone who has access to the device.

NSUserDefaults为我们提供了一种方法，可以保存在应用程序启动和设备重启之间需要保留的少量信息。 保存为UserDefaults一部分的所有信息均以纯文本格式保存在plist中，该列表未加密，任何有权访问该设备的人都可以读取。

If we want to save information in encrypted form, we need to use KeyChain, an encrypted container to store passwords for applications and secure services. Apple use the same technology for password management in Mac OS and iOS. Stay tuned, I will be writing article on the details.

如果我们想以加密形式保存信息，则需要使用KeyChain，这是一个加密容器，用于存储应用程序和安全服务的密码。 Apple在Mac OS和iOS中使用相同的技术进行密码管理。 请继续关注，我将在细节上写文章。

4.避免将机密信息作为代码存储库的一部分 (4. Avoiding confidential info as part of code repository)

Any secret info shouldn’t be part of repo/code base, instead we should use configuration file or environment variables that are injected while building apps. A good option is Xcode Config files which maintains info pertaining to a specific target. One use case is API keys, we shouldn’t put API keys as part of code base. We could use a config file that contains the API keys. This file can be hosted internally on company network and can be read while building the app and injecting as part of build process.

任何秘密信息都不应成为存储库/代码库的一部分，而应使用在构建应用程序时注入的配置文件或环境变量。 Xcode Config文件是一个不错的选择，该文件维护与特定目标有关的信息。 一个使用案例是API密钥，我们不应该将API密钥作为代码库的一部分。 我们可以使用包含API密钥的配置文件。 该文件可以在公司网络内部托管，并且在构建应用程序和作为构建过程的一部分注入时可以读取。

5.越狱检测 (5. Jailbreak Detection)

Application behavior and logic can be easily compromised by a hacker with little effort on a jailbroken device. As a developer, we need to make sure we make it as difficult as possible for a hacker to get to internal details of the app. We should definitely add the logic to check for jailbroken device as the first thing when we fire the app. And after informing the user, probably kill the app. Stay tune, I will write a detail article for detecting and handling jailbreak.

黑客只需在越狱设备上花费很少的精力，就可以轻易地破坏应用程序的行为和逻辑。 作为开发人员，我们需要确保使黑客尽可能难以获取应用程序的内部细节。 我们绝对应该添加逻辑，以在启动应用程序时首先检查越狱设备。 并通知用户后，可能会终止该应用程序。 请继续，我将写一篇详细的文章来检测和处理越狱。

6.仅调试日志 (6. Debug Logs Only)

Developers use debug message as a great way to log the behavior of the app. This is very useful while app is under development. When the app is under development we tend to log some information to help the developers build the features. But, if it becomes accessible to a hacker it can expose confidential info and internal working of the app. In order to make sure we don’t log the message on the version of the app that we submit to store we just to put a basic check to log only while app is in Debug mode by simply doing the following.

开发人员使用调试消息作为记录应用程序行为的好方法。 在开发应用程序时，这非常有用。 在开发应用程序时，我们倾向于记录一些信息以帮助开发人员构建功能。 但是，如果黑客可以访问它，则可以暴露该机密信息和该应用程序的内部运行情况。 为了确保我们不会在提交到存储的应用程序的版本上记录消息，我们只需执行以下操作即可对应用程序处于调试模式下的日志进行基本检查。

#ifDEBUG
print("log statement")
#endif           

We can take a step further and make a logger which will take care of every log going through it. Stay tuned, I will write a detail article separately to cover this.

我们可以更进一步，制作一个记录器，该记录器将处理通过它的每个日志。 请继续关注，我将单独写一篇详细的文章来介绍这一点。

7.第三方图书馆的使用 (7. Third Party Library Usage)

Third party library are a great way to avoid recreating a lot of things that we want to do in our mobile app. They definitely save us a lot of time, at the same time there are some things that we need to be careful while using third part apps. There is always a risk of those libraries injecting harmful code into our code base. We should always go through Github link, license and code/security review of any 3rd party app before actually integrating it.

第三方库是避免在移动应用中重新创建很多我们想做的事情的好方法。 它们无疑为我们节省了很多时间，同时在使用第三方应用程序时需要注意一些事项。 这些库始终有将有害代码注入我们的代码库的风险。 在实际集成任何第三方应用程序之前，我们应始终通过Github链接，许可证和代码/安全性审查。

8.文件数据保护 (8. File Data Protection)

Whenever we are saving any file in our app, we should use of these options to save information is a secure way

每当我们在应用程序中保存任何文件时，都应使用这些选项来保存信息是一种安全的方法

• Complete Protection (NSFileProtectionComplete)

  全面保护(NSFileProtectionComplete)

• Protected Unless Open (NSFileProtectionCompleteUnlessOpen)

  除非打开，否则受保护(NSFileProtectionCompleteUnlessOpen)

• Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication)

  在首次用户身份验证之前受保护(NSFileProtectionCompleteUntilFirstUserAuthentication)

• No Protection (NSFileProtectionNone)

  无保护(NSFileProtectionNone)

NSFileProtectionNone is easiest to use but most vulnerable for security risk. We should always use NSFileProtectionCompleteUnlessOpen or NSFileProtectionCompleteUntilFirstUserAuthentication as default file protection level option.

NSFileProtectionNone最容易使用，但最容易造成安全风险。 我们应该始终使用NSFileProtectionCompleteUnlessOpen或NSFileProtectionCompleteUntilFirstUserAuthentication作为默认文件保护级别选项。

9.屏幕录制和捕获 (9. Screen Recording & Capturing)

A lot of sensitive information can be exposed from app by screen recording or screen shots. This security check plays a very crucial role in banking applications where secured transaction details can be compromised if screenshot or screen recording is performed. We can listen/observe for notifications such as userDidScreenShotNotification to act appropriately on these events. We will cover details of this in a separate article, stay tuned.

通过屏幕记录或屏幕快照，可以从应用程序中暴露很多敏感信息。 此安全检查在银行应用程序中起着至关重要的作用，如果执行屏幕截图或屏幕录制，安全交易细节可能会受到损害。 我们可以侦听/观察诸如userDidScreenShotNotification之类的通知以对这些事件采取适当措施。 我们将在另一篇文章中对此进行详细介绍，敬请期待。

结论 (Conclusion)

As a developer we should always try to make as hard as possible for data/info to be compromised from our app. We can certainly do this by following standard practices for app security. I usually follow the list I mentioned above, very curious to hear what security best practices you follow in your own apps. Please let me know your thoughts and stay tune for detail articles on some of these security practices.

作为开发人员，我们应该始终努力使数据/信息从我们的应用程序中泄漏出去。 我们当然可以通过遵循应用安全性的标准做法来做到这一点。 我通常遵循上面提到的列表，非常想知道您在自己的应用程序中遵循的最佳安全最佳做法。 请让我知道您的想法，并继续关注有关某些安全实践的详细文章。

Originally published at https://www.shashankthakur.dev.

最初发布在 https://www.shashankthakur.dev 。

翻译自: https://medium.com/@shashank.thakur/how-to-make-an-ios-app-secure-831e310c79e2