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本質上是複雜的，如果沒有適當部署它可能會變得混亂，一個應用良好的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/

 

學習的道路是漫長的