Csrf4

跨站请求伪造。

 由于你访问同一个域名下的网站，都会带有相同的cookie，当你点击恶意链接的时候，恶意链接网站可能会利用获取到的你的cookie发送改密码的包，你就中招了。

克隆没空间，原理的话就是利用网站中获取的cookie发包。

这东西还得登录状态，而且还给你限制长度，气死我了。前两个终于搞完了，让我康康最后一个

核心原因是 攻击者无法跨域“主动获取”用户的有效Cookie，只能“被动利用”用户登录后浏览器自动携带的Cookie，具体逻辑如下：

 

1. 浏览器的“同源策略”阻止了Cookie窃取

浏览器有严格的同源策略（同一域名、协议、端口），攻击者的恶意页面（如  attacker.com ）无法跨域读取用户在目标网站（如  target.com ）的Cookie（比如登录后的Session ID）。也就是说，攻击者根本“拿不到”用户的Cookie，只能等用户自己触发请求时，让浏览器自动带上。

2. “登录状态”=“浏览器存有有效Cookie”

用户登录目标网站后，网站会在用户浏览器中种下 有效Cookie（包含身份验证信息，如Session ID），且该Cookie仅在用户访问该网站时生效。若用户未登录，浏览器中没有这个有效Cookie，即使攻击者发包，请求也会因“缺乏身份凭证”被服务器拒绝，攻击无法成功。

3. “自动发包”的前提是“Cookie已在浏览器中”

你说的“自动获取Cookie发包”，本质是：用户处于登录状态（浏览器里有有效Cookie）→ 点击恶意链接/访问恶意页面 → 浏览器在发送请求时，自动将目标网站的Cookie附加到请求头中（这是浏览器的默认行为，无需攻击者主动“获取”）→ 服务器验证Cookie有效，从而执行恶意操作。

 

简单说：不是攻击者“主动拿到Cookie”，而是用户登录后，浏览器里“自带了有效Cookie”，攻击者只是借用户的手，让这个Cookie“被动参与”了请求——没有登录状态，就没有这个“能让服务器认账”的有效Cookie，发包也没用。

 

 

 在没登陆的时候，前端有个奇怪的TOKEN，对比发现和抓包的token一模一样，所以可以利用这一点。

我想问的是这个talking是不是算法根据请求自动刷新然后对比的

你说的“token”（令牌）的核心机制就是通过算法自动刷新并对比的，具体流程是这样的：

 

1. 后端生成与刷新逻辑

 

后端会通过加密算法（如HMAC、基于用户信息+时间戳的哈希算法，或JWT的签名算法）生成动态token。

 

- 当用户发起请求（如登录、操作敏感接口）时，前端携带当前token，后端会：

- 对比验证：检查请求中的token是否与后端“预期的有效token”匹配（比如验证签名、有效期、用户身份关联等）。

- 自动刷新：验证通过后，后端会生成新的token，并返回给前端。下次请求时，前端需携带这个新token，以此循环，实现“每次请求自动刷新token”。

 

2. 对比的核心作用

 

对比的目的是确保请求的合法性：

 

- 防止“旧token被重复使用”（比如攻击者截获旧token后伪造请求，后端发现token已过期或非最新，就会拒绝）。

- 验证token是否被篡改（比如通过签名算法，后端能判断token在传输过程中是否被修改）。

 

举个例子，登录场景中：

 

- 你登录后，后端给你一个tokenA；

- 你发起“修改密码”请求时，携带tokenA，后端验证tokenA有效后，返回新的tokenB；

- 下次请求需携带tokenB，后端再验证并生成tokenC……以此类推。

 

 不安全的前端示意图。

最后一题是我们修改的一瞬间，它的token就在前端生成了，所以相当于在生成的时候我们可以用这个token为所欲为,前提是他在登录状态。