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><br></system.webServer><br>

2.Content-Security-Policy

內容安全策略（CSP）旨在容許Web應用程序的全部者通知客戶端瀏覽器有關應用程序的預期行爲（包括內容源，腳本源，插件類型和其餘遠程資源），這容許瀏覽器更多智能地執行安全約束。雖然CSP本質上是複雜的，若是沒有適當部署它可能會變得混亂，一個應用良好的CSP能夠大大下降利用大多數形式的跨站點腳本攻擊的機會。

須要整個帖子來深刻了解CSP容許的功能和不一樣設置，所以建議進一步閱讀。如下是Mozilla開發者網絡對CSP的精彩介紹性帖子：https：//developer.mozilla.org/en-US/docs/Web/Security/CSP

下面的簡要示例顯示瞭如何使用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/