對於不存在的REST資源，何時返回404以及何時返回403？

Question

我對這個邏輯很熟悉，如果你想使用用戶名和密碼對某人進行身份驗證，那麼無論用戶名是否被找到，或者密碼錯誤，你都應該返回相同的錯誤。這個想法是，如果你返回單獨的「用戶未找到」和「用戶發現，但密碼錯誤」錯誤，攻擊者可以嘗試所有用戶名，並找出哪些用戶名是有效的，然後將他們的字典攻擊集中在那些用戶名。

使用REST服務，我有一個只有特定用戶可以訪問的資源，我們稱之爲/foo/{id}。因此，有多種情況：

1. 用戶試圖訪問/foo/4，他們有機會，他們顯然得到了200響應和資源。

2. 用戶試圖訪問/foo/3並且它不存在。 （我不知道他們是否有權訪問它，因爲它不存在。認爲Facebook上不存在的照片，照片只有當它存在時才擁有所有權信息。）

3. A用戶嘗試訪問/foo/4，它存在，但他們沒有訪問權限。

所以我的問題是，什麼樣的返回代碼返回情況2和3？至於我可以看到有選項：

1. 返回404的情況下2，和403的情況下3.但是，這意味着攻擊者可以找出哪些對象存在，類似於密碼例如在第一例。

2. 對於所有示例，畢竟，從用戶的角度返回404，如果他們列出了他們有權訪問該資源的所有資源，則他們無權訪問的資源「不存在」不在列表中。

3. 返回403爲所有示例。

你會做什麼？這裏的標準是什麼？

Answer 1

這是什麼標準？

RFC 7231 6.5.3

一個希望「隱藏」禁止的目標資源的當前存在可能，而不是用的狀態代碼404（未找到）響應的原始服務器。

有趣的是，在HTTP/1.0，這是圍繞

轉身如果服務器不希望提供給客戶這些信息，狀態代碼403（禁止）可以用來代替。

你應該知道403和404有different default caching behavior。

OWASP: Exception Handling

在審查錯誤響應小心惡意用戶無法收集有關係統的任何潛在的敏感信息從狀態代碼返回。例如：採用租戶ID參數的API搜索，並返回無結果的HTTP 404響應，以及如果租戶ID不存在，則返回HTTP 500響應。攻擊者可能會利用此信息來確定租戶ID是否有效。一種解決方案是捕獲提供的租戶ID不存在時拋出的異常，並返回帶有錯誤響應的HTTP 404狀態碼。

請注意，狀態碼不是可被利用的響應的唯一部分;如果您要完成對齊狀態代碼的工作，則還應該確保消息正文和標題不會給任何東西帶走任何東西，the timing of the response不會讓節目脫穎而出，依此類推。

Answer 2

在我們的項目中，我們繼續進行選項之一：

404 - 如果資源的物理丟失

403 - 如果用戶沒有權限訪問

與ID猜測的問題被解決使用不透明的標識符，如GUIDs：

/foo/08490cee-c5a1-4ea5-a00e-1a488fd58044 

不可猜測的標識符是因爲否則攻擊者可以簡單地添加或減少ID號碼，甚至可以學習他們不應該知道的事情，例如創建了多少個實體對象。還要記住 - 數據庫主鍵可能仍然是整數。

除此之外，我不確定這裏是否有任何標準。您可以繼續使用適用於您業務領域的三種方法。

Answer 3

如果資源有一個所有者，或多個業主，這可能幫助：

如果資源確實存在，但用戶不應該被允許看到它，在內部把它想「資源確實存在 - 但不適合你！「，因此我會返回404.

正如你所說，小心你返回403的地方，因爲它可能會暴露內部元數據。