Http請求頭安全策略
今天在網上浪了許久,只是為了找一個很簡單的配置,卻奈何怎麼都找不到。
好不容易找到了,我覺得還是記錄下來的好,或許省得許多人像我一樣浪費時間。
1.X-Frame-Options
如果網站可以嵌入到IFRAME元素中,則攻擊者可以在社交場合設計一種情況,即受害者被指向攻擊者控制的網站,該網站構成目標網站的框架。然後攻擊者可以操縱受害者在目標網站上不知不覺地執行操作。即使有跨站點請求偽造保護,這種攻擊也是可能的,並且被稱為“clickjacking”,有關更多資訊,請參閱https://www.owasp.org/index.php/Clickjacking。為了避免這種情況,建立了“X-Frame-Options”標題。
通常的建議是將此標頭設定為“SAMEORIGIN”,它只允許屬於同源策略的資源構成受保護資源的框架,或者設定為“DENY”,它拒絕任何資源(本地或遠端)嘗試框架也提供“X-Frame-Options”標頭的資源。如下所示:
X-Frame-Options:SAMEORIGIN
請注意,“X-Frame-Options”標題已被棄用,將由內容安全策略中的Frame-Options指令替換,該指令仍處於活動開發階段。但是,“X-Frame-Options”標題目前具有更廣泛的支援,因此仍應實施安全措施。
說白了呢,就是讓你的網站禁止被巢狀。
其實也很簡單(我還在網上搜羅了半天)
配置檔案config
<httpProtocol> <customHeaders> <add name="X-Frame-Options" value="SAMEORIGIN" /> </customHeaders> </httpProtocol></system.webServer>
2.Content-Security-Policy
內容安全策略(CSP)旨在允許Web應用程式的所有者通知客戶端瀏覽器有關應用程式的預期行為(包括內容源,指令碼源,外掛型別和其他遠端資源),這允許瀏覽器更多智慧地執行安全約束。
下面的簡要示例顯示瞭如何使用CSP指定您的網站希望從任何URI載入影象,從受信任的媒體提供商(包括內容分發網路)列表中插入外掛內容,以及僅從您控制的伺服器載入指令碼:
Content-Security-Policy:default-src'self'; img-src *; object-src media1.example.com media2.example.com * .cdn.example.com; script-src trustedscripts.example.com
請注意,使用CSP的主要問題涉及策略錯誤配置(即使用“不安全內聯”),或使用過於寬鬆的策略,因此在實施CSP時應特別注意。
這個呢,是將你引入的一切,加一個限制,這樣如果別人想通過一些手段在你的網站加一些不好的東西,我們就可以有效地防止了
<httpProtocol> <customHeaders> <add name="Content-Security-Policy" value="script-src 'unsafe-inline' http://localhost:56504; object-src 'none'; style-src 'unsafe-inline' http://localhost:56504;" /> </customHeaders> </httpProtocol> </system.webServer>
其中預設值有以下這些:
none
不匹配任何東西。self
匹配當前域,但不包括子域。比如example.com
可以,api.example.com
則會匹配失敗。unsafe-inline
允許內嵌的指令碼及樣式。是的,沒看錯,對於頁面中內嵌的內容也是有相應限制規則的。unsafe-eval
允許通過字串動態建立的指令碼執行,比如eval
,setTimeout
等。
3.X-Content-Type-Options
一種稱為MIME型別混淆的漂亮攻擊是建立此標頭的原因。大多數瀏覽器採用稱為MIME嗅探的技術,其中包括對教育伺服器響應的內容型別進行教育猜測,而不是信任標頭的內容型別值。在某些情況下,瀏覽器可能會被欺騙做出錯誤的決定,允許攻擊者在受害者的瀏覽器上執行惡意程式碼。有關更多資訊,請參閱https://en.wikipedia.org/wiki/Content_sniffing。
“X-Content-Type-Options”可用於通過將此標頭的值設定為“nosniff”來防止發生這種“受過教育”的猜測,如下所示:
X-Content-Type-Options:nosniff
請注意,Internet Explorer,Chrome和Safari都支援此標題,但Firefox團隊仍在辯論它:https://bugzilla.mozilla.org/show_bug.cgi? id = 471020
<httpProtocol> <customHeaders> <add name="X-Content-Type-Options" value="nosniff" /> </customHeaders> </httpProtocol> </system.webServer>
4.X-XSS-Protection
現代瀏覽器包括一項有助於防止反映跨站點指令碼攻擊的功能,稱為XSS過濾器。“X-XSS-Protection”標頭可用於啟用或禁用此內建功能(目前僅在Internet Explorer,Chrome和Safari中支援此功能)。
建議的配置是將此標頭設定為以下值,這將啟用XSS保護並指示瀏覽器在從使用者輸入插入惡意指令碼時阻止響應,而不是清理:
X-XSS-Protection:1; mode = block。
如果沒有從伺服器傳送“X-XSS-Protection”標頭,Internet Explorer和Chrome將預設清理任何惡意資料。
請注意,X-XSS-Protection標頭已被棄用,將被內容安全策略中的Reflected-XSS指令取代,該指令仍處於活動開發階段。但是,“X-XSS-Protection”標題目前有更廣泛的支援,因此仍應實施安全措施。
0 – 關閉對瀏覽器的xss防護 1 – 開啟xss防護 1; mode=block – 開啟xss防護並通知瀏覽器阻止而不是過濾使用者注入的指令碼。 1; report=http://site.com/report – 這個只有chrome和webkit核心的瀏覽器支援,這種模式告訴瀏覽器當發現疑似xss攻擊的時候就將這部分資料post到指定地址。
配置方法
<httpProtocol> <customHeaders> <add name="X-XSS-Protection" value="1;mode=block" /> </customHeaders> </httpProtocol> </system.webServer>
這就是困擾了我許久,網上又找不到的幾個安全配置
文中介紹引自 : https://www.dionach.com/blog/an-overview-of-http-security-headers
如果大家想要更深入瞭解,這是我一下午找的資料
https://www.cnblogs.com/alisecurity/p/5924023.html
https://www.cnblogs.com/Wayou/p/intro_to_content_security_policy.html
https://www.cnblogs.com/doseoer/p/5676297.html
網址安全型檢測
https://tools.geekflare.com/report/xss-protection-test/http://hgwebsite.cn/
學習的道路是漫長的