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

我知道這個問題以前曾以各種形式提出過。但是，我不在尋找「使用https」的答案。我已經在使用HTTPS，而且我並不擔心有效負載傳輸的敏感性。但是，我正在使用的iPhone應用程序正在與我創建的REST API（我有應用程序和服務器的控制權 - 因此，歡迎任何建議）交談。在iPhone應用程序中使用REST API時的安全性

我用於身份驗證的OAuth2用戶協議，這意味着，我的「API密鑰」是一個客戶端ID和客戶端祕密的組合僅需要被髮送到獲取access_token。之後，使用access_token和包含請求主體的HMAC的標頭（使用客戶機密鑰作爲密鑰）將所有請求發送到服務器。這個添加的唯一原因是，有人不能通過一個access_token進行API請求。

我正在與之交談的API將在我發佈應用程序時公佈。所以我不一定擔心其他人能夠對其進行API調用。

我關心的是：

人們能夠使用我的應用程序的客戶端憑證（這意味着我無法檢測在服務器端，它不是來自我的應用程序調用API ）
人們能夠濫用額外的範圍，我的客戶端ID將讓他們有和傳統的API用戶將不必

我的猜測是，有沒有真正解決這個問題的解決方案（除使用UIWebView並製作一個glor ified webapp），但我想我會問在這裏無論如何。

如果需要應用程序使用，你們都可以考慮保護客戶端ID /客戶端密碼的方法嗎？

來源

2013-03-07 Colin M

你是說oauth對你的應用程序不夠安全嗎？ oauth客戶端必須簽署所有參數，因此只有具有訪問令牌和祕密的客戶端才能包含一些參數_and_正確簽名。 – danh 2013-03-07 16:07:35

@danh實際上，OAuth2不會簽署參數（這是OAuth1的一部分，它違反了該規範）。但是，不，我只是用相對微小的努力來說，有人可以對我的應用程序進行逆向工程，並獲得我的客戶ID和祕密，並將API作爲我的應用程序發出請求。 – 2013-03-07 16:12:08

如果您可以（某些人）授予任何購買iPhone應用程序唯一標識符的人，可以將其鏈接到單個用戶的憑據。有了這些，你就可以將已經獲得iPhone應用程序的客戶與另一個來源的客戶區分開來。 – AardvarkSoup 2013-03-07 16:48:02

我知道這不是你所希望的答案，但不幸的是，我不認爲你能夠絕對保證地完成你的目標。在一天結束的時候，你不能相信你不能控制的客戶，一旦離開你的手，你就無法控制它。

爲了實現您的兩個目標，您需要驗證訪問該API的客戶端是否由您編寫。做到這一點的方法是使用公鑰/私鑰對。您需要將私鑰嵌入到可用於簽署某些內容的客戶端中。這樣服務器就知道請求來自你的客戶而不是別人的請求。這也可以讓你限制只有你的客戶的某些電話。

但是，這不是防彈的，因爲精明的用戶可以逆向工程並從您的應用程序中提取私鑰並使用它來欺騙源。雖然不是防彈的，但它是防彈的，因爲這樣做需要很多工作，並且技術性很強，尤其是在使用緩衝塗抹，大量紅鯡魚等抗RE技術時。

如果我對於你，我會問自己，如果有人確信黑客攻擊會造成什麼樣的損害。如果你是Facebook，它是災難性的。如果你服務於一個內部組織，它可能不是什麼大問題。如果你無法承受單一的濫用，那麼你需要重新考慮你的設計，因爲這一個不起作用。你根本無法信任你無法控制的代碼，並且一旦它在別人的設備上，你就不再控制客戶端了。

來源

2013-03-07 17:18:09

欣賞評論。通過獲取'access_token'（或者我的客戶端ID /祕密），並不是真的有人能攻擊任何東西。只是他們可以向API發出看起來像他們的請求。誰知道，這可能是爲什麼Facebook是作爲一個Web應用程序分發。 – 2013-03-07 17:20:44

如果你可以容忍一些看起來像是來自你但沒有的請求，那麼你應該可以使用私鑰/公鑰模型，否則你可能會被卡住。我認爲你是對的，這就是爲什麼Facebook是作爲一個Web應用程序發佈的:-) – 2013-03-07 17:24:01

@Freedom_Ben，你能解釋一下Facebook如何處理這個和分佈式Web應用程序嗎？或指引我到任何地方，我可以得到更多信息？謝謝 – nightograph 2015-03-16 18:51:24

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

回答

相關問題