HTTPSecurity
时间：2023-03-27 23:37:08
HTML
HTTPSecurityHTTPCSP3旨在降低内容注入攻击的风险，包括：1）文档中嵌入的资源（worker/iframe）2）内联脚本3）动态脚本（eval）4）内联样式提供了以下能力controlembeddingWhichsources(origin)可以被资源使用提供报告机制Directives指令相关的执行检查时机：Pre-requestcheckPost-requestcheckInlinecheckInitializationPre-navigationcheckNavigationresponsecheck可配置的SourceList关键字none和self（只匹配Originof当前URL)URL（例如：https://example.com/path/to/f...，具体文件；https://example.com/，Origin下的所有资源）协议（例如：https:)域名（例如：example.com,*.example.com）随机数（例如：nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA，匹配页面上的特定元素例如：)摘要（例如：sha256-abcd，匹配页面上的特定元素：例如)PolicyDelivery可以在HTTP返回标头Content-Security-Policy或元元素http-中声明页面上的equiv属性声明Content-Security-Policy-Report-Only响应头允许开发者收集页面上的策略违规报告，但该响应头不支持在meta标记上配置。支持元标记配置。例如：但是Content-Ssecurity-Policy-Report-Only、report-uri、frame-ancestors和sandbox也不支持如何捕获和报告违规行为。发生违规时，将在元素或窗口上触发SecurityPolicyViolationEvent事件。js可以通过以下代码实现catchif('SecurityPolicyViolationEvent'inwindow){//检查浏览器是否支持window.addEventListener('securitypolicyviolation',function(e){console.log(e.violatedDirective,e.originalPolicy);});}alldirectivesFetchDirectiveschild-src可以控制iframe,frame和worker请求加载connect-src可以控制fetch(),xhr,eventsource,beacon,atag,websocket请求加载default-src可以作为其他fetch的默认值directivesfont-src可以控制字体资源请求加载frame-src可以控制iframe，frame请求加载img-src控制图片请求加载manifest-src控制manifest请求加载media-src控制视频、音频、曲目等请求加载object-src控件嵌入，对象请求加载prefetch-srcscript-src不仅控制脚本元素的请求加载，还包括：内联脚本块，除非没有设置script-src或default-src以“unsafe-inline”或nonce-source、hash-sourceeval()、Function()、setTimeout和setInterval的第一个参数不是函数，除非script-src或default-src设置为“unsafe-eval”类似javascript:url必须所有的脚本请求和脚本块都由script-src控制inlinecheckscript-src-elem;然而，像
这样的内联事件处理程序是由script-src-attr处理控制的script-src-attr控制类似元素上的内联事件处理程序style-src主要控制以下points：所有样式请求，包括样式元素，@import内联样式块，除非style-src或default-src没有设置为“unsafe-inline”或nonce-source，hash-source修改style的cssText等insertRule方法，除非script-src或default-src设置为“unsafe-eval”style-src-elem控制样式元素，但不包含元素style-src-attr控制元素上的内联样式是worker-src上的内联样式控制Worker、ShareWorker和ServiceWorker请求加载DocumentDirectivesbase-url控制base元素上的url并设置沙箱，使页面上的iframe具有相同的沙箱属性。NavigationDirectivesform-action控制表单的提交路径。frame-ancestors可以控制资源是否可以放在frame、iframe、object、embed等元素加载显示这个命令类似于X-Frame-Options响应头函数，frame-ancestorsX-Frame-Options表示noneDENY禁止在frame、iframe等元素上加载和显示自己的SAMEORIGIN，只有同源的唯一区别是X-Frame-Options的SAMEORIGIN只会匹配顶级页面的URL；而frame-ancestors将检查frame、iframe、object、embed的所有祖先元素；而frame-ancestors会覆盖X-Frame-Optionsnavigate-to来控制整个页面的跳转，包括a,form,window.loacation,window.open等ReportingDirectivesreport-to可以设置上报地址（不过，它感觉使用捕获SecurityPolicyViolationEvent的方法更可控。）CSP规则的继承所有iframe在加载时都会复制一份CSP规则，所以iframe无法绕过CSP的安全策略HSTS（Strict-Transport-Security）背景虽然目前大多数网站都支持https，仍然不代表绝对安全。其中一种场景是当浏览器和服务器建立链接时，会先发起http请求（如果没有使用httpsurl），然后重定向到https的url，发起http的过程到redirecthttps会很容易受到中间人攻击，所以这里有一个方法可以避免这个问题：Strict-Transport-Security响应头可以强制浏览器和服务器从一开始就创建一个https链接而不是重定向http请求后https，所以对服务器的第一次请求成功建立了https链接，并收到了Strict-Transport-Security响应头；那么浏览器下次请求服务器的时候会直接发起一个https请求，但是HSTS的方式还有一个漏洞就是必须和服务器进行通信首先建立第一个https链接（可以从http重定向到https）middle)，这意味着攻击者仍然有机会利用它，Google在这里维护了一个HSTS预加载服务，只要在它上面提交成功，域名就会被硬编码到浏览器中。浏览器第一次对这些域名发起请求时，会直接跳转到https；但这是一个硬编码的配置，意味着它只有在chrome更新版本后才会生效，只能作为一种补充手段。之前一直有个错误的想法，HSTS会记录网站的证书，在建立链接的时候对比（忘了网站的证书也会更新，所以没意义）一些安全相关的响应头X-Content-Type-Options因为浏览器存在内容嗅探行为，只要没有设置Content-Type或者Content-Type设置的类型与实际内容不匹配，这种行为就会尝试猜测实际内容内容;而X-Content-Type-Options会禁止这种嗅探行为，让浏览器根据Content-Type设置的类型来解释内容，如果script/style请求返回的内容不是JavaScriptMIME类型或者text/css，这些请求也会被拦截X-Frame-Options可以控制页面上frame、iframe、embed和object元素的加载，有效避免点击劫持等攻击。tokenHttpOnly可以限制通过document.cookie直接获取cookie，防止xss攻击窃取tokenSameSite可以控制在跨站请求中可以传输哪些cookie（限制第三方cookie），可以抵抗csrf攻击。目前Chrome默认SameSite=Lax什么是跨站请教？首先我们要明白同域和同站点的区别，因为两者很容易混淆同域：两个来源的scheme+host+port完全一样站点：全名一个网站的域名是eTLD+1，eTLD是一个有效的TLD，TLD（顶级域名）是.com和.org，eTLD就像.co.jp或.github.io，这些域名是在公共领域定义的后缀列表；eTLD+1是eTLD加上前面的部分。例如：www.taobao.com和www.baidu.com是跨站www.a.taobao.com和www.b.taobao.com是同站a.github.io和b.github.io是跨站-site(注意是跨站)那么在浏览器中如何判断一个请求是否为跨站请求是根据请求的目标站点和发起请求的站点是否在同一个站点，否则这是一个跨站点请求。例如使用
提交给exampleB.com是不允许携带exampleB.com上设置的sameSitecookie的server，我们还是可以通过HTTP请求头Sec-Fetch-Site来判断请求的来源（浏览器支持率不是很高），Sec-Fetch-Site有以下属性值cross-site，same-site,same-origin,noneSameSite不同属性值的区别：如果SameSite的属性值为“Strict”，则只允许Sendcookiesonsame-siterequests；如果属性值为“Lax”，那么除了在同站请求、跨站导航（“跨站”顶级导航）和请求方法为GET时发送cookie也会发送发送cookie如果属性值为“无”，则必须设置Secure属性同时生效，因为相当于去掉了SameSite的保护，所以一定要保证没有https链接环境中的中间人攻击。什么是顶级导航，例如：来自exampleA。com点击a标签跳转至exampleB.com，那么说明在“Lax”条件下，仍然可能存在漏洞。在攻击者的网站上，可以：使用链接跳转使用使用会触发成功的同站请求。SameSite在ShareWorker和ServiceWorker环境下的作用：首先，确定worker的当前站点。因为ShareWorker可以绑定多个文档，所以它计算当前的“siteforcookies”计算方法是：1)将worker_site设置为worker注册的域2)遍历worker绑定的文档列表，如果文档列表中有与worker_site不匹配的文档站点，则返回空字符串3)否则，返回worker_siteServiceWorker，返回worker注册的域，根据计算出的站点，与请求的来源进行比较，判断是跨站请求还是同站请求，然后应用SameSiteajax中的withCredentials属性request以及samesitesamesite控制的跨站请求是否可以传输cookie。withCredentials控制跨站请求。cookies可以在域请求中传输吗？当一个请求既是跨域又是跨站请求时，cookie会先受samesite属性影响，再受ajax中的withCredentials影响。SameParty由于SameSite对第三方cookies的限制太多，在某些业务场景下很难实现（比如登录淘宝后，应该可以和天猫共享登录信息，所以需要第三方-partycookietoshare)First-PartySetspolicy首先，我们有一个策略，将不同的站点标记为同一方站点，这样标记为SameParty的cookie在这些站点之间传输是合理的。如何定义第一方集？比如有brandx.site、fly-brandx.site、drive-brandx.site；brandx.site作为顶级域名，必须定义/.well-known/first-party-set路径下的内容：{"owner":"brandx.site","version":1,"members":["fly-brandx.site","drive-brandx.site"]}和fly-brandx.site,drive-brandx.site也在https://fly-brandx.site/.well...,https://德里ve-brandx.site/.we...定义{"owner":"brandx.site"}，那么他们之间的关系就可以明确判断了。First-PartySets政策如何影响cookie？如果在brandx.sitecookie中设置如下：Set-Cookie:session=123;安全的;SameSite=松散；SameParty现在从fly-brandx.site跳转到brandx.site会自动带上这个cookie（没有SameParty还是会被限制）但是注意：SameParty必须和Secure一起设置。SameParty不能与SameSite=Strict同时设置。CORS和CSRF可以通过Access-Control-Allow-Origin设置来限制跨域请求（很多时候为了方便设置成“*”，其实是很危险的）Access-Control-Allow-Methods限制了可以跨域使用的请求方法。Access-Control-Allow-Credentials限制是否允许跨域携带cookies。本质上我们是不信任跨域请求的，因为我们不确定是不是csrf攻击。可以对跨域请求进行限制。参考HTTP状态管理机制SameSite同站同源区别CORSSameParty关于cookiesamesite和xHrwithCredentials的思考
