Web服務API密鑰和Ajax - 保護密鑰

Question

這可能是一個通用的安全問題，但我想我會在我正在開發的內容中提出這個問題。

場景是：一個Web服務（WCF Web Api），它使用API​​ Key來驗證並告訴我用戶是誰，以及前端的jQuery和應用程序的混合。

一方面，流量可以是https，因此無法檢查，但如果我每個用戶使用相同的密鑰（比如一個guid），並且我在兩者中都使用它，那么就有可能采取它並且有人可以冒充用戶。

如果我實現類似於OAuth的東西，那么會生成一個用戶和每個應用程序密鑰，這可能會起作用 - 但仍然對於jQuery方面，我需要javascript中的應用程序API密鑰。

如果某人在實際計算機上並且執行了視圖源，那么這只會是一個問題。

我該怎么辦？

1. md5或以某種方式加密密鑰？
2. 把密鑰放在會話變量中，然后當使用ajax檢索它時？
3. 克服它，這不是一個大交易/問題。

我敢肯定這可能是一個常見的問題 - 所以任何指針都會受到歡迎。

為了使這更清楚 - 這是我寫的API，我寫的是我要查詢，而不是谷歌等。所以我可以做每個會話令牌等，我只是想找出最好的方法來保護客戶端我會用的代幣/鑰匙。

我在這里有點過於謹慎，但只是用它來學習。

Answer 1

（我建議標記這篇文章“安全”。）

首先，你應該清楚你正在保護什么。 你能信任客戶嗎？ 一個狡猾的用戶可以在您的頁面上粘貼Greasemonkey腳本，並准確調用您的UI調用發送請求的代碼。 將所有內容隱藏在Javascript閉包中只意味着您需要一個調試器; 它不會使攻擊變得不可能。 Firebug可以跟蹤HTTPS請求。 還要考慮受感染的客戶端：是否安裝了鍵盤記錄器？ 整個系統是否秘密運行虛擬化，以便攻擊者可以隨時隨地檢查內存的任何部分？ 當你像webapp一樣暴露時的安全性真的很棘手。

盡管如此，您可以考慮以下幾點：

1. 考慮不是實際使用密鑰而是使用HMAC哈希，例如，您在認證時立即提供的令牌。

2. DOM存儲可能比cookie更難捅。

3. 有關示例安全模型，請查看Google的OAuth 2實現。 基本上，您使用的令牌僅在有限時間內有效（並且可能對於單個IP地址有效）。 這樣即使令牌被攔截或克隆，它也僅在很短的時間內有效。 當然，當令牌用完時你需要小心你做的事情; 攻擊者可能只是做你的代碼所做的事情並得到一個新的有效令牌嗎？

不要忽視服務器端安全性：即使您的客戶端在提交請求之前已經檢查過，如果用戶實際上有權執行他們要求的操作，請再次檢查服務器。 事實上，這個建議可以消除上述大部分內容。

Answer 2

這取決於API密鑰的使用方式。 Google提供的API密鑰與發起請求的網站的網址相關聯; 如果您嘗試在具有備用URL的站點上使用該密鑰，則該服務將引發錯誤，從而無需保護客戶端上的密鑰。

然而，一些基本API與客戶端綁定並且可以跨多個域使用，因此在此實例中，我之前已經將這個API包裝在服務器端代碼中，並對客戶端如何與本地服務進行通信設置了一些限制並保護服務。

然而，我的總體建議是對Web API應用如何使用密鑰的限制，從而消除了嘗試在客戶端上保護密鑰的復雜性和必要性。

Answer 3

通常在這種情況下，雖然您通過服務器使用'AJAX'代理請求，該'AJAX'驗證瀏覽器是否有權這樣做。 如果您想直接從JavaScript調用服務，那么您需要某種令牌系統，如JSON Web令牌（JWT） ，如果服務位於當前域以外的某個位置，您將不得不解決跨域問題。

Answer 4

如何使用jQuery調用處理與API通信的服務器端代碼。 如果您正在使用MVC，則可以調用控制器操作，該操作可以包含代碼和API密鑰以命中您的服務並返回部分視圖（甚至是JSON）到您的UX。 如果您使用Web表單，則可以創建一個aspx頁面，該頁面將在后面的代碼中進行API通信，然后將內容寫入響應流以供您使用。 然后，您的UX代碼可以包含對服務器端代碼的一些$ .post（）或$ .load（）調用，並且您的API密鑰和端點都將受到保護。

Answer 5

請參閱http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx了解更多信息信息（如何在.NET 4中對REST服務進行API密鑰驗證）