网络安全初探-CSRF攻击方式&&防御手段

忘是亡心i 2023-01-22 11:48 68阅读 0赞

### 文章目录 ###

*  一、CSRF
 *  二、常见的攻击类型
 *   *  1.GET类型的CSRF
     *  2.POST类型的CSRF
     *  3.链接类型的CSRF
 *  三、CSRF的特点
 *  四、防护策略
 *   *  1.同源检测
     *   *  Origin Header和Referer Header
         *  Samesite Cookie属性
     *  2.提交时要求附加本域
     *   *  CSRF Token
         *  双重Cookie验证

# 一、CSRF #

> CSRF（Cross-site request  
> forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

**流程：**

1.  受害者登录a.com，并保留了登录凭证（Cookie）。
2.  攻击者引诱受害者访问了b.com。
3.  b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
4.  a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
5.  a.com以受害者的名义执行了act=xx。
6.  攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

# 二、常见的攻击类型 #

## 1.GET类型的CSRF ##

GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：

![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/ff0cdbee.example/withdraw?amount=10000&for=hacker)

在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

## 2.POST类型的CSRF ##

这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：

<form action="http://bank.example/withdraw" method=POST>
        <input type="hidden" name="account" value="xiaoming" />
        <input type="hidden" name="amount" value="10000" />
        <input type="hidden" name="for" value="hacker" />
    </form>
    <script> document.forms[0].submit(); </script>

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。

## 3.链接类型的CSRF ##

链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：

由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击成功。

# 三、CSRF的特点 #

*  攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
 *  攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
 *  整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
 *  跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
 *  CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

# 四、防护策略 #

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

*  阻止不明外域的访问
    
     *  同源检测
     *  Samesite Cookie
 *  提交时要求附加本域才能获取的信息
    
     *  CSRF Token
     *  双重Cookie验证

## 1.同源检测 ##

CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。

### Origin Header和Referer Header ###

在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

*  Origin Header
 *  Referer Header  
    这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名，确定请求的来源域。

如果Origin和Referer都不存在，建议直接进行阻止，特别是没有使用随机CSRF Token作为第二次检查的清空下。

### Samesite Cookie属性 ###

防止CSRF攻击的办法已经有上面的预防措施。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。

**Samesite=Strict**：  
这种称为严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外。比如说 b.com 设置了如下 Cookie：

Set-Cookie: foo=1; Samesite=Strict
    Set-Cookie: bar=2; Samesite=Lax
    Set-Cookie: baz=3

我们在 a.com 下发起对 b.com 的任意请求，foo 这个 Cookie 都不会被包含在 Cookie 请求头中，但 bar 会。举个实际的例子就是，假如淘宝网站用来识别用户登录与否的 Cookie 被设置成了 Samesite=Strict，那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后，淘宝都不会是登录状态，因为淘宝的服务器不会接受到那个 Cookie，其它网站发起的对淘宝的任意请求都不会带上那个 Cookie。

## 2.提交时要求附加本域 ##

### CSRF Token ###

CSRF，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。

而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。  
**原理**:  
1.将CSRF Token输出到页面中

2.页面提交的请求携带这个Token

3.服务器验证Token是否正确

因为cookie采取同源策略，只有相同域名的网页才能获取域名对应的cookie，别的网站获取不到cookie里面的token

### 双重Cookie验证 ###

利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。

**流程**：

1.  在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
2.  在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
3.  后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

[本文链接https://blog.csdn.net/qq\_39903567/article/details/117037413][https_blog.csdn.net_qq_39903567_article_details_117037413]

参考：  
[https://tech.meituan.com/2018/10/11/fe-security-csrf.html][https_tech.meituan.com_2018_10_11_fe-security-csrf.html]

[https_blog.csdn.net_qq_39903567_article_details_117037413]: https://blog.csdn.net/qq_39903567/article/details/117037413
[https_tech.meituan.com_2018_10_11_fe-security-csrf.html]: https://tech.meituan.com/2018/10/11/fe-security-csrf.html