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/

学习的道路是漫长的