跨站请求伪造。
由于你访问同一个域名下的网站，都会带有相同的cookie，当你点击恶意链接的时候，恶意链接网站可能会利用获取到的你的cookie发送改密码的包，你就中招了。
克隆没空间，原理的话就是利用网站中获取的cookie发包。
这东西还得登录状态，而且还给你限制长度，气死我了。前两个终于搞完了，让我康康最后一个
核心原因是 攻击者无法跨域"主动获取"用户的有效Cookie，只能"被动利用"用户登录后浏览器自动携带的Cookie，具体逻辑如下：
- 浏览器的"同源策略"阻止了Cookie窃取
浏览器有严格的同源策略（同一域名、协议、端口），攻击者的恶意页面（如 attacker.com ）无法跨域读取用户在目标网站（如 target.com ）的Cookie（比如登录后的Session ID）。也就是说，攻击者根本"拿不到"用户的Cookie，只能等用户自己触发请求时，让浏览器自动带上。
- "登录状态"="浏览器存有有效Cookie"
用户登录目标网站后，网站会在用户浏览器中种下 有效Cookie（包含身份验证信息，如Session ID），且该Cookie仅在用户访问该网站时生效。若用户未登录，浏览器中没有这个有效Cookie，即使攻击者发包，请求也会因"缺乏身份凭证"被服务器拒绝，攻击无法成功。
- "自动发包"的前提是"Cookie已在浏览器中"
你说的"自动获取Cookie发包"，本质是：用户处于登录状态（浏览器里有有效Cookie）→ 点击恶意链接/访问恶意页面 → 浏览器在发送请求时，自动将目标网站的Cookie附加到请求头中（这是浏览器的默认行为，无需攻击者主动"获取"）→ 服务器验证Cookie有效，从而执行恶意操作。
简单说：不是攻击者"主动拿到Cookie"，而是用户登录后，浏览器里"自带了有效Cookie"，攻击者只是借用户的手，让这个Cookie"被动参与"了请求------没有登录状态，就没有这个"能让服务器认账"的有效Cookie，发包也没用。
在没登陆的时候，前端有个奇怪的TOKEN，对比发现和抓包的token一模一样，所以可以利用这一点。
我想问的是这个talking是不是算法根据请求自动刷新然后对比的
你说的"token"（令牌）的核心机制就是通过算法自动刷新并对比的，具体流程是这样的：
- 后端生成与刷新逻辑
后端会通过加密算法（如HMAC、基于用户信息+时间戳的哈希算法，或JWT的签名算法）生成动态token。
-
当用户发起请求（如登录、操作敏感接口）时，前端携带当前token，后端会：
-
对比验证：检查请求中的token是否与后端"预期的有效token"匹配（比如验证签名、有效期、用户身份关联等）。
-
自动刷新：验证通过后，后端会生成新的token，并返回给前端。下次请求时，前端需携带这个新token，以此循环，实现"每次请求自动刷新token"。
- 对比的核心作用
对比的目的是确保请求的合法性：
-
防止"旧token被重复使用"（比如攻击者截获旧token后伪造请求，后端发现token已过期或非最新，就会拒绝）。
-
验证token是否被篡改（比如通过签名算法，后端能判断token在传输过程中是否被修改）。
举个例子，登录场景中：
-
你登录后，后端给你一个tokenA；
-
你发起"修改密码"请求时，携带tokenA，后端验证tokenA有效后，返回新的tokenB；
-
下次请求需携带tokenB，后端再验证并生成tokenC......以此类推。
不安全的前端示意图。
最后一题是我们修改的一瞬间，它的token就在前端生成了，所以相当于在生成的时候我们可以用这个token为所欲为,前提是他在登录状态。