CSRF(Cross site request forger)跨站请求伪造，利用了网站对用户浏览器的信任，把攻击者伪装成合法用户向服务器发送请求，以达到其不可告人的目的。他的大致攻击流程是这样的：
- 用户访问一个正常网站，并在这个正常网站上进行了登陆，这时正常网站返回一个cookie来表明该用户已经登陆。
- 用户在cookie失效前，又访问了恶意网站。
- 恶意网站注入了一段恶意请求，这个请求指向用户刚刚访问的正常网站。
- 这个恶意请求会携带上正常网站的cookie，从而在服务端让恶意请求被误认为是用户正常发送的请求。
例如：某银行的转账api为一个get请求：http://www.myBank.com/transfer?target=xx&amount=xx 其中target表示转账目标，amount表示转账金额。用户在登录后拿到一个isLogin: true的cookie。这时用户访问恶意网站，在恶意网站中存在一个img：
<img src='http://www.myBank.com/transfer?target=badGuy&amount=3000'/>当浏览器开始加载这个图片时，会向src这个地址请求数据，同时会带上http://www.myBank.com这个domain下的cookie，在银行的服务器角度看来，这个请求是完全合法的。用户就会发现自己的卡里少了3000。
首先我们会发现，这个转账请求使用get方法就很不合理，如果我们使用post方法是不是就可以避免CSRF呢？也并不是。比如我们现在使用post请求，那么这个api就会变成：url：http://www.myBank.com/transfer，body：{.target: xx, amount: xx }。而恶意网站可以通过一个form来完成对这个api的调用：
<body onload="document.forms[0].submit()">
<form action="http://myBank.com/transfer" method="POST">
<input type="hidden" name="target" value="badGuy" />
<input type="hidden" name="amount" value="3000" />
</form>
</body>在加载完成后，这段代码会自动发起对form的提交，也就是一个post请求，同时带上目标银行网站发送给用户的cookie，转账依然会成功。
那么我们不禁要问：这个cookie这么蠢么，谁叫他他就跟谁走？其实cookie有一个属性SameSite，可以限制第三方使用cookie，减少风险，这个属性可以设置为三个值：
- Strict
最严格的限制，彻底禁用第三方使用cookie，只有当前网页URL和目标URL一致，才会带上cookie。这个规则的问题是会造成不好的用户体验，比如当前网页有一个github链接，如果github对SameSite设置了strict，在跳转后就会变为未登录状态 - Lax
相比strict，lax稍微放宽了限制，除非是导航到目标网址的get请求，其余请求都不会带上cookie。 - None
不限制
可以看到，上面的解决方法要么会牺牲用户体验，要么没有完全限制CSRF的攻击，况且SameSite并非所有浏览器都能支持。
难受了，这个cookie这么不安全，我们不用它行不行？可以，其实cookie的不安全之处就在于它会被所有指向目标URL的请求自动带上，这个机制导致了非法请求有机可乘。而cookie的作用大部分情况是用于验证用户状态，那么我们是否可以使用别的方法来存储用户状态，同时避免所有请求都自动带上这个状态呢？
我们可以让服务器在每次确认用户登录后，生成一个随机的token，并存储在session中，之后每一次收到请求，要求请求中要带上一个token的参数，通过对比请求中的token和session中的token，来判断是否是合法用户。而在用户端，当收到这个token的时候，没有把它存放在cookie中，而是存放在诸如localstroage中，每次需要发送请求时就取出这个token并写进请求中，看起来这样就可以避免CSRF了。
然鹅，存在localstorage中的token或许可以避免被CSRF获取，但是这并不意味着这种方式就绝对安全了，恶意网站仍然可以通过各种手段从localstorage中获取你的token，不过这就不在CSRF的范畴中了。所以想要确保你的请求不被盗用，还是尽量保证你的token本身有足够的保密性，而不是寄希望于在客户端找到一个绝对安全的地方来存储敏感信息。
724
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
