CSRF入门

0x01 基础学习

概述

Cross-site request forgery 跨站点请求伪造，是一种 Web 安全漏洞，它允许攻击者诱使用户执行他们不打算执行的操作。它允许攻击者部分规避同源策略，该策略旨在防止不同网站相互干扰。

攻击流程

Step1:使用者成功登入A 银行网站的帐户，并且代表使用者身份的cookie 在本地保存下来，所以下次再来A 银行网站时，不用重新登入

Step2:由于使用者没有登出A 银行网站的帐户，在浏览B 恶意网站时，B 网站有个被设为透明的图片，因为是透明的，所以使用者在画面上看不到，然而该图片包含一段恶意程式码，程式码如下。

1
2
3
4
5
6
// 備註：CSRF 攻擊手法有很多，此程式碼例子是一種最基本的攻擊方法之一
<img
  src="http://a-bank.com/transfer.do?acct=BadGuy&amount=100000 HTTP/1.1"
  width="0"
  height="0"
/>

Step3:使用者虽然将看不到此图片， 但是，浏览器仍会向http://a-bank.com/提交请求，同时此请求是带有使用者的cookie，所以A 银行可以辨识使用者身份，此恶意攻击执行成功。

总结：CSRF攻击利用了受害者的cookie，本质上还是信任的问题，这也为如何防范CSRF攻击提供了思路。

0x02 CSRF类型

GET型CSRF

URL附带上参数，已经攻击成功了。

1
<img src="htp://bank.example/withdraw?amount=1000O&for=hacker">

可以看出这与XSS很接近，在某些情况下这两种攻击差别也不大。以下是·二者的区别：

XSS和CSRF的区别在于攻击方式不同。 XSS攻击是通过注入恶意脚本来攻击，而CSRF攻击则是利用用户在已登录的Web应用程序中的身份进行攻击。 此外，XSS攻击的目标是获取用户的敏感信息或劫持用户会话，而CSRF攻击的目标是在用户不知情的情况下执行恶意操作。

POST型CSRF

1
2
3
4
5
6
<form action="ht://bank.example/withdraw" method=POST>
<input type="hidden" name='account" value="xiaoming" />   //name为参数value为参数的值
<input type="hidden" name='amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>    //自动提交表单

自动提交表单，这种不需要交互，但是比较理想。

链接型CSRF

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

例如:

1
2
<a href="http://test.com/csrf/withdraw. php?amount=1000&for=hacker" taget="blank"> 重磅消息! !
<a/>

0x03 防御方法

加上验证机制

那些看似简单的图形验证码、简讯验证码等等其实也是为了防止CSRF攻击

不要用GET请求来做关键操作

GET请求不需要点击，可以直接在url上。换句话说：只要你进了B网站，你在A网站的信息就已经不安全了，而这正是在你完全不知情的情况下进行的。

相比GET请求，POST请求至少需要一个点击的步骤，这也是为什么一些广告需要点击。

检查domain

  1. 浏览器会在request header 加入Referer及Origin两个栏位代表请求的来源domain，server 可以检查这两个栏位的值是不是允许的domain，虽然这两个栏位是Forbidden header name，但仍有些小技巧可以修改，而且有些浏览器可能没有这两个栏位，所以只用这个方法并不安全。
  2. 后端服务在response headerAccess-Control-Allow-Origin指定允许的domain，浏览器会先发出preflight 请求给server 检查client domain 是否被允许，如果允许的话才会再发出真正的请求。

CSRF token

server 加密产生一个唯一且有时效性的token，在前端载入页面时或是在呼叫需要保护的api 之前先跟server 取得这个token，再把token 放进api request header 中送给server 检查是合法token 才接受请求。

CSRF token 就像是一次性使用的验证码来让请求多一层保护，所以特别需要注意取得CSRF token 的api 不能接受跨网域的请求，如果让骇客有机会取得CSRF token 一样有风险。

这个也是最常见的方法，实作上可以使用套件达成，例如nodejs 的csurf。

token起到验证的作用，但如果这个token可以被拿到那也没有意义——取得CSRF token 的api 不能接受跨网域的请求。

浏览器本身防护- SameSite cookies

  • Strict: 这个cookie 只会跟着相同domain 的请求送出，不会跟着cross site request 一起送出去
  • Lax: 只允许特定方式的cross site request 可以一起带着送出去，特定方式包含：<a>, <link rel="prerender">, <form method="GET">，Chrome set cookie 预设SameSite=Lax

Double submit cookie: 前端随机产生一个CSRF token，同时放进cookie 以及每个request header，server 检查两边的token 是相同的才接受请求，因为浏览器的设计骇客无法将伪造的token 放进你的domain的cookie，此时跨domain 请求所带的cookie 中一定没有正确的CSRF token。

相关文章

https://www.explainthis.io/zh-hant/swe/what-is-csrf

https://gcdeng.com/blog/five-ways-to-defend-against-CSRF-attacks

https://xz.aliyun.com/t/12866?time__1311=mqmhq%2Bxfx0xIODBqDTexUx2KH50KNe%2BdD8eD&alichlgref=https%3A%2F%2Fwww.google.com%2F#toc-3