您现在的位置是：网站首页> 内容页
Http请求头安全策略
- 欧亿手机客户端
- 2019-08-18
- 306人已阅读
今天在网上浪了许久，只是为了找一个很简单的配置，却奈何怎么都找不到。
好不容易找到了，我觉得还是记录下来的好，或许省得许多人像我一样浪费时间。
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/
学习的道路是漫长的