标签:sni 社交 uri 技术 scripts serve 输入 tle prot
如果网站可以嵌入到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> |
内容安全策略(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
允许通过字符串动态创建的脚本执行,比如 eval
,setTimeout
等。一种称为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>
现代浏览器包括一项有助于防止反映跨站点脚本攻击的功能,称为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/
标签:sni 社交 uri 技术 scripts serve 输入 tle prot
原文地址:https://www.cnblogs.com/Mickey697/p/12932417.html