我需要API安全基礎的資源。有什麼建議麼？

Question

我已經做了一點Google搜索，但已被信息量淹沒了一點。到目前爲止，我一直在考慮爲每個API調用請求一個有效的md5哈希，但是我意識到劫持這樣一個系統並不是一件困難的事情。你們會友善地向我提供幾個可能幫助我進行搜索的鏈接嗎？謝謝。

Answer 1

首先，考慮OAuth。它現在是基於網絡的API的標準。

其次，其他一些潛在資源 -

幾個像樣的博客文章：

• http://blog.sonoasystems.com/detail/dont_roll_your_own_api_security_recommendations1/
• http://blog.sonoasystems.com/detail/more_api_security_choices_oauth_ssl_saml_and_rolling_your_own/

前一個問題：

• Good approach for a web API token scheme?

Answer 2

我想爲此問題添加一些澄清信息。 「使用OAuth」的答案是正確的，但也是加載的（鑑於規範很長，不熟悉它的人通常想看到它後自殺）。

我寫了關於如何在這裏設計一個安全的REST API時，從沒有安全到基於HMAC-安全劇情式教程：

• http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

這最終是基本所謂的「雙腿OAuth」;由於OAuth最初旨在驗證客戶端應用程序，因此該流程涉及3個部分，涉及身份驗證服務，用戶盯着屏幕以及希望使用客戶端憑據的服務。

雙腿OAuth（以及我在該文章中深入概述的內容）旨在用於服務API彼此之間的身份驗證。例如，這是Amazon Web Services用於所有API調用的方法。

的要點是通過HTTP與任何要求，你必須考慮攻擊向量，其中一些惡意的人在這方面的中間人被記錄和重放或更改您的要求。

例如，您向/ user/create發出名爲'bob'的POST，以及中間人可以使用名稱'bob'向/ user/delete發出POST，這只是令人討厭的。

客戶端和服務器需要某種方式互相信任，唯一可能發生的方式是通過公鑰/私鑰。

你不能僅僅通過公鑰/私鑰來回也不能把你只需提供與私鑰簽名的唯一令牌（這是通常是大多數人做，認爲這使得他們的安全），而這將識別來自真實客戶端的原始請求，但它仍然將評論的論據留給可以改變的意見。

例如，如果我送： /chargeCC用戶=先令& AMT = 100.00 &鍵= kjDSLKjdasdmiUDSkjh

其中關鍵是我的公鑰通過我的私鑰簽名只是一個人在the- middle可以攔截這個調用，然後用「amt」值「10000.00」重新提交給服務器。

關鍵是你必須包括你發送的哈希計算中的所有參數，所以當服務器獲取它時，它會通過重新計算其側邊的相同哈希來重新驗證所有值。

提示：只有客戶端和服務器知道私鑰。

這種驗證方式稱爲「HMAC」。它是驗證請求內容的校驗和。

因爲哈希生成是SO敏感，爲了得到相同的哈希必須做到EXACTLY客戶端和服務器上一樣，還有的所有價值究竟應該如何組合的超級嚴格的規定。

例如，這兩條線提供了非常不同的散列當你嘗試並用SHA-1他們簽名： /chargeCC &用戶=擺錘& AMT = 100 /chargeCC & AMT = 100 &用戶=擺錘

大量的OAuth規範花費了極其詳盡的描述，其中使用了諸如「自然字節排序」和其他非人類可讀垃圾等術語的組合方法。

這很重要，因爲如果你得到的錯誤值的組合，客戶端和服務器不能正確審查對方的請求。

你也不能採取捷徑，只是將所有東西都轉換成一個巨大的字符串，亞馬遜試圖用AWS簽名版本1和它turned out wrong。

我希望所有這一切都有所幫助，如果您遇到困難，請隨時提問。