在iPhone應用程序中使用REST API時的安全性

Question

我知道以前曾以各種形式提出過這個問題。 但是，我不是在尋找“使用https”的答案。 我已經在使用HTTPS了，我並不擔心有效載荷來回傳輸的敏感性。

但是，我正在處理的iPhone應用程序正在與我構建的REST API進行通信（我已經控制了應用程序和服務器 - 因此歡迎任何建議）。

我使用OAuth2協議進行身份驗證，這意味着我的“API密鑰”是客戶端ID和客戶端密鑰的組合， 只需要傳輸以獲取access_token 。 之后，使用access_token和包含請求主體的HMAC的標頭（使用客戶機密鑰作為密鑰）將所有請求發送到服務器。 這種添加的唯一原因是，有人無法使用JUST access_token發出API請求。

我正在談論的API將在我發布應用程序時公開。 所以我不一定擔心別人能夠對它進行API調用。

我關心的是：

• 人們可以使用我的應用程序的客戶端憑據進行API調用（這意味着我無法在服務器端檢測到它不是來自我的應用程序）
• 人們可以濫用我的客戶ID允許他們擁有的其他范圍，而傳統的API用戶也不會

我的猜測是，這個問題並沒有真正的解決方案（除了使用UIWebView並制作一個美化的webapp），但我想我還是會在這里問一下。

如果應用程序需要使用客戶端ID /客戶端密碼，您能想到保護客戶端ID /客戶端密鑰的方法嗎？

Answer 1

我知道這不是你所希望的答案，但不幸的是，我認為你無法絕對保證完成你的目標。 在一天結束時，您無法信任您無法控制的客戶，並且一旦離開您就無法控制它。

為了實現您的兩個目標，您需要驗證訪問API的客戶端是否由您編寫。 這樣做的方法是使用公鑰/私鑰對。 您需要將一個私鑰嵌入客戶端，它可以用來簽名。 通過這種方式，服務器知道請求來自您的客戶端而不是其他人的請求。 這也允許您將某些調用限制為僅限您的客戶端。

但是，這不是防彈，因為精明的用戶可以從您的應用程序反向工程和提取私鑰，並使用它來欺騙源。 雖然不是防彈，但它是防彈的，因為這樣做需要大量的工作並且技術性很強，特別是如果你使用反RE技術，如緩沖塗抹，質量紅鯡魚等。

如果我是你，我會問自己如果有人肯定會攻擊它會造成什么類型​​的傷害。 如果你是Facebook，那就是災難性的。 如果您在內部組織服務，那可能不是什么大問題。 如果您無法承受單一的濫用行為，那么您需要重新考慮您的設計，因為這不會起作用。 您根本無法信任您無法控制的代碼，並且一旦在其他人的設備上，您就不再控制客戶端了。