欢迎各位兄弟 发布技术文章

这里的技术是共享的

You are here

Content Security Policy 入门教程 里面有作者: 阮一峰 有大用 有大大用 有大大大用

下面是我自己亲自做的,不太理想(是关于爱丁堡的)

网页是 http://www.aaaaa.com 或 https://www.aaaaa.com

<meta http-equiv="Content-Security-Policy"

          content="upgrade-insecure-requests; //加上它的话,主网站不管是 http 还是 https,里面的所有都变成https,不好,

                不加上它的话,对于http://common.aaaaa.com/......js 的话,,又不行,说是什么违反script-src规则,哎 

          connect-src 'self' common.aaaaa.com  *.jiathis.com *.cnzz.com cnzz.mmstat.com pyt.zoosnet.net ; 

          default-src 'self' common.aaaaa.com *.jiathis.com *.cnzz.com cnzz.mmstat.com  pyt.zoosnet.net  *.map.qq.com; 

          img-src 'self' common.aaaaa.com *.jiathis.com *.cnzz.com cnzz.mmstat.com  pyt.zoosnet.net  *.map.qq.com;

          style-src 'self' common.aaaaa.com  *.jiathis.com *.cnzz.com cnzz.mmstat.com pyt.zoosnet.net  *.map.qq.com  'unsafe-inline' 'unsafe-eval';

          script-src 'self' common.adbxy.com *.jiathis.com *.cnzz.com cnzz.mmstat.com  pyt.zoosnet.net  *.map.qq.com 'unsafe-inline' 'unsafe-eval'">

由于上面的问题,所以我只好 把所有的 http://common.aaaaa.com   改成  //common.aaaaa.com 了,这样这会自适应(自适配) http://www.aaaaa.com  或 https://www.aaaaa.com 了


Content Security Policy 入门教程

               

作者: 阮一峰            

日期: 2016年9月13日            

跨域脚本攻击 XSS 是最常见、危害最大的网页安全漏洞。

           

为了防止它们,要采取很多编程措施,非常麻烦。很多人提出,能不能根本上解决问题,浏览器自动禁止外部注入恶意脚本?

这就是"网页安全政策"(Content Security Policy,缩写 CSP)的来历。本文详细介绍如何使用 CSP 防止 XSS 攻击。

           

一、简介

CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。它的实现和执行全部由浏览器完成,开发者只需提供配置。

CSP 大大增强了网页的安全性。攻击者即使发现了漏洞,也没法注入脚本,除非还控制了一台列入了白名单的可信主机。

两种方法可以启用 CSP。一种是通过 HTTP 头信息的Content-Security-Policy的字段。

           


Content-Security-Policy: script-src 'self'; object-src 'none';
style-src cdn.example.org third-party.org; child-src https:
           

另一种是通过网页的<meta>标签。


<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
           

上面代码中,CSP 做了如下配置。

  • 脚本:只信任当前域名

  • <object>标签:不信任任何URL,即不加载任何资源

  • 样式表:只信任cdn.example.orgthird-party.org

  • 框架(frame):必须使用HTTPS协议加载

  • 其他资源:没有限制

启用后,不符合 CSP 的外部资源就会被阻止加载。

Chrome 的报错信息。

           

Firefox 的报错信息。

           

二、限制选项

CSP 提供了很多限制选项,涉及安全的各个方面。

2.1 资源加载限制

以下选项限制各类资源的加载。

  • script-src:外部脚本

  • style-src:样式表

  • img-src:图像

  • media-src:媒体文件(音频和视频)

  • font-src:字体文件

  • object-src:插件(比如 Flash)

  • child-src:框架

  • frame-ancestors:嵌入的外部资源(比如<frame>、<iframe>、<embed>和<applet>)

  • connect-src:HTTP 连接(通过 XHR、WebSockets、EventSource等)

  • worker-srcworker脚本

  • manifest-src:manifest 文件

2.2 default-src

default-src用来设置上面各个选项的默认值。


Content-Security-Policy: default-src 'self'
           

上面代码限制所有的外部资源,都只能从当前域名加载。

如果同时设置某个单项限制(比如font-src)和default-src,前者会覆盖后者,即字体文件会采用font-src的值,其他资源依然采用default-src的值。

2.3 URL 限制

有时,网页会跟其他 URL 发生联系,这时也可以加以限制。

  • frame-ancestors:限制嵌入框架的网页

  • base-uri:限制<base#href>

  • form-action:限制<form#action>

2.4 其他限制

其他一些安全相关的功能,也放在了 CSP 里面。

  • block-all-mixed-content:HTTPS 网页不得加载 HTTP 资源(浏览器已经默认开启)

  • upgrade-insecure-requests:自动将网页上所有加载外部资源的 HTTP 链接换成 HTTPS 协议

  • plugin-types:限制可以使用的插件格式

  • sandbox:浏览器行为的限制,比如不能有弹出窗口等。

2.5 report-uri

有时,我们不仅希望防止 XSS,还希望记录此类行为。report-uri就用来告诉浏览器,应该把注入行为报告给哪个网址。


Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
           

上面代码指定,将注入行为报告给/my_amazing_csp_report_parser这个 URL。

浏览器会使用POST方法,发送一个JSON对象,下面是一个例子。


{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}
           

           

三、Content-Security-Policy-Report-Only

除了Content-Security-Policy,还有一个Content-Security-Policy-Report-Only字段,表示不执行限制选项,只是记录违反限制的行为。

它必须与report-uri选项配合使用。


Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
           

四、选项值

每个限制选项可以设置以下几种值,这些值就构成了白名单。

  • 主机名:example.orghttps://example.com:443

  • 路径名:example.org/resources/js/

  • 通配符:*.example.org*://*.example.com:*(表示任意协议、任意子域名、任意端口)

  • 协议名:https:data:

  • 关键字'self':当前域名,需要加引号

  • 关键字'none':禁止加载任何外部资源,需要加引号

多个值也可以并列,用空格分隔。


Content-Security-Policy: script-src 'self' https://apis.google.com
           

如果同一个限制选项使用多次,只有第一次会生效。


# 错误的写法
script-src https://host1.com; script-src https://host2.com

# 正确的写法
script-src https://host1.com https://host2.com
           

如果不设置某个限制选项,就是默认允许任何值。

五、script-src 的特殊值

除了常规值,script-src还可以设置一些特殊值。注意,下面这些值都必须放在单引号里面。

  • 'unsafe-inline':允许执行页面内嵌的&lt;script>标签和事件监听函数

  • 'unsafe-eval':允许将字符串当作代码执行,比如使用evalsetTimeoutsetIntervalFunction等函数。

  • 'nonce值':每次HTTP回应给出一个授权token,页面内嵌脚本必须有这个token,才会执行

  • 'hash':列出允许执行的脚本代码的Hash值,页面内嵌脚本的哈希值只有吻合的情况下,才能执行。

nonce值的例子如下,服务器发送网页的时候,告诉浏览器一个随机生成的token。


Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
           

页面内嵌脚本,必须有这个token才能执行。


<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>
  // some code
</script>
           

hash值的例子如下,服务器给出一个允许执行的代码的hash值。


Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
           

下面的代码就会允许执行,因为hash值相符。


<script>alert('Hello, world.');</script>
           

注意,计算hash值的时候,<script>标签不算在内。

除了script-src选项,nonce值和hash值还可以用在style-src选项,控制页面内嵌的样式表。

六、注意点

(1)script-srcobject-src是必设的,除非设置了default-src

因为攻击者只要能注入脚本,其他限制都可以规避。而object-src必设是因为 Flash 里面可以执行外部脚本。

(2)script-src不能使用unsafe-inline关键字(除非伴随一个nonce值),也不能允许设置data:URL。

下面是两个恶意攻击的例子。


<img src="x" onerror="evil()">
<script src="data:text/javascript,evil()"></script>
           

(3)必须特别注意 JSONP 的回调函数。


<script
src="/path/jsonp?callback=alert(document.domain)//">
</script>
           

上面的代码中,虽然加载的脚本来自当前域名,但是通过改写回调函数,攻击者依然可以执行恶意代码。

七、参考链接

(完)

广告(购买广告位)    

网络书签分享平台            

="倾城之链"        

未来世界的幸存者            

未来世界的幸存者        

留言(24条)

                       

感谢教学。

                       

关于web安全,这个repo也可以看一下,https://github.com/FallibleInc/security-guide-for-developers

                       

有收获,http信息头的作用还是很大的~~~

                       

峰哥,
网络上传播的你们阿里安全部门的员工因为使用脚本盗刷月饼被开除的事件,是真的吗?

                       

学习了,这个低版本的浏览器不一定支持的吧

                       

请问真正用到 Web 开发中,需要怎么做?还是说,大部分 Web 框架已经内置了这些功能,不需要开发者担心?如果可以的话,麻烦讲一讲各大 Web 框架都是怎么处理这些问题的?

                       

从百度点进来的,支持一下,希望站长您多出一些好文章。

                       

我们也用到了移动端 屏蔽运营商广告注入,还是很赞的。

                       

我们也用到了移动端 屏蔽运营商广告注入,还是很赞的。

                       

有一点疑惑,望释疑。如果设置了HSTS,还有必要CSP么?

                       

内容安全策略 !== 网页安全政策

                       

IE10 和 IE11 根本就不支持,這個就是半套而已

                       

感谢阮老师又出干货了

                       

文章通俗易懂,感谢阮老师。

                       

「2.1 资源加载限制」部分的 frame-ancestors 应该是 frame-src 吧。

                       

我有个疑问如果web server配置了csp,html文件中也用meta配置了csp,但是配置的value是不同的,这会是什么结果

                       

引用白色风车的发言:
                       

我有个疑问如果web server配置了csp,html文件中也用meta配置了csp,但是配置的value是不同的,这会是什么结果

做了个小实验,在Chrome和Safari中,最终生效的CSP安全策略是权限范围最小的那个,与CSP来自HTTP response header还是meta http-equiv无关。

                       

引用xgqfrms的发言:
                       

内容安全策略 !== 网页安全政策

内容安全策略是网页安全策略的子集

                       

"(2)script-src不能使用unsafe-inline关键字(除非伴随一个nonce值),也不能允许设置data:URL。"

这一点好像是错的。根据“https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Security-Policy/script-src”的资料,是说如果设置了 'nonce' 就会忽略 'unsafe-inline',并不是 'unsafe-inline' 需要伴随着 'nonce'。

                       

大佬,我被一个CSP的问题困住了,求帮助;
客户提出要修复CSP的问题,我就设定了:script-src 'self' 'unsafe-eval' 'unsafe-inline';
客户说不能用'unsafe-inline',要用nonce;
我就修改为script-src 'self' 'unsafe-eval' 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa';
这样OK,但是出现一个新的问题,JSP上面的监听事件全部都报错,例如:onload,onchange,onblur.....;
除了以下2种办法外,有没有其他办法来解决?
1. 添加回'unsafe-inline'
2. document.getElementById("userId").addEventListener('focus', chgOnFocusBgColor(this)); -- > 这个修改量太大了

                       

引用闪闪的星的发言:
                       

"(2)script-src不能使用unsafe-inline关键字(除非伴随一个nonce值),也不能允许设置data:URL。"

这一点好像是错的。根据“https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Security-Policy/script-src”的资料,是说如果设置了 'nonce' 就会忽略 'unsafe-inline',并不是 'unsafe-inline' 需要伴随着 'nonce'。

没错,chrome 测试,添加了nonce, 会忽略'unsafe-inline'

                       

http是透明的,技术上营运商不是可以将这个http头部字段删除吗?

                       

如果是NGINX服务设置了csp头,http的meta标签也设置了csp,两个内容不一样,以哪个为准呀

                       

在https上的iframe里,如果加载http,浏览器会报关于“混合内容”的错误。如果设置csp default-src '*',那可以绕过这个限制吗?

我要发表看法


来自  http://www.ruanyifeng.com/blog/2016/09/csp.html


Content-Security-Policy的实战应用

       
1                字数 1,874阅读 36,115            


今天在浏览微信页面的时候,发现他的script标签上都有个once属性,好奇之下查阅了一番,发现这个属性是和一个http header Content-Security-Policy有关,这个header不看不知道,一看吓一跳啊,一把利器啊

1. 同源限制

首先我们要知道web浏览器为了安全都有会同源限制,什么是同源限制?就是来自 https://mybank.com 的代码应仅能访问 https://mybank.com 的数据,而绝不被允许访问 https://evil.example.com。同源政策的目的,是为了保证用户信息的安全,防止恶意的网站窃取数据,比如cookie/locaStoragy/IndexDB就遵守同源限制。XMLHettpRequest也是存在同源限制,相信只要开发过web的同学在ajax获取数据时都遇到过这个问题。

同源限制可以一定程度上限制我们的用户信息不会被盗取,但是却没法防止我们的页面被插入不法分子的资源(js,img,css等),毕竟页面上带src的元素资源是不受同源限制的。这些页面上的牛皮鲜让人很讨厌,影响是极其恶劣的:会让我们的js监控误报、会影响用户体验、甚至隐私泄露,所以我们需要对src资源也作出一定的限制,这就得Content-Security-Policy来了

2. Content-Security-Policy(内容安全政策,下文简称为CSP)

  • 主要作用

了解一样东西,我们首先的知道他有啥用,没用不是浪费时间么,毕竟大家都在假装生活很忙的样子,作用呢主要有两点:

  1. 使用白名单的方式告诉客户端(浏览器)允许加载和不允许加载的资源。

  2. 向服务器举报这种强贴牛皮鲜广告的行为,以便做出更加针对性的措施予以绝杀。

  • 怎么用

我们知道了好处还是很犀利的啊,这么好的东西怎么玩?其实也很简单,前面说到了他其实就是一个http header嘛,所以我们只需要在返回html页面的同时加上个response header 就行了,后面的script-src代表是一个指令,指示浏览器你只能加载我屁股后面那些规则下的js代码,其他的都一律拒绝。

Content-Security-Policy: script-src 'self' https://apis.google.com
   

你还可以通过元标记的方式使用:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
   
  • 指令

前面说到script-src是一个指令,那就说明还有其他的指令罗,没有错,下面的都是指令,覆盖了web页面的所有资源

base-uri: 用于限制可在页面的 <base> 元素中显示的网址。
child-src: 用于列出适用于工作线程和嵌入的帧内容的网址。例如:child-src https://youtube.com 将启用来自 YouTube(而非其他来源)的嵌入视频。 使用此指令替代已弃用的 frame-src 指令。
connect-src: 用于限制可(通过 XHR、WebSockets 和 EventSource)连接的来源。
font-src: 用于指定可提供网页字体的来源。Google 的网页字体可通过 font-src https://themes.googleusercontent.com 启用。
form-action: 用于列出可从 <form> 标记提交的有效端点。
frame-ancestors: 用于指定可嵌入当前页面的来源。此指令适用于 <frame>、<iframe>、<embed> 和 <applet> 标记。此指令不能在 <meta> 标记中使用,并仅适用于非 HTML 资源。
frame-src: 已弃用。请改用 child-src。
img-src: 用于定义可从中加载图像的来源。
media-src: 用于限制允许传输视频和音频的来源。
object-src: 可对 Flash 和其他插件进行控制。
plugin-types: 用于限制页面可以调用的插件种类。
report-uri: 用于指定在违反内容安全政策时浏览器向其发送报告的网址。此指令不能用于 <meta> 标记,这就是举报电话
style-src: 是 script-src 版的样式表。
upgrade-insecure-requests: 指示 User Agent 将 HTTP 更改为 HTTPS,重写网址架构。 该指令适用于具有大量旧网址(需要重写)的网站。

这么多指令都要写?写起来不是很麻烦,不是的。你只需要写自己要求限制的指令就行,没写的都会默认没有限制。

你还可以通过指定一个 default-src 指令替换大部分指令的默认行为,也就说如果你写了default-src 指令,那其他没写的指令都会服从default-src 的规则。

  • 规则

规则主要是罗列一些你信任的域名,除此之外还有四个关键词:

none 表示不执行任何匹配。
self'表示与当前来源(而不是其子域)匹配。
unsafe-inline表示允许使用内联 JavaScript 和 CSS。
unsafe-eval 表示允许使用类似 eval 的 text-to-JavaScript 机制。

  • nonce属性

讲了这么多那和我一开始发现的那个script标签上的nonce属性有啥关系呢?首先说明不存在不正当*关系。主要是现代浏览器认为内联css和内联js都是应该被视为危险的行为,但是你总不能因为菜刀能杀人就不让百姓用菜刀了吧,所以开个口子吧。如果你在使用CSP策略的同时有确实需要使用内联css和js怎么办?用nonce+随机数的方式

<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>
  //Some inline code I cant remove yet, but need to asap.
</script>
   

然后我们在CSP的白名单中加上

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
   

这样你这段内联js就可以生效了

补充说明

CSP 1 在 Chrome、Safari 和 Firefox 中非常实用,但在 IE 10 中仅得到非常有限的支持。 您可以 在 canisue.com 上查看具体信息。CSP Level 2 在 Chrome 40 及更高版本中可用。 Twitter 和 Facebook 等大量网站已部署此标头(Twitter 的案例研究值得一读),并为您开始在自己的网站上进行部署制定了相应标准。

实战效果

我们加上CSP头部后,开启csp上报功能后发现,10分钟上报了几千条,这被强奸的厉害啊,所以加上这个头部就显得更加有必要了

遇到的坑

在应用CSP后,有用户反映访问我们的站点出现问题,我们发现用户获取到的meta头乱了,而且在里面发现了一个不是我们写的域名:local.adguard.com,一查发现adguard是款 vpn软件,他对我们meta头部进行修改,修改就算了,还修改错了。后面我们改成response header的方式,不使用meta了,发现他也会修改http的response header,但是没修改错,垃圾VPN害死人啊

今天发现有个CDN劫持相关的议题也挺有意思的

具体内容可以看这篇知乎回答,里面提到一个关键词SRI

参考文章:

同源限制 - 阮一峰
内容安全政策 - Google    


来自  https://www.jianshu.com/p/a8b769e7d4bd


Content Security Policy介绍


本文介绍的是W3C的 Content Security Policy,简称CSP。顾名思义,这个规范与内容安全有关,主要是用来定义页面可以加载哪些资源,减少XSS的发生。

Chrome扩展已经引入了CSP,通过manifest.json中的content_security_policy字段来定义。一些现代浏览器也支持通过响应头来定义CSP。下面我们主要介绍如何通过响应头来使用CSP,Chrome扩展中CSP的使用可以参考Chrome官方文档

浏览器兼容性

早期的Chrome是通过X-WebKit-CSP响应头来支持CSP的,而firefox和IE则支持X-Content-Security-Policy,Chrome25和Firefox23开始支持标准的的Content-Security-Policy,见下表。

响应头ChromeFirefoxSafariIE
Content-Security-Policy25+23+--
X-Content-Security-Policy-4.0+-10.0(有限的)
X-Webkit-CSP14+-6+-

完整的浏览器CSP支持情况请移步CanIUse

如何使用

要使用CSP,只需要服务端输出类似这样的响应头就行了:

 
Content-Security-Policy: default-src 'self'                                            

default-src是CSP指令,多个指令之间用英文分号分割;'self'是指令值,多个指令值用英文空格分割。目前,有这些CSP指令:

指令指令值示例说明
default-src'self' cnd.a.com

定义针对所有类型(js、image、css、web font,ajax请求,iframe,多媒体等)资源的默认加载策略,某类型资源如果没有单独定义策略,就使用默认的。

script-src'self' js.a.com定义针对JavaScript的加载策略。
style-src'self' css.a.com定义针对样式的加载策略。
img-src'self' img.a.com定义针对图片的加载策略。
connect-src'self'

针对Ajax、WebSocket等请求的加载策略。不允许的情况下,浏览器会模拟一个状态为400的响应。

font-srcfont.a.com针对Web Font的加载策略。
object-src'self'针对<object>、<embed>或<applet>等标签引入的flash等插件的加载策略。
media-srcmedia.a.com针对<audio>或<video>等标签引入的html多媒体的加载策略。
frame-src'self'针对frame的加载策略。
sandboxallow-forms

对请求的资源启用sandbox(类似于iframe的sandbox属性)。

report-uri/report-uri

告诉浏览器如果请求的资源不被策略允许时,往哪个地址提交日志信息。

特别的:如果只想让浏览器汇报日志,而不阻止任何内容。可以改用Content-Security-Policy-Report-Only响应头。

指令值可以由下面这些内容组成:

指令值指令示例说明
*img-src *允许任何内容。
'none'img-src 'none'不允许任何内容。
'self'img-src 'self'允许来自相同来源的内容(相同的协议、域名和端口)。
dataimg-src data允许data:协议(例如base64编码的图片)。
www.a.com                            img-src img.a.com允许加载指定域名的资源。
*.a.com                            img-src *.a.com允许加载a.com任何子域的资源。
https://img.com                            img-src https://img.com允许加载img.com的https资源(协议需匹配)。
https:img-src https:允许加载https资源。
'unsafe-inline'script-src 'unsafe-inline'

允许加载inline资源(例如常见的style属性,onclick,inline js和inline css等等)。

'unsafe-eval'script-src 'unsafe-eval'允许加载动态js代码,例如eval()。

从上面的介绍可以看到,CSP协议可以控制的内容非常多。而且如果不特别指定'unsafe-inline'时,页面上所有inline的样式和脚本都不会执行;不特别指定'unsafe-eval',页面上不允许使用new Function,setTimeout,eval等方式执行动态代码。在限制了页面资源来源之后,被XSS的风险确实小不少。

当然,仅仅依靠CSP来防范XSS是远远不够的,不支持全部浏览器是它的硬伤。不过,鉴于低廉的开发成本,加上也没什么坏处。如果担心影响面太大,也可以像下面这样,仅收集不匹配规则的日志,先观察下:

 
Content-Security-Policy-Report-Only: script-src 'self' ; report-uri http: //test/                                            

这样,如果页面上有inline的JS,依然会执行,只是浏览器会向指定地址发送一个post请求,包含这样的信息:

 
{ "csp-report" :{ "document-uri" : "http://test/test.php" , "referrer" : "" , "violated-directive" : "script-src 'self'" , "original-policy" : "script-src 'self'; report-uri http://test/" , "blocked-uri" : "" }}                                            

CSP先介绍到这里。现代浏览器支持不少与安全有关的响应头,以后接着再介绍。


来自  https://blog.csdn.net/usoa/article/details/52460842



前端安全配置之Content-Security-Policy(csp)

2016-12-23 18:14  紫日残月  阅读(50458)  评论(0)  编辑  收藏

 

什么是CSP

CSP全称Content Security Policy ,可以直接翻译为内容安全策略,说白了,就是为了页面内容安全而制定的一系列防护策略. 通过CSP所约束的的规责指定可信的内容来源(这里的内容可以指脚本、图片、iframe、font、style等等可能的远程的资源)。通过CSP协定,让WEB处于一个安全的运行环境中。

有什么用?

我们知道前端有个很著名的”同源策略”,简而言之,就是说一个页面的资源只能从与之同源的服务器获取,而不允许跨域获取.这样可以避免页面被注入恶意代码,影响安全.但是这个策略是个双刃剑,挡住恶意代码的同时也限制了前端的灵活性,那有没有一种方法既可以让我们可以跨域获取资源,又能防止恶意代码呢?

答案是当然有了,这就是csp,通过csp我们可以制定一系列的策略,从而只允许我们页面向我们允许的域名发起跨域请求,而不符合我们策略的恶意攻击则被挡在门外.从而实现

需要说明的一点是,目前主流的浏览器都已支持csp.所以我们可以放心大胆的用了.

指令说明

指令就是csp中用来定义策略的基本单位,我们可以使用单个或者多个指令来组合作用,功能防护我们的网站.

以下是常用的指令说明:

指令名

demo

说明

default-src

'self' cdn.example.com

默认策略,可以应用于js文件/图片/css/ajax请求等所有访问

script-src

'self' js.example.com

定义js文件的过滤策略

style-src

'self' css.example.com

定义css文件的过滤策略

img-src

'self' img.example.com

定义图片文件的过滤策略

connect-src

'self'

定义请求连接文件的过滤策略

font-src

font.example.com

定义字体文件的过滤策略

object-src

'self'

定义页面插件的过滤策略,如 <object>, <embed> 或者<applet>等元素

media-src

media.example.com

定义媒体的过滤策略,如 HTML6的 <audio>, <video>等元素

frame-src

'self'

定义加载子frmae的策略

sandbox

allow-forms allow-scripts

沙盒模式,会阻止页面弹窗/js执行等,你可以通过添加allow-forms allow-same-origin allow-scripts allow-popups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, and allow-top-navigation 策略来放开相应的操作

report-uri

/some-report-uri


 

指令值

所有以-src结尾的指令都可以用一下的值来定义过滤规则,多个规则之间可以用空格来隔开

demo

说明

*

img-src *

允许任意地址的url,但是不包括 blob: filesystem: schemes.

'none'

object-src 'none'

所有地址的咨询都不允许加载

'self'

script-src 'self'

同源策略,即允许同域名同端口下,同协议下的请求

data:

img-src 'self' data:

允许通过data来请求咨询 (比如用Base64 编码过的图片).

domain.example.com                        

img-src domain.example.com

允许特性的域名请求资源

*.example.com                        

img-src *.example.com

允许从 example.com下的任意子域名加载资源

https://cdn.com                        

img-src https://cdn.com

仅仅允许通过https协议来从指定域名下加载资源

https:

img-src https:

只允许通过https协议加载资源

'unsafe-inline'

script-src 'unsafe-inline'

允许行内代码执行

'unsafe-eval'

script-src 'unsafe-eval'

允许不安全的动态代码执行,比如 JavaScript的 eval()方法

 

示例

default-src 'self';   

只允许同源下的资源

 

script-src 'self';     

只允许同源下的js

 

script-src 'self' www.google-analytics.com ajax.googleapis.com;

允许同源以及两个地址下的js加载

 

default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

多个资源时,后面的会覆盖前面的

 

服务器端配置

  • Apache服务

在VirtualHost的httpd.conf文件或者.htaccess文件中加入以下代码

Header set Content-Security-Policy "default-src 'self';"

  • Nginx

在 server {}对象块中添加如下代码

add_header Content-Security-Policy "default-src 'self';";

  • IIS 

web.config:中添加

<system.webServer>

  <httpProtocol>

    <customHeaders>

      <add name="Content-Security-Policy" value="default-src 'self';" />

    </customHeaders>

  </httpProtocol>

</system.webServer>

 

参考链接:

https://www.zhihu.com/question/21979782        

https://content-security-policy.com/


来自  https://www.cnblogs.com/heyuqing/p/6215761.html



cordova错误之: Refused to connect to XXX -- because it violates the following Content Security Policy..


 

Refused to connect to 'http://localhost:8545/' because it violates the following Content Security Policy directive: "default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.

(anonymous) @ chunk-vendors.8e02e518.js:33
app.f97599e1.js:1 Error during service worker registration: DOMException
error @ app.f97599e1.js:1
2chunk-vendors.8e02e518.js:33 Uncaught (in promise) Error: invalid response - 0
    at XMLHttpRequest.a.onreadystatechange (chunk-vendors.8e02e518.js:33)


解决办法:            

错误提示中,已经说是违反了Content Security Policy指令,            

因为在Content Security Policy中,没有配置对应的部分,那么会默认使用default-src指令,而default-src指令中没有设置我们发送请求url设置,因此拒绝访问。

如果要设置允许请求数据的话,则需要设置Content-Security-Policy的connect-src *,意思是可以请求到任何的url,如下所示:

  1. <meta http-equiv="Content-Security-Policy"                        
  2. content="connect-src *; default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *; img-src 'self' data: content:;">
           


只要是配置了connect-src指令,则不会使用默认指令default-src。
 

解决办法参考链接:https://blog.csdn.net/michael_ouyang/article/details/50757456            

meta标签官网:https://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/meta            

Content Security Policy官网:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Security-Policy__by_cnvoid            



来自  https://blog.csdn.net/weixin_43343144/article/details/89212324




获取“拒绝应用内联样式,因为它违反了以下内容安全策略”错误(Getting “refused to apply inline style because it violates the following content security policy” error)    

 1553   IT屋    

百度翻译此文   有道翻译此文                    
                           
                               

I am getting the below error while running the application

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/ 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=' 'sha256-5uIP+HBVRu0WW8ep6d6+YVfhgkl0AcIabZrBS5JJAzs='". Either the 'unsafe-inline' keyword, a hash ('sha256-4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq/s1Kn4/KQ='), or a nonce ('nonce-...') is required to enable inline execution.

Below is the code currently I am using

What I have tried:

                           

const string modernizrHash1 = "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=";
const string modernizrHash2 = "sha256-5uIP+HBVRu0WW8ep6d6+YVfhgkl0AcIabZrBS5JJAzs=";
app.UseCsp(options => options
.DefaultSources(s => s.Self())
.ScriptSources(s => s.Self().CustomSources("https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/"))
.StyleSources(s => s.Self().CustomSources("https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/", modernizrHash1, modernizrHash2))
.FontSources(s => s.Self().CustomSources("https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/fonts/"))
.ImageSources(s => s.Self().CustomSources("data:"))
);
                           
解决方案
It looks like this may be Modernizr not getting along with the sites Content-Security-Policy. Seems to me that you are not the only one experiencing this:

Modernizr Causes Content Security Policy (CSP) Violation Errors · Issue #1450 · Modernizr/Modernizr · GitHub[^]

Possible workaround
Content Security Policy restrictions workaround by termi · Pull Request #1263 · Modernizr/Modernizr · GitHub[^]

More on CSP
Content Security Policy (CSP) - HTTP | MDN[^]

                           
Quote:
Either the 'unsafe-inline' keyword, a hash ('sha256-4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq/s1Kn4/KQ='), or a nonce ('nonce-...') is required to enable inline execution.

Neither of the two hashes you've added to your CSP match the inline <style> content you're trying to load.

Generate a hash for the inline stylesheet, and add it to your CSP.

Report URI: CSP Hash Generator[^]

                           


                           

运行应用程序时出现以下错误



拒绝应用内联样式,因为它违反了以下内容安全策略指令:"style-src'self 'https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/'sha256-47DEQpj8HBSa + / TImW + 5JCeuQeRkm5NMpJWZG3hSuFU =''sha256-5uIP + HBVRu0WW8ep6d6 + YVfhgkl0AcIabZrBS5JJAzs ='"。可以使用'unsafe-inline'关键字,散列('sha256-4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq / s1Kn4 / KQ =')或nonce('nonce -...')来启用内联执行。



以下是我目前正在使用的代码



我的尝试:



                           

 const string modernizrHash1 ="sha256-47DEQpj8HBSa + / TImW + 5JCeuQeRkm5NMpJWZG3hSuFU ="; 
const string modernizrHash2 ="sha256-5uIP + HBVRu0WW8ep6d6 + YVfhgkl0AcIabZrBS5JJAzs =";
app.UseCsp(options => options
.DefaultSources(s => s.Self())
.ScriptSources(s => s.Self()。CustomSources(" https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/"))
.StyleSources(s => s.Self()。CustomSources("https://cdnjs.cloudflare .com / ajax / libs / font-awesome / 4.7.0 / css /",modernizrHash1,modernizrHash2))
.FontSources(s => s.Self()。CustomSources("https:// cdnjs。 cloudflare.com/ajax/libs/font-awesome/4.7.0/fonts/"))
.ImageSources(s => s.Self()。CustomSources("data:"))
);
                           
解决方案
Ad by Valueimpression
看起来这可能是Modernizr不与网站Content-Security-Policy相处。在我看来,你不是唯一一个遇到这个问题的人:



Modernizr导致内容安全策略(CSP)违规错误·问题#1450·Modernizr / Modernizr·GitHub [ ^ ]



可能的解决方法

内容安全政策限制由termi解决方案·Pull Request#1263·Modernizr / Modernizr·GitHub [ ^ ]



更多关于CSP

内容安全策略(CSP) - HTTP | MDN [<a href="https://www.it1352.com/%22https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP/%22" target="\"_blank\"" title="\"New" window\"="" style="box-sizing: border-box; background-color: transparent; color: rgb(47, 164, 231); text-decoration-line: none;"> ^ ]

                           
Quote:
'unsafe-inline'关键字,一个哈希值('sha256-4Su6mBWzEIFnH4pAGMOuaeBrstwJN4Z3pq / s1Kn4 / KQ =')或nonce('nonce -...')是启用内联执行所必需的。


您添加到CSP的两个哈希值都不符合您尝试加载的内联< style> 内容。



为内联样式表生成一个哈希值,并将其添加到您的CSP中。



报告URI:CSP哈希生成器 [ ^ ]


来自   https://www.it1352.com/1078696.html

普通分类: