浅谈跨站请求伪造(CSRF)

浅谈跨站请求伪造(CSRF)

  这里简单的记录一下CSRF漏洞~~

什么是CSRF?

  CSRF（Cross-Site Request Forgery，跨站点伪造请求）是一种网络攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作，具有很大的危害性。具体来讲，可以这样理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

  CSRF攻击方式并不为大家所熟知，实际上很多网站都存在CSRF的安全漏洞。早在2000年，CSRF这种攻击方式已经由国外的安全人员提出，但在国内，直到2006年才开始被关注。2008年，国内外多个大型社区和交互网站先后爆出CSRF漏洞，如：百度HI、NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站）和YouTube等。但直到现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。

  CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

CSRF攻击原理

  CSRF攻击原理比较简单，如 CSRF攻击原理错误!未找到引用源。所示。其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

CSRF攻击分类

  CSRF漏洞一般分为站外和站内两种类型。

  CSRF站外类型的漏洞本质上就是传统意义上的外部提交数据问题。通常程序员会考虑给一些留言或者评论的表单加上水印以防止SPAM问题（这里，SPAM可以简单的理解为垃圾留言、垃圾评论，或者是带有站外链接的恶意回复），但是有时为了提高用户的体验性，可能没有对一些操作做任何限制，所以攻击者可以事先预测并设置请求的参数，在站外的Web页面里编写脚本伪造文件请求，或者和自动提交的表单一起使用来实现GET、POST请求，当用户在会话状态下点击链接访问站外Web页面，客户端就被强迫发起请求。

  CSRF站内类型的漏洞在一定程度上是由于程序员滥用$_REQUEST类变量造成的。在一些敏感的操作中（如修改密码、添加用户等），本来要求用户从表单提交发起POST请求传递参数给程序，但是由于使用了$_REQUEST等变量，程序除支持接收POST请求传递的参数外也支持接收GET请求传递的参数，这样就会为攻击者使用CSRF攻击创造条件。一般攻击者只要把预测的请求参数放在站内一个贴子或者留言的图片链接里，受害者浏览了这样的页面就会被强迫发起这些请求。

漏洞影响

  CSRF攻击迫使终端用户在通过验证后在web应用中执行不必要的操作。在社会工程帮助下（如通过电子邮件/聊天发送的链接），攻击者可能会迫使Web应用程序用户执行攻击者所选择的行动。

  当一个成功的CSRF漏洞的目标是普通用户时，它能够危害终端用户的数据和操作。但如果最终的目标用户是管理员帐户，一个CSRF攻击可以损害整个Web应用程序。

漏洞例子

这里使用DVWA中的例子说一下吧，，，
首先是low级别的漏洞，在输入框填入两次新密码，点击“Change”，然后提示“Password Changed”

然后把链接复制下来创建一个新的标签页打开

dvwa/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#

修改一下URL的参数

dvwa/vulnerabilities/csrf/?password_new=1234&password_conf=1234&Change=Change#

当我们提交修改后的URL时，页面提示的还是Password Changed，说明修改成功

我们可以查看一下源码：

分析源码可以获知，没有判断原来的密码
直接两次输入的密码相同就修改原来的密码的数据库内容
那么需要避免CSRF应该判断下请求数据的来源，还有对原来的旧密码进行检查
那么我们把级别换成medium级别，直接查看源码：

这里开始判断请求来源了，也就是$_SERVER[‘HTTP_REFERER’] ，eregi 是判断是否存在某字符的
这里虽然检查了数据来源，但是还是没有对旧密码进行检查
这样我们还是可以进行CSRF的，使用bp进行抓包
修改http请求数据，比如请求IP的地址，改为127.0.0.1，点击Forward发送出去

这样我们还是能够看见页面提示的还是Password Changed

接下来我们把级别换到high级别
查看源码：

直接判断旧密码是否正确了。如果不正确，就提示：密码不匹配或原密码错误。
检验后，安全级别也得到相应地提高

防范方法

1、进行二次验证，在进行敏感数据操作时，要求用户进行二次验证，减少风险
2、在表单中增加一个 hidden隐藏字段，用来提交token，并在服务器检查token是否正确
3、验证 HTTP Referer 字段
4、在hhtp头中加入自定义的属性，在服务器进行验证

思考总结

  在DVWA这个靶场上跨站请求伪造漏洞产生原因：没有判断请求数据的来源；没有判断原来的密码，直接两次输入的密码相同就修改原来的密码的数据库内容。导致通过修改URL中的数据可以轻易修改密码。修复漏洞需修复以上两个问题，判断数据来源，同时需要判断原来的密码，因为只判断数据来源的话，攻击者仍可以通过修改数据包达到攻击目的。