什么是CSRF攻击，如何预防

Posted 2023-04-08

CSRF攻击，全称为“Cross-site request forgery”，中文名为跨站请求伪造，也被称为“One Click
Attack”或者“Session Riding”，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。
XSS主要是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求，来利用受信任的网站。与XSS相比，CSRF更具危险性。
CSRF攻击的危害：
主要的危害来自于攻击者盗用用户身份，发送恶意请求。比如：模拟用户发送邮件，发消息，以及支付、转账等。
如何防御CSRF攻击：
1、重要数据交互采用POST进行接收，当然POST也不是万能的，伪造一个form表单即可破解。
2、使用验证码，只要是涉及到数据交互就先进行验证码验证，这个方法可以完全解决CSRF。
3、出于用户体验考虑，网站不能给所有的操作都加上验证码，因此验证码只能作为一种辅助手段，不能作为主要解决方案。
4、验证HTTP Referer字段，该字段记录了此次HTTP请求的来源地址，最常见的应用是图片防盗链。
5、为每个表单添加令牌token并验证。 参考技术A

下面是CSRF的常见特性：

依靠用户标识危害网站

利用网站对用户标识的信任

欺骗用户的浏览器发送HTTP请求给目标站点

另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。

CSRF攻击依赖下面的假定：

攻击者了解受害者所在的站点

攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie

目标站点没有对用户在网站行为的第二授权

这里要说的解决办法是利用Token

以下信息来自：Sinesafe官方

Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。

那么，Token有什么作用？又是什么原理呢？

Token一般用在两个地方:

1)防止表单重复提交、

2)anti csrf攻击（跨站点请求伪造）。

两者在原理上都是通过session token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端。然后，如果应用于“anti csrf攻击”，则服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。

上面的session应用相对安全，但也叫繁琐，同时当多页面多请求时，必须采用多Token同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用cookie存储验证信息的方法来代替session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，由于cookie已经有提交记录，因此第二次提交会失败。不过，cookie存储有个致命弱点，如果cookie被劫持（xss攻击很容易得到用户cookie），那么又一次gameover。黑客将直接实现csrf攻击。

所以，安全和高效相对的。具体问题具体对待吧。

也可以通过安全公司来解决，国内也就Sinesafe和绿盟等安全公司比较专业.

CSRF攻击预防的Token生成以及验证原理

参考技术A token由msg、separator、signature三部分组成

msg由客户端标识信息(uid、did)、随机字符主体、过期时间戳两部分组成。

用符号分隔msg部分和加密后的signature签名部分，比如“$”、"."等

signature签名，是对上面提到的msg，按照msg中提到的msg的信息部分，按照特定的密匙进行加密。

token = base64(msg)格式化..base64(sha256("密匙", msg))

当用户从客户端，得到token，再次提交给服务器的时候，服务器先判断token的有效性，如果有效则处理请求。

服务器对客户端发来的token进行解构为msg、separator、signature三部分。

服务器先验证token是否还具有时效性，如果不具有时效性则拒绝访问。

服务器对客户端发送的信息进行签名，如果得到的签名与客户端发来的签名相同，则token有效

JWT由以下三部分组成：

即：

Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。

alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）
typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子:

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。

Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名:

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。