0x01

       Long long ago，我还是个懵懂的小孩，当时我不懂编程，不懂安全，只知道黑客无所不能，不经意间我知道了看雪。

       后来，一个偶然的机会我接触到了安全，又有这么一个偶然的机会我参加了看雪安全峰会，“晚秋京城，一见如故”。

       感觉要切入正题了，内心还是颇不宁静~~

0x02

       按照一般写作文套路，首先得解释下CSRF。（摘自百度百科）CSRF跨站请求伪造，听起来像跨站漏洞（XSS），但还是非常不同，XSS利用站内信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

       感觉这个解释还是没描述的很清楚，反正我第一次看这个解释的时候云里雾里。通过一个自己编的小故事来理解下：我请朋友A去一个饭店吃饭，饭店的无线密码是“来一瓶82年拉菲”的拼音，并且大大的写在了菜单上，我点菜的时候看到了菜单上的密码，就不小心念了一遍，“来一瓶82年拉菲”，结果“砰”的一声，服务员把酒开了，顿时内心奔溃，这个行为就是一个xss攻击，是本身的用户触发的恶意代码导致。饭吃到一半，酒喝完了，朋友A趁我上厕所的时间，对服务员说刚才点菜的哥们说点一瓶82年的拉菲，一会儿一起结账，我的内心又像千万只草泥马奔腾而过，朋友A的这个行为就可以理解为CSRF攻击，伪造了一个站内信任用户的请求，服务员认为这是一个合法的请求。

       可能上边这个例子有些不准确的地方，但感觉还是比较好理解了。

0x03

       先说第一种形式，相对来说还不太好触发的，得靠一定的运气。用户登录了安全站点A，再未登出的情况下，一不小心访问了危险站点B，而危险站点B对安全站点A发出了一个危险请求，这样就形成了一次CSRF攻击。

       如果你觉得还不好理解，那就容我再画个图：

       如果感觉看图还不好理解，那就直接看应用场景~~

0x0301

       登录系统后台，昵称这块允许修改：

       正常修改昵称，抓包一次，然后按照POST数据，构造一个form表单（1.html）：

      只要执行form表单正确POST数据以后，后台昵称就被修改了。

      应用场景就是当用户正常登录系统，在另外一个危险站点访问到1.html页面，并提交了表单，自己的昵称就被修改。

0x0302

      再来一个应用场景，同样登录系统后台，发现绑定的手机也可以修改。

     正常修改手机号，发现有两个步骤，第一步是先要获取修改新手机号的验证码，第二步输入验证码后提交修改手机号。

     首先按照抓包的POST数据，构造一个form表单（2.html），获取手机验证码：

    执行成功后，修改的新手机号会收到验证码：

    第二步，继续构造一个form表单（3.html），提交手机验证码：

执行成功后，后台手机号被修改。

       应用场景，用户正常登录后台，在另一个危险站点提交了2.html 表单数据，在30分钟内如果继续提交了3.html 表单数据，绑定手机号就被修改。接下来，就可以任意重置密码。

0x04 

       以上是一般有安全措施的站点可能会面临的问题，总体来说只要用户有安全意识，不需要浏览的站点及时安全退出，不要随意打开来路不明的网站、链接，在一定程度可以避免受到损失。

      但是接下来要说的这一类CSRF就显得有点不可思议了，但确实是实际碰到的！

      首先登录是一种摆设，看着登录页面很高大上，但是后台的所有操作都不验证账号登录状态。

     我们还是把第一种形式的图再修改下搬上来，所有环节都省去了，直接POST数据就好，这个form表单可以在站点B上、也可以在本机电脑。这里方法很容易，就不放场景。

       那么我们还是把刚才吃饭的故事讲完吧，我和朋友A吃完饭，刷会员储蓄卡结账走人。刚出了饭店门口，一个路人甲进来对服务员说，刚才出去那俩哥们让我再拿一瓶82年的拉菲，服务员也不确认身份，直接把我的会员卡刷了。

0x05

       CSRF配合其他漏洞攻击的思路还有很多，我这个算抛砖引玉吧，如果大家有更加风骚的走位希望分享出来~~~

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！