如何保護應用程序 - 後端通信？

我有一個iOS應用程序，也是我迄今用來管理apns（Apple推送通知）的小型後端。註冊過程只是一個帶有參數的GET調用，並且由於沒有'身份驗證'或任何其他類型的控制，所以我擔心任何人都可能僅僅使用虛假設備註冊來超載我的後端。如何保護應用程序 - 後端通信？

所以主要問題是：如何在沒有身份驗證的情況下使這種應用程序發送信息到後端傳輸安全？

這使我想起使用令牌註冊設備時，應用程序必須提供正在產生某種HASH的一個簡單的想法...

來源

2014-02-17 apascual

有沒有辦法徹底解決這個問題。無法知道它是您的應用程序正在連接。你所能做的只是添加一點混淆。

你最好的第一步是使用SSL with a pinned certificate來使中間人攻擊更難。客戶端證書可以提供幫助，但是設置起來有點痛苦，並且不會通過其他解決方案來購買很多。

如果您擁有固定證書和SSL，則只需發送共享密鑰和GET一起就可以滿足您的需要。將發佈的祕密更改爲發佈，以便讓舊的發佈。如果有人對您的應用程序進行了反向設計，足以擊敗固定證書（或直接讀取共享密鑰），那麼他們也將打破所有其他方法。

即便如此，這裏有一些更是添加一些額外的層：

Bidirectional shared-secret verification with AES是一個很好的和簡單的方法，但需要握手（即你不能用一個單一的GET做到這一點）。你當然可以實現這種單向（所以服務器驗證密鑰，但不是客戶端），但你仍然需要握手。

如果你想保持你的認證令牌到一個單一的GET並且不能固定你的SSL證書，並且你可以使你的GET冪等（好的REST調用應該是這樣），那麼這是一個簡單的實現：

構建GET請求
計算HMAC（SHA-256，共享祕密，得請求，16個字節）
發送HMAC與GET請求

在iOS上沿，這看起來所以方法如下：

NSData *key = ...random 32 bytes shared with server...; 
NSURLRequest *request = ...; 

// Allocate some memory for the HMAC 
NSMutableData *hmac = [NSMutableData dataWithCapacity:CC_SHA256_DIGEST_LENGTH]; 

// Convert your URL into data. This assumes that this is a GET request, so the URL 
// has everything. This also assumes that the GET is idempotent, so if someone 
// replays this GET request, you don't care. 
NSData *requestData = [[[request URL] absoluteString] dataUsingEncoding:NSUTF8StringEncoding]; 

// Compute the HMAC 
CCHmac(kCCHmacAlgSHA256, 
     [key bytes], 
     [key length], 
     [requestData bytes], 
     [requestData length], 
     [hmac mutableBytes]); 

// Truncate the HMAC (this is common practice. It's slightly better, and at least no 
// worse, to send half the HMAC rather than the whole HMAC). 
NSData *token = [hmac subdataWithRange:NSMakeRange(0, [hmac length]/2)]; 

NSURLRequest *finalRequest = ... add the token to your request ...

你當然會在服務器端計算相同的東西。您可以將其視爲「簽署GET」。如果你的請求不是冪等的，那麼你應該正在努力解決這個問題。如果你無法解決這個問題，你可以把一個時間戳集成到哈希中，並丟棄過時或以前見過的請求。（在這樣做的時候，你已經使你的GET冪等......）

當你升級你的應用時，你應該改變你的共享密鑰。這樣你可以最終使已發現的舊共享祕密變老。

是的，這些都可以被反向設計。 試圖驗證應用程序（而不是用戶）的任何東西都可以進行反向設計。所以保持簡單，並且更多地關注如果它確實發生，你將如何恢復。

如果可能，請添加用戶驗證。它更強大。

來源

2014-02-17 16:20:36

謝謝，這是更完整的答案！標記爲正確的答案... – apascual

哈希想法應該工作（未成年人注意，SHA-256止跌不存在衝突，MD5不再安全），但它取決於權衡，如果服務涉及真正非常重要的事情，客戶端SSL證書將是最好的處理方式。

來源

2014-02-17 15:23:29 theMarceloR

謝謝，我對客戶端證書的恐懼是，最終應用程序可能會被反編譯，然後證書將不再可靠......我是對的嗎？ – apascual

您可以放棄任何不是來自iOS設備的HTTP GET請求（這應該縮小可能生成服務器端處理的請求的數量），您只需要在後端應用程序中捕獲http標頭。 – theMarceloR

但是任何人都可以在請求中僞造用戶代理，因此您不能分辨是否存在真正的iOS設備... – apascual

設備上的任何內容都可供確定的攻擊者使用。

我會在設備上從相關令牌生成一個哈希值，並在註冊APN令牌時將其發送到您的後端。使用HTTPS。

如果有人想用虛假註冊重載後端，他們至少不得不反編譯應用程序以查看哈希如何生成。

讓服務器在設備註冊時根據令牌檢查哈希。

用註冊保存設備的IP地址和時間戳。如果您發現來自同一個IP號碼的註冊數量不合理，請暫停註冊，並對情況進行人工審查。如果一切正常，請發佈註冊。

來源

2014-02-17 16:21:51

謝謝你的回答和偉大的想法！ – apascual

如何保護應用程序 - 後端通信？

回答

相關問題