跨站请求伪造目录

CSRF漏洞概述

Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
这里列举一个场景解释一下
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的：
登录—修改会员信息，提交请求—修改成功。
所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在大白登录xxx网站后，欺骗他进行点击，大白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
—因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.大白点击了小黑发给的链接，并且这个时候大白刚好登录在购物网上;
—如果大白安全意识高，不点击不明链接，则攻击不会成功，又或者即使大白点击了链接，但大白此时并没有登录购物网站，也不会成功。
—因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗大白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，大白中招，小黑拿到大白的cookie，然后小黑顺利登录到大白的后台，小黑自己修改小白的相关信息。
—所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。

CSRF漏洞测试流程

通过上面这个例子来看，我们判断一个网站是否存在CSRF漏洞
1，对目标网站增删改的地方进行标记，并观察其逻辑，判断请求是否可以被伪造—比如----修改管理员账号时，并不需要验证旧密码，导致请求容易被伪造;
—比如对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造;
2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)
—虽然退出或者关闭了浏览器，但cookie仍然有效，或者session并没有及时过期，导致CSRF攻击变的简单

CSRF演示

csrf（get）
首先，我们来登录一下它给的账号

这个样子

接着，我们修改他的地址为china，提交

我们发现，他的地址已经被修改

那么，我们如何判断这边存在csrf漏洞呢
我们用burp抓到的包来看一下

这个get请求实际上是向后台发送了所有的参数
在这里我们没有发现csrf 的 token
说明就是没有做防csrf的措施的
同时他是get型
说明只需要拿到这个链接，就可以进行修改了

127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=13676767767&add=CHINA&email=allen%40pikachu.com&submit=submit

其实想拿到这个链接的话也简单，我们只需要重注册一个号，然后登录修改之后，就可以获取到这个链接
我们修改一下这段链接中的内容

127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=1&add=shanxi&email=allen%40pikachu.com&submit=submit

然后将这段链接发送给allen，当allen正好登录的时候，点击了这段链接，就相当于以allen的身份来修改了自己的信息，我们来做一下演示

当前是allen在这个网站

然后他点击了这段链接

其实这个时候，他的信息已经被修改了

在抓到的包中也可以看到

其实就相当于攻击者以allen的身份来向后台提交了一个修改信息的请求

至此，一个get型的csrf就完成了

那么，如果是post型的呢？
是不是就可以防止csrf了
我们来看看

进入到post型中

我们修改一下，看看它抓到的包

提交

我们发现它的提交方式为post
所有参数在请求体中提交，我们就不能通过伪造URL的方式进行攻击
是不是不能进行攻击了呢？
其实不是，我们可以自己搭建一个站点
诱导allen点击链接，那么就会以allen身份向后台用post请求提交修改信息
怎么操作呢？

这里有个简单的操作，我们可以在抓到的包中右键

它会给我们自己生成一个脚本

我们来测试一下

修改这两个信息后，我们点击下面的Test in browser
出来这个

复制好这段链接，我们去测试一下

点击提交请求


信息被修改！

其实我们也可以在本地写一个html文件，原理一样，都是让用户来访问我们写的脚本，以达到以post请求向后台修改信息的请求。

在这个文件下，写一个post.html

内容如下

总结一下

get型的话，我们可以通过获取到的URL直接修改信息来进行攻击

post型的话，我们可以自己写一个站点，诱导用户点击链接，以post请求向后台提交修改个人信息的请求

CSRF token

那么，token是如何防止csrf的呢？
其实csrf的问题是由于链接容易被伪造
那么如果每次请求的时候，都给他加一个随机的token呢，后台每次会对这个随机码进行验证，不容易被伪造

我们看看它

提交

可以发现多了一个token值
那这个token值是什么呢
每当我们访问这个页面的时候，它就会生成一个token值（随机数）
而每次提交的时候，后台会对token进行验证

这样的话就可以有效的防止csrf

看看后台源码

可以看到，它每次都会对前端后台的token进行验证
攻击者无法伪造！

常见的防范措施

通过上面的学习
我们总结出了csrf的防范措施
增加token
对关键操作增加token值，让攻击者无法伪造
关于安全的会话管理
1，不要在客户端端保存敏感信息（比如身份认证信息）;
2，测试直接关闭，退出时，的会话过期机制;
3，设置会话过期机制，比如15分钟内无操作，则自动登录超时;
访问控制安全管理
1，敏感信息的修改时需要对身份进行二次认证，比如修改账号时，需要判断旧密码;
2，敏感信息的修改使用post，而不是get ;
3，通过http头部中的referer来限制原页面
增加验证码
一般在登录界面，也可以在一些修改重要信息的修改表单中