瀏覽器在Origin標

不發送FQDN在CORS的情況下，是有可能迫使瀏覽器總是與一個FQDN發送的Origin標？目標服務應該看到Origin: http://website.intranet.example.com/page.html而不是Origin: http://website/page.html。瀏覽器在Origin標

如示例所示，這是一個Intranet環境，目標是按子域過濾請求源，以允許域計算機上託管的任何頁面（*.intranet.example.com）向同時託管在該域中的服務發出跨源請求相同的域。問題（如果你願意的話）是Intranet站點通常被尋址爲http://website/，其餘部分由通過域策略設置的連接特定的DNS後綴暗示：intranet.example.com。

我能想到的唯一解決方法是要求所有「原始」頁面強制規範URL（即重定向//foo到//foo.intranet.example.com），而「醜陋URL」的副作用最小。

來源

2015-11-04 Serguei

在CORS背景下，而不是試圖獲得原產值短期和完全合格的域名一樣，你可以只專注於服務器是否應允許請求繼續或取消任何原始值是否存在：

假設要允許交叉源請求，響應服務器只需要用合適的Access-Control-Allow-Origin響應頭進行響應，則可以使用通配符值進行響應，以表示任何傳入源都可以：

Access-Control-Allow-Origin: *

如果您的客戶需要一個特定的域而不是通配符，如果您選擇允許請求繼續進行，無論Origin值如何表示，ld都會讓Web服務器回顯傳入的Origin標頭的值。

例如Apache中，使用SetEnvIf之後和頭模塊寫包含原點值的環境變量，如果該值相匹配的特定的正則表達式，然後如果該變量存在寫與環境變量的值的訪問控制允許來源響應頭：

SetEnvIf Origin "(.+)" origin_header_value=$1 
Header set Access-Control-Allow-Origin "%{origin_header_value}e" env=origin_header_value

如果需要在Web服務器中是否包含以這種方式訪問控制允許來源頭更細粒度的控制，可以只設置在SetEnvIf之後命令，而不是使用.+限制性更強的正則表達式。

來源

2015-11-04 06:58:53 user3417917

問題是'Origin：http：// server1 /'不明確。請求可能來自'server1.intranet.example.com'上的頁面，或者'server1'可能是某個局域網上的惡意機器;這適用於域用戶是遠程用戶並使用VPN或DirectAccess訪問Intranet的情況。 – Serguei

對於任何http請求，這可能都是真的，儘管聽起來您正在尋求基於Origin頭值的請求合法性，但這不是確定惡意請求的好方法 - 您可以使用設置的任何值他們。也許你可以添加對白名單的傳入IP地址的額外檢查？或者添加一些http授權，或者假設您可以確定請求通過VPN到達應該已經被允許？ - 這可能取決於其封閉或開放的內部網。 – user3417917

用戶導航到對http：// payroll.intranet.example.com/confidential進行AJAX調用的http：// evil-comp/page.html（非域服務器），然後將數據轉發到其他地方。一個合適的CORS策略將阻止'http：// evil-comp/page.html'看到響應的內容。 – Serguei

瀏覽器在Origin標

回答

相關問題