CSRF跨站请求伪造漏洞
三亿人 人气:0CSRF
现在的网站都有利用CSRF令牌来防止CSRF，就是在请求包的字段加一个csrf的值，防止csrf，要想利用该漏洞，要和xss组合起来，利用xss获得该csrf值，在构造的请求中将csrf值加进去，就可以绕过csrf防御，利用该漏洞。
该漏洞与xss的区别：xss是通过执行恶意脚本，获取到用户的cookie等信息，再利用cookie等信息进行绕过登录限制，做一些用户可以做的事。
而csrf是伪造请求，让用户自己执行攻击者伪造的请求，这个过程是用户自己完成的。
漏洞原理
跨站请求伪造，攻击者伪造一个请求（通常是一个恶意链接）发送给用户，用户在登录的情况下点击该链接，服务器就会以用户的身份去执行攻击者伪造的这个请求，从而造成攻击。
漏洞危害
1. 修改用户信息：修改邮箱，更改密码、转账等。
如果修改的信息是GET方式提交的，我们就直接将修改信息的url发送给用户，用户登录情况下点击该链接，就把他的信息修改为我们url中的值了。
如果是POST传参，那我们就需要搭建一个公网服务器，伪造一个自动提交的修改用户信息的表单，同样发送给用户一个链接，让用户在登录存在漏洞网站的情况下访问我们构造的这个表单，从而修改用户信息。
防御绕过
1. 切换请求方式绕过CSRF令牌验证：
某些应用程序只在POST请求中验证CSRF令牌，所以我们将请求方法改为GET，就可以绕过CSRF令牌验证。
抓包，利用burp的 Change request method，来将请求改为GET方式。
再利用CSRF poc生成器生成一个自动提交脚本代码的poc。
2. 令牌存在即验证：
我们可以直接将CSRF令牌参数删除，看能否绕过，因为有的应用程序只有令牌存在时进行验证，如果不存在令牌，则不验证。
3. 令牌未绑定到用户会话绕过：
应用程序没有将CSRF令牌与用户会话进行绑定，只是在他的令牌池中进行验证，只要请求中的令牌存在于令牌 池中，则通过验证。攻击者就可以使用自己的账户登录，拿到一个有效令牌，然后在攻击者将该令牌提供给正常用户，就会绕过令牌验证，造成攻击。
4. 令牌未绑定到会话cookie:
虽然令牌绑定了cookie，但未将令牌绑定到用于跟踪会话的cookie上。当应用程序使用两个不同的框架时，很容易发生这种情况。一个cookie用于会话处理，一个用于CSRF保护，他俩没有集成在一起。
漏洞利用
利用burp 的CSRF poc生成器生成poc。再将poc复制到自己的vps中，让用户进行访问该poc，就完成攻击。
因为要自动提交修改信息的请求，所以在burp中，还要勾选include auto-submit script，重新生成一个可以自动提交的poc。
防御措施
1. 增加token验证：
在http请求中以参数的形式加入一个随机产生的token，并在服务端来验证这个token值，如果token不存在或者不正确，则拒绝该请求。
2. 验证Referer字段：
验证http请求包referer字段值，该字段值记录了http请求的来源url，如果来源地址不一样，则说明该请求不合法，服务端拒绝该请求。这个防御方法攻击者可以进行绕过，攻击者自定义referer字段来绕过。
或者直接删除Referer字段值，也可绕过。
3. 对关键操作进行二次身份验证：
修改密码、重置密码等要进行二次身份验证，或者增加验证码验证。
4. 使用SameSite cookie
SameSite属性用来控制在跨站请求中是否包含cookie。通常与CSRF令牌一起使用。
如果该属性设置为SameSite=Strict; 则浏览器不会在来自其他站点的任何请求中包含cookie，这种方法虽然防御性最好，但是影响用户体验，用户访问第三方链接时，用显示未登录。需要再次登录才能正常与网站交互。
如果设置为SameSite=Lax; 浏览器会判断跨站请求是GET还是POST请求方式，如果是GET请求，则会给该请求包含cookie，如果是其他请求方法，会不包含cookie。并且还会判断该请求是否是用户的顶级导航（单击链接 ）,如果是其他请求，例如：由脚本发起的请求，则也会不包含cookie。
Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Strict; Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Lax;
5. CSRF令牌验证
在服务端应用程序生成，并包含在后续的http请求中，后面所有的http请求都需要包含该令牌，如果令牌丢失或者无效，服务端会拒绝该请求。
总结
加载全部内容