概述
1.CSRF(get)
抓包看看
发现其参数直接用get提交,并且没做什么认证(即攻击者不需要任何用户的信息即可构造请求,如果防御的话我觉得应该利用cookie等认证用户的信息添加到get请求里)
用户点击该网站链接时会以用户的身份提交攻击者提前准备好的数据
2.CSRF(post)
抓包看看
其实与上面那个同理,只是稍微麻烦点,需要自己搭建一个网站(或用户能访问到的网站),然后用户点击该网站链接时,该网站向目标网站提交攻击者事先准备好的表单
3.CSRF Token
有token验证了唉
我们看看源码对token是怎样设置的
emmmm随机数的话就比较麻烦了.
我们易得知该token是用户进入token_get_edit.php时,页面给他返回一个随机的token,对用户在提交时拥有的会话token进行验证.这样就有点麻烦了.....(token走的应该是用用户自己的信息验证自己的信息吧,服务器这样操作会不会加重服务器的内存负担,并且需要对应好哪个用户对应哪个token)
资料如下:
虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，每次当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？