CSRF 跨站请求伪造***
  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，而不能阅读来自不同源的内容，但是它对写操作没有任何限制。

同源：指的是同协议，同域名和同端口

可以通过被请求的页面中对JS的变量document.domain进行响应的设置，

可以使浏览器有限度地违反同源策略：
————————————————————————————————————————–
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的提取方法
打开你登录过的任意网站，输入：alert(document.cookie)< /p>
你就可以获取到你想要的用户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过大引起的拒绝服务***