如何控制對http請求的響應訪問？（服務器端和客戶端）

排除所有主流瀏覽器具有的同源策略以及同步標記模式（如果標記所有請求，這會是一種痛苦），您將如何檢查請求是否直接從我發送用戶界面，而不是通過第三方。例如，從iframe發送請求到youtube（我的意思是src = ...不是xmlhttprequest對象），響應將是一個空白頁面（他們是如何做的？），發送一個請求從一個iframe到facebook ajax.hovercard（它是一個簡單的獲取內容請求），地址欄也會給你一個空白頁面（沒有內容）。 SO響應是來自iframe請求的正常內容。如何控制對http請求的響應訪問？（服務器端和客戶端）

就像我之前說過的那樣，如果請求來自可信來源，您將如何檢查（最好是某些服務器端代碼）？

P.S. ：不要依賴標題，idk爲什麼起源im沒有從請求中接收，所以我看到他們都在所有主流瀏覽器中實現了origin標頭。參考人員可以通過一些間諜軟件程序進行修改。無論如何，標題不能真正被信任。但是，是的，showld是一個檢查層。

來源

2012-04-06 Cata Cata

請定義第三方。 ISP也不是第三方嗎？我的意思是你不擁有它，對吧？ – hakre 2012-04-06 09:50:57

@hakre我認爲這是顯而易見的這個問題是一個關於跨域請求... – 2012-04-06 10:00:37

檢查$_SERVER['HTTP_REFERER']並查看它是否來自您自己的網站。

來源

2012-04-06 09:36:53

ty爲您的迴應，我已經添加p.s. – 2012-04-06 09:39:35

您無法真正確定用戶的來源。用戶代理很容易被欺騙。我認爲你可以在你的用戶界面中創建一些csrf標記，並且只允許擁有這些標記的客戶端

來源

2012-04-06 09:41:21

是啊這就是我害怕的，無法找到任何其他的easyer解決方案 – 2012-04-06 09:42:42

csrf保護相對容易實現。爲每個用戶的會話創建一個令牌，將其存儲在一個cookie中，併爲每個用戶的操作（POST，GET）追加該令牌。如果在http請求中傳遞的令牌等於來自cookie的令牌，那麼用戶是合法的。當然，如果攻擊者知道你是如何創建令牌的，那麼這也可能是僞造的。 – 2012-04-06 09:45:37

同步器令牌模式不能僞造一個長而自由的令牌。並通過cookie我希望我的意思是會話變量。 – 2012-04-06 09:58:44

如何控制對http請求的響應訪問？ （服務器端和客戶端）

回答

相關問題

如何控制對http請求的響應訪問？（服務器端和客戶端）