保護Web API免受未經授權的應用程序的攻擊

Question

我正在使用大量AJAX與服務器通信的網頁上工作。反過來，服務器有一個廣泛的REST/JSON API暴露Web客戶端調用的不同操作。

本網站由匿名用戶和經過身份驗證的用戶使用。正如您所預料的那樣，由經過身份驗證的用戶發出的Web服務調用需要身份驗證，並且因此可以防止未經授權的用戶或應用程

然而，該網站有很多是不需要身份驗證功能，而且其中的一些利用匿名Web服務。我用來阻止外人調用此Web服務的唯一方法是使用CSRF token。我知道，CSRF令牌在這方面並不是非常有用......在一段時間後，即使使用CSRF令牌，您也可以瞭解如何使用Web服務。

當然，你也可以使用一個驗證碼，防止應用程序或機器人從自主使用網絡服務。但是，任何人都可以使用它。

另一方面，在客戶端和服務器之間共享密鑰將毫無用處。這是因爲任何局外人從網頁源代碼中讀取它的能力。

我想使這些Web服務難以像任何第三方應用程序一樣調用。除了使用CSRF令牌，你還會做什麼？這聽起來有點愚蠢，但嘿，也許這是愚蠢的，我只是失去了我的時間。

注意：由於此應用程序使用瀏覽器而不是「可執行」作爲客戶端，因此this question與討論無關。我不能使用服務器和客戶端之間的祕密（據我所知，至少）

Answer 1

您可能需要比連接問題描述的一個容易問題，因爲你並不需要分配一個二進制用戶。即使您的應用程序是開源的，HMAC /簽名密鑰（位於該答案的「請求籤名」部分中）也可以通過環境/配置設置進行控制。

總結：

1. 的密鑰是不實際的客戶端和服務器之間發送。相反，它是用來簽署請求
2. 確保請求包括一些獨特/隨機元素（CSRF的關鍵可能就足夠了），這樣對於相同的API數據兩個要求是不相同的。
3. 使用密鑰簽署請求並將簽名附加到請求。你鏈接到一個PHP問題，但不清楚你使用的是什麼語言。在.Net中，我將使用HMAC類，如HMACSHA256。
4. 在API服務器端使用相同的HMAC對象來驗證請求是否使用相同的密鑰簽名。

Answer 2

也許你可以使用計數器來跟蹤對話。只有服務器和客戶端才能夠預測對話中的下一次迭代。這樣，我認爲，您可以阻止第三方應用程序冒充某人（只是一個想法）。

在開始時，他們開始在某個迭代中進行交談（例如i=0）。

• 每當客戶端請求的東西，計數器是由於兩種服務器端和客戶端（i=i+some_number）一定數量的增加。

• 而且，在幾分鐘沒有通信後，他們都知道他們必須重置計數器（i=0）。

Answer 3

這只是一個基於RSA概念的想法，並且還會將欺詐檢測功能置於您的系統上。授權用戶的風險很小，但他們也可以嘗試匿名撥打您的網絡服務。

對於聯合國授權用戶：對於每個Web服務調用，生成一個使用RSA的令牌，該令牌會在一段時間後改變（可配置爲30分鐘）。這種方式預測代碼被最小化。直到現在我還沒有聽說過RSA碰撞。將此令牌發回給用戶以進行瀏覽器會話。爲了進一步的安全性，我們可能想要附加一個會話ID與RSA令牌。由於會話ID是唯一的，所以新的匿名呼叫需要新的會話ID。

使用審計機制可以跟蹤調用。另外，每個Web服務還可以有不同的RSA設置。欺詐檢測算法如何工作本身就是一個挑戰。

對於授權用戶： 每個用戶都應該使用Header塊通過他的IP地址進行跟蹤。 RSA令牌原則可以應用。

該解決方案非常模糊，但值得考慮。

Answer 4

我會採取幾個步驟。

• 在網站上強制https。自動將任何傳入的http請求重定向到https請求（RequireHttps屬性對此非常方便）
• 每個頁面都需要（安全地，因此https）向客戶端發送一次性使用令牌，以用於頁面。運行在客戶端上的腳本可以將其保存在頁面內存中。任何返回的請求都會發送一個散列的&鹽味響應，以及nonce鹽。服務器可以使用保存的令牌+ salt和散列來重複這些步驟以確認請求。 （很像上面的explunit的回答） （值得注意的是，來自客戶端的安全請求沒有通過用戶帳戶進行認證，而僅僅是整頁發送的令牌。）
• 一次性定義可能會話或頁面加載，這取決於您的安全性vs便利性偏好。令牌應該很長並且相當快地過期以阻止攻擊者。

SSL +散列（令牌+隨機數）應該足以滿足您的需求。

Answer 5

這很有趣。下面是一個瘋狂的建議。請記住，你的問題也同樣瘋狂。

您的網站一旦通過瀏覽器打開，應該會生成一個長輪詢連接（Comet編程）。這將在瀏覽器和服務器之間創建一個唯一的會話。當ur JS正在進行ajax調用時，通過長輪詢線程向服務器發送一些令牌（每次都有唯一的令牌）。讓AJAX也發送相同的標記。在服務器上，獲取AJAX令牌並檢查您在長輪詢會話中是否有類似的令牌。如果是，請完成請求。任何編碼器都​​可以打破這一點。但是，這並不容易。機緣巧合的人甚至不會看到這些第二片彗星代碼。您可以通過不易察覺或理解的方式來實現慧星代碼。當他們撥打我們的服務時，發送'服務不可用'信息。他們會感到困惑。也使彗星代碼https。

您還可以檢查長輪詢線程開放多久。如果會話剛剛打開並且您立即得到ajax呼叫，則可以假定它是第三方呼叫。這取決於你的網站流量。如果在頁面加載1秒後發生了Ajax調用，則可以在服務器端檢查該模式。

任何編碼的公共API，將有1到2祕密檢查，他們甚至不知道即使他們知道，他們可能會被所有的額外編碼，他們所要做的氣餒。