CSRF跨站请求伪造漏洞分析与防御
作者：三亿人
CSRF
现在的网站都有利用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请求都需要包含该令牌，如果令牌丢失或者无效，服务端会拒绝该请求。
总结
到此这篇关于CSRF跨站请求伪造漏洞分析与防御的文章就介绍到这了,更多相关CSRF跨站请求伪造漏洞内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！