CSRF的防御

服务器端的防范措施

　　（1）对于网站所有接受用户输入的内容进行严格的过滤。这条措施不止针对CSRF漏洞，而主要是减少XSS漏洞的可能性。而一个有XSS漏洞的网站，很难保证它对CSRF是安全的。这条措施是其它安全措施的基础。

　　（2）GET方法只用于从服务器端读取数据，POST方法用于向服务器端提交或者修改数据。仅使用POST方法提交和修改数据不能防范CSRF攻击，但是会增加攻击的难度。避免攻击者简单地使用< IMG >等标签就能通过GET方法进行CSRF攻击。

　　同时，这样做也符合RFC2616推荐的Web规范。

　　（3）在所有POST方法提交的数据中提供一个不可预测的参数，比如一个随机数。或者一个根据时间计算的HASH值。并且在Cookie中也同样保存这个参数。把这个参数嵌入标签保存在FORM表单中，当浏览器提交POST请求到服务器端时。从POST数据中取出这个参数并且和Cook.ie中的值做比较，如果两个值相等则认为请求有效，不相等则拒绝。根据同源策略和Cookie的安全策略，第三方网页是无法取得Cookie中的参数值的。所以它不能构造出相同随机参数的POST请求。

　　另外，为了保证一个用户同时打开多个表单页面。所有页面都能正常工作，在一次会话的有效期内。只使用同一个随机参数。也就是说，在会话初始化的时候生成一个随机参数，在以后的页面和Cookie中，都使用这个参数。直到会话结束，新的会话开始时，才生成新的参数，否则会只有用户最后一次打开的页面才能正常提交POST请求。多标签或多窗口浏览器会不能正常工作。

　　（4）在关键的服务器端远程调用动作之前，增加人机交互环节。例如CAPTCHA人机区分识别程序㈣（典型应用如图片验证码）。

　　（5）利用Cookie安全策略中的安全属性，但是不要完全依赖Cookie安全策略中的安全属性，只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。

　　（6）正确配置网站针对Flash的跨域策略文件。严格限制跨域、跨站的请求。

　　（7）限制验证cookie的到期时间。这些cookie的合法时间越短，黑客利用你的Web应用程序的机会就越小。不过，这个时间越短，用户就越不方便。因此，你需要在安全性和方便性之间进行平衡。

　　（8）执行重要业务之前，要求用户提交额外的信息。要求用户在进行重要业务前输入口令，这可以防止黑客发动CSRF攻击（只要浏览器中没有包含口令），因为这种重要信息无法预测或轻易获得。

客户端的防范措施

　　（1）保持浏览器更新，尤其是安全补丁，包括浏览器的Flash插件等的更新。同时也要留意操作系统、杀毒、防火墙等软件的更新。

　　（2）访问敏感网站（比如信用卡、网上银行等）后，主动清理历史记录、cookie记录、表单记录、密码记录，并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。

　　（3）推荐使用某些带有“隐私浏览”功能的浏览器，比如Safail。“隐私浏览”功能可以让用户在上网时不会留下任何痕迹。浏览器不会存储Cookie和其它任何资料。从而CSRF也拿不到有用的信息。IE 8把它叫做“InPfivate浏览”，Chrome称作“Incognito模式”

 

Web安全模型及其缺点

同源策略

介绍：

是浏览器中的主要安全措施
这里的“源”指的是主机名、协议和端口号的组合
简单地说就是要求动态内容（例如，JavaScript或者VBScript）只能阅读与之同源的那些HTTP应答和cookies，而不能阅 读来自不同源的内容。
假定我们在网页http://foo.com/bar/baz.html中放上了JavaScript代码。那么，这些JavaScript可以读/写一些页面，但是却不能读/写其他页面。

解释同源策略的最好的方法是实例说明。假定我们在网页http://foo.com/bar/baz.html中放上了JavaScript代码。那么，这些JavaScript可以读/写一些页面，但是却不能读/写其他页面。下表说明了来自http://foo.com/bar/baz.html的JavaScript可以访问哪些URL。
　　URL 能否访问这个URL 原因
　　http://foo.com/index.html
　　可以。
　　协议和主机名匹配。
　　端口没有显式说明。
　　该端口被假设为80。注意，两者的目录是不同的。这个目录是/而非/bar。
　　http://foo.com/cgi-bin/version2/webApp
　　可以。 协议和主机名匹配。
　　端口没有显式说明。
　　该端口被假设为80。注意目录的区别这里的目录是/cgi-bin/version2，而非上面的/bar。
　　http://foo.com:80/bar/baz.html 可以。 具有几乎相同的URL，HTTP协议匹配，端口是80(HTTP默认的端口)，主机名也一样。
　　https://foo.com/bar/baz.html
　　不可以。 协议不同，这里使用的协议是HTTPS。
　　http://www.foo.com/bar/baz.html
　　不可以。 两个主机名不同，这里的主机名是www.foo.com而不是foo.com。
　　http://foo.com:8080/bar/baz.html 不可以。 两个端口号不同。这里的端口是8080，而前面的端口被假定为80。

缺陷：

同源策略仅仅阻止了脚本读取来自其他站点的内容。但是却没有防止脚本向其他站点发出请求。因为CSRF攻击是由于某些请求被发出，而引起在服务器端执行了某些动作所引起的，所以同源策略无法防止CSRF攻击。

有限度的违反：

通过在被请求的页面中对JavaScript的变量document.domain进行相应设置，可以使浏览器有限度地违反同源策略，即，如果http://www.foo.com/bar/baz.html页面中含有下列内容：<script > document.domain = "foo.com"; </script >。

那么任何http://xyz【任何二级域名】.foo.com/anywhere.html（其document.domain设为foo.com）页面内的脚本都可以向http://www.foo.com/bar/baz.html发送HTTP请求，并可以读取其内容。（http://hi.baidu.com/gyreg/blog/item/7a2b59fdad47651e08244d7f.html）

 

Cookie的安全策略

服务器设置Cookie值并为Cookie设置安全属性。Cookie的安全属性包括了Domain、Path、Secure、Expires、MaxAge和HttpOnly等。Cookie安全策略类似于同源策略并且要比同源策略更安全一些，但是利用脚本，可以把Cookie的安全级别降低。甚至Cookie的path属性可以被完全绕过。如果一位攻击者可以突破或绕过两源策略的话，就可以通过DOM的变量document.cookie轻松读取Cookie。

 

Flash安全策略

默认时，Flash的安全策略与同源策略非常类似，来自于某个域的Flash应用只可以读取来自该域的响应。但是Flash的安全策略并不被同源策略限制。Adobe公司定义了F1ash的跨域策略，该策略通常定义在一个名为crossdomain.xml的策略文件中。该文件定义了哪些域可以和当前域通信。错误的配置文件可能导致兀ash突破同源策略。导致受到迸一步的攻击。安全研究人员曾经对500个顶级网站进行了分析。发现其中有143个站点使用了crossdomain.xml策略文件。而在这143个站点中。又有47个站点对来自第三方站点的连接完全接受，这可能导致CSRF漏洞。

http://security.ctocio.com.cn/tips/147/8728647.shtml

http://219.238.233.205/safe/computer/2011-04-20/9275.html
五大方法减少跨站请求伪造（CSRF）攻击