码迷,mamicode.com
首页 > 其他好文 > 详细

XSS防御策略

时间:2020-05-21 19:47:48      阅读:66      评论:0      收藏:0      [点我收藏+]

标签:sni   社交   uri   技术   scripts   serve   输入   tle   prot   

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

1
2
3
4
5
<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时应特别注意。

这个呢,是将你引入的一切,加一个限制,这样如果别人想通过一些手段在你的网站加一些不好的东西,我们就可以有效地防止了

1
2
3
4
5
6
<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 允许通过字符串动态创建的脚本执行,比如 evalsetTimeout 等。

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”标题目前有更广泛的支持,因此仍应实施安全措施。

1
2
3
4
0 – 关闭对浏览器的xss防护 
1 – 开启xss防护 
1; mode=block – 开启xss防护并通知浏览器阻止而不是过滤用户注入的脚本。 
1; report=http://site.com/report – 这个只有chrome和webkit内核的浏览器支持,这种模式告诉浏览器当发现疑似xss攻击的时候就将这部分数据post到指定地址。 

  

配置方法

1
2
3
4
5
6
<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/

XSS防御策略

标签:sni   社交   uri   技术   scripts   serve   输入   tle   prot   

原文地址:https://www.cnblogs.com/Mickey697/p/12932417.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
分享档案
周排行
mamicode.com排行更多图片
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!