如果$ _SERVER ['HTTP_REFERER']不可靠，我將使用什麼來確保Web應用程序的完整性？

我以爲我真的很光滑，通過使用$_SERVER['HTTP_REFERER']變量來保證我的腳本被從適當的頁面調用。

幸運的是，當我在我的測試瀏覽器中執行header('Location: yourPathHere.php')重定向時，它不會設置$_SERVER['HTTP_REFERER']變量。所以，我看着它在http://php.net/manual/en/reserved.variables.server.php，才發現這...

「HTTP_REFERER」

頁（如有的話）稱爲用戶代理當前頁面的地址。這由用戶代理設置。並非所有的用戶代理都會設置此功能，並且有些功能提供將HTTP_REFERER作爲功能進行修改的功能。總之，它不能真正被信任。

所以我的問題是：我怎樣才能保證我的頁面被導航到來自可信來源？

編輯：澄清有關評論部分的問題。我試圖避免XSRF（跨站請求僞造）。

來源

2011-04-21 Zak

+10

您不能。你怕什麼呢？ – SLaks 2011-04-21 14:17:27

簡而言之，XSS（跨站腳本）。 – Zak 2011-04-21 14:20:04

@Zak：XSS如何與「我的訪客從哪裏來」相關？我感到困惑，請詳細說明。 – Piskvor 2011-04-21 14:21:08

依賴任何用戶發起的請求驗證輸入幾乎沒有比沒有驗證更好。

您應該閱讀維基百科的這個section on CSRF countermeasures以獲取解決問題的可用方法的基本概述。

簡而言之：

網站都提供各種CSRF對策：

需要在所有的表單提交和副作用URL的祕密，用戶特定的令牌防止CSRF;攻擊者的網站不能把正確的令牌在其提交
要求客戶在用於執行涉及安全問題（匯款等）
限制會話cookie
確保沒有crossdomain.xml文件授予意外訪問Flash影片

來源

2011-04-21 14:59:18

這正是我所尋找的，我只是不知道如何表達它。謝謝！ – Zak 2011-04-21 15:07:34

轉介網頁是否也在您的控制之下？如果是這樣，你可以嘗試設置一些服務器端會話變量，當用戶訪問頁面A，並檢查他們，當他試圖訪問頁面B. 但像其他響應者所說 - 這與預防XSS無關。

來源

2011-04-21 14:37:43 harelguy

你是對的，我的意思是說XSRF（跨站請求僞造）。我對這種混亂表示歉意。 – Zak 2011-04-21 14:58:05

如果$ _SERVER ['HTTP_REFERER']不可靠，我將使用什麼來確保Web應用程序的完整性？

回答

相關問題