web安全Day04：CSRF

目录

0x00 overview

0x01快速生成csrf poc：

0x02 如何防范csrf

0x03 如何证明csrf

---

0x00 overview

从开发的角度来看，你前端做了一个表单可以向后端发送post请求，后端接受post请求，并根据post请求的内容进行操作。

但是你能保证后端接受到的这个请求一定是自己的前端发过来的吗？别人可以写一个前端form表单，只要action指向你的后端不就好了吗？这就叫跨站请求伪造。

设想一下，假如你的后端进行一些敏感操作前首先会验证用户的sessionid。假设你的用户已经登录，浏览器已经保存了sessionid,那么当你的用户点击跨站请求伪造的表单时，这个伪造的表单将会携带着用户的sessionid来进行攻击者设定好操作。

注意：cookie 的path值限定了在哪些域名下发送这个cookie。只要表单的action指向你的后端，那么浏览器就会将对应path的cookie携带进post请求中。

攻击流程图解：

例如：银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

，后端接收到这个请求后会首先验证用户的sessionid，如果通过，则更新数据库将1000元转账给id为11的银行用户。

但是用户在登录A网站后，又访问了危险网站B，它里面有一段HTML的代码如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

这意味着浏览器会自动向src指向的网址发送get请求，而请求中自动携带该域名下对应的cookie。

这时你会发现你的银行账户少了1000块......

开发角度：csrf = 更新数据库+接受post/get请求+session验证+没有token/没有验证码

csrf能进行的操作：

1.伪造身份发送邮件

2.伪造身份发送消息

3.伪造身份购买物品

4.伪造身份转账

5.伪造身份修改密码

存储型xss+csrf组合拳：

例如有一个网站留言板存在存储型xss，那么只要将上文中csrf连接贴到留言板，那么所有访问留言板的用户并存有A网站sessionid的人都会中招。

0x01快速生成csrf poc：

首先找到网站前端和后端交互的点，前端提交post表单或者get请求后端时进行抓包。然后：

如果可以复制HTML代码将其挂在自己的服务器上，然后将链接打入留言板或者其他地方。

0x02 如何防范csrf

如何预防CSRF

1. 可以强行用验证码（强制用户必须和应用进行交互，但是体验性太差了）    
2. 请求中加随机Token

什么是随机Token值（不同的表单包含一个不同的伪随机值）

0x03 如何证明csrf

注册两个账号证明即可。