什么是CSP?

Content Security Policy (CSP)内容安全策略,是一个附加的安全层,有助于检测并缓解某些类型的攻击,包括跨站脚本(XSS)和数据注入攻击。

简单来说,csp就是为了减少xss,csrf等攻击的,是通过控制可信来源的方式,类似于同源策略…

CSP以白名单的机制对网站加载或执行的资源起作用。在网页中,这样的策略通过 HTTP 头信息或者 meta 元素定义。CSP虽然提供了强大的安全保护,但是他也造成了如下问题:Eval及相关函数被禁用、内嵌的JavaScript代码将不会执行、只能通过白名单来加载远程脚本。这些问题阻碍CSP的普及,如果要使用CSP技术保护自己的网站,开发者就不得不花费大量时间分离内嵌的JavaScript代码和做一些调整…

支持CSP的浏览器

Content Security Policy 最早在firefox 23中实现,当时使用的是 X-Content-Security-Policy,它使用了前置词的内容安全性策略,并以W3C CSP1.0规范作为标准

CSP主要有三个header,分别是:Content-Security-Policy,X-Content-Security-Policy,X-WebKit-CSP

  • Content-Security-Policy
    chrome 25+,Firefox 23+,Opera 19+
  • X-Content-Security-Policy
    Firefox 23+,IE10+
  • X-WebKit-CSP
    Chrome 25+

平时见的比较多的都是第一个Content Security Policy

CSP语法

这一部分的东西基本都是来自于w3c的文档

CSP的来源

我们经常见到的CSP都是类似于这样的:

header(
"Content-Security-Policy:default-src 'none';
connect-src 'self';
frame-src 'self';
script-src xxxx/js/ 'sha256-KcMxZjpVxhUhzZiwuZ82bc0vAhYbUJsxyCXODP5ulto=' '
sha256-u++5+hMvnsKeoBWohJxxO3U9yHQHZU+2damUA6wnikQ=' '
sha256-zArnh0kTjtEOVDnamfOrI8qSpoiZbXttc6LzqNno8MM=' '
sha256-3PB3EBmojhuJg8mStgxkyy3OEJYJ73ruOF7nRScYnxk=' '
sha256-bk9UfcsBy+DUFULLU6uX/sJa0q7O7B8Aal2VVl43aDs=';
font-src xxxx/fonts/ fonts.gstatic.com;
style-src xxxx/css/ fonts.googleapis.com;
img-src 'self'"
);

里面包括了各种各样的写法:

1、none和self,none代表什么都不匹配,self代表匹配同源的来源
2、类似于https://example.com/path/to/file.js这样的会匹配特殊的文件,或者https://example.com/这样会匹配源下的所有。
3、第三种是类似于https:,会匹配所有包含这个特殊的格式的来源。
4、也有可能是example.com这样的,会匹配所有这个host的来源,或者会有*.example.com,会匹配这个host的所有子域。
5、第五种是类似于nonce-qwertyu12345会匹配一个特殊的节点。
6、当然还有加密过的类似于sha256-abcd…同样会匹配页面中一个特殊的节点(每次修改这个值都会改变)。

在文档上能够找到一个详细的例子:

有个小问题是关于使用ip的

使用ip尽管符合上述语法,但是直接对ip地址的请求的安全性本身就是受到怀疑的,如果可以最好还是用域名。

CSP的属性

child-src

child-src指令管理了套嵌浏览的部分(类似于iframe、frame标签)

会匹配iframe和frame标签

connect-src

connect-src指令限制了可使用的脚本加载的url,会阻止a的ping属性,也控制着websocket的连接,有点难描述,举个例子。

这样的请求都会返回网络错误。

default-src

default-src作为所有其他指令的备用,一般来说default-src ‘none’; script-src ‘self’这样的情况就会是script-src遵循self,其他的都会使用none。(也就是说除了被设置的指令以外,其余指令都会被设置为default-src指令所设置的属性)

font-src

font-src指令限制了所有可以被加载的字体资源。

img-src

img-src指令限制着所有可以加载的图片资源的来源

manifest-src

manifest-src指令限制了从应用清单可以加载的url。

这个属性不太熟,比较常见的就是link

media-src

media-src指令限制令额所有从视频、音频、和相关的文本来源.

这个属性主要针对的是audio video以及连带的文本

object-src

object-src限制了所有从插件加载的来源.

不太熟的属性,好像是和flash相关的。

script-src

script-src指令限制了所有js脚本可以被执行的地方,不仅仅是包括通过链接方式加载的脚本url,同样包括所有内联脚本,甚至包括各种方式的引用。

还有个很重要的参数叫’unsafe-inline’
,如果加上这个参数,就不会阻止内联脚本,但这被认为是不安全的。

对于这个属性有个特殊的配置叫unsafe-eval,他会允许下面几个函数

style-src

style-src指令限制了所有可能被引用的css,包括下面三种引用的css属性,style也有个‘unsafe-inline’这个参数,同理会允许所有的内联css。

1、第一种是通过link标签加载的css,类似于<link href="001.css" type="text/css" rel="Stylesheet"/>

2、当然还有style标签

3、还有通过@import引入的样式表

4、内联样式表,类似于style="font-size:10px;font-color:#ff0000"

总的来说

CSP的检测方式是通过先判断特定的请求类型,然后通过下面的方式返回有效指令的名称,总的来说根据request类型的不同,会执行下面不同的步骤:

要读懂下面的算法,首先我们要知道什么是请求的发起者和

initiator:每个请求都有一个发起者,包括 “download”, “imageset”, “manifest”, or “xslt”.

destination:每个请求都有一个对应的目的地,包括 “document”, “embed”, “font”, “image”, “manifest”, “media”, “object”, “report”, “script”, “serviceworker”, “sharedworker”, “style”, “worker”, or “xslt”.

“”

1、If the request’s initiator is “fetch”, return connect-src.

2、If the request’s initiator is “manifest”, return manifest-src.

3、If the request’s destination is “subresource”, return connect-src.

4、If the request’s destination is “unknown”, return object-src.

5、If the request’s destination is “document” and the request’s target browsing context is a nested browsing context, return child-src.

“audio”

“track”

“video”

Return media-src.

“font”

Return font-src.

“image”

Return image-src.

“style”

Return style-src.

“script”

1、Switch on request’s destination, and execute the associated steps:

2、Return null.

基本上来说根据上面的文档,csp的意思已经能够理解了,那么怎么bypass csp呢

一个编写CSP的网站

http://cspisawesome.com/

Bypass CSP

基本上来说,CSP上容易存在的xss漏洞不多,除非你坚持使用‘unsafe-inline’,(多数情况来说,csp仍没有得到普及的原因就是因为大量的禁用内联脚本和eval这样的函数,导致如果配置不当,甚至网站都无法正常使用)否则来说,xss会被大幅度的减少,而bypass CSP更多来说是不容易被csp杀掉的csrf。

xxxx-src *

上面的那个*符号出现,表示,允许除了内联函数以外所有的url式的请求,那么bypass的方式比较简单,类似于src引用的方式,很容易造成csrf漏洞。

当然,如果熟悉了解CSP,一般来说不容易出现这样的情况,大部分来说会出现这种情况大多是下面这种情况。

范例

首先通过响应头信息看看CSP的构成,很容易发现问题

很容易发现问题frame-src *(当然为了支持W3C CSP标准,这里应该是child-src,测试环境就不乱改了),对于iframe的来源并没有做任何限制,当然实际环境可能需要iframe标签来内联来包含别的页面…

由于iframe的内联不同源,不无法通过任何方式get cookie,不存在xss漏洞(这也是大多开发者容易造成的想法),但是我们可以利用这种方式构造CSRF漏洞…

payload:(暂时拿www.baidu.com测试)

script-src unsafe-inline

在实际开发环境中,我们往往能够遇到这样的情况发生,明明开启了CSP,但是却对xss防护并没有任何帮助,就是上面这种情况的发生。

在真实的网站中,开发人员众多,在调试各个js文件的时候,往往会出现各种问题,为了尽快的修复bug,不得已加入大量的内联脚本,导致没办法简单的指定源来构造CSP,那么就会开启这个选项,殊不知,这样一来问题变得更严重了。

范例

首先我们看一下CSP设置

Content-Security-Policy
default-src 'none';
connect-src 'self';
frame-src *;
script-src http://xxx/js/ 'unsafe-inline';
font-src http://xxx/fonts/ fonts.gstatic.com;
style-src 'self' 'unsafe-inline';
img-src  'self'

重点是这一项

我们先尝试构造payload

可以明显的看到被拦了

但是我们尝试构造内联脚本

能看到成功执行

值得庆幸的是由于同源策略,这个请求不能发往别的域下,但是实战环境中利用方式很多,就比如这个聊天版,可以通过发给别的用户的方式get cookie

所以,安全性仍然应该被更多仔细考虑…

xxxx-src self

一般来说,self代表只接受符合同源策略的url,这样一来,大部分的xss和crsf都会失效,有个标签比较例外,虽然已经被加入的现在的csp草案中,但是的确还没有施行。

经过测试发现firefox在CSP规范的施行上还是走在前列,这种请求在firefox上会被拦截(除非同源),在公认安全性比较高的chrome确实存在

范例

当然首先我们先看看CSP的配置

Content-Security-Policy   default-src 'none';
connect-src 'self';
frame-src 'self';
script-src http://xxxx/js 'sha256-T32nlLrKkuMnyNpkJKR7kozfPzdcJi+Ql4gfcfl6PSM=';
font-src http://xxxx/fonts/ fonts.gstatic.com;
style-src 'self' 'unsafe-inline';
img-src 'self'

几乎可以说是滴水不漏了

然后我们刷新看,请求已经发出去了

当然是对外域的请求,如果站内有某种漏洞,可以通过这个构造csrf。测试环境下admin存在特殊的权限,可以添加管理员

如果构造

发给admin,就可以在不知情的情况下添加一个管理员

CSP滴水不漏 但存在内网文件上传点

不知道有多少人了解过cctf2016,其中有一道web题目IDS-Chicken

题目环境就符合我说的情况,CSP滴水不漏,几乎没办法用任何方式构造xss,但是内网存在上传点,上传文件会被重写为文件,link包含形成xss漏洞。

【XSS技巧拓展】————7、CSP浅析与简单的bypass相关推荐

  1. 【XSS技巧拓展】————15、Chrome 是怎么过滤反射型 XSS 的呢?

    XSS,即跨站脚本攻击,是Web程序中常见的漏洞,其原理是恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页面时,嵌入其中的Script代码会自动执行,从而达到恶意攻击用户的目的.为了防 ...

  2. 【XSS技巧拓展】————4、浅谈跨站脚本攻击与防御

    跨站脚本简称xss(cross-site scripting),利用方式主要是借助网站本身设计不严谨,导致执行用户提交的恶意js脚本,对网站自身造成危害.xss漏洞是web渗透测试中最常见而又使用最灵 ...

  3. 【XSS技巧拓展】————14、XSS攻击另类玩法

    今天就来讲一下大家都熟悉的 xss漏洞的攻击利用.相信大家对xss已经很熟悉了,但是很多安全人员的意识里 xss漏洞危害只有弹窗或者窃取cookie.但是xss还有更多的花式玩法,今天将介绍几种. 1 ...

  4. 【RPO技巧拓展】————3、IIS和.Net应用程序中的非根相对路径覆盖(RPO)

    在这篇博文中,我将向您展示一种更好的方法来利用ASP.NET Web窗体应用程序中的非根相对路径覆盖问题.这是一个低风险漏洞,可用于将资源(如样式表)甚至动态JavaScript注入受影响的网页. 介 ...

  5. 【JSONP技巧拓展】————2、JSONP 安全攻防技术

    关于 JSONP JSONP 全称是 JSON with Padding ,是基于 JSON 格式的为解决跨域请求资源而产生的解决方案.他实现的基本原理是利用了 HTML 里 <script&g ...

  6. 绕过html标签,巧妙绕过WAF的XSS技巧

    本文提出了一种绕过XSS安全机制的新型方法,这种技术由三个阶段组成:确定Payload结构.探测和混淆处理.首先,我们需要针对给定的上下文环境,确定各种不同的Payload结构以达到最优的测试效果.接 ...

  7. cad坐标归零lisp_「软件技巧」厉害了!输入简单命令轻松解决CAD几类常见问题...

    CAD作为工程作图最常用的软件,学会一些使用技巧和命令,有助于快速作图,提高工作效率.下面简单介绍几点快速绘图的技巧以及典型问题的解决办法. 1. 视口在布局中显示不全,新增一个视口,会自动消失一个. ...

  8. 【SQL注入技巧拓展】————13、我的WafBypass之道(SQL注入篇)

    0x00 前言 去年到现在就一直有人希望我出一篇关于WAF的文章,我觉得这种老生常 谈的话题也没什么可写的.很多人一遇到waf就发懵,不知如何是好,能搜到的各种姿势也是然并卵.但是积累姿势的过程也是迭 ...

  9. 一些你可能不知道的Flash XSS技巧

    mramydnei · 2014/02/19 10:16 0x00 前言 原文链接 soroush.secproject.com/blog/2013/1- soroush.secproject.com ...

最新文章

  1. 简易在线实验室管理系统
  2. PathMatchingResourcePatternResolver通过适配符寻找符合条件的java类
  3. jvm性能调优实战 - 32一个10万并发的BI系统,如何定位和解决频繁Young GC问题?
  4. 计算机网络安全六要素,六要素教学在计算机网络教学中的探索与反思
  5. mysql函数创建与使用_mysql function函数创建与应用方法
  6. 计算机丢失pcdsp.dll,计算机libcef.dll丢失
  7. 全面整理(随时更新)
  8. excel首行空不能导入access_终于解决SQL Server 2008 64位系统无法导入Access/Excel的问题 2012/08/01...
  9. c语言文件替换字符串,C语言替换字符串
  10. maven生命周期入门
  11. HTML5 input新增属性
  12. 阿里云云计算 40 CDN的概念
  13. 阿里云服务器安全组授权对象ip设置
  14. 使用VS2017生成的动态库时出现__acrt_iob_func链接错误
  15. java测试工程师培训,看这一篇就够了
  16. C#-MSDN学习提高
  17. c语言编译配置文件出错,Android4.4/CM11编译常见错误及解决方法!
  18. 亲测有效IEEE数据库论文免费下载
  19. python之bt种子,dht网络共享热门资源
  20. 前端面试题汇总CSS篇

热门文章

  1. 免费抽奖 | 《阿巴豆》探索未来系列盲盒数字版权作品全网首发!
  2. CTF 每日一题 Day24 世上无难事
  3. scrapy 爬取苏宁图书
  4. 一分钟了解Java Attach机制
  5. Web安全-检测-网页挂马
  6. Transformer主干网络——T2T-ViT保姆级解析
  7. 人才库 talent pool
  8. 精准营销:从“广”告到“窄”告
  9. 学习英语的历史性转折
  10. GEE(python)使用GPM降水数据进行趋势分析,MK检验等