小编点评

**CSRF攻击的原理：** 1. 用户在登录页面中输入用户名和密码。 2. 服务器接收用户的请求并验证输入的信息。 3. 如果验证成功，服务器生成一个CSRF token，并将其存储在用户的会话中。 4. 用户再次访问登录页面，并携带CSRF token。 5. 服务器验证用户的输入信息，如果验证成功，就允许用户登录。 **如何利用CSRF攻击生成 token：** 1. 用户在登录页面中输入用户名和密码。 2. 服务器接收用户的请求并验证输入的信息。 3. 如果验证成功，服务器生成一个CSRF token，并将其存储在用户的会话中。 4. 用户再次访问登录页面，并携带CSRF token。 5. 服务器验证用户的输入信息，如果验证成功，就允许用户登录。 6. 服务器将CSRF token存储在用户的会话中，并将其返回给前端页面。 **如何利用CSRF攻击修改用户信息：** 1. 用户在修改个人信息页面中输入新的信息。 2. 浏览器将这些信息提交给服务器。 3. 服务器接收用户的请求并验证输入的信息。 4. 如果验证成功，服务器将CSRF token存储在用户的会话中。 5. 服务器将CSRF token返回给前端页面。 6. 用户在修改用户信息页面中再次提交这些信息。 7. 服务器将CSRF token与 session 中的 token vergleichen。 8. 如果验证成功，就允许用户修改个人信息。 **注意：**CSRF攻击需要在用户的会话中存储 CSRF token，因此攻击者需要找到用户在会话中的 token。如果服务器验证的机制允许，攻击者可以轻松绕过验证。

正文

CSRF(get)

自己随便输点东西，回显登录失败，查看源码没发现什么

点开提示，登录进去看看

看到可以修改个人信息，我们把居住改成China,修改成功，没发现urlhttp://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php有变化

这次我们在submit时抓包看看

/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=111&add=China&email=lili%40pikachu.com&submit=submit

url上并没有携带认证信息，所以在用户登录状态下（其实这个链接里面是不包含用户名的，谁登录都无所谓，只要有人登录着就行，登录着的用户的信息就会被改成url提供的那些），试试改一改上面的链接，比如把性别改一改。payload：

pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=111&add=China&email=lili%40pikachu.com&submit=submit

修改成功

因为这关session时间特别短（大概不到1min）可能会导致用户登录之后后端检测结果是用户未登录

网上有很多短链接网站可以修饰url（百度搜索“短链接”就有很多）

先检查是否登录，如果没登录则跳转到登录页面。如果用户已登录，就不再做任何验证，直接将前端传来的数据下到数据库了（看代码这关还有sql注入漏洞呢）。

CSRF(post)

和上一题一样修改个人信息的时候用bp抓包

依旧没有认证信息，有CSRF漏洞。

但是这一关是post类型，URL不再显示修改参数，所以无法再使用上述办法（即通过URL来伪造请求）进行修改，

需要我们去构造一个html，这里我们直接用burp的工具生成

点击用浏览器测试

点击提交

直接跳转

CSRF token

登录之后，修改个人信息时bp抓包

发现有token字段

token验证原理
CSRF的主要问题是敏感操作的链接容易被伪造
每次请求，都增加一个随机码（需要够随机，不容易伪造），后台每次对随机码进行验证

网页接受从后台发过来的token,类型不可见。将其一并提交给后台进行验证。每次刷新，后台发送过来的token都不一样，起到了防止伪造的作用。

删了token行不行，显然是不行嘟

多抓几次包发现token是无规律的，在一定程度上防御了CSRF攻击

查看源代码

修改用户信息时，服务器会比较url中的token字段和session中的token字段，如果相同才能修改用户信息。

修改完用户信息之后，会用set_token()函数生成新的token，将其返回到html表单中并隐藏起来，以便下次用户修改信息时代入url。