web基础漏洞之CSRF（跨站请求伪造漏洞)

R3ality

已于 2022-11-17 12:07:44 修改

阅读量1.3k

点赞数

分类专栏： web基础漏洞文章标签： csrf json 前端

于 2022-10-04 18:05:30 首次发布

本文链接：https://blog.csdn.net/m0_62274649/article/details/127164401

版权

web基础漏洞专栏收录该内容

9 篇文章 0 订阅

订阅专栏

`cookie session token`

我觉得在开始学习CSRF之前应该先学会区分这三种东西：cookie session token

cookie: Cookie，有时也用其复数形式 Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息

浏览器第一次访问服务端时，服务器此时肯定不知道他的身份，所以创建一个独特的身份标识数据，格式为key=value，放入到Set-Cookie字段里，随着响应报文发给浏览器。
浏览器看到有Set-Cookie字段以后就知道这是服务器给的身份标识，于是就保存起来，下次请求时会自动将此key=value值放入到Cookie字段中发给服务端。
服务端收到请求报文后，发现Cookie字段中有值，就能根据此值识别用户的身份然后提供个性化的服务。

session:

如果将账户的一些信息都存入Cookie中的话，一旦信息被拦截，那么我们所有的账户信息都会丢失掉。所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录SessionId一个SessionId对应一次会话请求。

token:

Session是将要验证的信息存储在服务端，并以Session Id和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。而Token是在服务端将用户信息经过Base64Url编码过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token)。

概念：

跨站请求伪造（Cross-Site Request Forgery，简称CSRF）是指，攻击者可能利用网页中的恶意代码强迫受害者浏览器向被攻击的Web站点发送伪造的请求，篡夺受害者的认证Cookie等身份信息，从而假冒受害者对目标站点执行指定的操作。

攻击原理：

总结一下：要想实现这个攻击，需要满足：登录受信任网站A，并在本地生成Cookie。在不登出A的情况下，访问危险网站B。

1、客户端通过账户密码登录访问网站A。

2、网站A验证客户端的账号密码，成功则生成一个sessionlD，并返回给客户端存储在浏览器中。

3、该客户端Tab—个新页面访问了网站B。

4、网站B自动触发要求该客户端访问网站A。(即在网站B中有链接指向网站A)

5、客户端通过网站B中的链接访问网站A。(此时携带有合法的SessionID进行访问站A的)

6、此时网站A只需检验sessionIlD是否合法，合法则执行相应的操作。(因此具体啥工具就得看链接，以及网站B要求访问时携带的数据

csrf的两类：

一：Get类型的csrf

仅仅须要一个HTTP请求。就能够构造一次简单的CSRF

样例：

银行站点A：它以GET请求来完毕银行转账的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危险站点B：它里面有一段HTML的代码例如以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先。你登录了银行站点A，然后访问危险站点B，噢，这时你会发现你的银行账户少了1000块。

为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。

在访问危险站点B的之前。你已经登录了银行站点A，而B中的一个合法的请求，但这里被不法分子利用了）。

所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了）

demo：dvwa:low level

这是一个修改密码的界面，然后我们点击右下角查看源码，

首先分析一下源码，他这个首先就是通过get方式传进password_new和password_conf这两个参数，然后判断用户输入的这两个参数是否一样。没有什么防控csrf的措施，所以很容易受到CSRF的攻击。

于是构造url:

http://64336ea7-ad15-47e2-bf11-17a61a7c78e4.node4.buuoj.cn:81/vulnerabilities
/csrf/?password_new=123456&password_conf=123456&change=change

登陆成功。over

现实中，攻击者往往会先搭建一个站点，然后上传一个html文档，该文档中含有恶意的链接。让后将这个html文档的地址发送给用户，用户一旦点击将会自动加载恶意链接完成攻击。

2. POST类型的CSRF:

在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。

比如:

/coures/user/handler666buy.php</font>

通过提交表单，buy.php处理购买的信息，这里的666为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容。

<form action=/coures/user/handler/666/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>

当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为666的视频，从而导致受害者余额扣除。

CSRF漏洞的防御

一：请求地址中添加 token 并验证。

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

二：验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问：

Refer:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory

时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。

demo：dvwa middle

用刚才的办法，发现不对，于是查看源码。

其中，stripos(strs, str)函数：返回字符str在字符串strs中的位置。 HTTP_REFERER表示数据包中的referer字段（表示数据包的来源链接），SERVER_NAME表示数据包中的host（要访问的主机地址），所以后端会检测看referer中是否有host，如果有才会通过。

直接将low级别制作的html文档名称改为[host].html，这样referer中就会存在host，用户一旦点击就会绕过检测攻击成功