浅谈csrf漏洞的测试方法
来源：本站转载
时间：2012-12-08 14:03:19
CSRF.指的是能够破坏其他正常用户的会话,或者是把其他用户的会话据为己有.
攻击过程：
受害者发起伪造请求，攻击者发送恶意代码，受害者在不知不觉中发送执行恶意代码的请求，服务器响应受害者的正当请求确认执行，至此CSRF攻击结束。
CSRF攻击的本质：强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求.
CSRF攻击特征：
1.用户请求修改信息——Web服务响应一张空白表单
2.用户修改信息并提交—-Web服务响应请求，保存
CSRF攻击直接跨越了第一步，直接修改数据….
攻击原理：
1.Get请求：隐式的通过http标签发出一个Get请求;
2.Post请求：通过Iframe能够设置界面大小为0的特性，加载页面自动执行，达到隐藏的目的；
登录式CSRF攻击：监听用户实际操作（这个不是很清楚，感觉就像钓鱼网站）；
Web2.0攻击：Web2.0虽然在一定程度上限制了CSRF攻击但是，通过脚本渗透漏洞，邮件或者上传文件攻击，也能达到攻击的目的
测试方法：
对于这类攻击,防范的办法是:session标记必须随机生成;禁止用户自主选择session标记;确认已有的session标记无法被二次使用;对会话进行时效限制,或者通过REFERER的域来识别是否一个标记登陆了多个用户等.其实就是杜绝标记被伪造和复用.
csrf
漏洞主要出现在http cookie被用于传送会话令牌的地方。一旦应用程序已经在用户的浏览器中设定一个cookie，他们的浏览器会自动在随后的每
个请求中将这个 cookie返回给应用程序。无论请求是源自应用程序提供的一个链接、从其他地方受到的一个url或者其他来源，他都会这样做。如果应用
程序并未采取防范 措施，防止令牌滥用，那么程序就易于受到csrf攻击。
对
于csrf的测试。首先，我们可以尝试查找出程序中的增删改功能的操作，可用于代表不知情的用户执行某种敏感操作，找到一项应用程序功能后，使用攻击者能
够提前决定的请求参数，也就是说，其中并不包含任何会话令牌或者其他无法预测的数据。然后创建一个html页面，他不需要进行任何用户交互即可提出想要的
请求。对于get请求，可以使用一个<img>标签，并通过src参数设置易受攻击的url；对于post请求，可以建立一个表单，其中包含
实施攻击所需要的全部相关参数的隐藏字段，并将其目标设为易受攻击的url。可以使用javascript在页面加载时自动提交该表
单 （document.formname.submit()）。
登录应用程序后，使用相同的浏览器加载专门设计的html页面，确认应用程序是否执行想要的操作。
防范思路：
1.form中添加秘密信息、用户代号验证等
2.双提交cookie：cookie在form post之前被JS读取，限制跨域规则将被应用。
这里就涉及到同源策略：
同源策略：要求动态内容只能阅读与之同源的Http应答和cookie，而不能阅读来自不同源的内容，但是它对写操作没有任何限制。
同源策略：要求动态内容只能阅读与之同源的Http应答和cookie，而不能阅读来自不同源的内容，但是它对写操作没有任何限制。
同源：指的是同协议，同域名和同端口
可以通过被请求的页面中对JS的变量document.domain进行响应的设置，
可以使浏览器有限度地违反同源策略：
—————————————————————————————————————————
举例：
如果http://www.foo.com/bar/baz.html页面中含有下列内容：
< script >
document.domain = “foo.com”;
< / script >
那么任何http://xyz.foo.com/anywhere.html页面内的脚本都可以向http://www.foo.com /bar /baz.html发送HTTP请求，并可以读取其内容。在此种情况下，如果攻击者能够向http: //xyz.foo.com /anywhere.html中注入HTML或JavaScript的话，那么他同时也能在http: //www.foo.com/bar/baz.html中注入JavaScript代码。
为此，攻击者需要首先在http://xyz.foo.com/anywhere.html（其document.domain设为foo.com）中 注 入HTML和JavaScript，并向http://www.foo.com/bar/baz.html（其document.domain也设 为 foo.com）中载入一个iframe，然后就可以通过JavaScript来访问该iframe的内容了。 例 如，http://xyz.foo.com/anywhere.html中的下列代码将在www.foo.com域中执行一个JavaScript 的 alert（）函数：
< iframe src=”http://www.foo.com/bar/baz.html”
onload=”frames[0].document.body.innerHTML+=’onerror=alert(1)’”>< / iframe >
这样，document.domain将允许攻击者跨域活动（域际旅行）。注意，你不能在document.domain变量中放入任何域名，相反，只 能 在document.domain变量中放置“源”页面即所在页面的域名的上级域名，如www.foo.com的上级域名是foo.com 。
< script >
document.domain = “foo.com”;
< / script >
那么任何http://xyz.foo.com/anywhere.html页面内的脚本都可以向http://www.foo.com /bar /baz.html发送HTTP请求，并可以读取其内容。在此种情况下，如果攻击者能够向http: //xyz.foo.com /anywhere.html中注入HTML或JavaScript的话，那么他同时也能在http: //www.foo.com/bar/baz.html中注入JavaScript代码。
为此，攻击者需要首先在http://xyz.foo.com/anywhere.html（其document.domain设为foo.com）中 注 入HTML和JavaScript，并向http://www.foo.com/bar/baz.html（其document.domain也设 为 foo.com）中载入一个iframe，然后就可以通过JavaScript来访问该iframe的内容了。 例 如，http://xyz.foo.com/anywhere.html中的下列代码将在www.foo.com域中执行一个JavaScript 的 alert（）函数：
< iframe src=”http://www.foo.com/bar/baz.html”
onload=”frames[0].document.body.innerHTML+=’onerror=alert(1)’”>< / iframe >
这样，document.domain将允许攻击者跨域活动（域际旅行）。注意，你不能在document.domain变量中放入任何域名，相反，只 能 在document.domain变量中放置“源”页面即所在页面的域名的上级域名，如www.foo.com的上级域名是foo.com 。
————————————————————————————————————————–
这里涉及到了域的概念（http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1），
set-cookie机制:
Set-Cookie: <name>=<value>[;<name>=<value>]...
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; httponly]
里面也有对域的访问设置，其中的path and domain可以设置.
其中的httponly是关于防止cookie通过js伪协议获取,强迫cookie过期
额，可以讲讲JS的cookie的提取方法
打开你登录过的任意网站，输入：javascript:alert(document.cookie)
你就可以获取到你想要的用户cookie信息了，再配合XSS攻击，能够做到非常多的事情
如何防范cookie被偷呢？
从IE6开始，微软就在他的浏览器上加入了HttpOnly Cookie的支持
cookie的安全，
就我所知有两种方法，一个就是从javax.servlet.http.Cookie派生，产生一个类对httponly进行设置
另外一种就是基于cookie的session机制，建议把所有的cookie读写，改成session读写
session的安全机制，主要是通过添加两个拦截器：日志、白名单…
其中taobao的轻量级安全框架Webx3就是这样做的…..
cookie机制里面有一个特性就是共享特性，在我理解就是在设置的域范围内可以共享这个cookie (不知道对不对)
同源策略虽然让Web的安全有了一定的提高但是在Web应用是极为不利的，
所以之后W3就提出了P3P概念：跨域访问cookie。
P3P：解决了Web应用上的难题，但是浏览器读取P3P头打开了第三方cookie的读取开关，带来了安全的隐患。这就要防止站外提交。
防止站外提交：判断Http头的Referer
但是Flash没有Referer头，这就要引申到Flash Security了，Flash的安全也是非常重要的可以说另外一个JS的安全隐患（从安全的威胁性来讲）
Flash Security：浏览器所贯彻的域安全策略被flash所打破，客户端所做的种种过滤也同样
被 flash所打破（只要你还使用flash）。但是flash也已经感觉到了这个问题，并且时时在改进，在设计上也引入了一些比较好的安全机制，恰当
的使 用这些安全机制可以避免你的应用程序遭到攻击。
应用程序安全设计的时候应该秉承最小化原则，在flash的大部分应用中，由于功能需求就经常需要跨域获取数据。
域安全是浏览器安全的基本策略，flash作为浏览器的扩展允许跨域获取数据就从根本上打破了浏览器的安全性
flash 在跨域时唯一的限制策略就是crossdomain.xml文件，该文件限制了flash是否可以跨域获取数据以及允许从什么地方跨域获取数据。
Discuz 论坛存在一个flash CSRF的Bug，由于Discuz!对flash跨域策略文件及上传图片文件处理不严导致可以绕过formhash及Referer的限制,导致csrf攻击.
这里稍微提一下Discuz的一类论坛的formhash技术，
formhash:类似于验证码，防止网站外部提交数据。
我们回到上面的CSRF攻击，额好像讲的差不多了，这里可以提一下JS的劫持技术
JS劫持技术:针对Json动态数据接口的攻击方式，也是一种变现的CSRF攻击
劫持技术还有DNS劫持技术、Dll劫持技术等等，额，原理也挺简单，不过这些跟CSRF不搭边，就不去讲了。
———————————————————————————————————–
防御原理：
上面讲了很多关于攻击啊，现在讲讲Webx3的CSRF防御原理
Webx3使用form service处理和验证表单，其中一点很重要的是要禁用GET请求，因为未使用form service来处理的表单将无法自动禁用GET请求。
注意，禁用GET提交表单，只能增加CSRF攻击的困难，但不能杜绝这种攻击。
下面讲一下它的CSRFToken校验的具体过程：
1.
通过一个pull tool实现在模板和session中生成CSRF Token，随机生成的csrfToken 会在session存在一个副本，以
便于校验，值得注意的是同一请求中csrfToken只会生成一遍，所以多次调 用$csrfToken.hiddenField将产生完全一样的结果；
2.通过pipeline value实现对比request和session中的csrfToken，注意仅在request中存在token时，才会对这个token进行验证，这样你是不是觉得很Bug，其实不然！如果不是这样，那么那些普通的、非表单提交的请求也会被拒绝。
3.
想到了吧，对，就是要校验request是否存在token，对于不存在csrfToken的提交表单中，会使用validator来验证，在 配置文件
中定义一个form service的validator验证request中是否存在csrfToken。当然每一个group中都要这么设置是非常麻
烦的，你可以定义一个公用的parent group 以后继承的每一个group都会自动生成validator验证。
对于不使用form service的还可以进行手工测试：
if(!CsrfToken.check(request)){
return;
}
CSRFToken只能使用一次，这样就防止了表单的刷新过后的重复提交
(在表单提交以后，网站进行一次外部重定向,即使用户点了浏览器上的“刷新”按钮，也不会产生重复提交表单)
然而，如果你利用cookie的session机制，把csrfToken保存到cookie中，只要让表单和cookie同时被提供给网站即可实现攻击
所以csrfToken必须保存在服务器端，Webx3的session机制可以扩展，你可以创建一个基于服务端存储的session store。
Webx3 CSRF token验证机制，默认最多支持8个表单同时开启，这个在多表单提交的时候很关键，
可以在pipeline里面进行设置，如果设置过小可能会冲掉前面的，会使表单提交失败。
这
里要顺便讲讲Http Header的安全，其实在前面的几个学习笔记中已经有提到了在RC中添加<basic />会自动生成一个
respone-header-security-filter的过滤器就能够防止CRLF Injection和Http Header过大引起的拒绝
服务攻击
没有评论:
发表评论