web漏洞：CRSF（跨站请求伪造）_crsf漏洞get

概述：在CRSF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。

与XSS漏洞的区别：CRSF是借用户的权限完成攻击，攻击者并没有拿到用户权限，而XSS是直接盗取到了用户的权限，然后实施破坏。

因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
对敏感信息的操作增加安全的token；
对敏感信息的操作增加安全的验证码；
对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。

下面开始举例（pikachu靶场）

CRSF(get)

首先随便登录上去，看到了有修改个人信息选项

随便修改一下，提交后发现页面url没有任何改变

用bp抓一下包，发现发送过去的GET请求中只存在前边的文件名和后边修改的相关信息，没有其他特定验证信息，猜测应该存在CRSF漏洞。

将GET请求复制，放包之后，再修改一下自己要修改的GET请求

可以写一个这样的html文件<script src=http:………………GET请求></script>构造一个假链接，当别人点击这个链接的时候便会触发GET请求，修改客户信息

然后在另一个站点打开文件，若原界面出现变化，则表示成功

CRSF（POST）

与上一关相同，发送的请求报文里依然没有任何验证信息，因此可以被利用，但显然，该关是POST请求，无法用上一关伪造URL的方法对其进行修改。

但抓包可以获得页面的其他有效信息，因此可以构造恶意站点，当用户在登陆状态下，误触表单，则会被修改信息

CRSF（token）

补充信息：为了防止这种攻击，网站会生成一个随机的token，并将其包含在每个请求中。服务器会验证这个token，以确保请求是合法的。

通常，CSRF token会被包含在表单中的隐藏字段中，或者通过HTTP头部传递。在服务器端，会验证这个token是否与服务器端存储的token匹配，如果匹配则认为请求是合法的。这样可以有效防止CSRF攻击。

有些会根据HOST和Referer是否同源来进行判断，但可以通过bp抓包修改Referer简单进行绕过，

token则不同，他是随机生成的，不易伪造，而且后台每次都会对随机码进行校验。

因此无法进行简单的CRSF攻破

Token的过程

1. 生成Token：

   • 在用户登录时，为每个会话生成一个唯一的token，并将其存储在用户的会话中。
   • 将该token发送给客户端，并在每个请求中包含该token。

2. 验证Token：

   • 在每个请求中，验证客户端发送的token是否与用户会话中存储的token匹配。
   • 如果token匹配，请求被视为有效；如果不匹配，则请求被视为CSRF攻击，并被拒绝。

3. 保护表单：

   • 对于提交表单的请求，确保表单中包含token字段，并且该字段的值与用户会话中存储的token相匹配。
   • 在处理表单提交时，验证token的有效性。

4. 过期处理：

   • 确保token有一定的有效期，以防止被重放攻击。一般来说，token的有效期应该比用户会话的有效期短。