谨慎能捕千秋蝉(二)——CSRF

简介:

CSRF(Cross Site Request Forgery)跨站点请求伪造。

CSRF的本质是当重要操作的参数都能被攻击者预测到,才能成功伪造请求。

一、场景演示

下图是一个伪造请求的场景,按顺序来看;

1、2是正常登陆并产生Cookie,3、4是在登陆后访问骇客的网站并发请求,5是服务器执行骇客发出的请求。

这个场景的关键就是带上Cookie伪造请求。

1)浏览器中的Cookie

浏览器有“Session Cookie”(临时Cookie)和“Third-party Cookie”(本地Cookie);

前者浏览器关闭后就失效了,后者指定了Expire时间,只有超过了时间才会失效。

默认会拦截“Third-party Cookie”的有IE6、IE7、IE8、Safari;

不会拦截的有Firefox、Opera、Chrome等,我就验证了Firefox、Chrome、以及IE8。

2)验证浏览器的支持

设计两个域名“www.normal.net”(正常的网站)和“www.csrf.net”(伪造的网站)

1. 访问“www.normal.net/cookie.php”页面,在cookie.php中设置Cookie,用PHP代码实现。

<?php
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 接着访问“www.csrf.net/csrf.html”,在csrf页面中添加了一个iframe,通过iframe访问normal网站。

<iframe src="http://www.normal.net"></iframe>

3. 查看用iframe访问normal网站中的请求头信息,Cookie只有IE8会拦截,接下来会说明一种绕过拦截的方法。

Firefox

Chrome

IE8

 

3)P3P头

P3P头(Platform for Privacy Preferences Project)隐私偏好项目平台,通过加这个头,可以让IE不拦截第三方Cookie。

不过IE11以及Microsoft Edge将不在支持P3P头。

1. 还是用PHP来实现,与上面的不同之处用加红区分。

<?php
    header("P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR");
    setcookie("cookie1",'session');
    setcookie("cookie2",'third',time()+3600*24);

2. 请求“www.normal.net/cookie.php”页面,响应头中有下面一句话。

3. 在iframe中访问normal网站的请求头中出现了两个Cookie。

4)GET或POST请求

HTML中能够设置src/href的标签都可以发起一个GET请求,例如上面的攻击通过iframe的src属性发起的。

<link href=""/>
<img src=""/>
<meta http-equiv="refresh" content="0; url="/><!--HTML重定向-->
<script src=""></script>
<a href=""></a>
<video src=""></video>
<audio src=""></audio>
...

攻击者还可以通过伪造表单来执行POST请求,例如在一张页面中布置好输入框、选择框等标签,通过JavaScript自动提交。

 

二、CSRF的危害

1)篡改目标网站上的用户数据

2)盗取用户隐私数据

3)作为其他攻击的辅助手法

4)传播CSRF蠕虫

例如某个社交网站爆出的漏洞,让某个用户查看恶意页面后,给他所有好友发送短信,短信中又包含了这个恶意页面;

好友点击的话,又会给他的好友发送短信,这样就开始了传播,受感染的人也将越来越多。

CSRF蠕虫的原理和XSS蠕虫基本类似,但也略有不同:

1. CSRF的攻击代码存在于攻击者页面中,目标网站传播的内容都包含攻击者页面的URL。还有前提,目标用户登录了目标网站,之后的传播需要带上目标用户的“Session Cookie”。

2. XSS的攻击代码存在于目标页面中,即使是Script从攻击域上引进来的,对JavaScript上下文来说,也属于目标网站。

 

三、CSRF的防御

1)验证码

CSRF的过程,往往是在用户不知情的请求下发起了网络请求;

而加了验证码,就让用户必须与应用进行交互,才能完成最终请求,能够遏制CSRF的攻击。

但是加了验证码后,在用户体验上面会大打折扣,所以要因地制宜。

2)Referer Check

Referer Check常用于“防止图片盗链”,同理,也可以检查请求是否来自合法的“源”。

但Referer Check有缺陷,服务器并非任何时候都能取到Referer,例如HTTPS跳转到HTTP,就不会发送。

3)Anti CSRF Token

在每个请求中增加一个Token参数,这个Token是个随机数,为用户和服务器共同持有,不能被第三者知晓。

Token可放在用户的Session或Cookie中,为了使用方便,还可设置一个生命周期

在提交请求的时候,服务器只需验证表单中的Token和Session(或Cookie)中的Token是否一致即可遏制CSRF攻击。

但在XSS的攻击下,Token会无效,因为XSS可以模拟客户端浏览器执行任意操作,那就可以读取出Token,再构造一个合法的请求,这个过程称为XSRF

 

demo代码下载:

http://download.csdn.net/download/loneleaf1/9746890

 

参考资料:

zenphoto csrf 攻陷

用P3P header解决iframe跨域访问cookie[各种语言]



本文转自 咖啡机(K.F.J) 博客园博客,原文链接:http://www.cnblogs.com/strick/p/6364097.html   ,如需转载请自行联系原作者

相关文章
|
安全 测试技术
网站CSRF跨站漏洞修复方案
CSRF通俗来讲就是跨站伪造请求攻击,英文Cross-Site Request Forgery,在近几年的网站安全威胁排列中排前三,跨站攻击利用的是网站的用户在登陆的状态下,在用户不知不觉的情况下执行恶意代码以及执行网站的权限操作,CSRF窃取不了用户的数据,只能执行用户能操作的一些数据。比如在用户不知道的情况下, 把账户里的金额,以及银行卡号,体现功能,都转移到其他人账户里去。如果被攻击者是一个管理员的权限,那么就会对网站安全构成严重的危害。
1071 0
网站CSRF跨站漏洞修复方案
|
7月前
|
安全 PHP 开发者
CSRF 攻击的防范措施
CSRF 攻击的防范措施
|
8月前
|
安全 中间件 数据安全/隐私保护
网站如何防止CSRF攻击?这几个方法教你管用!
网站如何防止CSRF攻击?这几个方法教你管用!
121 0
|
8月前
|
安全 中间件 数据安全/隐私保护
Django中防范CSRF跨站点请求伪造攻击
Django中防范CSRF跨站点请求伪造攻击
|
存储 JSON 安全
别再用 JWT 作为 Session 系统了,问题重重,后果很危险!
别再用 JWT 作为 Session 系统了,问题重重,后果很危险!
244 0
别再用 JWT 作为 Session 系统了,问题重重,后果很危险!
|
前端开发 安全 JavaScript
防止CSRF攻击与针对CSRF方法接口测试的调整
防止CSRF攻击与针对CSRF方法接口测试的调整
153 0
防止CSRF攻击与针对CSRF方法接口测试的调整
|
供应链 安全 IDE
Http4s 存在输入验证不当漏洞(CVE-2023-22465)
Http4s 存在输入验证不当漏洞(CVE-2023-22465)
Http4s 存在输入验证不当漏洞(CVE-2023-22465)
|
安全 网络协议 JavaScript
如何测试CSRF
前言 阅读本文之前如果不了解什么是csrf,请先看一个视频: https://v.qq.com/x/page/c0877u4a1ei.html 为什么要谈这个漏洞?这种漏洞单独提交的话,厂家可能不会给你还多钱,但是它往往和其他脆弱点造成一些高危漏洞:比如账户劫持,Oauth相关的漏洞 本文主要总结了几种常见的测试(绕过)方法
343 0
|
SQL 安全 Python
【Django | 安全防护】CSRF跨站伪请求和SQL注入攻击
【Django | 安全防护】CSRF跨站伪请求和SQL注入攻击
【Django | 安全防护】CSRF跨站伪请求和SQL注入攻击
|
Web App开发 前端开发 JavaScript
谨慎能捕千秋蝉(二)——CSRF
CSRF(Cross Site Request Forgery)跨站点请求伪造。 CSRF的本质是当重要操作的参数都能被攻击者预测到,才能成功伪造请求。
谨慎能捕千秋蝉(二)——CSRF