如何使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