假設我將 url 路徑存盤在查詢引數中，例如/?return_back_to=/foo/bar
然后將其傳遞給像 Microsoft 這樣的外部身份驗證服務，該服務進行登錄并使用我的查詢引數回傳相同的 url。
此時，從查詢引數中獲取值并使用 React 重定向navigate()到此 url 是否安全？還是這被認為是“開放重定向漏洞”？
uj5u.com熱心網友回復：
從表面上看，只要遵循一堆最佳實踐并驗證查詢引數，就應該可以保存使用它，而不是“開放重定向漏洞”。
您提到使用 Microsoft auth 服務，我個人沒有太多經驗，但我已經使用了很多 firebase 和 google auth，我知道它們會自動檢查，如果重定向 URL 未列入白名單，它將無法正常作業。firebase 會自動將 localhost 和您的應用程式域添加到白名單，如果您有希望將用戶重定向到的外部鏈接，您可以添加更多。
來源 1：https ://support.google.com/firebase/answer/6400741?hl=en
來源 2：https ://support.google.com/firebase/answer/9021429?hl=en
就在用戶實際回傳您的應用時使用 react 是否安全而言navigate()，您應該確保根據本地白名單檢查 URL，或者在重定向用戶之前將您的應用域添加到 URL。
navigate({safeDomain} {query parameter})
雖然我應該提到，如果navigate()你指的是useNavigate()鉤子，我認為你不能使用它，你需要使用redirect().
緩解開放重定向漏洞的一些更有用的資訊
我希望這可以幫到你！
uj5u.com熱心網友回復：
這取決于誰在呼叫該端點。知名身份提供者將要求您設定允許的重定向 url，并且只會發回授權的（您設定的）。所以他們只會在沒問題的情況下呼叫回呼，這樣你就可以安全地重定向。
但是，其他任何人都可能使用帶有不同引數的此 url（指向它的鏈接），您不想導航到該引數，這將是一個開放重定向。因此，您需要確保請求實際上來自受信任的來源，即。來自 Azure AD。根據您實施的流程，您可以驗證收到的令牌以確保它是有效請求，或者至少您可以檢查 Origin / Referer 標頭以查看呼叫者是誰（無法更改Javascript 中的 Origin 或 Referer，因此攻擊者無法讓合法用戶訪問帶有惡意重定向的鏈接，其 Origin 來自 Microsoft）。
此外，如果您只在自己的來源（域）中重定向，您可以并且應該添加重定向路徑 ( return_back_to) 是內部的驗證，例如以 a 開頭/和/或不包含://.
uj5u.com熱心網友回復：
我不完全同意其他答案中所說的話。
實際上，使用此機制可能包含任何資訊的回傳 URL 會將這些資料暴露給各種攻擊。
舉個例子，如果回傳 url 例如用戶的儀表板，那么 url 可以是型別/users/<id or name of the user>
此外，所有這一切還取決于在您身邊實施的檢查。
假設攻擊者試圖使用您的 url 覆寫您的身份驗證服務合法回傳的 url：http://callback.url/?return_back_to=http://malicious.example.com
如果您沒有正確處理收到的資料，這將導致潛在的安全漏洞。
由于所有這些原因（以及許多其他原因），如果您認為您應該避免直接在 GET 或 POST 變數中傳遞和使用 Web（或檔案系統）路徑。
相反，您可以評估在將其傳遞給navigate().
另外，我不知道你是否這樣做，避免在 POST 和 GET 變數中傳遞任何數字 ID。而是生成一個字母數字的唯一 ID，以避免攻擊者預測 ID。
要了解有關 Web 安全的更多資訊，我建議學習 OWASP 十大規則：https ://owasp.org/www-project-top-ten/
這是構建安全 Web 應用程式的一個很好的切入點。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/511457.html